Investigate a Cloudflare 521 error by checking whether the origin web server is accepting the connections Cloudflare needs. Collect the affected hostname, time, error details and recent changes, then ask the responsible administrator to inspect the origin and relevant filtering. Keep a record of each observation before changing configuration.
Cloudflare defines error 521 as the origin web server refusing its connections. This definition gives the investigation a useful starting point. The error is a connection problem between Cloudflare and the origin, so begin with evidence from that path. A browser error page alone does not identify which origin process or security rule needs attention.
What evidence should you collect before making a change?
Record the full affected URL without exposing private query parameters, the visible error, the observation time and whether other paths on the same hostname behave similarly. Add the identity of the person responsible for the hosting environment. If a recent change is known, record exactly what changed rather than assuming it caused the incident.
Cloudflare lists an offline origin web application as a common cause of 521. Cloudflare also lists blocked Cloudflare requests as a common cause of 521. The 521 troubleshooting page therefore supports two distinct lines of enquiry: the origin application’s availability and the treatment of Cloudflare requests. Keep both open until the evidence points to a cause. Repeatedly refreshing a page will not distinguish them.
Ask the administrator to retain a short evidence snapshot before a restart or configuration edit. It should identify the affected site, relevant listener, log period and any filtering decision. On shared hosting infrastructure, keep the investigation within the affected site’s scope. Broad service changes deserve particular care because they may affect unrelated sites.
How do origin and filtering checks differ?
Cloudflare recommends reviewing origin error logs for crashes or outages. Request the relevant origin log evidence alongside the visible error time. A process failure and a blocked connection call for different remedies. Record what the log actually shows, including the absence of a matching entry if that is the observation. Do not turn missing evidence into a confident diagnosis.
Ask whether the origin application is responsive and listening where the configured connection expects it. Separately, have the responsible administrator inspect firewall or security decisions involving Cloudflare traffic. Use Cloudflare’s current official IP-range references when evaluating those rules. Do not copy a remembered address list into an incident fix.
Where a rule blocks legitimate traffic, prepare a narrowly scoped correction and retain the prior configuration. Do not disable the whole security layer to obtain a quick-looking result. The objective is to restore the intended path while preserving a clear explanation of the change and a route back if the hypothesis is wrong.
| Observation | Question for the administrator | Evidence to retain |
|---|---|---|
| Origin application appears offline | Which site process is affected? | Relevant service state and log period |
| Origin responds but Cloudflare path fails | Are Cloudflare connections blocked or limited? | Matching filtering decision |
| Listener differs from expected connection | Which port does the selected mode require? | Mode and listener comparison |
| Error changes after intervention | What does the new code describe? | Before-and-after response |
| One site fails on a shared server | Which configuration belongs to that hostname? | Site-specific configuration reference |
How do HTTPS mode and certificates fit into a 521 investigation?
Cloudflare documents port 443 for origin connections using Full or Full (Strict). The 521 guidance makes the configured encryption mode relevant to the origin listener. Record that mode before asking the administrator to compare it with the actual connection path. A mismatch is a specific finding to investigate; changing several unrelated settings at once makes the result harder to explain.
Cloudflare requires HTTPS connections on port 443 before enabling Full (strict). This Full (strict) prerequisite is one part of the HTTPS check. Confirm the intended listener before moving on to certificate properties. A server that refuses the required connection cannot be diagnosed solely by looking at a certificate file on disk.
Full (strict) requires an unexpired origin certificate. Full (strict) accepts certificates issued by a publicly trusted authority or Cloudflare Origin CA. Full (strict) requires a matching Common Name or Subject Alternative Name. Compare these certificate requirements with the certificate actually presented for the affected hostname. Record the hostname used for the test and the resulting certificate identity. A different site’s valid certificate is not evidence that this hostname is configured correctly.
Failure to satisfy Full (strict) prerequisites can produce a 526 error. If the visible code changes during investigation, reassess it using the relevant documentation. Do not treat every new failure as the original 521 persisting unchanged. Preserve the intended HTTPS design while correcting the demonstrated fault; lowering protection is not a substitute for understanding the failing prerequisite.
Original incident card: one hostname and one hypothesis at a time
This hypothetical incident concerns a fictional website, sample.example. A visitor reports 521 after an administrator has changed site configuration. The recent change is a lead to inspect, not proof of cause. Use the following card to organise the conversation with the person who controls the origin.
Observation. Record the hostname, affected path, observed code and local time with its timezone. Note whether the public homepage and another known path show the same result. Retain an appropriate screenshot or response excerpt with personal information removed. Give the incident a stable reference so later evidence does not become scattered across messages.
Connection expectation. Record the configured Cloudflare mode and the corresponding expected origin connection. Ask the administrator to identify the site configuration and listener that should receive it. Keep desired configuration and observed configuration as separate fields. This avoids accidentally treating the intended setup as a measurement of the live one.
Origin evidence. Ask for the relevant application state and error log around the observation. Record a concrete result such as “site process unavailable” or “listener present, further filtering review needed” only when supported by the administrator’s evidence. An uncertain result remains an open question with a named next action.
Filtering evidence. Record whether a matching security decision explains the refused path. If a correction is proposed, describe the affected rule, why the traffic should be permitted and how the previous configuration will be retained. Obtain the necessary operational authority before applying it. This drafting worksheet does not authorise a production change.
Controlled intervention. Agree one correction, its owner and its recovery step. After the authorised change, repeat the same observation and compare the result. If the hypothesis fails, return to the evidence card before introducing another change. Repeated unrelated edits can make an outage harder to diagnose and leave unnecessary configuration behind.
Recovery check. Inspect the original URL and a representative user journey after connectivity returns. Confirm the intended encryption mode and ask whether any temporary incident change remains. Record the final cause only when the evidence supports it, together with the corrective action and the person responsible for follow-up.
What should the hosting handover include?
A useful handover contains the symptom, affected scope, cause evidence, exact authorised correction and verification result. Add any remaining action separately, such as improving the site’s monitoring or clarifying who owns its security rules. Keep recovery observation distinct from a promise that the site cannot fail again.
For related planning, see website hosting and WordPress requirements. You can get started with the incident card and the administrator’s findings. That gives a support discussion a concrete technical basis without requiring broad or speculative changes to the live environment.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.