Cloudflare in front, without two challenges in series.
Proxying a protected hostname through Cloudflare works, and plenty of customers do it. It works after you turn Cloudflare's own challenges off, because two challenge systems in series cannot both complete. This page is what to disable and where it lives, why we have to be told that a domain is proxied, and the record and encryption mode that make the second leg work.
1. Turn Cloudflare's own protection off first
Cloudflare in proxied mode, the orange cloud, puts a second filter in front of the one you bought. That part is fine. What is not fine is a second challenge. Cloudflare challenges a visitor by replacing the response with a document of its own and waiting for that document to report back. DEFLECTO does the same thing. Neither one can see the other finish, so the visitor sits between two pages that are each waiting for a result the other one is holding.
There is no configuration that makes two interstitials cooperate, on either side, and there will not be one. Pick which system challenges your visitors. If your hostname is behind DEFLECTO, that is DEFLECTO, and the settings below have to be off before anything else on this page matters.
You are not giving up protection by doing it. The signature ruleset, the proof of work, the rate limits and the judgements that get enforced in the network driver all run on the edge regardless of what Cloudflare is doing in front of it. What you keep from Cloudflare is what it is genuinely good at here: anycast reach, caching, and a very large amount of bandwidth in front of your web hostname.
- Bot fight mode
- Security > Settings, filter by Bot traffic, turn Bot fight mode off. This is the free plan bot product, and it is the most common cause of this whole page. It cannot be scoped or skipped: it does not run on Cloudflare’s rules engine, so a skip rule has no effect on it. Turning it on also turns on Cloudflare’s JavaScript detections, which injects a script of its own into HTML responses, including our interstitial, and that cannot be turned off separately while Bot fight mode is on.
- Super Bot fight mode
- Security > Settings, filter by Bot traffic. The paid plan version, and it does not have a single off switch. Set Definitely automated traffic, Likely automated traffic and Verified bots to Allow, then open the edit icon on Static resource protection, JavaScript detections and Optimize for WordPress and confirm each one is off. Static resource protection is the one that produces the most confusing symptom, because it challenges your scripts and stylesheets rather than your pages.
- Browser integrity check
- Security > Settings, filter by DDoS attacks, turn Browser integrity check off. It denies a request on the shape of its headers alone, and it is on by default. A visitor it denies never reaches the challenge that would have cleared them, so the effect is not a challenge in series, it is a refusal in front of one.
- Under Attack mode
- Zone overview page, Quick Actions sidebar, turn Under Attack Mode off. It presents a Cloudflare managed challenge to everybody, which is exactly the document that cannot coexist with ours. In the new security dashboard the same control is expressed as the security level rather than as a toggle. If you are genuinely under attack while behind DEFLECTO this is the wrong lever regardless: tell us, and the difficulty goes up at the edge, where a challenged request still costs you nothing.
- Rocket Loader
- Speed > Settings, Content Optimization, switch Rocket Loader off. This one is not a security feature, which is why it is the one people leave on. It rewrites every script in an HTML response and defers it until after rendering. Our interstitial is a single document with an inline solver in it, so rewritten and deferred, the solver either never runs or runs after the page has given up on it.
- WAF Managed Rules, but only the part that reads a POST body
- Security > Settings, filter by Web application exploits, to see what is deployed. Do not turn the ruleset off. Managed Rules do not challenge anybody, so they are not a second challenge in series. They block on content, and the only content of ours they ever see is the solution posted to
/.waf/verifyand a captcha token posted under/cap/v1/. If a rule matches one of those, add an exception rather than removing the ruleset: on the Security rules page, a rule with the Skip action, placed before the rule that executes the managed ruleset, matching those two paths. Turning the whole ruleset off is a much larger change than the problem, and it removes cover you are paying for. A managed rule blocking a request looks like a Cloudflare block page with a ray ID on it, not like the 400 in the next section.
Anything else that issues a challenge counts as well. A WAF custom rule with an action of Managed Challenge, JS Challenge or Interactive Challenge, a rate limiting rule with a challenge action, an IP Access rule set to challenge: all of them serve a Cloudflare document in place of ours and produce the same stall. Block actions are not a problem in the same way, because a block is an answer rather than a conversation.
Every path above was read from Cloudflare’s own documentation rather than from memory, and it was correct on 20 August 2026. Cloudflare is currently running two dashboards, an older one and a new security dashboard, and the same control does not sit in the same place in both. Under Attack mode is the clearest example: a toggle in one, a security level in the other.
If a name here does not exist in your account, search the dashboard for the words rather than picking the nearest looking match, and tell support what you found instead. A doc that names a menu which no longer exists is worse than no doc, and we would rather fix this page than have you guess at it.
2. The challenge never completes
A domain proxied through Cloudflare before we have been told it is proxied breaks in a way that does not look like a proxy problem from a browser. What follows is what a customer sees, and it is written out because those words are what somebody searches for at two in the morning.
- The challenge reaches 100 percent and then fails.
- The page reads Verification could not be completed (HTTP 400). Please reload the page to try again. The solver did its work and the answer was correct, and it was refused anyway. A reload sometimes appears to fix it for exactly one page load, and the next page fails the same way, which is the detail that sends people looking at their own site.
- Scripts and stylesheets arrive as HTML.
- A request for a
.jsfile is answered with the interstitial document instead. The status is 200 and the body is a page, which is the worst combination for diagnosis because nothing in the network tab looks like an error. - The console fills with syntax errors.
- A run of
Unexpected token ’:’and its neighbours. That is the browser parsing an HTML document as JavaScript. It is the row above, not a separate fault, and chasing it through your own bundler is a wasted afternoon. - Rate limits and bans land on people who did nothing.
- A per-address limit is being spent by the whole crowd that shares one route into the edge. One noisy client takes the budget for everybody alongside it, and a ban on it removes all of them. This is the quiet half of the failure, and unlike the challenge it does not announce itself.
That is a setting on the edge rather than anything on your side, so tell us in a ticket or to support that the domain is proxied through Cloudflare, and we enable it for that domain.
Reachable from Cloudflare is not the same as reachable only from your zone. Cloudflare’s network is shared by everyone who has an account on it, so arriving through Cloudflare is not on its own evidence of which Cloudflare configuration a request started in.
Close that with something an attacker cannot borrow. Turn on Authenticated Origin Pulls in your own dashboard and we will require the client certificate, or have your Cloudflare configuration add a secret header and we will require that. Ask for one at the same time as you tell us the domain is proxied, and treat the gap before it as temporary.
3. The record, and which address it points at
In Cloudflare’s DNS tab, the A record for your web hostname points at the service address we issued you, the one shown in your panel, and the cloud next to it is orange. That is the whole change on the Cloudflare side.
The address matters more than it looks. A node answers on more than one address, and only one of them is the address it serves your traffic on. Point the record at any of the others and you get a 525 with an otherwise perfect configuration, on both sides, which is about as unhelpful as an error gets. Copy the address from the panel, do not infer it from a traceroute or from an old ticket.
Your hostname also has to be provisioned here before Cloudflare sends it anything. The edge refuses a handshake for a name it does not recognise, deliberately, so that it cannot be used as an anonymous front for somebody else’s domain. Cloudflare reports that refusal as 525 as well, which is why the two causes look identical from a browser: confirm the address first, then confirm the hostname is on your account here.
; the web hostname, proxied by Cloudflare (orange cloud)
example.com. 300 IN A <the service address in your panel>
; anything that is not HTTP stays unproxied (grey cloud), see section 5
play.example.com. 300 IN A <the service address in your panel>- 521
- Nothing is listening, or the port is filtered on the way. Almost always the wrong address in the record, or a firewall between Cloudflare and the edge.
- 525
- The TLS handshake failed. Either the record points at an address that terminates nothing for you, or the hostname is not provisioned here yet. Those are the only two causes worth checking before you ask us.
- 526
- The handshake worked and Cloudflare would not accept the certificate. That is not a DNS problem at all, it is the mode in the next section: you are on Full (strict) without a certificate the public world trusts.
4. The three encryption modes
Your SSL/TLS encryption mode, on the SSL/TLS Overview page of your own dashboard, decides what Cloudflare requires of the edge on the second leg. Nothing on our side chooses it and nothing on our side can override it, so it is worth knowing which one you are in before an error code arrives.
| You set | What the edge then needs | Works today |
|---|---|---|
| Flexible | Nothing. Cloudflare connects to the edge on port 80 in the clear, so no certificate is involved, and the edge serves port 80 for any hostname routed to it. | Yes, with the redirect hazard below. |
| Full | Only that your hostname is provisioned here. Cloudflare connects over TLS and accepts any certificate, including one issued for a different name or already expired, so all it needs is a handshake that finishes. | Yes. This is what a proxied domain runs on today. |
| Full (strict) | A real certificate on the edge, valid for the hostname and chaining to a CA Cloudflare trusts. Two routes: ACME issued through the proxy, or a Cloudflare Origin CA pair you generate and hand to us. A self signed certificate will not do, and the symptom for that is 526, not 525. | Yes, once one of those two is in place. |
Cloudflare lists two more. Off is plaintext on both legs and is not a mode to run a protected site in. Strict (SSL-Only Origin Pull) has the same certificate requirement as Full (strict) and additionally connects over TLS even when the visitor arrived over plain HTTP, so if you can satisfy Full (strict) you can satisfy that one.
The two routes to a real certificate are worth separating, because they fail for different reasons. ACME works through Cloudflare: validation arrives on port 80 for a path under /.well-known/acme-challenge/, Cloudflare forwards it, and the edge answers it from an exact token lookup. Two of your own settings break that, aggressive caching of that path and any redirect to HTTPS while you are on Flexible. A Cloudflare Origin CA pair is the other route: you generate it in your own dashboard, it is free, it lasts years, and it needs no inbound reachability at all, so it works in cases where ACME cannot. It is trusted by Cloudflare and by nobody else, which is exactly right for this leg and worthless to a visitor who reaches the edge directly, so we install it exactly as you give it to us and never try to renew it.
Flexible means Cloudflare fetches your site over plain HTTP. If anything behind it answers that with a redirect to HTTPS, the visitor goes back to Cloudflare, Cloudflare fetches HTTP again, and the loop has no exit. The browser reports too many redirects rather than a page.
That includes us: nothing we serve for a hostname on Flexible redirects to HTTPS. It also includes a redirect written into your own origin. Cloudflare’s Always Use HTTPS, on SSL/TLS > Edge Certificates, is the safe place to force HTTPS on Flexible, because it answers the visitor before the request is ever forwarded. Choose Full instead and the whole question goes away.
New zones default to Automatic SSL/TLS, where Cloudflare probes your site and picks the mode itself, ramping from one percent of traffic upward. It will not move you to a less secure mode, but it will move you, and the mode is the thing that decides whether the edge needs a certificate at all.
If you would like to know in a month what the second leg is doing, select Custom SSL/TLS and set Full explicitly. Then the answer to “what changed” is never the encryption mode.
5. What the orange cloud cannot carry
Cloudflare’s proxy carries HTTP and HTTPS, on a fixed list of ports, and nothing else. It does not carry a game server, Minecraft, FiveM, a voice server, a database, SSH or mail. Arbitrary TCP through Cloudflare is a separate Enterprise product, Spectrum, and it is not what the orange cloud does.
This is worth knowing in advance because of how it fails. A client pointed at an orange-clouded record for a game port does not get an error page, it does not get a timeout you can read, it gets no connection at all, and there is nothing in any log on your side to explain it. People find this out by spending an evening on it.
- Proxy the web hostname, leave everything else grey. The game record points at the same edge address with the cloud turned off, or lives on a separate hostname that is never proxied. Both reach the edge directly and are protected exactly as before.
- Leave mail alone. MX records, and the hostname they name, must keep resolving to your mail server and must not be proxied. This is the same rule as in the going live guide, and it is the one people break while tidying up a zone.
- The unproxied half sees real addresses. Traffic that reaches the edge directly arrives from the visitor, so there is nothing to arrange for it. That half of your traffic is judged on real addresses whatever the web half is doing.
One consequence is worth saying plainly: putting Cloudflare in front of your website does not put it in front of your game, and it never will. If what you are protecting is a game server, the orange cloud is decoration on the part of your traffic that was never the problem.