Cloudflare “too many redirects” errors occur when the visitor’s request repeatedly returns to a URL or state that produces another redirect. Diagnose the chain across Cloudflare, the origin server, and WordPress before changing settings. A common cause is Flexible mode sending HTTP to an origin that insists on HTTPS, but hostname rules, reverse-proxy detection, application settings, and cached responses can also create loops.
The durable remedy is a consistent public URL policy backed by working origin HTTPS and the correct proxy configuration. Do not treat downgrading encryption, disabling certificate validation, or removing every redirect as a general solution. Identify the conflicting instructions and correct the responsible layer.
This guide is for authorized owners and maintainers of WordPress websites using Cloudflare. Its examples are conceptual and use fictional addresses. They are not traces from your installation or commands that have been executed against a live site.
Confirm that the problem is actually a redirect loop
Record the exact entry URL, browser error, time, and affected path. Check whether the problem affects the homepage, login, a particular directory, checkout, or every public URL. An SSL handshake error, invalid certificate, blocked request, and redirect loop require different investigations even if they appeared after the same configuration change.
Ask what changed: Cloudflare activation, SSL mode, origin certificate, host migration, domain preference, WordPress address, redirect plugin, or edge rule. Preserve the previous configuration where available. The latest change is a hypothesis to test, not automatic proof of the cause.
Inspect the response sequence. A loop may alternate HTTP and HTTPS, switch between hostnames, add and remove a path segment, or repeatedly redirect to what looks like the same public address. The hidden edge-to-origin request can explain why the same browser URL keeps returning a redirect.
Use a small, controlled trace
Capture enough evidence to identify repetition, then stop. Repeatedly refreshing an endless chain adds little value and may burden the site. Use read-only requests and browser tools appropriate to the authorized environment.
Chrome’s Network panel documentation explains request inspection. Preserve the entry URL, response status, Location target where present, and order of requests. Redact cookies and tokens before sharing the trace.
A browser can also apply stored security or redirect behavior before a network request reaches the server. Keep that possibility separate from a server response. A clean comparison context can help, but it does not prove that the website’s configuration is correct for all visitors.
Draw the two connections, not just the browser URL
Cloudflare sits between the visitor and the origin when the relevant hostname is proxied. The visitor-to-Cloudflare connection and Cloudflare-to-origin connection can use different transport settings. A certificate shown to the visitor describes only part of that path.
Cloudflare’s redirect-loop documentation explains the conflict created when Flexible mode uses HTTP toward an origin that redirects HTTP to HTTPS. It also describes loops caused by an origin redirecting HTTPS back to HTTP under Full modes and by opposing redirect rules.
Write the actual intended path in plain language. For example: visitors use one approved HTTPS hostname; Cloudflare connects to a correctly configured HTTPS origin; alternate public addresses lead to the approved destination without cycling. Then compare each layer’s current behavior with that intent.
A conceptual Flexible-mode loop
Imagine a fictional site whose browser address is https://example.com/. Cloudflare receives that secure request but contacts the origin over HTTP under Flexible mode. The origin sees HTTP and responds with a redirect to the public HTTPS address. The browser requests that address again, and the same origin condition repeats.
The browser may therefore appear to be redirected from an HTTPS URL back to the same HTTPS URL. The origin’s view explains the contradiction. The solution needs an aligned connection and redirect design, not a rule that ignores the visible repeated address.
This example does not establish that every site using Flexible mode has the same symptom. Trace your actual configuration and check the origin’s capabilities before selecting a change.
A conceptual opposing-hostname loop
Another fictional site has an edge rule directing www.example.com to example.com, while the origin or application directs the root hostname back to www.example.com. Each layer may look reasonable in isolation, but together they cycle.
Choose the approved public hostname and update the conflicting ownership deliberately. Confirm that certificates and application behavior support it. Do not merely remove the first rule you happen to find without checking the return path.
Preserve meaningful paths and parameters during normalization. A homepage test can pass while deeper product, campaign, or login URLs lose information or enter another loop.
Inventory the controls that can issue redirects
List Cloudflare redirect features, edge code where present, host control-panel rules, server configuration, WordPress settings, redirect plugins, security plugins, and relevant custom code. Add any load balancer or upstream proxy between Cloudflare and the application.
Use the actual configuration sources and owners. A redirect plugin’s list does not include every server rule. An .htaccess file does not describe an Nginx configuration. A CDN header can appear on an origin-generated redirect, so one header alone may not identify its author.
Cloudflare documents its redirect features. Review the active rule types and their current behavior rather than assuming one dashboard section contains all possible redirects.
Assign one coherent policy across layers
Several layers can legitimately enforce the same approved destination, but their conditions must agree. Document which layer is responsible for scheme, hostname, and special path migrations. Avoid maintaining the same logic independently without a clear reason and regression test.
For each rule, record its match condition, target, purpose, owner, and exception. Ask whether the target still matches the source condition. A broad pattern that also catches its own destination can create repetition even without another layer’s help.
Keep old migration rules in scope. A previous domain move, language redirect, or subdirectory change can interact with a new HTTPS policy. The relevant conflict may be an old rule that became visible only after the latest deployment.
Preserve the current state before editing
Export or record the active settings through supported tools. Keep secrets and private origin details restricted. Establish a recovery route that does not depend on the WordPress dashboard if that dashboard is part of the loop.
If changing a configuration file, preserve its original content and understand the server stack. It may contain access restrictions, routing, or host-managed sections. Replacing the whole file with a generic reset can create a wider outage.
For a store, define how current orders and other writes will be preserved. A redirect correction should not casually require restoring an older database. Choose the narrow deployment and rollback method that matches the actual change.
Establish valid origin HTTPS before selecting the intended mode
Confirm that the origin accepts the required HTTPS connection for the correct hostname and presents an appropriate certificate. Work with the host on the actual virtual host, port, certificate chain, and routing. The presence of a certificate file somewhere on the server does not establish that the requested hostname serves it.
Cloudflare’s Full (strict) documentation describes origin requirements, including a valid matching certificate issued by a supported authority and HTTPS connectivity. Check these prerequisites before enabling the mode intended for the final configuration.
If a mode change produces a certificate-related error instead of a redirect loop, diagnose the new observation precisely. It may reveal an origin prerequisite that was previously hidden. Do not mask it by disabling validation as the permanent outcome.
Understand Origin CA trust boundaries
Cloudflare Origin CA certificates are designed for the Cloudflare-to-origin relationship. They are not generally trusted by ordinary browsers visiting the origin directly. This matters when someone suggests bypassing the proxy as a quick test or fix.
Do not pause or remove proxying casually on a production hostname. Direct traffic may expose origin details, change security behavior, or encounter a certificate trust problem. Any origin comparison should be planned by the host or authorized maintainer with the correct hostname and trust assumptions.
A direct-origin test also answers a different question from the public path. Label its result separately. An origin that behaves correctly in isolation can still conflict with the edge or proxy metadata.
Keep certificate renewal and ownership visible
After the immediate repair, identify who maintains the certificate and relevant origin configuration. A valid connection today does not remove the need for renewal monitoring and supported host configuration.
Record the hostnames covered and any dependency on the CDN. A later DNS or proxy change can alter the trust path. The operational team should know what must be reviewed before making that change.
Do not publish private keys in a diagnostic record. Provider support can usually investigate with appropriate metadata and authorized access rather than receiving key material in ordinary messages.
Check how WordPress recognizes secure requests
WordPress and its extensions may make redirect decisions based on whether the application believes the request is secure. Behind proxies, that view needs a supported configuration reflecting the actual trusted request path.
The WordPress is_ssl() reference shows the application-level detection context. A proxy-aware correction should be made with the host or developer and should respect the trusted-proxy boundary. Do not blindly trust arbitrary client-supplied forwarding headers.
If the origin receives HTTPS correctly but the application still generates HTTP URLs or repeats a security redirect, inspect the platform’s current proxy guidance and host-managed settings. The appropriate correction can differ by infrastructure.
Review public and installation addresses carefully
Check the configured public site address and WordPress installation address, including overrides and host-managed values. They should match the intended architecture. They do not always need to be identical; an installation in its own directory can be legitimate.
Do not change these values merely to make a generic checklist pass. An incorrect edit can lock out administrators or break assets and integration paths. Preserve the previous values and a supported recovery route before a necessary change.
WordPress’s migration guidance helps frame address changes and stored data considerations. Use a supported method for the actual installation rather than a blind database replacement across unrelated values.
Inspect plugins and custom redirects without blanket deactivation
An SSL, security, domain-mapping, multilingual, or redirection component may participate in the chain. Identify the relevant setting or code from evidence. The fact that a plugin is installed does not prove it generated the observed redirect.
Use a controlled test environment for component isolation when practical. WordPress and commerce sites can depend on those components for important functions. Disabling everything on production can interrupt security, checkout, and routing while leaving a server-level conflict unchanged.
If a narrow setting change is justified, record its scope and verify the original path plus an unaffected comparison. A homepage improvement alone does not establish that login, account, or checkout routes are correct.
Distinguish edge HTTPS enforcement from HSTS
A configured edge redirect and a browser’s HSTS behavior are not the same mechanism. HSTS tells supporting browsers to use HTTPS for the relevant host according to the policy they have learned. It can make an insecure configuration more visible because the browser will not simply return to HTTP.
Cloudflare’s HSTS documentation explains setup and operational considerations. Do not enable a broad policy or preload-related settings as a speculative cure for a broken HTTPS path.
If a policy is already in use, account for stored browser state. Changing a dashboard option does not instantly erase every browser’s learned policy or preload behavior. Correct HTTPS continuity and involve the responsible maintainer before altering the policy.
Avoid solving a loop by weakening the intended transport
Removing all HTTPS enforcement can make one symptom disappear while leaving the site accessible insecurely or conflicting with existing browser expectations. That is not equivalent to a verified secure repair.
Write the intended final state before making changes. If an emergency rollback is necessary, document its scope, customer effect, and next corrective step. Do not quietly turn a temporary workaround into the permanent architecture.
After the repair, verify secure login and relevant customer actions. A loop-free page with broken authentication or insecure resources still needs work. Keep those findings distinct so the redirect case can be evaluated accurately.
Inspect browser and cache state after correcting the source
Browsers can retain redirects and site state. A clean comparison context helps distinguish stored behavior from a current response, but clearing cookies alone does not repair conflicting server instructions. Explain that difference to staff before asking them to erase useful sessions.
Inspect application, host, and edge caches where the evidence points to stored responses. Use the provider’s supported invalidation method for the affected scope. Cloudflare documents cache purging, but purging is not a substitute for correcting the rule that generates the response.
Record the before-and-after configuration and public result. If a cache refill recreates the loop, the source still needs investigation. If only one stored browser context remains affected, investigate its retained state without declaring that every visitor still receives the same response.
Keep cache and redirect policies separate
Some redirect responses may be generated outside ordinary content caching, and different layers can retain different behavior. Ask the provider what was purged and what was not. A generic “cache cleared” statement is not enough to explain the result.
Avoid repeated whole-site purges during a busy store period without a reason. They can increase origin work and complicate comparisons. A targeted correction and verification usually produce clearer evidence.
If the issue appears regional or intermittent, provide dated examples to the relevant provider. One local successful check cannot establish that every edge location and visitor context has been verified.
Use a read-only request example with clear limits
An authorized maintainer can inspect the first response without following redirects automatically. The following is an illustrative GET request for a fictional public address. Replace it only with a site you are authorized to inspect; it does not alter server configuration:
curl --silent --show-error --dump-header - --output /dev/null --max-time 20 'https://example.com/'The response headers can reveal a status and Location target. The example deliberately does not follow the destination. It does not execute JavaScript, reproduce every browser state, or prove which internal layer authored the response. A HEAD request can also behave differently from GET on some systems, so keep the method in the record.
Use bounded, purposeful comparisons with the host or developer. Do not add insecure certificate-bypass flags to make a failing HTTPS connection look successful. A trust failure is evidence that needs interpretation.
Record what each observation means
A redirect to the same visible URL suggests repetition but may involve a hidden origin scheme conflict. Alternating hostnames suggests opposing preferences. Repeated path changes suggest routing or normalization logic. These are hypotheses to confirm through the responsible configurations.
If no server redirect appears but the browser navigates, inspect client-side behavior and stored browser policy. If the browser reports a TLS error before receiving a response, do not keep debugging Location headers that were never delivered.
The useful output is a small trace and a concrete next question, not a large command transcript. Share only the evidence needed by the responsible owner.
Test the approved correction across meaningful paths
Choose a regression set before deployment. Include the approved HTTPS hostname, relevant alternate entry forms, a deep content page, login, and business-critical paths affected by the rule. For a store, use supported methods for customer and checkout verification.
Confirm that each entry reaches the intended final page without repetition, that certificates are valid for the actual connection, and that path and required query information survive. Test an already-canonical URL to ensure it does not redirect unnecessarily or match its own normalization rule.
Deploy the narrow approved change and preserve current data. A server or edge rule rollback should normally use its own configuration recovery, not an unrelated database restore. If the change includes application data, define its supported reversal separately.
Verify operational integrations where the change touches them
Login, password recovery, payment returns, provider notifications, forms, and API clients can use URLs beyond the homepage. Determine which are within the corrected rule’s scope and test the relevant ones through authorized methods.
A browser following a redirect successfully does not prove that every external client will handle the same chain. Use the integration’s documented endpoint requirements rather than assuming all requests behave like a visitor browsing a page.
Preserve the tested configuration and responsible owner. A later host migration or edge-rule update should repeat the appropriate regression cases so the same conflict is not reintroduced.
Work through an illustrative Cloudflare activation incident
Imagine a fictional WordPress business site that begins looping after Cloudflare is enabled. The team records the public request sequence, current encryption mode, origin redirect policy, and origin HTTPS capability. The visible browser URL repeats, but the configuration comparison reveals why the origin keeps seeing a request it wants to upgrade.
The host prepares the correct origin HTTPS configuration and verifies the certificate requirements. The authorized operator then applies the approved encryption and redirect design. The team does not disable validation or send customers to HTTP as the final remedy.
Acceptance covers the preferred hostname, alternate entries, deep pages, login, and relevant customer paths. The result and rollback configuration are recorded. If a later browser still shows stored behavior, that is investigated separately from the now-correct public response.
A different fictional site alternates between root and www hostnames. There, valid origin HTTPS alone does not resolve the opposing rules. The team chooses the intended hostname and corrects the conflicting layer. Similar browser errors therefore require different fixes when the chain is understood.
Follow a controlled investigation sequence
Use this sequence to turn the observations into a reviewable change. It is a diagnostic workflow, not a universal server configuration. The operator needs the appropriate access and an understanding of the actual hosting stack before changing anything.
1. Write the intended final address and preserved behavior
Specify the approved scheme, hostname, and public path layout. List the alternate entry forms that should normalize and the special routes that must remain valid. Include language paths, application callbacks, and meaningful parameters where the site uses them.
Ask the owner to resolve ambiguity before implementation. A developer should not choose a new public hostname merely because it makes a rule shorter. Changing that preference can affect links, integrations, cookies, certificates, and search representation. The intended destination should be a business and architecture decision expressed by the rules.
2. Capture one representative failing path
Select a path reported by a user and preserve its exact address. Record whether authentication or a particular session state is involved. Capture a bounded response sequence and identify the first repeated address or state.
If the browser changes scheme internally before a network request, note that separately. If a server returns a redirect, record its Location value. This distinction prevents a stored browser behavior from being assigned to an origin rule that never handled the request.
Do not collect a full private session when a public path can demonstrate the conflict. If the issue requires an authenticated context, restrict the capture and redact sensitive values before escalation.
3. Compare the active configuration with the observed chain
Review the edge and origin rules that could produce each step. Ask the host to identify server-generated behavior when you cannot see the relevant configuration. Check application settings and custom components only for the branch they can affect.
For each suspected rule, write the condition it sees and the destination it creates. If the rule’s input depends on proxy metadata, establish which trusted component provides that information. A plausible rule name is less useful than a demonstrated match between condition and response.
If no accessible configuration explains a step, state that gap. A provider trace or log review may be the next task. Do not fill the gap with a copied rewrite snippet.
4. Verify origin prerequisites independently
Have the responsible operator confirm the origin listener, hostname routing, certificate, and supported connection from Cloudflare. Keep any private-origin comparison controlled and separate from ordinary public acceptance.
If the origin cannot yet serve the intended secure connection, prepare that work first. Otherwise changing the public mode may trade one visible error for another. The goal is a coherent final path with valid prerequisites, not a sequence of dashboard changes until the homepage happens to load.
Record who owns the certificate and connection configuration so the prerequisite remains maintained after the incident.
5. Prepare one correction and its rollback
Name the specific conflicting instruction and the approved replacement behavior. Preserve the previous rule or setting and define how it will be restored if acceptance fails. Use a supported configuration mechanism rather than editing generated files that another system will overwrite.
If several layers must change together, document their order and the temporary states. A coordinated correction can be necessary, but the operator should know which intermediate response is expected and when to stop. Avoid presenting a multi-layer release as a one-setting experiment.
Keep unrelated cleanup out of the release unless it is required for the demonstrated problem. This makes the result easier to assess and reverse.
6. Test positive and negative rule boundaries
Positive examples are the entry forms that should redirect. Negative examples are already-correct URLs or exceptions that should remain unchanged. Both matter. A rule that normalizes an alternate hostname but also catches its own destination can recreate a loop.
Include deep paths and required parameters. Check for accidental path truncation, duplicated segments, incorrect encoding, or an unwanted switch between slash forms. The application’s real routing behavior determines which differences matter.
For a broad wildcard rule, have the developer review the match scope rather than relying on a single test. A successful root request is not enough evidence for every address the pattern can affect.
7. Verify fresh public output and relevant functions
After deployment, inspect the public path and any necessary fresh-cache response. Confirm the final page and valid secure connection, then check the functions touched by the rule. A login-specific correction needs a login check; a checkout return correction needs an approved transaction-path check.
Do not infer success from a dashboard save message. The served result is the acceptance evidence. Keep a small dated record with the configuration version, tested paths, observed result, and remaining untested scope.
If the first check fails, return to the trace and rollback plan rather than adding a second speculative rule on top of the first.
8. Remove temporary measures and assign maintenance
Reconcile any temporary customer notice, access restriction, diagnostic setting, or support workaround. Confirm that removing it does not reintroduce the original behavior. Staff should know which approved public address to use and who to contact if the symptom returns.
Store the rule inventory and regression sample with the site’s operational documentation. The next migration, CDN change, or domain-normalization update should reuse it. A repaired configuration without a maintained owner can easily drift back into conflict.
Recognize a different problem exposed by the repair
A successful redirect correction can reveal another issue that was previously unreachable. For example, the browser may now reach the intended HTTPS page but report a blocked insecure script. That is a mixed-content problem with a resource-source investigation, not evidence that the redirect correction failed.
Similarly, a certificate error can become visible when the connection changes to a mode requiring origin validation. The new evidence should lead to a certificate or routing check. It should not prompt a return to permanently unvalidated transport simply to restore the previous appearance.
An authentication loop can also be more specific than global HTTPS normalization. If only the login path cycles, review cookie scope, hostname consistency, application state, and relevant access components with the responsible maintainer. Do not clear all customer sessions or change every domain rule without understanding the affected branch.
Keep findings separate in the incident record
Use a separate row for each confirmed problem, its owner, and its acceptance test. The original loop may be resolved while a resource or integration issue remains open. That is a clearer operational picture than labeling the entire website either fixed or broken.
State the evidence that supports each conclusion. “The public request now reaches the approved page without repetition” is a redirect finding. “The checkout gateway script still requests an insecure resource” is a resource finding. “A provider callback has not been verified” is a remaining limitation.
This separation helps the business prioritize the next task without losing the completed work. It also prevents a specialist in one layer from being asked to certify unrelated functions that were never within the test scope.
Avoid misleading fixes that erase the diagnostic trail
Do not reset every plugin, replace all server rules, purge every cache, and switch encryption mode in one undocumented pass. Such a change may restore a page, but it can remove useful controls and make the cause impossible to identify. If an emergency requires broad rollback, record the full scope and verify the resulting security and business behavior.
Do not assume one browser’s success establishes general recovery. Compare the original affected context and the defined public paths. Where a provider-specific or regional question remains, preserve it as a follow-up with an owner instead of inventing global coverage.
Finally, do not retain an unexplained exception simply because removing it once caused trouble. Determine what it protects or corrects, document the supported behavior, and include it in maintenance. A clear rule with a clear purpose is easier to preserve than a collection of emergency toggles whose interactions nobody understands.
Prepare a handoff that answers the next question
For the hosting team, provide the affected hostname, timestamp, short response sequence, and the question about origin behavior. Ask whether the origin issued the redirect, which configuration produced it, and whether the intended HTTPS connection is supported. Keep private infrastructure details in the approved support channel.
For the WordPress developer, provide the intended address model, observed application-generated step, relevant plugins or customizations, and known host behavior. Ask which component decides the destination and whether it receives the correct trusted request information. This avoids another generic recommendation to install an SSL plugin.
For the Cloudflare administrator, provide the active rule inventory, relevant mode, affected public paths, and the origin findings already established. Ask for the specific edge decision or rule interaction still unresolved. If the evidence shows the origin created the response, say so while retaining any edge behavior relevant to the chain.
Each handoff should distinguish observation, hypothesis, and proposed change. Include what has already been changed, because an investigator looking at the current site may otherwise miss the configuration that produced the original report. Retain the earlier trace as historical evidence and label the new trace with its own time.
Close the handoff with a concrete acceptance question: does this path reach the approved secure destination while preserving the required behavior? That question gives every team the same outcome to verify. It is more useful than asking whether a single dashboard setting is correct in isolation.
After the answer arrives, update the shared record and remove superseded instructions. A staff member should not continue using an insecure temporary link or old hostname because the incident thread contains several conflicting suggestions. Keep the approved final state easy to find. Include the responsible contact and the exact regression paths so the next release can verify the same agreed outcome efficiently.
Frequently asked questions
Why can an HTTPS URL redirect to itself repeatedly?
The origin may see a different scheme from the visitor-facing URL because a proxy sits between them. A rule can keep asking for HTTPS even though the browser already uses it. Inspect both connection legs and the responsible configuration instead of judging the loop solely from the visible address.
Is Flexible mode always the cause?
No. It can conflict with an origin HTTPS redirect, but hostname normalization, path rules, proxy recognition, application settings, and other controls can also loop. Capture the actual sequence and compare the active instructions before selecting a correction.
Should I switch to Full (strict) immediately?
First verify the origin’s supported HTTPS and certificate requirements. The intended mode needs a prepared origin and coherent application behavior. If a change reveals a certificate error, diagnose that prerequisite rather than treating disabled validation as a permanent fix.
Will clearing cookies fix the problem?
It can change a stored browser context, but it does not repair conflicting edge, origin, or application rules. Correct the source and compare current responses. Use browser-state troubleshooting only for the part of the problem it can actually explain.
Should I pause Cloudflare to diagnose the origin?
Do not do it casually on production. Direct access can change security behavior, expose origin details, or fail browser trust with an Origin CA certificate. Plan an authorized origin comparison with the host and label its limits separately from the public request path.
Must the WordPress address and site address be identical?
Not in every legitimate architecture. An installation can use a different directory from the public site. Review the intended layout and any overrides before changing values. Preserve access and a supported recovery route so an address correction does not create a second outage.
Can an SSL plugin solve every Cloudflare redirect loop?
No. A plugin cannot necessarily correct a registrar, edge, server, or upstream proxy conflict. Identify the layer and use its supported controls. Adding another redirect mechanism without understanding existing rules can make the chain harder to diagnose.
What should I send the host or developer?
Provide the exact entry URL, time and time zone, short response sequence, affected scope, recent changes, current mode, and relevant configuration through a secure process. Redact credentials, cookies, and private origin details. State which boundary remains uncertain so the recipient can answer a specific question.
Align the redirect policy with a working HTTPS path
A reliable repair makes Cloudflare, the origin, and WordPress agree on the destination and connection they are meant to serve. Trace the conflict, prepare valid origin HTTPS, correct the responsible rule, and verify the paths the business actually uses.
Web Expert Solutions can help investigate Cloudflare redirect loops and prepare a WordPress HTTPS correction plan. Start with the observed chain and recent configuration changes so the work can target the conflicting layer and restore dependable secure access.
