Why Nginx Shows the Welcome Page on www but Not the Bare Domain

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

If example.com serves your site but www.example.com shows NGINX’s welcome page, the two requests are not being handled by the same virtual host. DNS first decides which address receives each request. NGINX then uses the listening address and port, the TLS handshake when applicable, and the HTTP Host value to select a server block. If the host name does not match any block on that listener, NGINX sends the request to that port’s default server, which commonly has the packaged welcome page as its document root.

Usually the fix is to add both exact names to the intended block, or deliberately redirect one name to the other. You must make the same decision on HTTP and HTTPS, check both A and AAAA DNS records, and verify the complete rendered NGINX configuration rather than only the file you happened to edit.

#	Preview	Product	Price
1		Recipe Book to Write in Your Own Recipes, Spiral Blank Cookbook 150 Recipes	$14.98	Buy on Amazon
2		Pipilo Press Blank Family Cookbook Recipe Binder - 6.5 x 8.2 in Hardcover Spiral Bound - 90 Ruled...	$7.98	Buy on Amazon

How NGINX reaches the wrong page

A browser request passes through several independent decisions:

1. DNS resolution: The resolver looks up an A record for IPv4 and, when present, an AAAA record for IPv6.
2. Network connection: The client connects to one of those addresses on port 80 for HTTP or port 443 for HTTPS.
3. Listener selection: NGINX chooses the group of server blocks attached to that address and port. A default_server designation belongs to this listen socket, not to a domain name.
4. Host-name selection: For HTTP, NGINX compares the request’s Host value with the server_name directives in that group. For HTTPS, certificate and TLS server selection occur before the encrypted HTTP request is processed, so the 443 configuration and certificate also matter.
5. Content handling: The selected block applies its root, proxy settings, redirects, and other directives.

NGINX’s documented behavior is that when the Host value matches no configured server name, or is missing, the request is routed to the default server for that port. Unless you explicitly declare another default, the first server for that address and port is normally used. A distribution’s sample block often points at a directory containing the NGINX welcome page, making the fallback visible.

#1 Best Overall

Recipe Book to Write in Your Own Recipes, Spiral Blank Cookbook 150 Recipes

• B5 Recipe Book: This hardcover blank recipe book measures 10''×7.3'', containing 150 blank pages, comes with 1 sheet of DIY category stickers, perfect for writing down your own recipes and organizing them in one place.
• Practical Layout - 5 pages of conversion charts show you everything you'll ever need to know in the kitchen. The table of contents will help organize your personal favorite recipes. A back pocket is designed for loose items.
• Easy to Use - This blank cookbook is made of high-quality paper with a beautiful hardcover for long-term use. The sturdy gold double-wire spiral binding makes writing easier and page turning smoother.
• Make Your Own Recipes - This blank cookbook has up to 150 blank pages for you to write in your own recipes, with plenty of space to record ingredients and instructions. You can write down all the special tips for your family members.
• Thoughtful Gift - A personalized recipe book makes a thoughtful gift for your children or newlyweds, and a great gift for housewarming, weddings, bridal showers, anniversaries, or any other occasion.

$14.98

Buy on Amazon

Why the apex and www names can behave differently

www is missing from server_name

The most common configuration is a block containing only server_name example.com;. The apex request matches it, while www.example.com does not. The unmatched request falls through to the default block. The reverse mismatch is possible if only the www name is declared.

A spelling, punctuation, or include-file error

Server names must match the requested host. A typo, an accidental trailing character, or a name placed in a file that is not included has the same effect as omitting the name. Inspect the rendered configuration with nginx -T; looking only at one site file can hide an include or an override elsewhere.

The names reach different addresses

example.com and www.example.com may have different A records, different AAAA records, or a mixture of old and new values. IPv4 users can reach one NGINX instance while IPv6 users reach another. A load balancer, reverse proxy, or separate server may then present a different virtual-host configuration. Before changing NGINX, confirm that both names resolve to the intended endpoint.

The listener is different

