HGfast Cloud 灵狐加速 · 一站式全球云网络返回首页

Cloudflare 522 怎么解决？从源站连通到防火墙的完整排查指南

更新于 2026-11-04 · hgfastapp.lol

简答：Cloudflare 522 的含义是 Cloudflare 联系源站服务器时超时，通常不是浏览器本身故障。普通访客可先等待约 120 秒后重试，并把页面上的 Ray ID、时间和完整网址交给网站管理员；站长则应按“源站在线与端口→DNS 指向→防火墙与安全组→服务器负载→日志和网络路径”的顺序排查。

定义：Cloudflare 522 是 Cloudflare 与网站源站之间建立连接或等待源站确认请求时超时产生的 5xx 错误。

先用 3—6 步判断：你是访客还是网站管理员

看到 Cloudflare 522: Connection timed out 时，先不要反复修改浏览器 DNS 或清空缓存。这个错误的核心位置在 Cloudflare 与源站之间，Cloudflare 官方说明它可能发生在 TCP 连接尚未建立，或连接建立后源站没有及时确认请求的阶段。

  1. 普通访客：记录错误页面中的 Ray ID、显示时间和完整 URL；如果页面提供可重试提示，等待约 120 秒后刷新一次。
  2. 只在一个网络打不开：用手机网络或另一条固定网络测试同一 URL。若只有单一网络失败，记录网络类型和失败时间，不要直接判断源站宕机。
  3. 网站管理员：先从服务器本机或同一云网络检查 Web 服务是否运行、目标端口是否监听，再核对 DNS 中的 A/AAAA 记录。
  4. 刚启用或刚迁移 Cloudflare：优先检查 DNS 是否仍指向当前源站公网 IP，以及服务器防火墙是否允许 Cloudflare IP 段访问。
  5. 修复后：至少测试首页、一个静态资源和一个动态接口，并观察源站日志与 Cloudflare 错误分析是否还出现 522。

Cloudflare 的结构化错误响应把 522 归为可重试的源站类错误，当前官方错误响应说明中的默认 Retry-After 值为 120 秒；但访客不应把等待当成修复方案，持续出现时仍需要网站管理员处理。可参考 Cloudflare 错误响应字段与重试说明。

Cloudflare 522 到底意味着什么？先分清两类超时

根据 Cloudflare 官方 Error 522 文档，522 的直接含义是 Cloudflare 联系源站 Web 服务器时超时。官方区分了两种典型触发点：

  • TCP 建连阶段：Cloudflare 发出 SYN 后，没有在约 19 秒内收到源站的 SYN+ACK。
  • 请求确认阶段：TCP 连接已经建立，但 Cloudflare 没有在约 90 秒内收到源站对资源请求的确认。

因此，522 不等于“Cloudflare 一定故障”，也不等于“网站服务器一定完全宕机”。常见责任点包括：源站离线或过载、源站 IP 已变更但 DNS 未更新、Cloudflare IP 被 .htaccess、iptables、云安全组或主机防火墙限速/拦截、源站丢包，以及 Keep-Alive 等连接配置不合适。具体判断应以源站日志和可复现测试为准，不能只凭错误页猜测。

如果你只是访问者，最有用的信息不是继续改本机设置，而是把 Ray ID、时间、完整 URL、所在网络和是否能通过另一网络复现 一并提供给站长。Cloudflare 的错误响应字段中，Ray ID 用于标识具体错误实例，时间戳和请求主机名也有助于对应日志。

站长排查顺序：源站、端口、DNS、防火墙、日志

1. 先确认源站在线并监听正确端口

适用条件：你拥有 Linux 服务器、云主机或主机面板权限。先在源站执行服务状态检查；命令名称会因发行版和服务管理方式不同而变化，以下仅适用于使用 systemd 的 Linux：

sudo systemctl status nginx

如果使用 Apache，可将服务名替换为 apache2 或系统实际服务名。结果判断：状态应显示服务正在运行；若服务已停止，先查看 sudo journalctl -u nginx -n 100 --no-pager，修复配置或应用错误后再启动。不要在未确认配置正确时直接循环重启，以免覆盖故障线索。恢复方法是撤销最近的配置改动，再用配置测试命令确认后启动服务。

2. 检查 80/443 是否监听且绑定公网接口

适用条件：Linux 源站，且你知道网站实际使用 HTTP、HTTPS 或其他受支持端口。可执行：

sudo ss -lntp | grep -E ':80|:443'

结果应能看到对应端口处于监听状态；若只绑定 127.0.0.1，外部连接可能无法到达，应检查 Web 服务的监听地址。若站点使用非标准端口，还要核对该端口是否在 Cloudflare 当前代理支持范围内；无法从当前配置确认时，以 Cloudflare 控制台和官方端口文档为准，不要凭经验改端口。

