登录 注册
By Isoziyuan in Cloudflare —

Cloudflare 开启代理后报 522？按端口、源站防火墙和回源 IP 完整排查

Cloudflare DNS 记录开启橙色云朵后，访问网站出现 Error 522: Connection timed out，通常意味着浏览器已经连接到 Cloudflare，但 Cloudflare 无法在规定时间内与源站正常建立或维持连接。

这类问题往往不是域名没有解析，也不是 Cloudflare 节点本身故障，而是出现在以下链路中：

访客 → Cloudflare 边缘节点 → VPS 公网 IP → 云平台防火墙 → 系统防火墙 → Nginx/Apache/容器

因此，解决 522 的关键不是反复修改 DNS，而是确认：Cloudflare 正在连接哪个 IP、使用哪个端口，以及源站是否允许 Cloudflare 的回源请求通过。

先理解 522 到底代表什么

按照 Cloudflare 对 522 的定义，常见超时发生在两个阶段：

  • Cloudflare 向源站发起 TCP 连接后，源站未及时返回 SYN+ACK。
  • TCP 连接已经建立，但源站长时间没有确认或处理 Cloudflare 发出的请求。

常见原因包括：

  1. DNS 记录填写了错误或已经变更的源站 IP。
  2. 源站没有监听 Cloudflare 实际使用的端口。
  3. VPS 安全组、云防火墙或系统防火墙拦截了 Cloudflare IP。
  4. Fail2ban、WAF、入侵防御程序误封了 Cloudflare 回源地址。
  5. 源站负载过高、连接数耗尽或网络异常。
  6. 同一域名配置了多个 A/AAAA 记录，其中部分源站不可用。
  7. IPv6 的 AAAA 记录存在，但源站 IPv6 并未正确配置。
  8. Docker、反向代理或 NAT 端口映射配置错误。

Cloudflare 官方说明中，建立连接阶段通常以约 19 秒为超时判断之一；连接建立后，如果源站长时间没有确认请求，也可能返回 522。实际排查时不应只关注应用响应速度，还要检查 TCP 连接是否真正到达服务器。

第一步：确认 Cloudflare 记录指向了正确的源站

进入 Cloudflare 控制台的 DNS Records 页面，检查发生故障域名对应的记录。

重点核对：

  • A 记录是否填写了当前 VPS 的公网 IPv4。
  • AAAA 记录是否填写了真实可用的公网 IPv6。
  • 是否存在多个 A 或 AAAA 记录。
  • www 和根域名是否指向不同服务器。
  • VPS 重装、迁移或更换公网 IP 后，记录是否仍是旧地址。
  • CNAME 最终指向的目标是否正确。

开启代理后，公共 DNS 查询通常只会返回 Cloudflare 的边缘 IP，因此不能通过下面的结果判断真实源站地址：

dig +short example.com

应以 Cloudflare 控制台中 DNS 记录保存的目标地址为准。

特别检查 AAAA 记录

如果服务器没有正确配置 IPv6，却保留了 AAAA 记录，应删除该 AAAA 记录，或者先把源站 IPv6 配置完整。

可以在服务器上查看实际拥有的 IPv6 地址：

ip -6 addr

并检查 IPv6 默认路由：

ip -6 route

如果域名同时配置多个源站地址，其中只有一个不可访问，522 可能表现为间歇性出现，而不是始终报错。排查时必须逐个检查所有 A、AAAA 和 CNAME 目标。

第二步：确认 Cloudflare 正在回源到哪个端口

浏览器没有显式指定端口时：

  • http://example.com 默认使用 80。
  • https://example.com 默认使用 443。

Cloudflare 橙色云朵只能代理其支持的 HTTP/HTTPS 端口。常见支持端口如下。

HTTP 端口

80
8080
8880
2052
2082
2086
2095

HTTPS 端口

443
2053
2083
2087
2096
8443

例如，应用只监听 3000 端口，而访问地址是：

https://example.com

Cloudflare 默认不会因为应用运行在 3000，就自动把 443 转发到 3000。通常需要让 Nginx、Caddy 或 Apache 监听 443，再反向代理到本机的 3000：

