2

My nginx.conf is pretty much the default conf with a fallback server block added:

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 768;
    # multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip on;
    gzip_disable "msie6";

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##

    # fallback-server if host is not known
    server {
        listen 80 default_server;
        server_name _;
        return 404;
    }

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

The folder /etc/nginx/conf.d/ is empty.

Sites-enabled contains a symlink to the following configuration file:

server {  
    listen 80;
    server_name www.subdomain.example.com subdomain.example.com;
    root /var/www/subdomain;
    index index.html;   

    location / {
        try_files $uri $uri/ =404;
    }
}

The problem is that nginx is always defaulting to the fallback server, even for requests with subdomain.example.com.

Removing the fallback server results in the subdomain server serving all requests which is, as far as I understand, default nginx behaviour.

This is a test setup I like to extend to serve multiple subdomains. Adding a second server for a second subdomain also results in just one server serving all requests.

nginx access.log excerpt (2 recent requests):

XX.XXX.XXX.XXX - - [17/Aug/2017:18:13:32 +0200] "GET / HTTP/1.1" 404 152 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_3 like Mac OS X) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.0 Mobile/14G60 Safari/602.1"
XX.XXX.XXX.XXX - - [17/Aug/2017:18:14:17 +0200] "GET / HTTP/1.1" 404 209 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"

nginx error.log excerpt (last 2 entries)

2017/08/17 16:11:53 [notice] 3829#3829: signal process started
2017/08/17 16:32:10 [notice] 3914#3914: signal process started

My questions:

  1. What am I missing here?
  2. Is it possible that my subdomains are misconfigured such as that the wrong host is submitted? However checking the request headers host entry with Chrome shows the correct subdomain (subdomain.example.com) and doing a dig on it also returns an answer section.

Of course I did some research on this but was not able to figure out what is wrong:

  • This question -> wrong listening directive: checked.
  • This question -> misconfigured subdomain: checked (although this might be the problem and I do not know how to further verify this).
  • This question -> Server block not in sites-enabled: checked.
  • This question -> No server_name in server block: checked.

Update

Results of nginx -t

nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
2017/08/18 08:03:51 [warn] 6200#6200: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
2017/08/18 08:03:51 [emerg] 6200#6200: open() "/run/nginx.pid" failed (13: Permission denied)
nginx: configuration file /etc/nginx/nginx.conf test failed

Results of sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Update 2

Not sure if this is relevant. After removing all server blocks requests with subdomain.example.com result in a 503 Service Temporarily Unavailable site. Requests to XX.XXX.XXX.XXX:80 result in the browser telling me it's unable to open the page.

In addition, I tried serving different locations in the subdomains server block, which worked. However, I misconfigured a location using root instead of alias and this returned the default nginx page in /var/www/html, which is nowhere set as either root or alias directory. How is this possible?

fr3d-5
  • 141
  • 4
  • are you sure it isn't working change `try_files $uri $uri/ =404;` to `try_files $uri $uri/ =403;` and retest for the response – Drifter104 Aug 17 '17 at 16:32
  • changed that and I still get the 404 page of the default server. The subdomain server is serving index.html correctly once the fallback is removed, so it might not be a location issue. – fr3d-5 Aug 17 '17 at 16:39
  • Are you sure nginx is reading that file when loading? It might not be readable by the nginx process, especially if you have SELinux enabled. – Pak Aug 17 '17 at 18:13
  • As a test, move the default_server ("fallback server") into a configuration file set up the same way as your subdomain file - ie in the sites-enabled with a symlink. Try with both symlinks there, and with each one individually. It may help narrow down the problem. – Tim Aug 17 '17 at 19:13
  • I am pretty sure the configs in sites-enabled are read. I did the following tests: 1) Move the fallback to sites-available and symlink to sites-enabled as well as changing 404 to 403 for testing -> successfully getting 403 response. 2) Removing fallback alltogether -> getting subdomain.example.com response as configured. – fr3d-5 Aug 17 '17 at 21:27
  • Since all subdomains I am using as well as the servers IP address itself always return what seems to be the servers default response (either default server or the first available), I assume there must be an issue with the server recognizing the host in the header. Any way I can investigate this further? – fr3d-5 Aug 17 '17 at 21:52
  • Check with `nginx -T` that the configuration is included. – Tero Kilkanen Aug 17 '17 at 22:52
  • See update above. – fr3d-5 Aug 18 '17 at 06:07
  • It seems I misconfigured the subdomains, as I expected. They were configured as redirects rather than setting the severs IP address as A-record. As an answer to this question maybe someone could describe how to thoroughly check for this. – fr3d-5 Aug 20 '17 at 08:38

0 Answers0