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

If example.com serves your site but www.example.com shows NGINX’s packaged welcome page, the two requests are not being handled by the same virtual host. Usually the apex name matches your intended server_name, while the www Host header is missing, misspelled, loaded in another file, or arriving at a different listener or IP address. NGINX then sends the unmatched request to the default server for that port, whose document root often contains the welcome page.

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

DNS can create the same appearance before NGINX is involved. If the apex and www records point to different IPv4 or IPv6 addresses, they may reach different NGINX instances or load balancers. Fix the complete path—DNS, listeners, server names, TLS, and the default site—rather than editing the welcome-page files.

#	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

As an Amazon Associate I earn from qualifying purchases.

What NGINX is doing

Every HTTP request passes through two distinct decisions. DNS resolves the hostname to an address. After the connection reaches that address, NGINX selects a listening socket such as port 80 or 443 and then compares the HTTP Host header (or the TLS server name during an HTTPS handshake) with the server_name values attached to that listener.

When no configured name matches, NGINX routes the request to the default server for that address and port. If no block is explicitly marked default_server, the first server block loaded for that listening socket becomes the default. Distribution packages commonly make that block point at a sample document root containing the NGINX welcome page.

#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

That is why the result can look inconsistent: example.com may match server_name example.com, while www.example.com falls through to the default. The reverse situation is also possible.

How server-name matching works

The server_name directive supports exact names, wildcards, and regular expressions. NGINX evaluates them in this order:

1. Exact name.
2. The longest wildcard beginning with an asterisk, such as *.example.com.
3. The longest wildcard ending with an asterisk, such as mail.*.
4. The first regular expression that matches, in configuration order.

An exact declaration is usually the clearest and safest choice for a public site:

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

Putting both names in the same block makes them serve identical content, provided both requests reach that listener. A wildcard is not a substitute for explicitly listing the two canonical hostnames when you control them and want predictable certificate and redirect behavior.

First check DNS and the network destination

Before changing NGINX, verify that both names reach the intended endpoint. Check A records for IPv4 and AAAA records for IPv6:

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

When one site is supposed to run on one server, the returned addresses should be consistent with that design. A stale www record, an overlooked AAAA record, or a separate load-balancer address can send only one hostname to an old machine. Compare the results from more than one network if DNS changes were recent, because resolver caches can retain old records until their TTL expires.

DNS does not select an NGINX server block. It only determines where the TCP connection goes. NGINX still needs the requested hostname in the configuration at the destination that answered.

Use HTTP responses to identify the failure

Request both names and record the status code, redirect target, and certificate information. Start with headers:

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

Look for differences in Location, the Server header, response status, and certificate names. A welcome page with a successful 200 response usually means the request reached a valid NGINX instance but matched its default virtual host. A DNS or connection error points to the layer before virtual-host selection. A certificate warning or a certificate that lacks the requested name indicates a TLS configuration problem even if the address is correct.

Separate DNS from virtual-host matching with –resolve

The --resolve option forces curl to connect to a chosen address while preserving the hostname in the URL and Host header. Replace the example address with an address returned by DNS:

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/

If this test produces the correct site, but an ordinary request does not, DNS is directing traffic elsewhere. If it still produces the welcome page, inspect the NGINX configuration on that address. For HTTPS, curl also sends the hostname during TLS negotiation, so this test can expose a missing 443 server block or an incorrect certificate.

Inspect the complete NGINX configuration

Individual files can be misleading because the active configuration may include directories you did not open. Render the complete configuration and search it:

sudo nginx -T
sudo nginx -T 2>&1 | grep -nE 'server_name|listen|default_server|root'

Confirm all of the following:

• The intended block contains both example.com and www.example.com, or a deliberate redirect block contains the secondary name.
• The block is attached to every required listener, normally port 80 and port 443.
• No spelling error, omitted dot, or unrelated suffix prevents an exact match.
• The file containing the block is actually included and enabled.
• A different block is not marked default_server for the same address and port.
• The welcome-page root belongs to the default or sample block, not to your application block.

nginx -T also reveals duplicate declarations and the order in which files are loaded. Remember that default_server belongs to a listening address and port; it is not attached to a hostname. A default for port 80 does not automatically control port 443.

Choose the hostname policy before editing

There are two valid designs. You can serve the same content from both names, or choose one canonical URL and redirect the other. Decide this first so HTTP and HTTPS behave consistently.

Fix 1: serve the apex and www from one block

