接入 Cloudflare 或其他 CDN 后，中国大陆用户仍可能遇到打不开、挑战页、旧内容或 5xx。先保存实际失败的请求，再确认它是否经过代理；随后区分访客到边缘、缓存与安全策略、边缘到源站这几个边界，最后用同一目标、时间与网络复查。不要第一步就清空所有缓存、关闭防护或把故障统称为“被墙”。
本文面向管理自己网站或已获排查授权的团队。Cloudflare 用作具体例子；其他 CDN 的配置名称、错误码和日志能力应以供应商文档为准。域名检测提供网络观测，不能独立确定 CDN、运营商、源站或应用谁是根因。
1. DNS 托管、代理与缓存不是同一个开关
在 Cloudflare 托管 DNS，不表示所有网站请求都经过它的 HTTP 代理。根据官方 Proxy status 文档，Proxied 记录把相应 HTTP/HTTPS 流量导向 Cloudflare 网络，DNS-only 则不经过这条代理路径。橙云状态描述的是代理关系，不是中国大陆访问保证。
先核对用户实际访问的主机名，而不是只看整个域名是否加入 Cloudflare。主域名、www、API 与资源子域名可能有不同配置，重定向还可能把请求送往另一个主机。记录实际协议、主机名、端口与脱敏路径模板，再由负责人确认该请求的代理状态和近期变更。
同一服务在不同观察中返回不同地址，也不能仅凭 IP 的地理标签解释请求经过哪座机房。DNS 调度与缓存背景见国内外 DNS 答案不同的排查指南；本篇继续关注请求路径与故障边界。
2. 分清访客到边缘，与边缘到源站
对于经过代理的 HTTPS 请求，浏览器与 Cloudflare 边缘之间、Cloudflare 与源站之间是不同连接。访客使用 HTTPS，不代表回源一定使用 HTTPS；回源协议取决于配置。使用 HTTPS 回源时，源站侧使用自己的证书。浏览器看到的边缘证书正常，不表示回源证书、连接或应用处理正常，见Cloudflare SSL/TLS 概念。
如果用户没有获得有效 HTTP 响应，应先保存浏览器具体错误及失败阶段，比较相关网络，并核对边缘是否有对应记录。若同一次请求确实收到了 Cloudflare 生成的错误页面，则这次请求已经获得边缘 HTTP 响应，可以优先调查错误所指的回源或安全策略边界。这是对该次请求的推论，不证明其他资源、所有用户或整条业务链路正常。
连接重置、超时和 TLS 成功都不是完整根因名称；有关握手与证书的基础区别，参见DNS 正常但 HTTPS 失败的指南。不要用一次成功重试覆盖最初失败记录。
3. 绕过缓存，不等于绕过 Cloudflare 代理
缓存决定响应能否从已有内容提供；代理决定请求经过哪里。Cloudflare 的缓存响应说明中，HIT 表示命中缓存；MISS 表示本次未命中符合缓存条件的内容并回源；DYNAMIC 表示请求时不具备缓存资格；BYPASS 表示响应条件令本来具备资格的内容不被缓存。后两者不代表 DNS-only，也不代表安全策略已关闭。
不要把“已设置绕过缓存”写成“已直接访问源站”。先查看具体 URL 的实际响应、匹配规则和内容版本。缓存命中也只说明这次响应来自该缓存，不证明所有边缘均已更新或源站当前可用。HTML 与 JSON 默认不缓存，但 Cache Rules 等配置可以改变行为，见默认缓存行为；不能只凭文件类型猜测实际结果。
处理旧内容时，先确认过期的是页面、脚本还是 API 响应，保存资源 URL、内容版本和可用的缓存状态。只有证据指向具体缓存层，且负责人批准后，才针对该层做必要调整或清理，并验证源站与公开响应。浏览器缓存、CDN 内容缓存和 DNS 缓存应分别记录。
4. 挑战页与 403，需要安全策略和应用证据
Cloudflare 的 WAF、Bot Management 或限流策略可以触发 Challenge Page。它返回供浏览器处理的 HTML，可能中断期待 JSON 等非 HTML 内容的 API 或 Fetch/XHR 请求，见挑战页及兼容性限制。浏览器用户能通过挑战，不表示自动化客户端执行的是同一流程。
网站负责人可以在真实请求的响应中检查 cf-mitigated: challenge，这是官方用于识别 Challenge Page 的标记，见挑战响应识别文档。它是该响应的线索，不是 WeaveBit 承诺返回的字段。403 也可能涉及源站权限或 Cloudflare 策略，应结合页面、响应和双方日志核对，参见403 排查说明。
不要把挑战或 403 直接改写成 GFW 封锁。若确认监控或获准客户端被自己的规则误拦，应由安全负责人按最小范围评估例外，而不是关闭全站 WAF 或允许所有流量。登录、API 或脚本失败时，继续按业务依赖指南检查真正受影响的请求。
5. 522–526 先按对应回源边界调查
下表适用于 Cloudflare 网站反向代理返回的这些错误，不应直接套用到其他 CDN 或其他 Cloudflare 产品。错误码提供优先调查方向，不独立证明唯一根因，也不代表所有用户都遇到相同故障。
| 错误 | 官方含义对应的边界 | 优先核对 |
|---|---|---|
| 522 | Cloudflare 联系源站超时 | 源站负载、地址、防火墙与连接日志 |
| 523 | Cloudflare 无法联系源站 | 源站地址与 Cloudflare 到源站的路由 |
| 524 | 已连接源站，但回源读或写未及时完成 | 应用耗时、源站资源及异步处理设计 |
| 525 | Cloudflare 到源站的 TLS 握手失败 | 源站 TLS、端口、SNI 与加密套件 |
| 526 | Full (strict) 模式下，Cloudflare 无法验证源站证书 | 证书名称、有效期、信任与证书链 |
针对 524，确认是哪项处理超出当前回源等待窗口，查询应用与服务器耗时；长期运行的操作可由开发团队评估异步提交、状态轮询等设计。具体等待限制和可调选项以当时产品与套餐文档为准，不把重试当成修复。
针对 525 或 526，应修复对应 TLS 或证书配置。不要把忽略证书错误、降低验证要求当成标准解决方案。一次连接或 HTTP 响应成功，不等于用户应当放弃安全验证。
6. 普通橙云，不等于开通 China Network
不能仅因域名使用 Cloudflare，就推断中国大陆访客获得大陆节点服务。官方China Network 概览和接入说明将其列为 Enterprise 客户的额外独立订阅，并包含 ICP 材料与内容审核等接入条件；部分产品能力也不同。这里说明产品边界，不提供法律结论，具体资格和部署要求应与服务方核实。
Cloudflare 还说明，Anycast 请求不一定到达地理上最近的数据中心，见地理路由说明。不能由某个 IP 的国家标签推导所有大陆用户的实际路径或表现，也不能承诺更换 CDN 后所有网络一定恢复。
评估供应商或迁移方案时，应按客户实际地区、运营商和关键业务路径建立基线，记录相近时段的结果。把“某些网络上改善”与“已验证全部目标用户”分开报告，不把单个节点的正常扩展为全国保证。
7. 用 WeaveBit 补充域名观测，不替代 CDN 根因分析
对企业自己管理或已获检测授权的实际主机，可先用免费 DNS 污染检测了解这一类结果。多个域名、更完整的 HTTP/HTTPS 相关观测或多节点对照，可以直接选择 GFW 全量，不要求先逐个完成 DNS 初查。只保存平台公开结果，不自行推导内部判断过程。
GFW 全量返回选定节点的 DNS 污染、HTTP Host、TLS SNI 分项及汇总，并非将全部七种检测方式逐一执行。HTTP_RESPONSE_OK 不等于 2xx 或业务成功；TLS 握手成功不是完整的浏览器证书信任审计。它不执行页面 JavaScript、解挑战、登录账户或访问你指定的业务路径。方法覆盖见检测方式，正常、异常与无法判定的边界见结果文档。
节点观测与受影响用户不是同一次请求。保持实际域名、相关端口和时间可比较，按用户网络选择相关 GFW 节点，仍需浏览器、CDN 与源站证据。全量正常不能证明所有网络、资源和业务可用；无法判定也不能补成正常或封锁。如何对齐不同观测，见监控结果与用户反馈指南。
8. 留下最小证据，安全地验证调整
为每次观察保留：带时区的时间、实际域名与端口、脱敏路径模板、用户地区和运营商、浏览器错误或 HTTP 状态、当时代理配置，以及可用时的 CF-Ray、CF-Cache-Status 和挑战标记。再与同期安全和源站日志对齐，分别说明已经确认与仍未知的边界。
Ray ID 文档说明，该标识不保证每次请求都唯一，Security Events 还可能使用抽样数据。应结合时间与其他必要字段查询；找不到对应日志不证明请求没有到达。具体采集方式可参考官方排查信息指南，但不要直接分享原始 HAR、完整请求头或日志。
切换 DNS-only 不是无风险验证：它改变访问路径、可能暴露源站并移除代理侧保护；源站的 Cloudflare Origin CA 证书也不受普通浏览器直接信任，可能新增证书错误，见Origin CA 说明。若确需对照，由负责人确认授权、源站承载、防护、证书及回退方案，并保留原主机名和正确 TLS 名称，不以忽略证书错误获取“成功”。
每次只改变必要因素，保存前后配置与新观测，再让受影响用户验证原业务。对外记录逐项去掉 Cookie、Authorization、密钥、查询令牌和个人信息；只分享人工复核后的最小字段。结束排查时，说明哪些网络与业务已恢复、哪些仍待确认，而不是只留下“CDN 正常”或“GFW 正常”一个标签。