Problem Explanation

You've followed all the steps to deploy your web application behind Nginx, configured your server blocks, and pointed your domain to the server. Yet, when you navigate to your website, instead of seeing your carefully crafted application, you're greeted by the generic Nginx default "Welcome to nginx!" page. This indicates that Nginx is successfully running, but it's not routing traffic to your intended application or is falling back to its default behavior. This is a common stumbling block for developers and system administrators, especially when setting up new Nginx instances or modifying existing configurations.

Why It Happens

The Nginx default "Welcome" page typically appears when Nginx cannot find a specific server block (virtual host) configuration that matches the incoming request, or when the default server block is incorrectly configured or prioritized. Nginx processes incoming requests by matching them against defined server blocks in its configuration files. If no server block's server_name directive matches the Host header of the incoming request, or if the server_name is not properly defined (e.g., a typo, incorrect domain, or missing wildcard), Nginx falls back to the first server block it encounters in its configuration that is designated as the default server. If this default server block is configured to serve Nginx's default welcome page (often located at /usr/share/nginx/html/index.html or a similar path), that's what you'll see.

Step-by-Step Solution

Here's a systematic approach to diagnose and fix Nginx serving the default welcome page:

## Step 1: Verify Nginx is Running and Accessible

Before diving into configuration, ensure Nginx is active and listening on the correct ports.

Check Nginx Service Status:
```
sudo systemctl status nginx
```
Look for active (running) in the output. If it's not running, start it:
```
sudo systemctl start nginx
```
And enable it to start on boot:
```
sudo systemctl enable nginx
```
Check Listening Ports:
```
sudo netstat -tulnp | grep nginx
```
You should see Nginx listening on port 80 (HTTP) and/or 443 (HTTPS). If not, there's a fundamental issue with your Nginx installation or its startup.

## Step 2: Locate and Inspect Your Nginx Configuration Files

Nginx configurations are typically stored in /etc/nginx/. The main configuration file is nginx.conf, which often includes configurations from subdirectories like sites-available/ and sites-enabled/.

Identify Configuration Directory: The primary configuration directory is usually /etc/nginx/.
Check nginx.conf: Open the main configuration file:
```
sudo nano /etc/nginx/nginx.conf
```
Pay attention to the http block and any include directives that point to other configuration files, especially for server blocks.
Examine sites-available and sites-enabled: These directories are standard for managing virtual hosts.
- sites-available/: Contains all your potential server block configurations.
- sites-enabled/: Contains symbolic links to the server blocks you want to activate.

## Step 3: Verify Your Application's Server Block Configuration

This is the most critical step. Your application's configuration should be defined within a server block in one of the files within sites-available/ (and then symlinked to sites-enabled/).

Open Your Application's Config File: Navigate to sites-available/ and open the file corresponding to your application (e.g., your_domain.conf).
```
sudo nano /etc/nginx/sites-available/your_domain.conf
```

Ensure Correct server Block Structure: Your configuration should look something like this:

server {
    listen 80;
    listen [::]:80;

    server_name your_domain.com www.your_domain.com; # <-- Crucial line

    root /var/www/your_application/public; # Or your application's web root
    index index.html index.htm index.php; # Adjust if your app uses a different index file

    location / {
        try_files $uri $uri/ =404; # Or your app's routing rules (e.g., for frameworks)
    }

    # ... other directives for your application (PHP-FPM, proxy_pass, etc.)
}

Check server_name: Ensure the server_name directive correctly lists your domain name(s) exactly as users will type them. Typos are a common cause of this issue. If you are testing locally without a proper DNS setup, you might need to edit your local hosts file or use an IP address.
Check root Directive: Verify that the root directive points to the correct directory where your application's index file (e.g., index.html, index.php) resides.

## Step 4: Ensure Your Server Block is Enabled

If your configuration file exists in sites-available/ but isn't being used, it's likely not symlinked into sites-enabled/.