Cloudflare → 源站 443 → Nginx → 127.0.0.1:3000

如果必须使用其他回源端口，需要确认所用 Cloudflare 产品和账户配置是否支持端口覆盖；普通 DNS 代理配置不能被视为任意端口映射工具。

SSL/TLS 模式也会影响回源端口

在 Cloudflare 的 SSL/TLS 设置中：

  • Flexible（灵活）：访客到 Cloudflare 使用 HTTPS，但 Cloudflare 通常通过 HTTP 连接源站，因此源站 80 端口必须可用。
  • Full（完全）/ Full (strict)（完全严格）：Cloudflare 通过 HTTPS 连接源站，因此源站 443 端口必须可用。

生产环境通常应配置有效的源站证书并使用 Full (strict)。不要为了掩盖端口或证书问题长期使用 Flexible，否则还可能引发重定向循环或安全性下降。

第三步：检查源站是否真的监听了 80 或 443

登录 VPS，执行：

sudo ss -lntp

也可以只查看常见 Web 端口：

sudo ss -lntp | grep -E ':(80|443|8080|8443)\b'

正常情况下应该看到类似：

LISTEN 0 511 0.0.0.0:80
LISTEN 0 511 0.0.0.0:443

需要注意监听地址：

监听地址 含义
0.0.0.0:443 接受所有 IPv4 网卡上的 443 连接
[::]:443 接受 IPv6 连接，是否同时接受 IPv4取决于系统配置
127.0.0.1:443 只允许本机访问，Cloudflare 无法连接
127.0.0.1:3000 适合作为反向代理后端，但不能直接作为公网入口

如果 Nginx 没有运行，可检查：

sudo systemctl status nginx
sudo nginx -t

Apache 常见命令为：

sudo systemctl status apache2
sudo apachectl configtest

不同发行版上的服务名称可能是 httpd：

sudo systemctl status httpd

确认配置无误后再重载服务：

sudo systemctl reload nginx

不要在尚未查看日志的情况下反复重启，否则可能丢失有价值的故障现场信息。

第四步：从源站本机测试 Web 服务

先绕过 Cloudflare，在服务器本机测试 HTTP：

curl -I http://127.0.0.1/ -H 'Host: example.com'

测试 HTTPS 时，最好同时保留正确的域名和 SNI：

curl -vk --resolve example.com:443:127.0.0.1 \
  https://example.com/

结果可以这样判断：

  • 本机连接被拒绝：服务没有监听对应端口，或者服务已经崩溃。
  • 一直超时：程序阻塞、反向代理上游卡住，或者本机网络配置异常。
  • 返回 404：可能进入了错误的虚拟主机。
  • 返回 502：Nginx/Apache 可以访问，但后端应用不可用。
  • 正常返回 200、301、302：源站应用基本可用，应继续检查公网入口和防火墙。

如果使用 Nginx 虚拟主机，还要检查 server_name：

server {
    listen 80;
    server_name example.com www.example.com;
}

HTTPS 配置应确认存在相应的 listen 443 ssl、证书和私钥设置。

第五步：从外部网络直接测试源站

本机测试正常，不代表公网可以连接。应从另一台服务器、家庭网络或其他外部网络测试源站公网 IP。

假设源站 IPv4 为 203.0.113.10：

curl -vk --resolve example.com:443:203.0.113.10 \
  https://example.com/

HTTP 可使用：

curl -v --resolve example.com:80:203.0.113.10 \
  http://example.com/

也可以只测试 TCP 端口：

nc -vz 203.0.113.10 443

结果含义：

  • succeeded：TCP 端口从测试网络可访问。
  • Connection refused：请求到达了服务器，但没有程序监听，或防火墙主动拒绝。
  • 一直超时：经常是安全组、防火墙丢弃、路由异常或 IP 填写错误。

如果源站已经设置为“只允许 Cloudflare IP 访问”，普通外部网络直接测试超时是正常现象。此时可以临时放行测试机的固定 IP，测试完成后立即删除规则；不要为了测试长期向全网开放管理端口。

