The core problem you're having here is that the pgadmin4
backend is highly sensitive to the URIs being passed to it. It's also statically configured, so we can't add a 'prefix' to the URIs for how to process it.
Therefore, since we can't alter the pgadmin4
'paths' to serve in the frontend, we have to take the much more evil path of serving this as a subdomain - pgadmin.domain.tld
with corresponding SSL certificates.
The nginx configuration bits would be as follows:
server {
listen 80;
server_name pgadmin.domain.tld;
# Redirect any non-HTTPS requests to HTTPS (aka: Force HTTPS)
return 301 https://pgadmin.domain.tld$request_uri;
}
server {
listen 443 ssl;
# SSL Config goes here, but the bare minimum is this:
ssl_certificate /path/to/ssl/cert/with/fullchains.pem;
ssl_certificate_key /path/to/privkey.pem;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_pass http://127.0.0.1:5050;
}
}
This presupposes you already have, or know how to get, the SSL certificates to put into place in the configurations. However that's outside the scope of the question.
This is, unfortunately, the most simple solution to getting pgadmin4 to work with a 'reverse proxy', but you won't be able to easily do it within a location block on an existing site. It's been requested for a couple years but never developed.
Just make sure you also harden the server and close off ports that shouldn't be accessed directly (like the pgadmin4
port from the 'outside'). Otherwise the reverse proxy component can be circumvented easily.