Score:0

Nginx Reverse proxy can only find one site out of 3

lr flag

Update the behaviour of only being able to load one site at a time appears to be client side browser related - If I open all 3 sites in one browser window (one tab each) then we get the behaviour described below. If I use 3 separate browsers (I used Edge, Opera and Chrome) then all 3 sites load as expected. /Update

I have an Nginx reverse proxy setup to pass external traffic to one of 3 internal servers (Windows server 2019 running IIS 10) based on the url (this is for a testing environment). The nginx server and the webservers are all in the same vlan.

This has been working as intended until this morning when following a reboot of the web servers nginx can now only load one of the 3 sites at a time.

If I try to open all 3 sites, the first one loads as normal, the other 2 instantly give 404 errors. If I wait a few minutes and refresh one of the 404s it will load but the first site that was ok will now go to 404, same happens if the third site is loaded.

The Nginx config hasn't been changed and was loading all 3 sites at the same time prior to the reboots this morning.

I have tested the nginx conf with nginx -t which came back ok I have reloaded the nginx conf with sudo systemctl reload nginx - no change to behaviour I have restarted the nginx server - no change in behaviour

Browsing the web servers directly all 3 sites work as normal.

I can telnet on port 443 from nginx to all 3 web servers and vice versa.

Any suggestions as to why the behaviour may have changed?

The nginx config is as below (I have replaced the actual urls but the conf is otherwise unaltered):

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 1024;
        # multi_accept on;
}
#added by Ian to allow streaming
stream {
# To add additional websites and servers:
# Add the hostname and backend label to the map, then add the upstream blocks, as in the commented example below.
# ***Once you have updated the config you MUST reload nginx with the following command: sudo systemctl reload nginx
    map $ssl_preread_server_name $name {
   url.1.com                             GunServer;
   url.2.com                             CatServer;
   url.3.com                             BlueServer;
  # <hostname of website goes here>     <text label for the backend server goes here>;
  # example: mywebsite.com       myserver;
}

# Then create a new upstream block using the label set above as shown below
# upstream myserver {
        # server <IP:port>;
#}

upstream GunServer {
        server 10.25.2.12:443;
}

upstream CatServer {
        server 10.25.2.13:443;
}

upstream BlueServer {
        server 10.25.2.11:443;
}

server {
    listen      443;
    proxy_pass  $name;
    ssl_preread on;
}
}

# all settings below this line were from nginx example conf
in flag
If you get 404 errors nginx can reach the backend servers. Check the backend servers instead of nginx. Start with the server logs.
Ian Straton avatar
lr flag
The thing is it can reach all three of the servers, just not all at the same time. Whichever URL you load first loads fine and the other 2 give 404 instantly. At the same time browsing the 3 servers directly all 3 sites are working normally, all three can connect with the nginx server on port 443
in flag
When was the last time nginx was updated? Which version is it now, which version was it before? (Whole package version) check the log files of your package manager.
Michael Hampton avatar
cz flag
Are your backend servers using HTTP/2?
Ian Straton avatar
lr flag
Nginx version is 1.18.0, there has been no in place updates since initial install (this was a new install for this test environment). Sites are running HTTP 2
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.