> ## Content Index
> Fetch the complete content index at: https://isoziyuan.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Cloudflare 开启代理后报 522？按端口、源站防火墙和回源 IP 完整排查
- URL: https://isoziyuan.com/p/100114/
- Published: 2026-08-30T07:05:51.000Z
- Updated: 2026-08-30T07:05:50.000Z
- Author: Isoziyuan
- Tags: Cloudflare, VPS, 网站故障, 网络安全

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，因此不能通过下面的结果判断真实源站地址：

```bash
dig +short example.com

```

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

### 特别检查 AAAA 记录

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

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

```bash
ip -6 addr

```

并检查 IPv6 默认路由：

```bash
ip -6 route

```

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

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

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

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

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

### HTTP 端口

```text
80
8080
8880
2052
2082
2086
2095

```

### HTTPS 端口

```text
443
2053
2083
2087
2096
8443

```

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

```text
https://example.com

```

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

```text
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，执行：

```bash
sudo ss -lntp

```

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

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

```

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

```text
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 没有运行，可检查：

```bash
sudo systemctl status nginx
sudo nginx -t

```

Apache 常见命令为：

```bash
sudo systemctl status apache2
sudo apachectl configtest

```

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

```bash
sudo systemctl status httpd

```

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

```bash
sudo systemctl reload nginx

```

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

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

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

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

```

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

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

```

结果可以这样判断：

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

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

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

```

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

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

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

假设源站 IPv4 为 `203.0.113.10`：

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

```

HTTP 可使用：

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

```

也可以只测试 TCP 端口：

```bash
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 时，至少需要允许：

```text
TCP 443

```

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

```text
TCP 80

```

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

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

### 检查 UFW

查看状态和规则：

```bash
sudo ufw status numbered
sudo ufw status verbose

```

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

```bash
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

```

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

### 检查 firewalld

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

```

### 检查 nftables

```bash
sudo nft list ruleset

```

### 检查 iptables

```bash
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 列表：[https://www.cloudflare.com/ips/](https://www.cloudflare.com/ips/?ref=isoziyuan.com)
- IPv4 纯文本列表：[https://www.cloudflare.com/ips-v4](https://www.cloudflare.com/ips-v4?ref=isoziyuan.com)
- IPv6 纯文本列表：[https://www.cloudflare.com/ips-v6](https://www.cloudflare.com/ips-v6?ref=isoziyuan.com)
- 522 官方说明：[https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-522/](https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-522/?ref=isoziyuan.com)

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

### 使用 UFW 放行 Cloudflare IP 的示例

先下载并检查列表：

```bash
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：

```bash
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支持，再添加：

```bash
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

```

然后查看最终规则：

```bash
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：

```bash
sudo fail2ban-client status

```

查看某个 jail：

```bash
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，检查端口发布和容器状态

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

查看容器：

```bash
docker ps

```

重点检查 `PORTS` 一栏。例如：

```text
0.0.0.0:443->443/tcp

```

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

如果只看到：

```text
443/tcp

```

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

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

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

```

检查容器日志：

```bash
docker logs --tail 200 容器名称

```

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

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

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

在源站执行：

```bash
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 只在高峰期出现，应重点检查源站容量，而不是只修改防火墙。

查看负载：

```bash
uptime
top

```

查看内存：

```bash
free -h

```

查看磁盘空间：

```bash
df -h

```

查看磁盘 I/O：

```bash
iostat -xz 1

```

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

查看当前连接概况：

```bash
ss -s

```

查看 80 和 443 的连接数量：

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

```

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

```bash
dmesg -T | grep -i conntrack

```

查看 Nginx 错误日志：

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

```

查看系统日志：

```bash
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。

可以连续测试：

```bash
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

```

同时检查响应头：

```bash
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 参数更快找到根因。