香港节点CDN回源连接超时，源站端口、WAF策略与Nginx日志如何互证

先把“超时”限定在回源链路

奇怪的是，业务页面在源站本机 curl 正常，部分用户直连源站也能打开，但一经过 CDN，香港节点就报 504、522、回源连接超时，或者缓存命中正常、缓存未命中就失败。这个现象容易让人误判为“CDN节点不稳定”，但真正要先确认的是：超时发生在用户到 CDN，还是 CDN 到香港源站的回源连接。

排查顺序建议固定为三步：先验证源站端口是否对 CDN 回源可达；再看 WAF 是否在 HTTP 层误拦截；最后用 Nginx 访问日志与错误日志确认请求有没有进入源站、进入后卡在哪一段。只有这三类证据能互相对上，才能避免“端口没通却调 WAF”“WAF 已拦截却改 Nginx 超时”“后端慢却怀疑网络”的反复试错。

这里的“香港节点”通常指源站部署在香港机房或香港区域节点，CDN 边缘节点回源到该源站。用户本地访问源站正常，不等于 CDN 回源路径正常；同样，源站 80/443 对公网可访问，也不等于已允许 CDN 当前回源 IP 段访问。

先看现象对应哪一层

CDN回源连接超时不是一个单一原因。它可能发生在 TCP 建连阶段，也可能是 HTTPS 握手、WAF拦截、Nginx代理后端超时，甚至是 CDN 配置了错误的回源端口。

可以先按下表归类：

这个表不是最终结论，而是决定下一步检查方向。尤其要注意：WAF是 Web 应用防护策略，主要处理 HTTP/HTTPS 请求规则，不等同于主机防火墙或系统安全组；端口不通时，先查网络和监听，不要直接把 WAF 关掉。

检查源站端口：确认80/443或自定义回源端口真的在监听

先在香港源站本机确认 Nginx 是否监听了 CDN 配置中的回源端口。以下命令适用于常见 Linux 环境，实际服务名和日志路径需以系统安装方式为准。

sudo ss -lntp | grep -E ':(80|443|8080)\s'
sudo systemctl status nginx --no-pager

如果 CDN 配置的回源端口是 443，而源站只监听 80，CDN自然会回源失败。反过来，如果 Nginx 监听了 443，但对应站点没有正确的 server_name 和证书，可能表现为 TLS 握手失败，而不是普通 HTTP 错误。

在源站本机再验证本地访问：

curl -I --connect-timeout 5 http://127.0.0.1/
curl -kI --connect-timeout 5 https://127.0.0.1/

本机正常后，需要从源站外部模拟访问。直接访问 IP 时要带上真实 Host，因为很多 Nginx 虚拟主机依赖 Host 匹配站点。

nc -vz ORIGIN_IP 80
curl -v --connect-timeout 5 -H "Host: www.example.com" http://ORIGIN_IP/

如果是 HTTPS 回源，建议用 --resolve 同时模拟域名、SNI 和源站IP：

curl -vk --connect-timeout 5 --resolve www.example.com:443:ORIGIN_IP https://www.example.com/

结果可以这样判断：

• Connection refused：目标端口可达，但服务未监听，或防火墙明确拒绝。
• Connection timed out：更像安全组、防火墙 DROP、回源IP未放行、路由不可达。
• TCP连接成功但返回 403/444：端口不是问题，继续查 WAF、Nginx规则或应用策略。
• HTTP正常但HTTPS失败：重点查证书、SNI、TLS版本、CDN回源协议配置。
• 只有自定义端口失败：核对 CDN 回源端口、Nginx listen、系统防火墙和云安全组是否一致。

如果源站只允许 CDN 回源 IP 访问，应以 CDN 厂商当前官方公布的回源 IP 段为准。不要为了排障长期放开 0.0.0.0/0 到管理端口或业务端口；临时放行也应限定端口、来源和时间窗口。

排查WAF误拦截：看动作、规则ID和命中条件

当端口连通性没有问题，但 CDN 回源仍异常，就要检查 WAF。这里的 WAF 可能在 CDN 边缘，也可能在源站前面，还可能是 Nginx 上的 ModSecurity、OpenResty 规则或其他 Web 防护模块。位置不同，日志证据也不同。

