Resolving 502 Bad Gateway Errors in Nginx Reverse Proxy Caused by Missing SNI Configuration

When using Nginx as a reverse proxy for an HTTPS backend, the author encountered intermittent 502 Bad Gateway responses even though direct curl requests succeeded. The error log revealed an SSL handshake failure: SSL_do_handshake() failed (SSL: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:SSL alert number 80) , indicating that the upstream server did not receive the required SNI (Server Name Indication) information.

Investigation showed that Nginx’s default proxy configuration does not include the proxy_ssl_server_name directive, so the host name is not passed during the TLS handshake. Without SNI, many HTTPS servers cannot select the correct certificate, leading to the 502 error.

The fix is to enable SNI forwarding and adjust the proxy settings. A working configuration example is:

location / {
    proxy_ssl_server_name on;
    proxy_pass https://$http_host$request_uri;
    proxy_ssl_verify off;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $http_host;
    proxy_set_header cookie $http_cookie;
    proxy_set_header Proxy-Connection "";
    proxy_http_version 1.1;
}

Key points of the solution:

Set proxy_ssl_server_name on to forward the original host name to the upstream TLS layer.

Use proxy_pass https://$http_host$request_uri so the request is sent over HTTPS.

Disable certificate verification with proxy_ssl_verify off if the upstream uses self‑signed certificates.

Pass necessary headers ( Host , X-Real-IP , cookie ) to preserve client context.

Reload Nginx after configuration changes, avoiding a simple reload on a socket that is still in use.

If SNI is not configured, the upstream server will return a 502 error because it cannot complete the TLS handshake, which is why enabling the directive resolves the issue.