HTTP to HTTPS redirect: how to fix it

Your site stays on HTTP or chains several HTTPS redirects? Here is how to fix Cloudflare, Apache, Nginx and LiteSpeed settings.

Why fix this?

An address like http://example.com/page should redirect to its final HTTPS address. If it stays on HTTP, the connection is not encrypted. If it goes through several addresses, browsing slows down and search engines have more steps to follow.

Goal: one HTTPS address that responds normally (HTTP 200), with the old variants reaching it in a single 301 or 308 whenever possible.

Before changing anything

1. Check that a TLS certificate works for the domain, and for www if that subdomain is used.
2. Find out where redirects are handled: Cloudflare, your host, Apache, Nginx or WordPress.
3. Back up the configuration and plan a rollback. Do not stack competing rules.

Cloudflare

Always Use HTTPS (SSL/TLS → Edge Certificates) is the best-known option, but it often adds a hop when the site also changes hostname. In practice, it runs before your rules: http://www.example.com first goes to https://www.example.com, and only then to https://example.com. That is two redirects instead of one.

It is enough if every variant already reaches the right address with no other change. Otherwise, hand everything to Redirect Rules (Rules → Redirect Rules), which change the protocol and hostname in a single hop. Example for the destination https://example.com:

Rule 1 — main domain (first):

• Condition (Expression Editor): (http.host eq "www.example.com") or (http.host eq "example.com" and not ssl)
• Dynamic target: concat("https://example.com", http.request.uri.path)
• Status code: 301
• Preserve query string: on.

Rule 2 — other subdomains over HTTP (optional, last): it replaces Always Use HTTPS for the rest of the zone.

• Condition: (not ssl)
• Dynamic target: concat("https://", http.host, http.request.uri.path)
• Status code: 301
• Preserve query string: on.

A redirect stops the evaluation of the following rules, so order matters. Follow these steps so the site is never left without HTTPS:

1. create and enable both rules;
2. turn off Always Use HTTPS;
3. check the result in Redirect Audit: each variant should arrive in a single 301.

Hostnames must be proxied by Cloudflare (orange cloud) for Redirect Rules to run. If the redirect already lives in a Worker, change the Worker instead of adding a second redirect layer.

Watch out: the “Flexible” SSL/TLS mode can cause a loop when the origin server also forces HTTPS. Whenever possible, use “Full (strict)” with a valid certificate on the origin.

Apache

If you manage a VirtualHost for port 80, Apache recommends a permanent redirect:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    Redirect permanent / https://example.com/
</VirtualHost>

The HTTPS VirtualHost is configured separately. If you only have access to .htaccess, and the server knows directly whether the connection uses HTTPS, you can combine the protocol and hostname change:

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

Put these rules before the WordPress rules and adapt them to your setup. Behind a proxy or CDN, %{HTTPS} may not reflect the protocol the visitor used.

Nginx

In the port 80 server block, redirect directly:

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

Also add an HTTPS block for www.example.com if it must be redirected: it needs a valid certificate for that name. Keep a separate HTTPS block that actually serves example.com. Before applying, run nginx -t, then reload Nginx.

LiteSpeed / OpenLiteSpeed

LiteSpeed accepts most Apache-style rewrite rules. If you use .htaccess, check that reading this file and rewriting are enabled. With OpenLiteSpeed, these options must be turned on explicitly, and a restart may be needed after a change.

Check the result

Test the domain root and an inner page, for example /products/?ref=test, to make sure the path and parameters are kept. In Redirect Audit, the final destination should be on HTTPS and the domain variants should all reach the same address.

These examples are a starting point: adapt them to your setup and test them before applying them to a live site.