A block that works on port 80 does not automatically handle port 443. NGINX can also have separate IPv4 and IPv6 listeners. If the names are present on one listen group but not another, the result can change with protocol or client network.

TLS chooses a different 443 block

HTTPS adds Server Name Indication (SNI) and certificate selection. A request can arrive at the correct IP yet receive a certificate or content from a 443 block that does not list the requested name. The certificate must contain every hostname you intend to serve, and the corresponding 443 block must cover those names.

How NGINX matches server names

NGINX accepts exact names, wildcard names, and regular expressions. Its documented precedence is:

1. An exact name, such as www.example.com.
2. The longest leading wildcard, such as *.example.com.
3. The longest trailing wildcard, such as example.*.
4. The first matching regular expression, in configuration order.

For two known hostnames, explicit names are clearer and avoid surprising wildcard interactions:

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example;
}

The underscore often seen in catch-all examples has no special NGINX meaning; it is simply an invalid name conventionally used so that the block does not accidentally match a real host.

Diagnostic workflow

Work from the outside in. Record what each name does before editing files.

1. Compare A and AAAA records

dig +short A example.com
dig +short A www.example.com
dig +short AAAA example.com
dig +short AAAA www.example.com

If both names are intended to use one server, their active records should lead to the same service. An unexpected AAAA record is a frequent explanation for a problem that appears only on some networks. If a DNS provider uses an alias or proxy record, inspect the resulting addresses and the provider’s target as well.

2. Capture HTTP and HTTPS responses

curl -I http://example.com
curl -I http://www.example.com
curl -I https://example.com
curl -I https://www.example.com

Note the status code, every Location header, and whether the TLS connection succeeds. A 301 or 308 may be intentional canonicalization; a welcome-page response with a successful status usually indicates that a fallback block served static content. Add -L only after recording the first response, because following redirects can hide the original mismatch.

3. Separate DNS from virtual-host matching

Use --resolve to force a hostname to a known address while preserving the desired Host name and, for HTTPS, SNI:

curl -i --resolve www.example.com:80:203.0.113.10 http://www.example.com/
curl -i --resolve www.example.com:443:203.0.113.10 https://www.example.com/

Replace the example address with the actual endpoint. If this test works while ordinary DNS does not, correct DNS or the load-balancer route. If it still returns the welcome page, inspect NGINX’s server blocks on that endpoint.

4. Inspect the complete active configuration

sudo nginx -T

Search the output for both hostnames, all relevant listen directives, default_server, and the document root associated with the welcome page. The command expands included files, so it shows what NGINX actually loaded rather than what a single source file appears to contain. On a busy system, save the output and search it with your preferred text tool.

5. Identify the fallback block

Find the block that owns the welcome-page document root. Determine whether it is the default for port 80, port 443, an IPv6 listener, or more than one. This explains exactly why the unmatched request produces that page and prevents you from changing the wrong site definition.

Rank #2

Pipilo Press Blank Family Cookbook Recipe Binder - 6.5 x 8.2 in Hardcover Spiral Bound - 90 Ruled Pages with Memo Pocket - Write In Your Own Recipes & Meal Planning Notebook

• Create a Culinary Legacy: The Pipilo Press Blank Family Cookbook Recipe Binder offers a timeless platform for chronicling beloved recipes. With its hardcover and spiral binding, this recipe book to write in your own recipes ensures durability and ease of use for generations
• Thoughtful Gifting Choice: This book for writing recipes is an ideal present for various occasions, adding a personal touch to celebrations. Its elegant design makes it perfect for moms cookbook DIY projects or anyone passionate about preserving family traditions
• Durable Design Features: Constructed with a 300gsm cardstock cover and matte lamination, this cookbook you can write in ensures longevity. Its spiral-bound format provides convenient access to pages, making it a practical tool for everyday use
• Organized Recipe Storage: The included memo pocket offers a space to store handwritten notes or recipe cards, enhancing its functionality. This feature transforms the recipe book for moms into a sentimental family memento
• Ample Writing Space: Measuring 6.5 x 8.2 inches, this blank spiral family recipe cookbook offers plenty of room for detailed notes. It is perfect for jotting down ingredients, preparation methods, and serving suggestions for a complete culinary record