第六步：逐层检查防火墙，而不是只看 UFW

VPS 上通常存在多层访问控制：

  1. 云服务商安全组或云防火墙。
  2. VPS 系统中的 UFW、firewalld、nftables 或 iptables。
  3. 宝塔、1Panel 等管理面板生成的防火墙规则。
  4. Fail2ban、CSF、WAF 或入侵防御程序。
  5. Nginx、Apache 自身的访问控制。
  6. Docker 网络及端口发布规则。

任何一层拦截 Cloudflare，都可能造成 522。

检查云平台安全组

进入 VPS 服务商控制台，确认入站规则允许实际回源端口。

例如采用 Full (strict) 且仅使用标准 HTTPS 时，至少需要允许：

TCP 443

如果还要处理 HTTP 跳转，则通常还需要：

TCP 80

如果安全组只允许个人办公 IP，而没有放行 Cloudflare 网络段，开启小云朵后就会无法访问。

同时检查是否存在优先级更高的拒绝规则。部分平台按优先级处理规则，不是“添加允许规则”就一定能覆盖现有拒绝规则。

检查 UFW

查看状态和规则：

sudo ufw status numbered
sudo ufw status verbose

临时确认问题时可以放行 Web 端口：

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

如果这样操作后 522 消失，基本可以确认问题位于防火墙规则。但生产环境如需隐藏源站，建议进一步改为只允许 Cloudflare 官方 IP 段，而不是长期向所有来源开放。

检查 firewalld

sudo firewall-cmd --list-all
sudo firewall-cmd --list-ports
sudo firewall-cmd --list-rich-rules

检查 nftables

sudo nft list ruleset

检查 iptables

sudo iptables -L -n -v --line-numbers
sudo ip6tables -L -n -v --line-numbers

检查时重点关注：

  • DROP 或 REJECT 规则。
  • 80、443 是否允许。
  • IPv4 和 IPv6 是否分别放行。
  • 规则顺序是否导致允许规则尚未匹配，就先命中拒绝规则。
  • 是否设置了过低的连接频率或并发限制。
  • conntrack 是否耗尽。

第七步：正确放行 Cloudflare 官方回源 IP

开启代理后，源站在网络层看到的连接来源通常是 Cloudflare 边缘节点 IP，而不是访客真实 IP。

如果防火墙只允许固定来源，就必须放行 Cloudflare 官方公布的 IPv4 和 IPv6 网段。

官方地址：

Cloudflare IP 段可能调整，不建议从多年未更新的文章中复制一份静态列表后永久使用。应以官方页面当前公布的内容为准，并建立定期核对机制。

使用 UFW 放行 Cloudflare IP 的示例

先下载并检查列表：

curl -fsS https://www.cloudflare.com/ips-v4 -o /tmp/cloudflare-ips-v4.txt
curl -fsS https://www.cloudflare.com/ips-v6 -o /tmp/cloudflare-ips-v6.txt

cat /tmp/cloudflare-ips-v4.txt
cat /tmp/cloudflare-ips-v6.txt

确认内容无误后，放行 IPv4 到 80 和 443：

while read -r cidr; do
  sudo ufw allow proto tcp from "$cidr" to any port 80
  sudo ufw allow proto tcp from "$cidr" to any port 443
done < /tmp/cloudflare-ips-v4.txt

如果源站实际使用 IPv6，并且 UFW 已启用 IPv6支持，再添加：

while read -r cidr; do
  sudo ufw allow proto tcp from "$cidr" to any port 80
  sudo ufw allow proto tcp from "$cidr" to any port 443
done < /tmp/cloudflare-ips-v6.txt

然后查看最终规则：

sudo ufw status numbered

如果实际回源端口不是 80 或 443，应将命令中的端口替换为真实端口，并确认该端口属于 Cloudflare 支持代理的端口，或已通过适用的 Cloudflare 配置完成端口覆盖。

不要把请求头当成防火墙来源地址