3. 从外部核对 DNS 是否指向当前源站

适用系统：Windows、macOS、Linux 都可以使用 nslookup 或 dig；前置条件是你知道当前源站公网 IPv4/IPv6 地址。

  • Windows：nslookup example.com
  • macOS/Linux：dig A example.com +short 与 dig AAAA example.com +short

将返回结果与主机商当前分配的公网地址逐项核对。若 A 或 AAAA 记录仍指向旧服务器，先在 Cloudflare DNS 中修正记录；若 IPv6 源站没有正确监听或路由不通，也要暂时按实际部署情况核对 AAAA 记录。恢复方法是保留正确记录、删除或修正失效记录，并等待 DNS 变化后重新测试；不要为了“碰碰运气”同时保留多个未经确认的源站地址。

4. 检查防火墙、安全组和主机面板白名单

Cloudflare 官方把 Cloudflare IP 被防火墙、iptables 或 .htaccess 拦截列为常见原因。先查看服务器本地防火墙、云平台安全组、主机商防护和面板规则是否限制了 Cloudflare 到源站 80/443 端口的访问。Cloudflare 当前 IP 段应从其官方 IP Ranges 页面获取，不要复制搜索结果中的旧列表。

安全边界：放行时只针对实际 Web 端口和 Cloudflare 官方 IP 段，不要为了排障关闭整台服务器防火墙，也不要把所有公网地址加入白名单。修改前导出或记录原规则；验证失败时，按记录回滚到原配置。

5. 检查过载、连接耗尽和丢包

若端口监听和防火墙均正常，继续检查 CPU、内存、连接数、反向代理错误日志、应用日志和主机商告警。可以从外部执行以下基础测试：

curl -Ivs --connect-timeout 10 https://example.com/

适用条件是目标域名已解析且你有权限测试；结果重点看 TCP/TLS 是否建立、是否收到 HTTP 响应，不要把一次成功当成彻底修复。若需要区分路径问题，可在不同时间测试首页、静态文件和动态接口。Cloudflare 官方建议使用 MTR 或 traceroute 排查源站到 Cloudflare 的网络路径，并可在 Origin Analytics 中观察 TCP 连接失败情况。

如何使用日志、Error Analytics 和 MTR 定位责任点

修复 522 时，最重要的是把一次错误对应到同一时间窗口。记录访问时间、时区、完整 URL、Ray ID、源站公网地址、Cloudflare DNS 变更时间，以及源站 Web/防火墙/安全组日志中的对应记录。

  1. 看 Cloudflare 面板：在 HTTP Traffic 或相应的错误分析页面中筛选 5xx，并区分 Edge status code 与 Origin status code。当前页面名称和权限可能随账户状态变化，以控制台实际显示为准。
  2. 看源站访问日志：如果完全没有对应请求，优先检查 DNS、端口、防火墙、安全组或网络路径；如果有请求但应用迟迟不响应，优先检查连接数、上游数据库、进程池和应用耗时。
  3. 跑 traceroute 或 MTR：Linux/macOS 可使用 traceroute 或已安装的 mtr；Windows 可使用 tracert。它们只能提供路径线索，单个中间节点不响应不一定代表最终故障，应观察后续跳数与目标端是否持续丢包。
  4. 做最小化验证：临时使用一个不涉及登录和敏感数据的健康检查路径，避免把复杂业务耗时误判为网络连接失败。

Cloudflare 的站点排障指南将 curl 用于 HTTP 错误、MTR/traceroute 用于连接超时与丢包，并提醒 HAR 等诊断文件可能包含敏感信息。提交日志或 HAR 前，应删除 Cookie、密码、令牌、支付信息和私钥。

特殊场景：Pages、Workers Custom Domain 与 Origin Rules

如果普通源站检查都正常，但 522 只出现在特定 Cloudflare 产品链路中，应单独核对配置：

  • Cloudflare Pages：确认自定义域名已正确设置，CNAME 指向当前 Pages 自定义域名。
  • Workers Custom Domain：Worker 对自身主机名执行 fetch 可能造成 522。应检查代码是否请求自身主机名，并按官方说明考虑使用 Route、另一个目标主机名或相应兼容性配置。
  • Origin Rules：检查规则改写后的主机名能否解析。若改写到保留地址或不可用目标，仍可能返回 522。

这些场景不能用“重启 Web 服务”一概处理。先确认请求链路究竟是传统 DNS→源站，还是 Pages、Workers、Route、Origin Rules 组合，再针对对应产品文档核验。任何兼容性开关、字段名或控制台按钮都应以当前官方页面为准。

Cloudflare 522 与其他 52x 错误怎么区分

