After modifying TLS settings and working with a WordPress API plugin, my production server suddenly started serving the default Nginx page from /usr/share/nginx/html instead of the WordPress installation at /var/www/html/smokingquartz/. The error logs clearly show failed attempts to access WordPress files in the wrong directory:

2018/07/13 19:37:01 [error] 4593#4593: *206 open() "/usr/share/nginx/html/wp-admin/admin-ajax.php" failed (2: No such file or directory)

My sites-available configuration explicitly defines the correct root path:

server {
    listen 80 default_server;
    server_name smokingquartz.com www.smokingquartz.com;
    root /var/www/html/smokingquartz/;
    # ... other configs ...
}

Yet Nginx ignores this and uses the default path. This suggests either:

• A configuration inheritance issue
• SSL configuration conflicts
• Symbolic link problems in sites-enabled

First, I verified the configuration syntax:

sudo nginx -t

Then checked for conflicting default configurations:

grep -r "root /usr/share/nginx/html" /etc/nginx/

The issue stemmed from the SSL configuration block at the bottom of my site configuration. Notice how it's defined as a separate server block without inheriting the root path:

server{
    listen [::]:443 ssl ipv6only=on;
    listen 443 ssl;
    # SSL certificates but NO root path!
}

I merged the SSL configuration into the main server block:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    listen 443 ssl;
    listen [::]:443 ssl;
    
    server_name smokingquartz.com www.smokingquartz.com;
    root /var/www/html/smokingquartz/;
    
    # SSL configuration
    ssl_certificate /etc/letsencrypt/live/smokingquartz.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/smokingquartz.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
    
    # ... rest of configuration ...
}

After fixing the configuration, I:

1. Verified symbolic links in sites-enabled:

   ls -l /etc/nginx/sites-enabled

2. Checked for default server blocks:

   grep -r "default_server" /etc/nginx/

3. Confirmed PHP-FPM socket permissions:

   ls -l /run/php/php7.2-fpm.sock

To avoid similar issues:

• Always use nginx -t after configuration changes
• Maintain consistent server block structure
• Use includes for common SSL configurations
• Implement configuration version control

While working on SSL/TLS configuration changes for a WordPress site, I encountered a puzzling issue where Nginx suddenly started serving content from /usr/share/nginx/html instead of the configured /var/www/html/smokingquartz/ directory. The error logs showed repeated attempts to access WordPress files in the wrong location:

2018/07/13 19:37:01 [error] 4593#4593: *206 open() "/usr/share/nginx/html/wp-admin/admin-ajax.php" failed (2: No such file or directory)

First, I verified my site configuration in /etc/nginx/sites-available was correctly pointing to the right directory:

server {
    listen 80 default_server;
    server_name smokingquartz.com www.smokingquartz.com;
    root /var/www/html/smokingquartz/;
    # ... rest of config ...
}

The configuration appeared correct when compared with backups, suggesting the issue wasn't with the file content itself.

To diagnose the root cause, I performed these checks:

1. Confirmed symbolic links in sites-enabled were valid
2. Checked for duplicate server blocks in nginx.conf
3. Verified no default server declarations were overriding my config
4. Tested configuration with nginx -t
5. Restarted Nginx with systemctl restart nginx

The breakthrough came when examining the SSL configuration. The Certbot-generated SSL block at the bottom of my config file was missing critical components:

server{
    listen [::]:443 ssl ipv6only=on;
    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/smokingquartz.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/smokingquartz.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
    # MISSING server_name and root directives!
}

The fix required merging the SSL configuration with the main server block:

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    
    server_name smokingquartz.com www.smokingquartz.com;
    root /var/www/html/smokingquartz/;
    
    ssl_certificate /etc/letsencrypt/live/smokingquartz.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/smokingquartz.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
    
    # ... rest of original configuration ...
}

• Always include complete configuration in both HTTP and HTTPS server blocks
• Use nginx -T to view the entire parsed configuration
• Check for default_server declarations that might override your config
• When using Certbot, verify it hasn't created separate incomplete blocks

After implementing this fix and reloading Nginx, the site properly served content from the correct directory, resolving both the default page issue and maintaining proper SSL configuration.