重点不是“关掉WAF试试”，而是看它是否在故障时间点对相同 Host、URI、Method、来源IP执行了拦截动作。

需要核对这些字段：

• 时间：与 CDN 报错时间是否一致，注意时区。
• 访问域名：是否为 CDN 配置的回源 Host。
• URI：是否只命中特定接口、上传路径、API路径。
• Method：GET、POST、HEAD、OPTIONS 是否被区别处理。
• 来源IP：是否为 CDN 回源 IP，而不是终端用户真实IP。
• 动作：block、deny、challenge、reset、captcha、observe。
• 规则ID：是否为 SQL 注入、XSS、Bot、防盗链、Host校验等规则。
• 请求头：User-Agent、X-Forwarded-For、Range、Content-Type 是否触发规则。

如果 WAF 位于 Nginx 前面，WAF 拦截时 Nginx 通常没有 access.log 记录；如果 WAF 模块运行在 Nginx 内部，Nginx access.log 可能会出现 403，同时 WAF审计日志或 error.log 中有规则命中信息。

临时验证建议采用最小变更：

1. 只对故障域名、故障URI或 CDN 回源 IP 设置短时间白名单。
2. 或将可疑规则切到观察模式，而不是全站关闭WAF。
3. 保留变更时间点，方便与 CDN 错误率、Nginx日志对比。
4. 验证通过后，改成精确例外规则，例如放行特定回源 Header 或特定接口参数。

需要特别注意，CDN 回源请求与真实用户请求不一定完全相同。CDN可能使用自定义 User-Agent，可能发起 HEAD 请求探测，也可能携带 Range 请求获取大文件片段。如果 WAF 策略过于严格，就会把正常回源行为当成异常请求。

用Nginx访问日志判断请求是否进站

Nginx access.log 是判断“请求是否真正到达源站应用层”的关键证据。默认路径通常是：

/var/log/nginx/access.log
/var/log/nginx/error.log

如果站点单独配置了日志文件，可用下面命令查看实际配置：

sudo nginx -T | grep -E 'access_log|error_log|server_name|listen'

按故障时间检索访问日志，例如：

sudo grep '03/Jul/2026:10:2' /var/log/nginx/access.log | tail -n 50

如果访问日志里完全没有 CDN 回源请求，而 CDN 侧显示 connect timeout，优先回到端口、安全组、防火墙、WAF前置拦截、回源IP白名单这些方向。因为请求连 Nginx 都没进入，调 Nginx 的 proxy_read_timeout 多半没有意义。

如果 access.log 有记录，要看状态码和耗时。默认日志格式可能不包含请求耗时和上游耗时，建议为故障排查预留一个更完整的日志格式。修改配置前先备份对应 Nginx 配置文件，并执行 nginx -t 校验。

log_format origin_debug '$remote_addr - $host [$time_local] '
                        '"$request" $status $body_bytes_sent '
                        'rt=$request_time '
                        'urt=$upstream_response_time '
                        'uaddr=$upstream_addr '
                        'xff="$http_x_forwarded_for" '
                        'ua="$http_user_agent"';

access_log /var/log/nginx/access_origin_debug.log origin_debug;

校验并平滑加载：

sudo nginx -t
sudo systemctl reload nginx

有了这些字段后，判断会清楚很多：

• status=200/301/302 且耗时很短：源站处理正常，问题可能在 CDN 缓存、回源配置或偶发链路。
• status=403：结合 WAF日志、Nginx deny/allow、防盗链、鉴权规则判断。
• status=499：客户端提前断开，常见于 CDN 等待源站太久后关闭连接。
• status=502：Nginx连接后端失败，查 upstream、PHP-FPM、应用端口。
• status=504：Nginx等待后端超时，源站内部链路慢。
• rt 接近 CDN 回源超时时间：请求进入源站后处理过慢，不能只按网络故障处理。
• urt 为 -：请求可能没有转发到上游，问题在 Nginx本地规则、静态文件或重写阶段。

用Nginx错误日志确认卡点

error.log 用来解释 access.log 里的异常状态。可以在复现时实时观察：

