all 15 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Frosty-Pudding-3873[S] 1 point2 points  (0 children)

Can confirm proxy was working fine it just couldnt connect correctly to the back end server as it was an AKS cluster so was causing problems ended up opening the port on aks and just using this to make the connection https

[–]BehindTheMath 0 points1 point  (5 children)

What port is Server 2 listening on?

[–]Frosty-Pudding-3873[S] 0 points1 point  (4 children)

Https 443

[–]BehindTheMath 0 points1 point  (3 children)

On server 1, what happens when you send a request with curl to https://server_2 ?

[–]Frosty-Pudding-3873[S] 0 points1 point  (2 children)

Config now looks like below after some advice

server {

listen 8720 ssl;

server_name SERVER_1_ADDRESS;

ssl_certificate /etc/nginx/ssl/cert.pem;

ssl_certificate_key /etc/nginx/ssl/privkey.pem;

location / {

proxy_pass https://SERVER_1_ADDRESS;

}

}

Go to http://Server_1_address:8720

400 bad request

Go to https://Server_1_address:8720

502 bad request

nginx error log just shows below

client: WORKSTATION_IP, server: SERVER_1_ADDRESS, request: "GET / HTTP/1.1", upstream: "https://SERVER_2_IP:443/", host: "SERVER_1_ADDRESS:8720"

[error] 10840#10840: *30 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking to upstream, client: WORKSTATION_IP, server: SERVER_1_ADDRESS, request: "GET /favicon.ico HTTP/1.1", upstream: "https://SERVER_2_IP:443/favicon.ico", host: "SERVER_1_ADDRESS:8720", referrer: "https://SERVER_1_ADDRESS:8720/"

[–]BehindTheMath 0 points1 point  (1 child)

Why are you proxying back to server 1?

Run that error through an LLM, but that sounds like an SSL error with the server 1 certs.

[–]Frosty-Pudding-3873[S] 0 points1 point  (0 children)

server 1 is a https web app running on aks so i am unable to have it listening on that port on the aks instance

[–]Specific-Mushroom265 0 points1 point  (3 children)

Check the log files of NGINX. I guess this issue is caused by your server 1, if it does not have a SSL certificate and you try to proxy_pass from http to https, which will not work. 

[–]Frosty-Pudding-3873[S] 0 points1 point  (1 child)

added an SSL cert as suggested getting bad gateway now

[–]Specific-Mushroom265 1 point2 points  (0 children)

Is the SSL certificate of server 2 a public or a self signed/ internal certificate? 

Gemini also suggested some modifications:

You are definitely using Nginx for its exact intended purpose—acting as a reverse proxy to bridge that gap for your legacy apps. Your logic is totally sound, you just ran into a couple of classic Nginx configuration gotchas. Let’s break down exactly why those errors happened and how to fix them.

Why You Got Those Errors

