Redirect HTTP to HTTPS: Apache, Nginx & Cloudflare

You installed the SSL certificate. The padlock finally shows up on the https:// version of your site. But type your domain without the "s" and it still loads over plain http:// — no lock, no encryption. If you want to redirect HTTP to HTTPS the right way, the fix is one rule in the right place, plus the single gotcha that traps almost everyone: the dreaded redirect loop.

This guide gives you copy-paste rules for Apache (.htaccess), Nginx, and Cloudflare, and shows you how to avoid taking your site down in the process — using the same three-layer stack we run at Hostaccent every day.

Quick Answer: To redirect HTTP to HTTPS, add a permanent 301 redirect at your web server. On Apache, use a RewriteRule in .htaccess. On Nginx, use return 301 https://$host$request_uri; in the port 80 server block. On Cloudflare, turn on "Always Use HTTPS." Always use a 301 (permanent), never a 302, so search engines pass authority to the secure URL.

Why HTTP-to-HTTPS Redirects Actually Matter

HTTPS isn't just a padlock icon. It encrypts the connection between your visitor's browser and your server, so passwords, form data, and cookies can't be read in transit. But here's what trips people up: installing an SSL certificate does not automatically send visitors to the secure version. Both http:// and https:// stay live until you force the redirect.

That split causes real problems. Search engines can index both versions and treat them as duplicate content. Browsers flag the http:// page as "Not Secure." And every hardcoded http:// link keeps leaking visitors onto the unencrypted version.

On our own Nginx to Apache stack, the most common SSL ticket we get isn't a broken certificate — it's a working certificate with no redirect in place. The cert is fine. The site just never tells browsers to prefer it. That's why a well-configured host enables the redirect as part of SSL setup, so the secure URL is the only one that answers.

Getting this right also protects the ranking signals you've built. Google has treated HTTPS as a lightweight ranking factor since 2014, and moving traffic cleanly to one canonical URL keeps your link equity in one place. If you're still mapping out your SSL and CDN setup, our 2026 Cloudflare setup guide pairs well with everything below.

How to Redirect HTTP to HTTPS on Apache (.htaccess)

If your host runs Apache (most shared and cPanel hosting does), the redirect lives in the .htaccess file in your site's root folder. This is the classic force https htaccess method, and it takes three lines.

Add these to the top of .htaccess:

apacheCopy
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Line by line: RewriteEngine On activates the rewrite module. RewriteCond %{HTTPS} off checks whether the request arrived over plain HTTP. RewriteRule then rebuilds the same URL with https:// and sends a 301 permanent redirect. The [L] flag stops processing further rules once this one fires, so nothing downstream undoes it.

Pro Tip: If your site sits behind Cloudflare or any reverse proxy, %{HTTPS} can read as "off" even when the visitor is already on HTTPS — because the proxy talks to your server over HTTP internally. That single mismatch is the number-one cause of the infinite redirect loop we cover below. When a proxy is involved, test %{HTTP:X-Forwarded-Proto} instead.

For the full rule reference, the Apache mod_rewrite documentation covers every flag and condition in detail.

A cleaner variant, if you want to force one canonical domain (always www or always the bare domain), swaps %{HTTP_HOST} for your fixed domain. Don't stack two separate redirects — one for http-to-https and another for non-www-to-www — as individual rules. Combine them into a single rule to avoid an extra hop that slows time-to-first-byte.

HTTP to HTTPS Redirect on Nginx (the Right Way)

Nginx doesn't use .htaccess. Redirects live in your server configuration, usually under /etc/nginx/sites-available/. The cleanest http to https redirect nginx setup uses a dedicated server block that listens on port 80 and does nothing but redirect:

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

Why return 301 instead of a rewrite? It's faster and unambiguous — Nginx answers immediately without evaluating regex. Skip the old if (-f ...) rewrite hacks you'll still find in outdated forum posts; the official Nginx rewrite module docs and the phrase "if is evil" both exist for a reason.

After editing, always test before you reload:

bashCopy
nginx -t && systemctl reload nginx

The nginx -t step catches syntax errors before they take your site down. We reload rather than restart so live connections aren't dropped. If you're hardening a fresh server anyway, our Ubuntu VPS security baseline walks through the rest.

Insider Insight: On the Hostaccent stack, Nginx handles the port 80 to 443 redirect at the edge and never passes plain HTTP through to Apache at all. Terminating the redirect as early as possible — ideally before the request touches your application — typically saves 20–30ms of time-to-first-byte and keeps your PHP workers free for real traffic. If you also run rate limiting, layer it into the same front server block; here's our take on Nginx rate limiting basics.

Cloudflare: Always Use HTTPS in One Toggle

If your site runs through Cloudflare, you get the simplest option of all. In your dashboard, go to SSL/TLS → Edge Certificates and turn on the Cloudflare Always Use HTTPS switch. Every http:// request gets a 301 to https:// at Cloudflare's edge, before it ever reaches your server.

Two things to set alongside it. First, set your SSL/TLS encryption mode to Full (Strict) — this encrypts the Cloudflare-to-origin hop and validates your origin certificate, which is how Hostaccent runs it on our own edge. Anything weaker leaves a plaintext leg between Cloudflare and your server. Second, once you're confident everything loads over HTTPS, enable HSTS to tell browsers to skip http:// entirely on future visits.

Cloudflare's own SSL/TLS documentation explains each encryption mode. One caution: don't run a Cloudflare edge redirect and a conflicting server-level redirect that disagree about www vs non-www — that combination is a classic loop generator.

The SSL Redirect Loop Trap (and How to Escape It)

You add the redirect, load your site, and the browser throws ERR_TOO_MANY_REDIRECTS. An ssl redirect loop happens when your server keeps bouncing the same request back and forth without ever landing on a final HTTPS page.