sudo tail -f /var/log/nginx/error.log

常见日志含义如下：

connect() failed (111: Connection refused) while connecting to upstream

表示 Nginx 到后端应用端口被拒绝，例如 PHP-FPM、Node.js、Java服务未监听或端口配置错误。这不是 CDN 到源站端口不通，而是源站内部 upstream 不通。

upstream timed out (110: Connection timed out) while reading response header from upstream

表示 Nginx已经把请求转给后端，但后端迟迟没有返回响应头。CDN看到的可能是回源超时，但根因在应用处理慢、数据库慢、外部接口慢或后端线程耗尽。

client timed out while waiting for request

可能是客户端或 CDN 与源站之间连接建立后，请求发送不完整或太慢。需要结合 CDN 回源日志和网络质量判断。

SSL_do_handshake() failed

通常与 HTTPS 握手有关，可能是协议版本、证书、SNI、回源域名不匹配。此时 access.log 未必有完整请求记录。

Nginx日志和 CDN 报错要按同一时间窗口比对。不要只看当前日志，因为 CDN 节点可能重试，源站可能只记录了重试成功的那一次。

三类证据如何互证根因

排障时最有效的做法，是把端口、WAF、Nginx日志放到同一个时间线里看。

分支一：端口不可达

证据组合通常是：

• 外部 nc 或 curl 到源站端口超时。
• Nginx access.log 没有对应请求。
• WAF日志也没有命中记录。
• CDN报 connect timeout 或 origin connection timeout。

处理方向：

• 核对 CDN 回源协议和端口是否与 Nginx listen 一致。
• 检查系统防火墙、云安全组、机房访问控制是否放行 CDN 回源 IP。
• 确认 Nginx 服务运行且监听在正确地址，例如不是只监听 127.0.0.1。
• 如果使用自定义端口，确认中间防护设备没有拦截该端口。

分支二：WAF误拦截

证据组合通常是：

• 源站端口从外部可连接。
• WAF日志在故障时间点有 block、challenge、reset 动作。
• Nginx access.log 无记录，或记录为 403。
• 放行特定规则后，CDN回源恢复。

处理方向：

• 不要长期关闭WAF。
• 将误伤规则改为针对特定路径、参数、Header 的例外。
• 对 CDN 回源 IP 或回源 Header 设置精确白名单。
• 保留高风险规则，例如常见注入、上传攻击、恶意扫描规则，只调整误伤条件。

分支三：Nginx或后端处理慢

证据组合通常是：

• 源站端口可达。
• WAF无拦截或只记录放行动作。
• Nginx access.log 有请求，request_time 很长。
• error.log 出现 upstream timed out、connect() failed 或后端连接异常。

处理方向：

• 检查后端服务是否存活、监听端口是否正确。
• 查看应用日志、PHP-FPM慢日志、数据库慢查询或线程池占用。
• 适当调整 Nginx 与应用的超时配置，但不要用无限增大超时时间掩盖性能问题。
• 对大文件、动态接口、上传接口分别设置合理的 CDN 和源站超时策略。

修复后用三组验证闭环

故障恢复后，不要只刷新首页确认能打开。建议按以下顺序复测：

1. 从外部执行端口验证，确认源站 80/443 或自定义回源端口可连接。
2. 使用 curl --resolve 模拟真实域名、SNI和源站IP，确认回源请求返回预期状态码。
3. 在 CDN 控制台刷新或预热一个未缓存URL，观察是否仍出现回源超时。
4. 同时查看 WAF日志，确认没有新的 block/challenge 命中。
5. 查看 Nginx access.log，确认 CDN 回源请求进入源站，状态码、request_time、upstream_response_time 正常。
6. 查看 error.log，确认没有持续的 upstream timeout、SSL handshake failed 或连接拒绝。
7. 如果此前调整过白名单或观察模式，按计划收敛为精确规则，避免长期扩大暴露面。

一次可靠的 CDN回源连接超时排查，最终应能形成这样的证据链：源站端口是否可达，WAF是否放行，Nginx是否收到请求以及请求在源站内部耗时多少。三者能互相印证，根因就不会停留在“可能是网络”或“可能是安全策略”这种模糊判断上。