I found to get this working there are several things which need to be checked:
- web server logs
- postgresql logs
- browser console outputs
If your web server (unless you are accessing pgadmin4 port directly) is proxying the correct port with all correct options. I use nginx and this is working fine with:
server
{
server_name db.serv1;
listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/myserver.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/myserver.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/myserver.com/fullchain.pem;
location /
{
proxy_pass http://127.0.0.1:5050;
proxy_http_version 1.1;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
Make sure that you X-Frame-Options are not set to "DENY". This is sometimes set on browsers as a click jacking prevention. Otherwise it will block the frame in which the Query Tools window opens in. You can check this with your web tools "inspection" or open up your console output for your browser.
The error message I got was somewhere along the lines of "X-Frame-Options set to 'DENY'" and the browser page displayed "FAILED TO CONNECT".
If you have differences in "localhost" versus "127.0.0.1" or similar types of differences between your permissions settings and connection options, this can create a conflict. Ensure that you server connection parameters you specify in pgadmin4 fit the connection settings in pga_hba.conf (localhost is not always the same as 127.0.0.1). They should be exact and that will eliminate the variable of permissions versus connection type.
I found that sometimes specifying localhost versus 127.0.0.1, that localhost in some instances connects through the Unix-domain socket connection rather than tcp.