Check for Symlink:
```
ls -l /etc/nginx/sites-enabled/
```
You should see a symbolic link from a file in sites-available/ to sites-enabled/ for your application.
Create Symlink (if missing): If the symlink is absent, create it:
```
sudo ln -s /etc/nginx/sites-available/your_domain.conf /etc/nginx/sites-enabled/
```
Important: If a default configuration file exists in sites-enabled/, it might be overriding your application's configuration. You may need to remove it:
```
sudo rm /etc/nginx/sites-enabled/default
```
(Be cautious with this step and ensure you understand which default file you are removing.)

## Step 5: Test and Reload Nginx Configuration

After making any changes, always test your Nginx configuration for syntax errors and then reload Nginx to apply them.

Test Configuration:
```
sudo nginx -t
```
This command checks for syntax errors and the validity of your configuration. If it reports errors, fix them before proceeding.
Reload Nginx:
```
sudo systemctl reload nginx
```
A reload applies configuration changes without dropping active connections. If you encounter issues or made significant changes, a restart might be necessary:
```
sudo systemctl restart nginx
```

## Step 6: Check for Default Server Configuration Issues

Nginx has a concept of a "default server" which handles requests that don't match any specific server_name. If this default server is incorrectly configured, it can cause problems.

Identify the Default Server: In nginx.conf or any included files, look for a server block with the listen directive that doesn't have an explicit server_name or has default_server specified. For example:

server {
    listen 80 default_server; # This is the default server
    listen [::]:80 default_server;
    root /var/www/html; # This might be serving the welcome page
    index index.html index.htm;
    server_name _; # Catches all other hostnames
}

Ensure Your App's Server is the Default (or is matched):
- Option A (Recommended for clarity): Make your application's server block the actual default server by adding default_server to its listen directive, but only if you only have one primary site.
- Option B (More common): Ensure your server_name directives are precise. If you have multiple server blocks, Nginx will pick the first one it finds that matches, or the designated default server if no match is found. If you have an explicit default_server block that isn't your application, Nginx will serve that.
Review sites-enabled Order (less common but possible): In rare cases, the order in which server blocks are processed can matter. Nginx typically processes them in the order they are defined in the configuration files. If you have multiple server blocks without explicit default_server settings and no server_name matches, the first one encountered will act as the default.

## Step 7: Clear Browser Cache and DNS Cache

Sometimes, the issue might be on your local machine rather than the server.

Browser Cache: Clear your browser's cache and cookies, or try accessing the site in an incognito/private browsing window.
DNS Cache: If you recently changed DNS records, your local machine might still be using old cached information. You can flush your DNS cache (the command varies by operating system):
- Windows: ipconfig /flushdns
- macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- Linux: sudo systemd-resolve --flush-caches (for systemd-resolved) or consult your distribution's documentation.

Common Mistakes

A frequent pitfall is incorrectly spelling the server_name in the Nginx configuration. Even a single misplaced character or an extra space can prevent Nginx from matching the incoming request to your intended server block. Another common error is forgetting to create the symbolic link from sites-available/ to sites-enabled/, or having the wrong file symlinked. People also sometimes forget to test the configuration (nginx -t) before reloading or restarting, leading to Nginx failing to start or reload due to syntax errors. Finally, misunderstanding the default_server directive and its precedence can lead to the wrong configuration being served.

Prevention Tips

To prevent this issue, maintain a clear and organized Nginx configuration structure. Use descriptive filenames for your server block configuration files (e.g., yourdomain.com.conf) and keep them in sites-available/. Always create a symbolic link to sites-enabled/ to activate them. Automate your Nginx configuration testing and reloads using scripts or deployment tools. Implement a robust .conf file naming convention and ensure all server_name directives accurately reflect your domain names. Regularly review your sites-enabled/ directory to ensure only active and intended configurations are present. Consider using a wildcard server_name like *.yourdomain.com if you manage multiple subdomains, but be mindful of its implications.