$7.98

Buy on Amazon

6. Validate before reloading

sudo nginx -t
sudo systemctl reload nginx

Reload only after the syntax test reports a successful configuration. Re-run the four curl -I checks and, if necessary, the --resolve tests. A reload applies configuration without dropping existing connections; a failed test leaves the running configuration unchanged.

Fix option 1: serve both names from one site

Choose this when the apex and www URLs may remain equivalent and you do not need one canonical URL. Put both exact names in every relevant listener:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example;

    # application or static-site directives
}

Use the equivalent names on 443, and configure the certificate for both names:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;
    root /var/www/example;
}

The certificate paths are examples; use the files issued for your domain. If an automated certificate tool creates separate blocks, verify that both names are present in the final 443 configuration, not only in the certificate request.

Fix option 2: redirect one name to a canonical URL

A redirect is preferable when cookies, analytics, search indexing, or application-generated links should use one hostname. Give the secondary name its own block and return a redirect before content processing:

server {
    listen 80;
    listen [::]:80;
    server_name www.example.com;
    return 301 http://example.com$request_uri;
}

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    root /var/www/example;
}

For an HTTPS canonical policy, provision a certificate that covers the secondary name as well, then redirect it on 443:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;
    root /var/www/example;
}

Use the scheme and hostname that are genuinely canonical. Do not redirect HTTPS traffic to a name that lacks a valid certificate, and preserve $request_uri so paths and query strings survive the redirect.

Protect unknown hostnames with a deliberate default

Leaving the packaged welcome site as the default can expose an unintended page whenever a host name is mistyped or an old DNS record points at the server. Replace it with a controlled catch-all after confirming that no required site depends on the sample block:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444;
}

Status 444 is an NGINX-specific connection-close behavior commonly used to drop unknown requests. A controlled redirect or a neutral error response may be more appropriate for your environment. Define an equivalent deliberate default for 443, with a certificate strategy that does not break valid names. Remove or disable the distribution’s sample default site only after checking all enabled virtual hosts and deployment automation.

Choosing the right design

Common failure modes after an apparent fix

Only port 80 was changed

HTTP may work while HTTPS still shows the welcome page or presents a certificate warning. Add the names to the 443 blocks and retest both protocols.

Only IPv4 was changed

Clients with IPv6 can continue reaching an old server through AAAA. Update or remove stale AAAA records, or configure the IPv6 listener consistently.

The edited file is not enabled

Many installations separate available and enabled site files. nginx -T reveals whether your file is included. A syntax test on an unused file does not change live traffic.

A wildcard masks an intended name

Review exact-name and wildcard precedence. Add explicit names for important hosts instead of relying on a broad wildcard whose block may contain a different root or proxy.

Redirect loops appear

Check whether a proxy terminates TLS and forwards HTTP to NGINX while your redirect logic assumes the connection is already HTTPS. Inspect forwarded-protocol handling and the first response’s Location value before changing status codes.

What to verify before considering the issue closed

• A and AAAA lookups for both names point to intended endpoints.
• HTTP and HTTPS responses have the expected status and redirect policy.
• The certificate presented for each HTTPS name includes that name and is trusted by clients.
• nginx -T shows both names in the intended blocks for every relevant listener.
• The welcome-page block is no longer an accidental default, or it is replaced by a deliberate catch-all.
• nginx -t succeeds before every reload.

For a deeper treatment of installation, configuration, and debugging patterns, Derek DeJonghe’s NGINX Cookbook, 3rd Edition was published by O’Reilly Media in May 2022.

Quick Recap

Bestseller No. 1

Recipe Book to Write in Your Own Recipes, Spiral Blank Cookbook 150 Recipes

$14.98

Bestseller No. 2

Pipilo Press Blank Family Cookbook Recipe Binder - 6.5 x 8.2 in Hardcover Spiral Bound - 90 Ruled Pages with Memo Pocket - Write In Your Own Recipes & Meal Planning Notebook

$7.98

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.