The usual culprit is a Cloudflare SSL mode mismatch. If Cloudflare is set to Flexible, it talks to your origin over HTTP. Your origin sees HTTP, redirects to HTTPS, Cloudflare rewrites it back to HTTP to the origin — forever. The fix is almost always switching Cloudflare from Flexible to Full (Strict).

Here's a quick decision shortcut:

| Symptom | Likely cause | Fix | |---|---|---| | ERR_TOO_MANY_REDIRECTS behind Cloudflare | SSL mode set to Flexible | Switch to Full (Strict) | | Loop after adding an .htaccess rule | Proxy sends internal HTTP; %{HTTPS} reads off | Check X-Forwarded-Proto instead | | Loop only on www or only on non-www | Two redirects disagree on canonical host | Combine into one rule | | Loop after enabling HSTS too early | Browser cached a broken HTTPS state | Clear HSTS, fix redirect, re-enable |

In the support tickets our team handles, this Flexible-mode loop is far and away the most frequent HTTPS problem we see — more common than certificate errors themselves. It looks scary, but it's a two-click fix once you know where to look. A stray loop can also surface as a broken page; if yours shows up as a missing URL instead, our guide to fixing 404 Not Found errors covers that path.

Common Mistakes We See on Real Sites

A few patterns come up again and again when we migrate customer sites onto our stack:

• Using a 302 instead of a 301. A 302 is temporary and doesn't pass full ranking signals. Use 301 for a permanent move. (Some prefer 308, which also preserves the request method — fine, but 301 is universally understood.)
• Redirecting in PHP or WordPress instead of the server. An application-level redirect runs after PHP boots — slower than catching it at Nginx or in .htaccess. Redirect as early in the stack as possible.
• Forgetting mixed content. Even after the redirect, hardcoded http:// image and script URLs still throw "Not Secure" warnings. Update them, or add a Content-Security-Policy upgrade-insecure-requests directive.
• Enabling HSTS before HTTPS fully works. HSTS with a long max-age (commonly 31536000 seconds — about 365 days) locks browsers onto HTTPS. Turn it on only once every page loads cleanly, or you'll lock in a broken state.

The MDN reference on Strict-Transport-Security is the clearest explanation of how HSTS max-age and preload behave. Get the redirect solid first, then add HSTS as the seatbelt.

Pro Tip: Before flipping HSTS on, test in a private window across two browsers. HSTS is sticky — if you preload a broken config, individual visitors can't easily undo it on their end, and clearing it is a support headache. Slow is smooth here.

Get HTTPS Working Without the Headache

Here's what to take away:

• Always redirect http to https with a 301, never a 302 — permanence matters for SEO.
• Do it at the server layer (.htaccess or Nginx return 301), not inside your app.
• Behind Cloudflare, set Full (Strict) mode to dodge the redirect loop.
• Add HSTS last, only after every page loads cleanly over HTTPS.

If you'd rather not touch config files at all, the right hosting setup handles the whole redirect for you the moment SSL is issued. That's the practical case for managed shared hosting: free SSL, the redirect pre-configured, Cloudflare-ready DNS, and NVMe SSD storage so the extra redirect hop adds only about 2ms.

Hostaccent's Shared Hosting starts at $1.99/mo on the Economy plan (it renews at the same $1.99/mo, not a jacked-up rate later), with free SSL, Cloudflare integration, and UK-based human support to sort out edge cases like redirect loops. As a UK-registered host operating since 2012 with a Bangladesh support branch, we run the exact Cloudflare to Nginx to Apache stack described above on 99.9%-uptime infrastructure. It's not the right pick if you need root-level control — that's what a VPS is for — but for most sites that just need HTTPS to work, it removes the guesswork. Need more room later? The Standard plan runs $4.58/mo. New to picking a plan? Start with our domain and hosting buying guide.

Frequently Asked Questions

How do I redirect HTTP to HTTPS without editing config files?

The easiest route is a managed host or CDN. On Cloudflare, enabling "Always Use HTTPS" adds the redirect at the network edge with no server edits. Many hosts — Hostaccent included — switch it on automatically the moment your SSL certificate is issued, so there's nothing for you to configure.

Should I use a 301 or 302 redirect for HTTPS?

Use a 301. It's a permanent redirect, so search engines transfer ranking signals to the HTTPS URL and remember the change. A 302 is temporary and tells crawlers the move might be undone, which can dilute your SEO. For a permanent switch to HTTPS, 301 is the correct choice every time.

Why do I get a redirect loop after forcing HTTPS?

Almost always a Cloudflare SSL mode mismatch. If it's set to "Flexible," Cloudflare talks to your origin over HTTP while your server keeps redirecting to HTTPS — an endless bounce. Switch to "Full (Strict)" mode. Behind other proxies, check the X-Forwarded-Proto header instead of %{HTTPS}.

Does redirecting HTTP to HTTPS hurt SEO?

No — done right, it helps. A clean 301 consolidates the duplicate http:// and https:// versions into one canonical URL and preserves link equity. Google has treated HTTPS as a positive signal since 2014. The only real risk is redirect chains or loops, so keep it to a single hop.

Is Cloudflare "Always Use HTTPS" enough on its own?

For visitor-facing traffic, usually yes — it redirects every http:// request at the edge. But set your encryption mode to Full (Strict) so the Cloudflare-to-origin connection is also encrypted. And keep a server-level redirect too, so direct-to-origin requests that bypass Cloudflare still land on HTTPS.

Do I still need HSTS if I already redirect to HTTPS?

They do different jobs. Your 301 redirect fixes each request after it reaches the server. HSTS tells the browser to never even attempt http:// on future visits — skipping the redirect entirely and closing a small security gap. Add HSTS once HTTPS is fully stable, with a long max-age.