One virtual host always masked by others

Troubleshooting
, ,
1

I have a server providing 3 virtual hosts, peertube, books (bookwyrm) and snikket, running Debian Bookworm (nginx 1.22.1). The configurations are in /etc/nginx/sites-available and the active ones linked to from /etc/nginx/sites-enabled. All are effectively reverse proxies and running as close as I can get to the provided configurations for the respective services.

Peertube and books work happily together, and I have no configuration errors reported from snikket, but when I browse to it I get the site, and SSL certificate for books, and if I disable that then I get the site and certificate for peertube. If that too is disabled then Snikket works perfectly.

cat 01-snikket.conf 
server {
  # Accept HTTP connections
#  listen 80;
  listen 80 default_server;
  listen [::]:80;

  server_name snikket.paladyn.org
   groups.snikket.paladyn.org
   share.snikket.paladyn.org;

  error_log /var/log/nginx/snikket-error.log;
  access_log /var/log/nginx/snikket-access.log combined;

  location / {
      proxy_pass http://localhost:5080/;
      proxy_set_header      Host              $host;
      proxy_set_header      X-Forwarded-For   $proxy_add_x_forwarded_for;

      # This is the maximum size of uploaded files in Snikket
      client_max_body_size 104857616; # 100MB + 16 bytes
  }
}

server {
  # Accept HTTPS connections
	#  listen [::]:443 ssl ipv6only=on;
	#  listen 443 ssl;
 listen 443 ssl default_server;
  ssl_certificate /etc/letsencrypt/live/snikket.paladyn.org/fullchain.pem; # managed by Certbot
  ssl_certificate_key /etc/letsencrypt/live/snikket.paladyn.org/privkey.pem; # managed by Certbot
  include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
   ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


  server_name snikket.paladyn.org
   groups.snikket.paladyn.org
   share.snikket.paladyn.org;

  location / {
      proxy_pass https://localhost:5443/;
      proxy_set_header      Host              $host;
      proxy_set_header      X-Forwarded-For   $proxy_add_x_forwarded_for;
      # REMOVE THIS IF YOU CHANGE `localhost` TO ANYTHING ELSE ABOVE
      proxy_ssl_verify      off;
      proxy_set_header      X-Forwarded-Proto https;
      proxy_ssl_server_name on;

      # This is the maximum size of uploaded files in Snikket
      client_max_body_size 104857616; # 100MB + 16 bytes

      # For BOSH and WebSockets
      proxy_set_header Connection $http_connection;
      proxy_set_header Upgrade $http_upgrade;
      proxy_read_timeout 900s;

  }
}

I can’t see anything in this configuration which would cause it to be ignored unless the other sites are disabled. Happy to post the other site configurations if that would help, though they are basically taking the respective example configurations and change the domain names.

2

HI @JohnLines , are you using nginx-ingress or just nginx?

3

I am using just nginx - from the Debian package - I have other servers using nginx with multiple virtual hosts and have not encountered this before.

4

thanks, I’ve updated the tags so it gets proper attention

5

I found the solution, or hints to it at https://vpsie.com/knowledge-base/when-is-nginx-serving-wrong-virtual-host-vhost-ssl-certificate/
I listen statements like:

/etc/nginx/sites-enabled$ grep -i listen *

01-snikket.conf:  listen 80 default_server;
01-snikket.conf:  listen [::]:80;
01-snikket.conf: listen 443 ssl default_server;
02-books.conf:    listen [::]:443 ssl ipv6only=on; # managed by Certbot
02-books.conf:    listen 443 ssl; # managed by Certbot
02-books.conf:    listen [::]:80;
02-books.conf:    listen 80;
03-peertube.conf:  listen 80;
03-peertube.conf:  listen [::]:80;
03-peertube.conf:  listen 443 ssl http2;
03-peertube.conf:  listen [::]:443 ssl http2;

Removing all the ‘[::]’ from all sites seems to have fixed the problem - and they are now all responding as I would expect.

It might be good to have a warning for this case, where some sites specify a wildcard host and others do not to the ‘nginx -t’ output as specifying wildcard host names, along with the port to listen to seems quite common in distributed sample configurations, and the suggested listen statement may vary according to the version of NGINX for which the configuration was first written.