错误码官方含义优先检查方向
521Web server is down，源站被判断为不可用源站进程、端口、拒绝连接和防火墙
522Connection timed out，Cloudflare 联系源站超时TCP 建连、请求确认、DNS、Cloudflare IP 放行、丢包
523Origin is unreachable，源站不可达源站地址、路由、网络和 DNS 解析
524A timeout occurred，已建立连接但处理超时应用执行时间、上游服务、数据库和长请求
525SSL handshake failed，源站 TLS 握手失败源站证书、协议、加密套件和 HTTPS 配置

这张表只能帮助分流，不能替代日志证据。Cloudflare 的 5xx 总览将 521、522、523、524、525 分别列为不同错误类型；如果错误码在复现过程中变化，应以每次错误页面的 Ray ID 和时间分别调查。

修复后如何验证，以及什么时候回退

  1. 先用 curl -Ivs 测试首页，确认能够完成连接、TLS 握手并收到 HTTP 状态。
  2. 再测试一个静态资源和一个不涉及敏感数据的动态路径，排除“首页正常但接口仍超时”。
  3. 从至少两个网络环境复测，并记录时间、状态码、响应主机和是否出现新的错误码。
  4. 检查源站日志，确认请求已到达且没有持续的拒绝、连接耗尽或上游超时。
  5. 回看 Cloudflare 错误分析，确认 522 不再持续增加；如果只改了 DNS 或防火墙，避免同时改动 SSL、缓存和应用配置，以便定位有效变更。

如果修改防火墙白名单、DNS 或反向代理后问题变得更严重，立即按变更前保存的规则回退，再逐项恢复。不要长期关闭代理或防火墙作为“修复”；这只能作为受控的短时对照测试，并应在测试完成后恢复原有安全边界。

参考资料与站内延伸阅读

本文内容按 2026-11-04 可访问的官方资料核验，重点结论来自 Cloudflare Error 522、Cloudflare 错误响应、Cloudflare 5xx 总览、Cloudflare IP Ranges、Cloudflare 站点排障指南，以及 cPanel 关于启用 Cloudflare 后出现 522 的排查说明。站内还可以继续阅读：

本文编写范围说明

本文是基于公开官方资料整理的故障排查指南，不代表 Cloudflare 官方支持，也不替代主机商、云平台或网站管理员的实际配置。控制台菜单、账户权限、IP 列表和产品行为可能变化；涉及当前状态时，请以对应官方页面和你的实际日志为准。

常见问题

Cloudflare 522 是我自己的网络问题吗？

不一定。522 的直接含义是 Cloudflare 联系源站超时，常见责任点在源站在线状态、DNS 指向、防火墙放行、服务器过载或网络丢包。若只有一个网络无法访问，可用另一网络复测，但仍应把 Ray ID 和时间交给站长。

普通访客遇到 Cloudflare 522 应该怎么做？

先记录完整网址、Ray ID 和错误时间，按页面提示等待约 120 秒后重试一次；如果仍失败，联系网站管理员。访客通常无法修复源站防火墙、DNS 或服务器负载，因此不建议仅反复清缓存或修改本机代理设置。

刚启用 Cloudflare 就出现 522，最先查什么？

优先核对 Cloudflare DNS 中的 A/AAAA 记录是否指向当前源站公网地址，再检查服务器安全组、防火墙、iptables 或 .htaccess 是否允许 Cloudflare 官方 IP 段访问实际 Web 端口。修改前应保存原规则，避免直接关闭防火墙。

Cloudflare 522 和 524 有什么区别？

522 更偏向 Cloudflare 无法及时建立与源站的连接，或源站没有及时确认请求；524 通常表示连接已经建立，但源站处理请求超时。前者优先查端口、DNS、防火墙和网络路径，后者还要重点检查应用执行时间与上游服务。

可以直接关闭 Cloudflare 代理来解决 522 吗？

不应把关闭代理当作长期修复。它可以在受控条件下作为短时对照测试，帮助判断直连源站是否可用，但会改变流量路径和安全边界。测试前记录原状态，验证后恢复，并继续修复 DNS、防火墙或源站本身的问题。

为什么源站本机 curl 正常，Cloudflare 仍然 522？

本机 curl 可能只证明本机到本机服务正常，不能证明 Cloudflare 能从其网络到达源站。还需要核对公网监听地址、云安全组、Cloudflare IP 白名单、DNS A/AAAA、IPv6 路由以及源站日志，并用 MTR 或 traceroute 获取路径线索。

相关阅读

参考资料

  1. Cloudflare 官方：Error 522
  2. Cloudflare 官方：Error responses
  3. Cloudflare 官方：Cloudflare 5xx errors
  4. cPanel 官方：522 error after enabling Cloudflare