CF-Connecting-IP 是 HTTP 请求头，适合让 Web 服务恢复访客真实 IP，但系统防火墙匹配的是 TCP 连接来源地址。

因此，下面两者不能混淆：

  • 网络防火墙放行：使用 Cloudflare 官方 IP 网段。
  • 应用日志记录访客 IP：使用 CF-Connecting-IP，并且只信任来自 Cloudflare 的请求。

不能在网络防火墙中“放行 CF-Connecting-IP”，因为 TCP 握手阶段还没有 HTTP 请求头。

第八步：检查 Fail2ban、WAF 和限速规则

开启代理后，大量请求会从有限的 Cloudflare 地址段到达源站。如果服务器仍按连接来源地址执行封禁或限速，可能把某个 Cloudflare 节点误判为攻击者。

检查 Fail2ban：

sudo fail2ban-client status

查看某个 jail：

sudo fail2ban-client status nginx-http-auth

具体 jail 名称以服务器实际输出为准。

同时检查：

  • Nginx allow / deny。
  • limit_req 和 limit_conn。
  • Apache Require ip。
  • ModSecurity。
  • CSF/LFD。
  • 管理面板的地区封禁和 IP 黑名单。
  • 主机商提供的 DDoS 清洗或端口防护策略。

如果解除某个 Cloudflare IP 的封禁后恢复，但稍后再次出现 522，就不能只做手动解封，还要修正真实 IP 获取方式和自动封禁策略。

第九步：如果使用 Docker，检查端口发布和容器状态

应用在容器中正常运行，不等于宿主机公网端口已经开放。

查看容器：

docker ps

重点检查 PORTS 一栏。例如：

0.0.0.0:443->443/tcp

表示宿主机 443 已发布到容器 443。

如果只看到：

443/tcp

通常只代表容器声明了端口，不一定已经发布到宿主机。

如果应用容器只监听内部 3000，常见正确链路是：

Cloudflare → 宿主机 443 → Nginx/Caddy → 容器 3000

检查容器日志：

docker logs --tail 200 容器名称

使用 Docker Compose 时，还要检查 ports、expose、网络名称以及反向代理连接的服务名是否正确。

第十步：通过抓包确定请求卡在哪一层

如果配置看起来都正常，抓包通常比继续猜测更有效。

在源站执行：

sudo tcpdump -ni any 'tcp port 80 or tcp port 443'

然后从浏览器再次访问出现 522 的页面。

根据抓包结果判断：

完全看不到连接包

可能原因：

  • Cloudflare DNS 中的源站 IP 填错。
  • 云平台安全组在服务器外层丢弃请求。
  • 上游网络或路由异常。
  • Cloudflare 实际访问了另一个 A/AAAA 记录。
  • 请求没有到达当前这台服务器。

能看到 SYN，但服务器没有返回 SYN+ACK

可能原因：

  • 本机防火墙丢弃。
  • 目标端口没有正常监听。
  • 监听地址错误。
  • 系统连接表或资源耗尽。

TCP 握手完成，但应用迟迟不返回

可能原因：

  • Nginx/Apache 工作进程阻塞。
  • PHP-FPM、Node.js、Java 等后端不可用。
  • 数据库或外部接口长时间阻塞。
  • 连接池耗尽。
  • 服务器 CPU、内存或磁盘 I/O 饱和。
  • Web 服务的并发连接上限过低。

抓包时如果访问量较大，可以记录故障发生时间和 Cloudflare 错误页面上的 Ray ID，再结合 Web 日志、系统日志进行定位。

第十一步：排查服务器资源和连接数耗尽

如果 522 只在高峰期出现，应重点检查源站容量，而不是只修改防火墙。

查看负载：

uptime
top

查看内存：

free -h

查看磁盘空间：

df -h

查看磁盘 I/O：

iostat -xz 1

iostat 通常由 sysstat 软件包提供，未安装时需要按发行版安装。

查看当前连接概况：

ss -s

查看 80 和 443 的连接数量：

sudo ss -ant | grep -E ':(80|443)\b' | wc -l

