How to Redirect HTTP to HTTPS in Nginx
If you want stronger security, better browser trust, and cleaner SEO signals, learning how to redirect HTTP to HTTPS in nginx is an essential step.
This guide shows the most reliable Nginx redirect patterns, explains why they work, and highlights the configuration details that prevent redirect loops and broken traffic.
By the end, you will know how to move all inbound HTTP requests to HTTPS without losing site functionality or search engine clarity.
Why HTTPS redirection matters
HTTPS encrypts traffic with TLS, protecting data in transit and reducing the risk of interception or tampering.
Modern browsers such as Google Chrome, Mozilla Firefox, Microsoft Edge, and Safari also flag non-HTTPS pages as not secure, which can reduce trust and hurt engagement.
- Security: TLS encrypts usernames, passwords, cookies, and form submissions.
- SEO: Search engines treat HTTPS as a positive signal and consolidate canonical signals more cleanly.
- User confidence: Visitors are less likely to abandon sites with browser warnings.
- Modern web features: Many APIs, service workers, and browser capabilities require secure contexts.
What Nginx is doing during the redirect
Nginx can listen on port 80 for HTTP and return a permanent redirect to the equivalent HTTPS URL on port 443.
In most cases, you want a 301 redirect because it tells browsers and crawlers that the move is permanent.
A proper redirect preserves the request path and query string, so http://example.com/page?ref=1 becomes https://example.com/page?ref=1 instead of sending users to the homepage.
Basic Nginx redirect configuration
The simplest setup is a dedicated server block for port 80 that returns a 301 redirect to the HTTPS version of the site.
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}This configuration is compact and efficient.
The $request_uri variable includes the full path and query string, making it ideal for preserving the original request.
Why use return instead of rewrite?
For simple HTTP to HTTPS enforcement, return 301 is usually preferred over rewrite.
It is easier to read, faster to evaluate, and less likely to cause unexpected redirect chains.
- return 301 sends an immediate permanent redirect.
- rewrite is more flexible but often unnecessary for this use case.
- Simple server blocks are easier to audit during troubleshooting.
Redirecting both www and non-www domains
You should decide whether your canonical hostname is example.com or www.example.com.
Then configure Nginx so every HTTP request redirects to the chosen HTTPS version.
If your canonical domain is non-www:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}If your canonical domain is www:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://www.example.com$request_uri;
}Matching the canonical hostname across redirects, TLS certificates, and application links helps avoid duplicate content and SEO confusion.
How to redirect all traffic except ACME challenges?
If you use Let's Encrypt with Certbot, you may need to keep the /.well-known/acme-challenge/ path reachable over HTTP for certificate validation.
A common pattern is to redirect everything except that path.
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
location ^~ /.well-known/acme-challenge/ {
root /var/www/html;
}
location / {
return 301 https://example.com$request_uri;
}
}This approach supports automated certificate renewal while still enforcing HTTPS for normal visitors.
Redirecting in the HTTPS server block
Once HTTPS is enabled, your TLS server block should serve the application or static content directly.
A typical secure configuration includes the certificate files and the real site content.
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /var/www/example.com;
index index.html index.htm;
}In this model, the HTTP server block handles only the redirect, while the HTTPS server block serves the site.
That separation keeps the configuration clean and easier to maintain.
Important SSL and TLS settings to check
A redirect is only useful if the HTTPS endpoint is configured correctly.
Make sure your certificate matches the hostname and that your TLS settings are current.
- Certificate coverage: Include every hostname you redirect, such as apex and www.
- TLS versions: Prefer modern protocols supported by current browsers.
- HTTP/2 support: Enable it for performance where available.
- Chain completeness: Use the full chain file when your certificate provider requires it.
Common certificate authorities and tools include Let's Encrypt, Certbot, DigiCert, and Cloudflare Origin Certificates, depending on your deployment model.
How to test the redirect?
After editing the Nginx configuration, validate it before reloading.
A syntax error can prevent Nginx from starting.
nginx -tIf the test passes, reload the service:
systemctl reload nginxThen verify the behavior from a terminal:
curl -I http://example.comYou should see a 301 Moved Permanently response with a Location header pointing to the HTTPS URL.
It is also worth checking the exact path handling:
curl -I "http://example.com/blog/post?utm_source=test"The redirect should preserve both the path and the query string.
Common mistakes when configuring the redirect
Several Nginx misconfigurations can break HTTP to HTTPS redirection or create loops.
- Redirecting to the wrong hostname: This can cause unnecessary hops or certificate mismatches.
- Forgetting IPv6: If
listen [::]:80;is omitted, IPv6 traffic may behave differently. - Using a 302 temporarily: A temporary redirect does not communicate a permanent site move.
- Creating duplicate server blocks: Conflicting
server_nameentries can lead to unpredictable matching. - Forgetting the HTTPS server block: Redirecting HTTP without a valid HTTPS listener causes failure after the first hop.
How does this affect SEO?
Search engines such as Google and Bing generally follow 301 redirects and transfer most ranking signals to the HTTPS destination over time.
A clean HTTP to HTTPS migration also helps ensure that canonical tags, sitemap URLs, and internal links all point to the secure version.
For best results, update the rest of your site infrastructure as well:
- Replace internal links with HTTPS URLs.
- Update XML sitemaps to list only HTTPS pages.
- Set the preferred canonical URL in your CMS or application.
- Check robots directives, Open Graph tags, and structured data URLs.
If you use Google Search Console, add and verify the HTTPS property so you can monitor indexing and crawl behavior after the migration.
Should you force HTTPS at the application level too?
In many stacks, yes.
Nginx should handle the web server redirect, but your application may also need to generate secure URLs, set secure cookies, and enforce HTTPS-aware redirects in framework logic.
This is common in WordPress, Laravel, Django, Node.js apps behind reverse proxies, and containerized deployments.
When Nginx sits in front of an application server, make sure the app trusts the proxy headers and understands that the original request arrived over HTTPS after redirection.
That prevents mixed-content issues and incorrect absolute URLs.
Production-ready Nginx redirect template
For a straightforward production setup, this template is often enough for small to medium sites:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /var/www/example.com;
index index.html index.htm;
}This pattern is easy to maintain and works well for standard deployments using Nginx, TLS certificates from Let's Encrypt, and a single canonical host.
What to verify after deployment
Before considering the job done, confirm the redirect from multiple angles:
- HTTP to HTTPS works on both apex and www hostnames.
- Query strings remain intact.
- Browsers show a secure connection without warnings.
- The certificate covers every redirected hostname.
- No mixed content loads over HTTP.
- Search Console and analytics reflect the HTTPS URLs.
These checks help ensure the redirect is not only technically correct but also reliable for users, crawlers, and application logic.