A little experimentation has been showing that for my usage, nginx makes for a great caching proxy. So good that I wondered what might happen if I started chaining the servers together (proxy A —> proxy B —> nginx server C, all over HTTPS/SSL).

Answer was… 502 Bad Gateway errors.

I’d set it up and then used Integrity by PeacockMedia (free/donationware on the Mac App Store) to test out the site. If you haven’t heard of it before, Integrity is something of a broken-link-checker for macOS – quick and dead easy to use. Anyway… it immediately threw up a bunch of 502 Errors for the HTTPS versions of the site.

I checked it out by trying to manually load up a page over HTTPS in a web browser, and sure enough, 502 error.

——

Turned out, my problem was that I had just changed from a simple proxy_pass https://123.45.67.89; in the location to the whole “upstream backend” thing, with something like this:

upstream backend {
     server 123.45.67.89;
     server 12.34.56.789 backup;
}
server {
     listen 443;
     server_name example.com;
     location / {
         proxy_pass https://backend;
     }
}
 

That doesn’t quite work, and the reason turned out to be that you need to specify the port in the “upstream backend” section if it isn’t port 80. It’s not enough that the proxy_pass line started with https – I also had to explicitly tell it to use port 443.

So the working version was of course as follows:

upstream backend-ssl {
     server 123.45.67.89:443;
     server 12.34.56.789:443 backup;
}
server {
     listen 443;
     server_name example.com;
     location / {
         proxy_pass https://backend-ssl;
     }
}
 

That’s not to say it’s the only cause of 502 errors when dealing with nginx’s caching proxy (timeouts are another common cause from what I understand). And if you’ve recently upgraded PHP, you may want to check out PHP 7.0 upgrade and “502 Bad Gateway”.

But if you’ve just implemented the upstream bit, it’s worth checking to see if you have the same issue.

If not, it’s worth taking a peek at your error log to help narrow things down. It’s usually found in your logs directory: if using Ubuntu /var/log/nginx/error.log is where it’s often at.