查看内核是否出现连接跟踪表耗尽：

dmesg -T | grep -i conntrack

查看 Nginx 错误日志：

sudo tail -n 200 /var/log/nginx/error.log

查看系统日志：

sudo journalctl -p warning --since "30 minutes ago"

可能需要调整的项目包括：

  • Nginx worker_connections。
  • PHP-FPM 进程数量。
  • 应用服务器线程池或连接池。
  • 数据库最大连接数。
  • 文件描述符限制。
  • 内核连接跟踪容量。
  • 上游接口超时和重试策略。
  • HTTP Keep-Alive 配置。

不要只看到“连接数很多”就盲目修改内核参数。应先确认瓶颈是 CPU、内存、I/O、应用线程、数据库还是网络连接表。

是否应该关闭小云朵测试

将 DNS 记录临时改为灰色云朵，确实可以作为诊断方法：

  • 灰色云朵正常、橙色云朵 522：优先检查 Cloudflare 回源端口和 IP 白名单。
  • 灰色云朵也无法访问：优先检查源站服务、端口、安全组和网络。
  • 灰色云朵正常，但只允许个人 IP：很可能是 Cloudflare 回源 IP 被防火墙拦截。

不过，这种测试会把源站 IP 直接暴露给访客，还会绕过 Cloudflare 的缓存、防护和证书终止。更稳妥的方法是使用 curl --resolve 指定源站 IP，或者只临时允许测试机 IP。

测试结束后应恢复代理，并再次验证域名访问。

修复后如何确认问题真正解决

不要只刷新一次首页。建议完成以下验证：

  1. HTTP 和 HTTPS 均按预期工作。
  2. 根域名和 www 子域名都能访问。
  3. 所有 A 和 AAAA 记录对应的源站都正常。
  4. 连续请求不会间歇性出现 522。

可以连续测试：

for i in $(seq 1 20); do
  curl -sS -o /dev/null \
    -w '%{http_code} %{time_connect} %{time_total}\n' \
    https://example.com/
  sleep 1
done

同时检查响应头：

curl -I https://example.com/

经过 Cloudflare 代理时，通常可以看到 server: cloudflare、cf-ray 等响应头。具体响应头可能受 Cloudflare 配置和响应流程影响，不应只依赖某一个头部判断。

一份更高效的 522 排查顺序

遇到“网站开启小云朵无法访问”时，可以按以下顺序处理：

  1. 在 Cloudflare 控制台确认 A、AAAA、CNAME 的源站地址。
  2. 确认 SSL/TLS 模式决定的回源协议和端口。
  3. 使用 ss -lntp 检查源站是否监听对应端口。
  4. 在源站本机用 curl 验证虚拟主机和应用。
  5. 从外部网络测试源站公网端口。
  6. 检查云服务商安全组和云防火墙。
  7. 检查 UFW、firewalld、nftables 或 iptables。
  8. 从 Cloudflare 官方页面获取并放行最新回源 IP 段。
  9. 检查 Fail2ban、WAF、限速和自动封禁规则。
  10. 使用 tcpdump 判断请求是否到达源站。
  11. 若故障间歇出现，检查负载、连接数、日志及多个源站记录。

大多数 Cloudflare 522 问题最终都可以归为三类：Cloudflare 找错了源站、Cloudflare 使用的端口没有服务监听，或者回源 IP 被某一层防火墙拦截。 按照网络链路逐层验证，通常比反复切换小云朵、清理浏览器缓存或修改无关 DNS 参数更快找到根因。

⚡ 极客核心要点提炼 可供 AI 智能体与搜索引擎引用检索

本文主题：Cloudflare 开启代理后报 522？按端口、源站防火墙和回源 IP 完整排查

引用出处：https://isoziyuan.com/p/100114/（作者：Isoziyuan · 发布于爱搜资源网）

Previous

Coolify 还是 Dokploy？低配置 VPS 的资源占用、备份恢复与安全对比
分享
Next

低显存运行 Ollama 内存不足怎么办：模型量化、上下文与并发优化指南