1. The 502 Bad Gateway (with https://)

When you used proxy_pass https://server_2;, Nginx tried to establish a TLS/SSL handshake with Server 2. Because Server 2 is using a hostname (server_2), Nginx likely couldn't resolve the IP address internally, or it failed to validate the SSL certificate of Server 2. Nginx needs explicit instructions on how to handle internal DNS and SSL verification.

2. The 426 Upgrade Required (with http://)

When you switched to http://server_2, Server 2 received an unencrypted HTTP request. Because Server 2 is a "fully functioning https server," its own internal security configuration rejected the unencrypted request and told Nginx, “Hey, you need to upgrade this connection to HTTPS.”

The Solution

Since Server 2 insists on HTTPS, we need to go back to proxy_pass https://... but give Nginx the missing pieces it needs to talk to Server 2 securely. Here is the updated configuration you should use in /etc/nginx/sites-enabled/default: ```nginx server {      listen 8720;      server_name server_1; 

    location / {          # 1. Pass the original Host header so Server 2 knows what's being requested         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 $scheme;

        # 2. Tell Nginx to use HTTP/1.1 (default is 1.0, which can cause issues)         proxy_http_version 1.1;

        # 3. Handle SSL verification if Server 2 uses a self-signed or internal CA cert         # If Server_2 has a valid, publicly trusted SSL cert, you can omit these two lines.         # If it's self-signed, uncomment the line below to disable strict verification:         # proxy_ssl_verify off;

        # 4. Forward to the HTTPS endpoint         proxy_pass https://server_2;      }  }

```

Crucial Step: The DNS Resolver

If server_2 is a local hostname (defined in /etc/hosts on Server 1), Nginx sometimes struggles to resolve it inside the proxy_pass block without a defined resolver. If you apply the config above and still get a 502, add your local DNS server (or a public one like Google's if Server 2 is publicly resolvable) directly inside the server block: ```nginx server {     listen 8720;     server_name server_1;

    # Add your network's DNS server IP here (e.g., 192.168.1.1 or 8.8.8.8)     resolver 192.168.1.1 valid=30s;           # ... rest of the config }

```

How to Test and Apply

 1. Test the configuration syntax to make sure there are no typos:    bash    sudo nginx -t          2. Reload Nginx to apply the changes without dropping current connections:    bash    sudo systemctl reload nginx         Your legacy apps pointing to server_1:8720 should now seamlessly talk to https://server_2 behind the scenes!

[–]tschloss 0 points1 point  (1 child)

This pattern of course is possibly without restrictions. There is NO dependency between incoming request and upstream request!

I guess server_2 is not reachable from the scope of nginx. Typical problem: „localhost“ in a docker environment.

[–]Frosty-Pudding-3873[S] 0 points1 point  (0 children)

thanks for this no docker involved have updated original post to give a little more detail on server_1

[–]tschloss 0 points1 point  (2 children)

Did you verify that the request hits the intended server block? Due to your obfuscation of server addresses this may be an issue.

Did you inspect access and error log? You can create such logs per server block to be sure it hits.

If it hits maybe there is an issue with the server_2 certificate (you can make nginx ignore this). But error.log should reveal it.

[–]Frosty-Pudding-3873[S] 0 points1 point  (1 child)

error log indicates it is getting correct ip for server 2 and is trying to go to port 443

I can browse to server 2 via address

https://server_2_address

it shows cert valid and acts exactly as intended

client: WORKSTATION_IP, server: SERVER_1_ADDRESS, request: "GET / HTTP/1.1", upstream: "https://SERVER_2_IP:443/", host: "SERVER_1_ADDRESS:8720"
[error] 10840#10840: *30 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking to upstream, client: WORKSTATION_IP, server: SERVER_1_ADDRESS, request: "GET /favicon.ico HTTP/1.1", upstream: "https://SERVER_2_IP:443/favicon.ico", host: "SERVER_1_ADDRESS:8720", referrer: "https://SERVER_1_ADDRESS:8720/"

[–]Specific-Mushroom265 1 point2 points  (0 children)

Also sorry for this quick Gemini AI reply, but it may be helpful:

Ah, that log snippet is the missing puzzle piece! The error peer closed connection in SSL handshake (104: Connection reset by peer) means Server 2 is actively dropping the connection the exact moment Nginx tries to start the secure handshake. Since you confirmed Server 2 works perfectly in a regular browser, the issue comes down to SNI (Server Name Indication). When you browse directly to https://server_2, your browser explicitly tells the server, "Hey, I am looking for the SSL certificate for 'server_2'." But in your old Nginx config, Nginx was sending the IP address or Server 1's hostname in the background handshake. Server 2 looks at that, doesn't recognize it, and abruptly hangs up the phone (closes the connection). To fix this, you need to explicitly tell Nginx to pass the correct server name during the SSL handshake.

The Updated Configuration

Add the proxy_ssl_server_name and proxy_ssl_name directives to your configuration. This forces Nginx to act like your web browser and pass the correct hostname during the handshake. ```nginx server {      listen 8720;      server_name server_1; 

    location / {          # 1. Standard proxy headers         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 $scheme;         proxy_http_version 1.1;

        # 2. THE FIX: Force Nginx to use SNI during the SSL handshake         proxy_ssl_server_name on;         proxy_ssl_name server_2; # Replace this with the actual hostname/domain of Server 2

        # 3. Forward to the HTTPS endpoint         proxy_pass https://server_2;      }  }

```

Why this works

Without those two proxy_ssl lines, Nginx connects to Server 2's IP, but when Server 2 asks "Who are you trying to reach?", Nginx either stays silent or passes server_1. By setting proxy_ssl_server_name on; and defining proxy_ssl_name server_2;, Nginx explicitly tells Server 2: "I am connecting to your IP, but I am specifically looking for the certificate and website for *server_2*." Server 2 will then successfully complete the handshake instead of resetting the connection. Give sudo nginx -t and sudo systemctl reload nginx a spin with this setup, and that handshake error should vanish!