Remove www and redirect HTTP to HTTPS in Nginx

Serve content at https://example.com and redirect the other three hostname/protocol combinations directly there. Use a fixed destination host plus $request_uri to preserve the path and query string.

Cover all four entry points

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

server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    root /var/www/site;
    index index.html;
    location / { try_files $uri $uri/ =404; }
}

This combines the two identical HTTP redirects into one block. Replace the final static-file handler with your application's handler when needed. Include equivalent IPv6 listeners if your DNS and deployment serve IPv6.

Certificates come before the HTTPS redirect

The shared certificate shown above must cover both hostnames. Separate certificates are also valid if each HTTPS server presents one covering its own name. A *.example.com wildcard alone does not cover the apex.

For an environment managed with Certbot's Nginx plugin, certificate issuance can use:

certbot --nginx -d example.com -d www.example.com

Review any generated server configuration afterward. A simple server-level if with return is not inherently invalid, but separate redirect and content blocks make this case easy to inspect.

Test the first hop and destination

curl -I 'http://www.example.com/path?q=1'
curl -I 'http://example.com/path?q=1'
curl -I 'https://www.example.com/path?q=1'
curl -I 'https://example.com/path?q=1'

Choose a path that actually exists. The canonical request should return that resource's expected status, not necessarily 200 for every possible path. Test a temporary 302 first if you need to avoid retaining a mistaken permanent redirect. For method-preserving redirects, consider 307/308 and verify client behavior.

Guance HTTP synthetic tests can check the first response with following disabled, then check the final page separately. Preserve query strings in the test cases. A 301-to-200 ratio alone cannot establish that the chain is correct.

FAQ

Can I make www canonical instead?

Yes. Redirect both HTTP names and the HTTPS apex to https://www.example.com$request_uri, then serve content in the HTTPS www block.

Why avoid multiple hops?

Each redirect adds another request. A direct target simplifies validation and avoids unnecessary chains. If a CDN also redirects, coordinate both layers so they do not loop or add an extra hop.

Should I add HSTS immediately?

First verify HTTPS, then introduce a suitable policy on the HTTPS content server. Start with a short max-age and do not add includeSubDomains until all affected hosts are ready. A valid HTTPS response can update the policy; clients unable to receive it may retain the old policy until it expires.

Reference: Nginx request and virtual-server processing.