CODEWITHSUNDEEP
nginxnginx-location
bjnsn
bjnsn

Reputation: 2830

Subdomain routing behaves differently than domain in Nginx

I'm running into an issue where pointing a domain example.com returns a 404 while a subdomain stage.example.com pointing to the same resource behaves as expected. I'm running this with Nginx 1.10.3 on Ubuntu.

Here is the configuration file for this server (/etc/nginx/sites-available/example.com symlinked into /etc/nginx/sites-enabled/example.com).

server {
    # Root directory
    root /home/username/example.com;

    # Index
    index index.php index.html index.htm index.nginx-debian.html;

    # Server name(s)
    server_name stage.example.com example.com www.example.com;

    # Create access and error logs in /var/log/nginx
    # access_log /var/log/nginx/example_com-access_log;
    # error_log /var/log/nginx/example_com-error_log info;


    # Generic location
    location / {
            # First attempt to serve request as file, the fall back
            # to allow hashless routing
            try_files $uri $uri/ /index.php;
    }

    location ~ \.json$ {
            # Patching existing loading of JSON via post
            # To allow POST on static pages
            error_page  405     =200 $uri;
    }

    # Pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000

    location ~ \.php$ {
            include snippets/fastcgi-php.conf;

             # With php7.0-fpm:
            fastcgi_pass unix:/run/php/php7.0-fpm.sock;

            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include fastcgi_params;
    }

    # route to headless use of wordpress
    location /content/ {
            try_files $uri $uri/ /content/index.php$is_args$args;
    }

    # route to api in headless wordpress
    location ~ ^/api/ {
        # if permalinks not enabled
        rewrite ^/api/(.*?)$ /?rest_route=/$1 last;
    }

    # Deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    location ~ /\.ht {
            deny all;
    }
}

Thoughts?

Upvotes: 0

Views: 386

Answers (1)

bjnsn
bjnsn

Reputation: 2830

This turned out to be an issue with having IPv6 not handled properly in my configuration. Updating my server configuration like this solved it:

server {
    # Port(s)
    listen                          80 default_server;
    listen                          [::]:80 ipv6only=on;

    # Remainder of config identical to sample provided
}

This is what led me to the solution: https://www.digitalocean.com/community/questions/ipv6-connectivity-issues-with-nginx

Upvotes: 1

Related Questions