Use this pattern when both hostnames should display the same site:

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

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

    root /var/www/example;
    index index.html index.htm;

    # location rules for the application go here
}

The IPv6 listener matters when an AAAA record exists. If NGINX listens only on IPv4 while clients receive an IPv6 address, those clients may reach another service or fail entirely. Add the equivalent names to the HTTPS block as well:

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 must contain both names, either as separate Subject Alternative Names or through a certificate that otherwise explicitly covers them. Matching the HTTP server_name does not fix a certificate that omits www.example.com.

Fix 2: redirect www to the bare domain (or the reverse)

If the apex is canonical, make the www block redirect and keep the content only in the apex block:

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 site, use the same policy on port 443. The redirecting HTTPS block still needs a certificate valid for www.example.com; TLS negotiation occurs before NGINX can send the HTTP redirect:

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;
}

Use the final scheme deliberately. If the site is HTTPS-only, redirect HTTP to HTTPS and then redirect the secondary hostname, or combine the policy in a way that produces one predictable hop. Test that query strings and paths survive the redirect.

Install a deliberate catch-all

Leaving the distribution sample site as the default makes unknown hostnames display a generic page. Replace it with a controlled response after confirming that all required names have their own blocks:

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

NGINX treats the underscore as an ordinary invalid name; it has no special catch-all meaning. The catch-all works because the block is explicitly the default, not because of the underscore. Some operators prefer a controlled redirect or a small error response instead of status 444; choose a behavior that fits monitoring and security requirements. Create an equivalent deliberate default for 443, with an appropriate certificate strategy, if unknown HTTPS names must not reach a sample site.

Disable the sample site only after checking dependencies

Many Linux packages enable a default configuration through a site directory or an included file. Remove or disable that sample link only after checking that no required hostname, health check, or temporary service depends on it. First identify which block owns the welcome-page root using nginx -T. Then make the intended application or catch-all block the explicit owner of the listener. Deleting files from the sample document root is not a fix; an unmatched request will still be served by whichever block is default.

Validate and reload safely

1. Edit the enabled configuration, including both IPv4 and IPv6 listeners where applicable.
2. Run sudo nginx -t. Do not reload if syntax validation fails; correct the reported file and line first.
3. Reload with sudo systemctl reload nginx or the service command used by your distribution.
4. Repeat the HTTP and HTTPS curl tests for the apex and www names.
5. Test an intentionally unknown hostname to confirm that the catch-all behaves as designed.
6. Check application logs and the NGINX error log if the response is still unexpected.

When a reload succeeds but the old page remains, verify that the request is reaching the machine you changed. Compare the address selected by DNS with the server’s public addresses, test each address with --resolve, and check any CDN or load balancer configuration in front of NGINX.

Common causes that look like a server-name problem

Only port 80 was fixed

HTTP may work while HTTPS still shows the welcome page because the 443 block has a different server_name, certificate, or default server. Treat ports 80 and 443 as separate virtual-host sets.

An AAAA record bypasses the corrected server

IPv6-capable clients may prefer an AAAA address. If that address points to an old host, the behavior can vary by network. Either configure the IPv6 endpoint identically or remove the stale record after confirming that IPv6 is not part of the deployment.

The hostname is present in an unused file

A configuration file in an available directory does nothing unless the main configuration includes it. The rendered output from nginx -T, rather than the file you expect, is the authoritative view.

A load balancer terminates TLS

If a proxy terminates HTTPS, it may select a backend using its own hostname rules and send NGINX a different Host header. Check the proxy’s certificates, listener rules, and forwarding behavior as well as the backend blocks.

A redirect creates a misleading result

A request can start at the correct server and then be redirected to a hostname whose DNS or NGINX block is wrong. Follow the Location header and test the destination separately instead of judging only the first response.

A practical decision sequence

1. If A or AAAA records differ unexpectedly, correct DNS or the endpoint configuration first.
2. If both names reach the same address, use --resolve to prove whether the Host header selects the intended block.
3. If matching fails, add the exact names to the appropriate 80 and 443 blocks or create an explicit redirect block.
4. If matching succeeds but the certificate is wrong, provision a certificate containing every hostname clients use and attach it to the correct TLS block.
5. If unknown names still show the welcome page, replace the packaged default with a deliberate catch-all.
6. Validate with nginx -t, reload, and retest from both IPv4 and IPv6-capable networks.

For a deeper treatment of installation, configuration, and debugging recipes, 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.

DNSHTTPSNGINXserver_namevirtual hostsWeb server troubleshooting