For a non-www (apex) canonical site, the final address should be https://example.com. Make sure both example.com and www.example.com reach the service that owns your redirect, verify that the TLS certificate covers every HTTPS hostname, then create one permanent rule from https://www.example.com/* to https://example.com/$1 with the query string preserved. Treat HTTP-to-HTTPS enforcement as a separate rule. Keeping those responsibilities separate prevents the most common loops and “HTTPS works, but www will not disappear” failures.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
What is actually being redirected?
HTTPS and hostname canonicalization are two different decisions. HTTPS changes the transport scheme from HTTP to HTTPS. Canonicalization changes the hostname from www.example.com to example.com, or the other way around. A browser can therefore receive several different URLs for the same page:
As an Amazon Associate I earn from qualifying purchases.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match| Request | Desired result for a non-www canonical site |
|---|---|
http://example.com/path?x=1 |
Redirect to https://example.com/path?x=1 |
http://www.example.com/path?x=1 |
Redirect to https://example.com/path?x=1 |
https://www.example.com/path?x=1 |
Redirect to https://example.com/path?x=1 |
https://example.com/path?x=1 |
Serve the page without another redirect |
The path and query string should survive a hostname-only change. A request for /news?id=42 must not be reduced to the home page, and a tracking or search parameter must not disappear unless you intentionally remove it.
Choose one canonical hostname before editing anything
This guide assumes the apex, or non-www, hostname is canonical. Decide this first and remove rules that make the opposite choice. A rule sending the apex to www and another sending www to the apex will create a redirect chain or loop, depending on which layer answers first.
#1 Best Overall
Write down the intended endpoint exactly, including scheme: https://example.com. The redirect should change only what is necessary: HTTP becomes HTTPS, and www is removed. Do not maintain competing canonical rules at the edge, load balancer, web server, CMS, and application.
Check DNS, proxy routing and certificates
Both hostnames must reach the redirect owner
A redirect rule cannot run for a hostname that never reaches the system containing that rule. Confirm that DNS records for both example.com and www.example.com resolve to the service intended to answer them. If traffic is proxied through an edge provider, both names must use that provider’s proxy path. If a name is DNS-only, the origin server or load balancer must handle its HTTPS request and redirect.
Alias-domain redirects can run at an edge without a separate origin site, but the alias still needs DNS that reaches the edge. An unproxied record bypasses edge Redirect Rules and Always Use HTTPS settings entirely.
The certificate must cover every HTTPS name users request
The TLS handshake happens before an HTTPS redirect can be returned. The certificate at the layer terminating TLS therefore needs a valid name for example.com and www.example.com. A proxied hostname may use the edge provider’s certificate; a DNS-only hostname requires the origin certificate to cover that name. If https://www.example.com shows a certificate-name warning, fix certificate coverage first rather than adding more redirects.
Implement the www-to-apex redirect at the edge
At an edge service, create one rule that matches the HTTPS www hostname and returns a redirect to the HTTPS apex hostname. Cloudflare’s documented pattern uses a wildcard match such as https://www.*, a target of https://${1}, status 301, and query-string preservation enabled. For a single site, use the explicit equivalent:
- Match:
https://www.example.com/* - Target:
https://example.com/$1 - Status:
301 Permanent Redirect - Preserve query string: enabled
The wildcard capture represents the original path. Thus, https://www.example.com/videos/episode-7?season=2 becomes https://example.com/videos/episode-7?season=2. Replace the example hostname and retain the path component used by your edge product.
Free tools Windows power users keep installed
One-click scans. No signup required.
Do not create the reverse rule at the same time. The separate reverse pattern—matching https://example.com/* and targeting https://www.example.com/${1}—is only for a site that deliberately chooses www as canonical.
Use a temporary status while testing
During changes, use a temporary redirect if your edge supports one. Browsers and intermediary caches can retain a 301, making a corrected rule appear broken after you have fixed it. Once all four URL combinations converge correctly, change only the canonical-host rule to 301 and test again in a fresh browser session and with a cache-bypassing client.
Enforce HTTP-to-HTTPS without creating a loop
If every path on the site supports HTTPS, enforce HTTP-to-HTTPS at the edge. An active edge certificate is required before an edge service can safely redirect HTTPS requests. Keep the host-normalization rule and scheme-enforcement rule logically distinct: one changes http to https, while the other removes www.
Cloudflare advises checking both dashboard rules and origin redirects when diagnosing loops, and recommends not performing the same redirect at the origin web server because duplicate ownership can produce redirect-loop errors. If the edge already redirects HTTP requests, remove an unnecessary duplicate rule from the application or web server, or make sure it only handles requests that genuinely arrive over HTTP.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Fix origin behavior when TLS terminates at a proxy
A reverse proxy or load balancer can terminate TLS and then send plain HTTP to the origin. The visitor’s request is HTTPS, but the origin connection is HTTP. Apache documents that in this arrangement the %{HTTPS} variable can remain off. An origin rule that checks that variable may therefore redirect an already-secure request to HTTPS again, producing a loop at the edge.
Pass the original scheme from the proxy and configure the application or framework to trust that forwarded scheme header. The exact setting depends on the proxy and application, but the required outcome is consistent: the origin must recognize a request as HTTPS when the client-to-edge connection was HTTPS. Do not blindly trust scheme headers from untrusted public clients; accept them only from your controlled proxy path.
After correcting scheme detection, inspect the application and CMS for their own “force HTTPS” or canonical URL settings. Set their canonical base URL to https://example.com and remove any setting that sends the apex back to www.
Avoid Flexible encryption loops
If the origin itself redirects HTTP to HTTPS, do not switch an edge service to a mode that connects to the origin over HTTP merely to make the warning disappear. Cloudflare Tunnel guidance specifically recommends either using an HTTPS service URL for the origin or removing the origin redirect and using HTTP consistently for that internal leg; it says not to switch to Flexible as a loop workaround.
Recommended Free Tools
The safe design is consistent scheme handling: terminate HTTPS at the edge, connect to the origin over HTTPS when the origin expects HTTPS, and configure the origin to trust the proxy’s original-scheme information. Mixing an HTTPS redirect at the origin with an HTTP-only edge-to-origin mode is a common reason the same URL alternates between two layers indefinitely.
Rank #4
Use this troubleshooting sequence
- Choose the canonical host. Set
https://example.comas the sole endpoint. Search edge, load-balancer, web-server and application settings for rules that point towwwand disable conflicting directions. - Check DNS and routing. Verify that both hostnames resolve to the service that should answer them. A DNS-only name will not execute an edge redirect; it must be handled by the origin.
- Check certificate coverage. Test both HTTPS hostnames independently. The certificate presented at the TLS-terminating layer must include each requested name.
- Inspect every hop. Request
http://example.com,http://www.example.com,https://www.example.comandhttps://example.comwith a header-following client. Record each status andLocationheader. The final response should be the HTTPS apex with the original path and query intact. - Find the redirect owner. Review edge Redirect Rules and “Always Use HTTPS,” then the load balancer, Apache or other origin server, and the application or CMS. Remove duplicate rules and any rule that points back to the previous hostname.
- Correct proxy scheme handling. If TLS ends upstream, pass the original scheme and configure the application to trust that proxy. Otherwise the origin can believe every secure request is HTTP and redirect repeatedly.
- Remove Flexible-loop configurations. Use an HTTPS origin URL, or consistently use HTTP internally without an origin HTTPS redirect. Do not change to Flexible as a loop fix when the origin insists on HTTPS.
- Retest before permanence. Validate status codes, paths, query strings, certificate names and cache behavior with a temporary redirect. Change to 301 only after the four combinations converge in one or two expected hops.
Read the redirect chain to locate the fault
| Observed behavior | Likely cause | Correction |
|---|---|---|
https://www returns 200 and keeps www |
No www-to-apex rule owns the HTTPS request, or DNS bypasses that owner. | Route the hostname to the redirect service and add the explicit HTTPS www rule. |
| Certificate warning before any redirect | The TLS certificate does not cover the requested hostname at the terminating layer. | Install or enable coverage for both apex and www names. |
| Apex redirects to www, then www redirects to apex | Opposing canonical-host rules exist. | Keep only the direction matching your chosen canonical host. |
| Browser reports too many redirects | Edge and origin both enforce conflicting schemes, or the origin misreads proxied HTTPS. | Inspect each Location, remove duplicate ownership and fix forwarded-scheme trust. |
| Path changes to the home page | The target omits the wildcard path capture. | Include $1 or the equivalent capture and preserve the query string. |
| Query parameters disappear | Query preservation is disabled or the target rebuilds the URL. | Enable preserve-query-string and test a URL containing multiple parameters. |
| HTTP works, HTTPS www fails only when DNS-only | The origin lacks TLS or a certificate for www. | Configure origin HTTPS and certificate coverage, or proxy the hostname through the edge. |
Test with headers, not just a browser
Browsers cache redirects and may hide intermediate responses. Use a header-following tool and inspect each hop separately. For example, run a request that displays headers and follows redirects, then repeat without following redirects so that each Location value is visible. Test a deep path and a query string rather than only the home page:
curl -I http://example.com/game/guide?platform=pc
curl -I http://www.example.com/game/guide?platform=pc
curl -I https://www.example.com/game/guide?platform=pc
curl -I https://example.com/game/guide?platform=pc
curl -IL http://www.example.com/game/guide?platform=pcThe expected final URL is https://example.com/game/guide?platform=pc. A temporary 307 or 302 can be useful while editing; after validation, the canonical www-to-apex response should be a 301. Keep the number of hops to one or two: one hop can combine scheme and host normalization, while two predictable hops can separate them when your platform requires it.
Keep redirect ownership simple
Assign each responsibility to one layer. An edge rule is usually the cleanest owner for host and scheme normalization because it runs before the request reaches the origin. The origin should still serve HTTPS correctly for any traffic that reaches it directly, but it should not fight the edge with a contradictory canonical hostname. A load balancer should pass the original scheme and host accurately, and the application should generate links using the same canonical base URL.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Document the final arrangement: DNS mode for each hostname, certificate location, edge rules and status codes, proxy headers trusted by the origin, and the expected result for all four input combinations. This record makes later CMS, hosting or certificate changes less likely to reintroduce the loop.
Quick Recap
Final validation checklist
https://example.comserves without a redirect.https://www.example.comreturns a single host-normalization redirect to the apex.- Both HTTP variants reach HTTPS and do not bounce between hosts.
- The certificate presented for each HTTPS hostname is valid for that name.
- Deep paths, fragments’ server-visible portions, and query strings are preserved; URL fragments are never sent to the server and therefore cannot be redirected server-side.
- No edge, origin, proxy or application rule sends the request in the opposite direction.
- The origin correctly recognizes HTTPS when TLS terminates upstream.
- Only after testing is complete, the permanent 301 is enabled and caches are considered.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
