How to Create a Meaningful Default Configuration in nginx

Introduction

The default setting of the nginx web server displays a page when no explicit configuration exists. This can be an entry point for attackers, which can be prevented by adjusting the default domain as follows.

Prerequisites

• You have a hosting.fr Cloud server with a valid DNS record, for example demo.mustermann-domain.fr.

• Privileged shell access on the system.

• nginx is already installed on the Cloud server.

Adjusting the Default nginx Configuration

The default file (usually located under /etc/nginx/sites-enabled)

The following contents should be entered there:

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        listen 443 ssl default_server;
        listen [::]:443 ssl default_server;
        ssl_reject_handshake on;
        server_name _;

        return 444;
}

Then, check the Nginx configuration with nginx-t to ensure its validity, and restart the web server (systemctl restart nginx.service).

Note

With this configuration, no web page will be displayed when the server is directly accessed with the IP address. Appropriate vHosts for the domains should be configured beforehand! However, connections made directly via the IP will be responded to with status code 444 and terminated immediately. Thanks to the ssl_reject_handshake on; directive, it is not necessary to integrate a certificate.

What the Nginx “default server” actually is

In Nginx, the default server is the server block that receives requests when no other server block matches the request. A match is typically determined by the requested hostname (Host header) and the listener configuration (listen address/port). If a client connects by IP address, uses an unknown hostname, or the request does not match any configured server_name, Nginx routes it to the default server for that IP:port combination.

The default server is not a special “feature page”, it is simply a rule that defines which server block becomes the fallback. This matters in real operations because unmatched traffic is common: users might type the server IP into a browser, bots scan public IPs, or a domain might still point to your server before you complete DNS or certificate setup. Defining a controlled default server helps you avoid accidentally serving the wrong website and gives you predictable behavior for unmatched requests.

Common use cases for configuring a default server

A custom default server is useful when you want unmatched requests to behave safely and predictably. Without a deliberate default, Nginx may fall back to the first server block it loads for a given port, unintentionally exposing the wrong content.

Common, practical use cases include:

• Catch-all response for unknown hosts: return a clean “not configured” message instead of serving a random site.
• Maintenance or holding page: show a controlled page while migrating domains or preparing the production configuration.
• Security hardening: return a minimal response or a non-success status code (e.g., 444 or 404) to reduce exposure to scanners and bots.
• IP-based access control: intentionally block access by IP address while allowing only known domain names to reach their configured virtual hosts.
• TLS hygiene: prevent certificate mismatch problems by ensuring the default HTTPS listener does not serve an unrelated certificate.

This makes the default server a practical tool for both operational clarity and security posture.

Best practices for structuring Nginx server blocks

When you run multiple sites on a single server, a clear structure reduces the risk of accidental routing to the wrong server block. The most common failure mode is that a “catch-all” server block unintentionally captures traffic intended for another hostname.

Recommended best practices:

• Define exactly one default server per IP:port combination using listen ... default_server.
• Make the default server’s purpose explicit:
  • Use a clear file name (e.g., 00-default.conf) so it loads predictably.
  • Add a comment stating it is the fallback for unmatched hosts.
• Keep server_name in the default server generic (for example _) so it does not compete with real domains.
• Ensure real websites have explicit server_name values (e.g., example.com www.example.com) and are not relying on implicit matching.
• If you run both HTTP (80) and HTTPS (443), decide whether you need a default server for both. In many cases, you want:
  • HTTP default: return a minimal message or redirect strategy
  • HTTPS default: avoid serving a mismatched certificate; keep it minimal and deliberate

These practices reduce the chance of “wrong site loads for my domain” and make it easier to reason about routing.

Troubleshooting common default server issues

If the default server appears to “take over” traffic, it usually means hostname matching or listener configuration is not what you expected. Use the checks below to find the cause quickly.

My domain shows the default server instead of the intended site

• Confirm the intended server block contains the correct server_name entries for that domain.
• Verify the domain’s DNS actually points to this server IP (otherwise you may be testing a different host).
• Check for duplicate or conflicting server_name entries across server blocks.

HTTPS shows certificate warnings

• This often happens when a request hits the default HTTPS server and it serves a certificate that does not match the requested hostname.
• Ensure the correct site has its own listen 443 ssl; block and the right certificate configuration.
• Consider keeping the default HTTPS server minimal and not serving a misleading certificate.

Unexpected behavior after changes

• Validate your configuration before reloading.
• Reload Nginx and then re-test from a clean client (different network or cleared cache) to avoid misleading cached results.

I don’t know which server block is being used

• Review the Nginx configuration set for the relevant port and identify which server block is marked as default_server.
• Check access logs for the Host header and request target to confirm whether requests are arriving with the expected hostname.

This troubleshooting flow helps you correct routing and certificate issues without trial-and-error edits.

Don't hesitate to subscribe to our newsletter

Back to form

Thank you for subscribing to the hosting.fr newsletter.

E-mail

Verification

Subscribe