An HTTPS redirect loop happens when requests keep being redirected instead of reaching the intended page. The browser eventually stops following them. A new certificate or another WordPress plugin will not necessarily resolve the disagreement between the systems issuing those redirects.
Start with the address sequence and the settings that could produce it. Keep the investigation small: capture the failure, identify the conflicting decision, change that decision, and repeat the same checks.
Record the fault before editing anything
Write down the affected address, the exact browser error, and a recent failure time with its time zone. Note whether the problem affects the whole site, a particular path, or only login.
Record recent changes, including a proxy activation, certificate installation, domain preference, or redirect plugin setting. Preserve the current redirect configuration before editing it. Have a recovery route that does not depend on the WordPress dashboard, since a mistaken address change can make that dashboard inaccessible.
Stop here if you cannot identify the correct hosting account or preserve its working configuration. Ask the account administrator to join the investigation.
Capture the redirects for four starting addresses
Choose a public page that should load without a login. In the browser's Network panel, preserve requests across navigation and inspect the document requests. Record each response status and its Location destination, keeping the order. The Chrome Network reference explains these views.
Repeat with these four starting forms, replacing the example domain with your own:
http://example.com/https://example.com/http://www.example.com/https://www.example.com/
Use the same public path for each comparison. Stop after the repeating pattern becomes clear; there is no value in repeatedly reloading a failing checkout.
Keep private tokens and customer information out of shared captures. A command line header check can supplement the browser record, but a different request method or session may produce different behaviour. Keep the actual browser failure as the reference.
Identify what changes at each hop
Compare the scheme, hostname, and path separately.
A sequence alternating between HTTP and HTTPS suggests opposing scheme decisions. A sequence alternating between example.com and www.example.com suggests opposing hostname preferences. A redirect back to the same visible HTTPS address can still involve disagreement between a proxy and the origin server.
If only a private account path loops, investigate authentication and session handling as well. Do not treat every redirect error as an SSL configuration problem.
Choose the intended destination before changing rules. Write it as a complete address, including HTTPS, the preferred hostname, and any required application directory. Every relevant rule should lead towards that decision rather than away from it.
Check the Cloudflare connection to the origin
With a proxy, the visitor connection and the connection to the hosting server are separate. The browser's successful HTTPS connection does not establish how the proxy contacts the origin.
Cloudflare's redirect troubleshooting guide describes a common conflict: Flexible mode sends HTTP requests to the origin, while the origin redirects HTTP to HTTPS. The browser can keep receiving a redirect to its existing HTTPS address. Full or Full strict can also conflict with an origin rule that sends HTTPS back to HTTP.
Check the effective encryption mode and redirect rules for the affected hostname. Record Always Use HTTPS settings as well. Identify the mismatch before deciding which configuration needs correction.
Do not blindly switch to Full strict. Its documented prerequisites include HTTPS on port 443 and an unexpired origin certificate, issued by a publicly trusted authority or Cloudflare Origin CA, with a matching hostname. Ask the hosting administrator to verify those requirements first.
A certificate validation failure is a stopping point for certificate investigation. Do not bypass browser warnings or leave certificate checks disabled as the solution.
Check the hosting redirects before changing the application
In cPanel, review the affected domain's Force HTTPS Redirect setting and its separate Redirects entries. Confirm that a rule applies to the intended domain and path. Do not change every domain in the account to troubleshoot one website.
The cPanel Domains documentation describes the HTTPS control. Its Redirects documentation also explains that redirects can interact with application rules.
Compare these settings with the proxy configuration and the intended hostname. If a server rule needs inspection, preserve its current contents and involve somebody who understands the web server configuration. Replacing the entire .htaccess file with a generic snippet can remove unrelated application behaviour.
Review WordPress addresses and proxy awareness
Check WordPress Address and Site Address against the deployment's intended locations. They have different purposes: the first identifies the core installation location, while the second identifies the public site address. They may legitimately differ when WordPress occupies its own directory.
The official General Settings documentation explains these fields and the configuration constants that can override them. A value that cannot be edited in the dashboard may require investigation of that override, rather than repeated attempts to save the field.
If the loop concerns HTTPS administration behind a reverse proxy, ask the administrator to check how WordPress recognizes the original connection. The WordPress HTTPS guide documents that situation. Any forwarded scheme handling must match a properly configured proxy; do not paste a universal header workaround into an unfamiliar environment.
Inspect redirect related plugins only when the evidence points there. Test the suspected rule or component through an agreed recovery procedure instead of disabling every plugin at once.
Hypothetical example: two hostname preferences disagree
Consider an invented configuration with valid HTTPS:
- A proxy rule sends
https://example.com/shop/tohttps://www.example.com/shop/. - The application's hostname preference sends the request back to
https://example.com/shop/. - The first rule applies again.
The captured sequence alternates hostnames while remaining on HTTPS. Switching encryption modes would not resolve those opposing preferences.
The next step is to verify which component issued each redirect, agree on the intended hostname, and amend the conflicting preference. Preserve any legitimate installation directory in the application addresses.
Then repeat all four starting addresses and the original shop path. An acceptable result reaches the intended HTTPS page without revisiting an earlier address. This example illustrates a diagnostic decision, not a reported customer incident or test result.
Verify the repair before closing the incident
Make one justified change at a time and record its effect. If the expected result does not appear, compare the new sequence with the original before changing another layer.
Check a public page and the login journey. Confirm that HTTPS remains active and that paths and required query parameters reach their intended destinations. Resolve certificate failures separately from redirect failures.
Where an obsolete redirect was cached, refresh the relevant cache after correcting the rule. The final record should identify the conflicting settings, the correction, and the successful checks.
If the investigation identifies a missing origin certificate, this cPanel AutoSSL reference explains the account interface. Confirm certificate issuance and the requirements of the actual hostname before changing the proxy's encryption mode.
Common questions
Can a temporary redirect create a loop?
Yes. Repeated destinations matter more than whether a redirect is temporary or permanent. Record the status and destination together.
Why does one browser still show the old failure?
A browser may retain a cached redirect. Compare a fresh session after the server configuration is corrected. Clearing a cache does not repair a rule that still produces the loop.
This article and the logo edit were prepared with AI assistance.
Top comments (1)
Great explanation! HTTPS redirect loops can become confusing when Cloudflare, web server redirects, and WordPress settings conflict. I agree that identifying the conflicting rule before making changes is important. This helps avoid unnecessary troubleshooting and configuration changes. Thanks for sharing!