高防接入后网站仍打不开？从DNS到回源端口逐项排查

高防接入后网站仍然打不开，并不一定是高防节点故障。访问链路通常经过“域名解析 → 高防入口 → 回源地址与端口 → 源站防火墙 → Web 代理 → 应用服务”多个环节，任何一层的地址、协议、端口或访问控制不一致，都会表现为超时、502、403、证书错误或页面空白。

排查时应先确认请求到底走到了哪一层，再逐步向源站内部收敛。运维现场建议按照低风险、由外到内的顺序进行：先查 DNS 和高防日志，再核对回源配置与端口，随后检查安全组、防火墙、Nginx 及应用状态。不要一开始就重启服务、放开所有端口或把源站重新暴露到公网。

先把“打不开”变成可判断的现象

记录访问时间和完整地址

先固定一次可复现的访问。记录以下信息：

• 访问的完整域名、协议和端口，例如 https://www.example.com/
• 发生故障的时间，最好精确到分钟，并统一时区
• 出问题的网络环境，例如办公网络、移动网络、云服务器或源站所在区域
• 浏览器显示的错误文字
• 是否所有页面都打不开，还是只有登录、上传、接口等特定路径失败
• 是否所有用户都失败，还是部分地区、部分运营商或仅 IPv6 用户失败
• 高防控制台中的请求日志、健康检查结果和回源错误信息
• 源站 Web 访问日志、错误日志及应用日志中对应时间段的记录

不要只记录“网站打不开”。下面这些现象对应的排查方向并不相同：

如果故障只发生在某个接口或登录页，不要把它直接归类为“高防不可用”。静态首页可以正常返回，但应用依赖的数据库、缓存、上传服务或鉴权接口仍可能异常。

先确认请求是否经过高防

从一台能够复现故障的 Linux 主机执行以下命令。www.example.com 仅为示例域名，请替换为实际域名。

DOMAIN="www.example.com"

curl -sS -D - -o /dev/null \
  --connect-timeout 5 \
  --max-time 15 \
  "https://${DOMAIN}/"

重点查看：

• HTTP 状态码；
• server、via、缓存状态、请求 ID 等响应头；
• 是否建立了 TLS 连接；
• 是连接超时，还是已经收到高防返回的错误页面；
• 高防控制台是否出现同一时间、同一域名的请求记录。

如果命令直接超时，而且高防侧没有任何请求日志，优先回到 DNS、网络入口或域名接入状态检查。如果高防有请求记录但没有回源记录，则问题通常位于高防到源站之间。如果高防和源站都有记录，则继续检查 Web 代理和应用。

一、检查 DNS：域名是否指向正确的入口

高防接入后，用户访问的域名通常应解析到高防提供的地址或接入目标，而不是直接解析到源站公网 IP。具体形式可能是 A 记录、AAAA 记录或 CNAME，但最终目标必须与高防服务商分配的接入信息一致。

分别查询 A、AAAA 和 CNAME

DOMAIN="www.example.com"

dig +noall +answer "$DOMAIN" A
dig +noall +answer "$DOMAIN" AAAA
dig +noall +answer "$DOMAIN" CNAME

也可以使用多个递归 DNS 进行对比：

for resolver in 1.1.1.1 8.8.8.8; do
  echo "Resolver: ${resolver}"
  dig @"${resolver}" +noall +answer "www.example.com" A
  dig @"${resolver}" +noall +answer "www.example.com" AAAA
done

这些命令的判断方式如下：

• 没有返回 A、AAAA 或 CNAME，可能是记录不存在、名称写错或记录尚未发布；
• 返回 NXDOMAIN，说明查询的名称在当前 DNS 体系中不存在；
• 返回 SERVFAIL，需要继续检查权威 DNS、DNSSEC、委派或上游故障；
• A 记录返回源站 IP，而不是高防入口，说明 DNS 可能仍指向旧配置；
• A 记录正确但 AAAA 记录仍指向旧源站，IPv6 用户可能绕过高防或访问到未配置的地址；
• CNAME 指向旧的高防接入目标、旧 CDN 或其他代理层时，可能形成错误链路；
• 多个解析结果中同时存在旧入口和新入口，只有部分用户失败是常见结果。

不要只在本地浏览器中观察解析结果。浏览器、操作系统和递归 DNS 都可能缓存旧记录。权威 DNS 已经修改，并不表示所有客户端会在同一时间刷新。应结合记录 TTL、负缓存时间以及不同网络的查询结果判断传播状态。

查询权威 DNS，排除递归缓存干扰

先获取域名的权威 DNS：

dig +short NS example.com

将结果中的权威 DNS 名称替换到下面命令中：

dig @ns1.example.net www.example.com A +noall +answer
dig @ns1.example.net www.example.com AAAA +noall +answer

如果权威 DNS 已经返回高防入口，而公共递归 DNS 仍返回旧地址，通常属于缓存尚未过期或不同解析线路仍在生效。此时不应频繁修改记录，否则会增加排查变量。

如果权威 DNS 本身返回错误，则需要检查：

• 记录是否添加在正确的主域名区域；
• www、根域名及其他业务子域名是否分别配置；
• CNAME 是否存在循环或目标不存在；
• DNS 托管商的 NS 委派是否正确；
• DNSSEC 签名与 DS 记录是否匹配；
• 是否存在按地区、运营商、线路划分的智能解析规则。

重点检查 AAAA 记录

很多“部分用户打不开”的故障来自 IPv6。浏览器可能优先使用 AAAA 记录，而源站或高防只配置了 IPv4。

dig +short www.example.com A
dig +short www.example.com AAAA

如果 AAAA 指向的地址没有对应的高防接入、云安全组放行、IPv6 路由或 Web 服务监听，处理方式有两种：

1. 完整配置 IPv6 的高防、网络、端口和源站链路；
2. 在确认业务暂不提供 IPv6 后，移除错误的 AAAA 记录。

删除或修改 AAAA 记录前，应确认它不是其他业务共用的入口，并记录原值以便回滚。不要为了快速恢复而直接删除所有 DNS 记录。

二、核对高防入口与回源配置

DNS 正确，只能说明用户找到了高防入口，不能证明高防能够访问源站。高防控制台中的接入配置通常至少包含以下项目：

区分“前端端口”和“回源端口”

例如，用户访问：

https://www.example.com/

这只说明用户与高防之间通常使用 TCP 443。实际链路可能是：

用户:443 → 高防:443 → 源站:8443

也可能是：

用户:443 → 高防:443 → 源站:80

两种架构都可以成立，但高防的回源协议必须与源站监听方式一致：

• 高防以 HTTP 回源，源站应在对应端口提供 HTTP；
• 高防以 HTTPS 回源，源站应完成 TLS 握手，并能识别正确的 SNI；
• 源站使用自签名证书时，高防可能因证书校验失败而拒绝回源；
• 源站证书覆盖的是 origin.example.com，但高防使用 www.example.com 作为 SNI 时，也可能导致握手失败。

如果高防日志显示“连接源站失败”，先核对端口和协议，不要立即修改应用代码。

通过高防入口验证 HTTP 层

DOMAIN="www.example.com"

curl -sS -D - -o /dev/null \
  --connect-timeout 5 \
  --max-time 15 \
  "https://${DOMAIN}/health"

/health 只是示例路径。如果业务没有该路径，可以改成一个明确返回 200 的静态或只读页面。结果可按以下方式解释：

• 收到 200、301、401 或 403，说明至少已经完成了 DNS、TCP、TLS 和 HTTP 通信，具体是否正常要结合业务预期；
• 收到 502 或 504，优先检查高防到源站的连接、端口和响应时间；
• 收到高防特征明显的 403，检查高防访问控制、地区策略、频率限制和规则命中记录；
• 收到源站自身的 403 或 404，说明请求大概率已经回源，继续检查 Host、路径和应用权限；
• 连接超时，先确认高防监听状态和回源链路是否有丢包、ACL 丢弃或错误端口；
• TLS 握手失败，使用带 SNI 的方式检查证书与协议。

DOMAIN="www.example.com"

openssl s_client \
  -connect "${DOMAIN}:443" \
  -servername "${DOMAIN}" \
  

如果输出中能看到证书链和握手协议，说明前端 TLS 至少能够建立。证书检查仍需关注主题名称、SAN、有效期以及证书链是否完整。

查看高防侧的回源字段

高防日志通常比浏览器错误页面更有价值。重点查看：

• 回源地址和回源端口；
• 连接源站耗时；
• TCP 连接是否建立；
• TLS 握手是否成功；
• 源站返回的 HTTP 状态码；
• 高防生成的错误码与源站错误码；
• 健康检查是否把源站标记为异常；
• 是否存在多个源站，其中只有部分地址故障。

如果一个源站地址健康、另一个地址不健康，用户可能出现间歇性访问失败。应先从高防配置中临时摘除明确异常的节点，并保留原配置，以便在修复后恢复。涉及生产流量切换时，应确认高防的权重、健康检查和自动摘除规则，避免多个变更同时发生。

三、由外到内检查源站端口和网络入口

先确认源站是否监听目标端口

登录源站执行只读检查：

sudo ss -lntp

如果只关心常见端口，可以缩小输出：

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

重点关注监听地址：

• 0.0.0.0:443 表示监听所有 IPv4 地址；
• [::]:443 通常表示监听 IPv6，具体行为还取决于系统参数；
• 127.0.0.1:8080 只允许本机访问，适合作为 Nginx 后端端口，但不能直接作为高防回源目标；
• 如果高防回源到源站公网 IP，而服务只监听 127.0.0.1，高防无法连接；
• 如果没有任何目标端口监听，防火墙放行也不能解决问题；
• 如果监听的是 8443，而高防回源配置为 443，仍会出现连接失败或拒绝。

在 Docker、容器编排或负载均衡环境中，还要确认端口映射是否存在。宿主机监听 443 不代表容器内应用已经监听对应端口，容器端口映射错误也会产生相同现象。

在源站本机测试 Web 服务

先测试本机 Web 入口：

curl -sv \
  --connect-timeout 3 \
  --max-time 10 \
  -H 'Host: www.example.com' \
  http://127.0.0.1/health

再测试实际应用后端端口，以下以 8080 为示例：

curl -sv \
  --connect-timeout 3 \
  --max-time 10 \
  http://127.0.0.1:8080/health

两次测试的结果可以帮助区分代理层和应用层：

• 直接访问 8080 正常，但访问本机 Nginx 失败，问题集中在 Nginx 站点配置或代理转发；
• Nginx 返回 502，通常是后端端口不可达、连接被拒绝或应用响应超时；
• 应用端口本身返回 500，说明请求已经到应用，需要检查应用日志和依赖服务；
• /health 返回 404，不一定代表服务不可用，可能只是健康检查路径不正确；
• 访问 127.0.0.1 正常，但通过源站公网地址失败，继续检查监听地址、云安全组、路由和防火墙；
• 本机访问也超时，先检查服务进程和本机资源，不要先修改高防配置。

从受控位置验证源站端口

源站通常只允许高防回源出口地址访问，不建议直接从任意公网主机扫描源站。可以使用高防提供的回源探测、源站运维跳板机或已加入白名单的维护主机测试。

ORIGIN_IP="203.0.113.10"

nc -vz -w 5 "${ORIGIN_IP}" 80
nc -vz -w 5 "${ORIGIN_IP}" 443

203.0.113.10 是文档示例地址，应替换为实际源站 IP。结果含义如下：

• succeeded：TCP 端口能够建立连接，但不代表 HTTP、TLS 或应用一定正常；
• timed out：常见于安全组、防火墙、路由或上游设备丢弃连接；
• refused：主机可达，但端口没有监听或服务主动拒绝；
• 从维护主机能连接，而高防仍不能连接：重点核对高防回源出口 IP 是否被放行，以及高防使用的端口和协议；
• 维护主机也不能连接，但本机访问正常：重点检查云安全组、NAT、主机防火墙和监听地址。

不要用临时开放 0.0.0.0/0 的方式验证高防回源。这样虽然可能快速改变结果，却会把源站暴露给扫描、攻击和绕过高防的直接访问。需要调整策略时，应只增加高防官方提供的回源 CIDR，只放行实际端口，并记录修改前规则。

检查云安全组和主机防火墙

云安全组、网络 ACL、负载均衡监听器和主机防火墙可能同时存在。建议按层查看，不要直接清空规则。

常见 Linux 环境的只读检查命令如下：

sudo nft list ruleset

使用 firewalld 的系统可以执行：

sudo firewall-cmd --state
sudo firewall-cmd --list-all

使用 UFW 的系统可以执行：

sudo ufw status verbose

实际执行前先确认系统使用的防火墙管理方式。不要在同一台机器上凭经验同时操作 nftables、firewalld 和 UFW，多个管理工具可能互相覆盖规则。

检查规则时关注：

• 高防回源出口网段是否被允许；
• 目标端口是否与高防回源端口一致；
• 规则是否只允许 TCP，却误配成 UDP；
• 安全组放行了 443，但高防实际回源到 8443；
• 入站规则正确，但出站规则阻止了响应；
• 规则顺序是否存在更早的拒绝；
• IPv4 已放行，但 IPv6 仍被拒绝；
• 云负载均衡或 NAT 是否还有一层端口转换。

防火墙规则变更前应保存当前规则或导出安全组配置，确认影响范围，并准备按“相同来源、相同端口、相反动作”回滚。生产环境不要使用清空规则、停止防火墙或永久放开全部来源的方式排障。修改后应先验证高防健康检查和业务请求，再观察是否影响 SSH、监控、备份等其他连接。

四、检查 Nginx 反向代理与虚拟主机

当源站端口可以建立连接，但高防仍返回 404、403、502 或重定向异常时，进入 Web 代理层检查。

确认配置语法和站点匹配

以 Nginx 为例，先执行语法检查：

sudo nginx -t

如果语法正确，再查看当前生效配置中的域名和监听端口：

sudo nginx -T 2>/dev/null | grep -E 'listen|server_name|proxy_pass'

重点确认：

• listen 是否包含高防回源使用的端口；
• server_name 是否包含用户访问的完整域名；
• 是否有默认站点抢先匹配请求；
• proxy_pass 指向的地址和端口是否正确；
• proxy_pass 末尾斜杠是否导致 URI 被重写；
• HTTPS 站点是否加载了正确证书；
• 配置文件修改后是否实际被 include；
• 是否存在重复的 server_name，导致请求落到其他虚拟主机。

如果高防把原始 Host 头传给源站，而 Nginx 没有对应的 server_name，可能返回默认站点页面或 404。若高防改写了 Host，则源站应按改写后的域名配置虚拟主机，不能只按用户在浏览器中看到的域名判断。

核对反向代理和请求头

一个常见的 HTTP 反向代理结构如下，仅用于说明配置关系：

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

    location / {
        proxy_pass http://127.0.0.1:8080;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
    }
}

实际修改前应备份目标配置文件，确认 Nginx 版本和现有 include 结构。示例中的 proxy_read_timeout 不是解决应用慢查询的通用方法，盲目调大只会让连接占用更久。

几个容易被忽略的边界：

• 高防终止 HTTPS 后以 HTTP 回源，应用若不知道原始协议，可能反复把用户重定向到 HTTPS，形成重定向循环；
• 源站日志中的 remote_addr 可能是高防回源地址，而不是最终用户地址；
• 只有在确认请求头来自可信高防出口时，才可以按服务商约定的头部恢复真实客户端 IP；
• 不要无条件信任用户自己提交的 X-Forwarded-For；
• proxy_pass 的 URI 处理方式可能使 /api/health 被转发成 /health 或其他路径；
• 应用依赖 Host、Origin 或 Referer 校验时，高防的头部改写必须与应用白名单一致。

修改配置后先验证，再加载：

sudo nginx -t
sudo systemctl reload nginx

reload 通常不会像重启那样立即中断现有连接，但仍应在变更窗口执行。若修改后故障扩大，应恢复修改前的配置文件，重新执行 nginx -t，确认通过后再 reload。例如，提前保存了原文件后，可以按实际路径执行：

BACKUP_FILE="/etc/nginx/conf.d/site.conf.bak"
TARGET_FILE="/etc/nginx/conf.d/site.conf"

sudo cp "$BACKUP_FILE" "$TARGET_FILE"
sudo nginx -t && sudo systemctl reload nginx

这里的备份文件和目标文件必须由运维人员根据实际配置路径填写，不要把示例路径直接用于生产机器。

五、检查应用状态和上游依赖

从日志判断请求停在哪一层

查看 Nginx 最近的访问和错误日志：

sudo tail -n 50 /var/log/nginx/access.log
sudo tail -n 50 /var/log/nginx/error.log

如果站点使用了独立日志文件，应以实际配置中的 access_log 和 error_log 路径为准。日志可能包含 Cookie、令牌或用户参数，不要直接发布到公共工单或聊天群。

典型判断方式如下：

• 没有访问日志：请求可能没有到达该 Nginx，或者请求被更前面的安全设备拒绝；
• 有访问日志但状态为 502：重点查看 error log 中的 connect() failed、upstream timed out 或 connection reset；
• 有访问日志且状态为 404：检查虚拟主机、URI 和应用路由；
• 有访问日志且状态为 499：客户端或高防提前断开，需结合上游响应时间判断；
• 有访问日志且状态为 500：请求已经进入 Web 或应用层，应继续查看应用错误；
• 高防显示 504，但源站没有访问日志：通常是回源连接尚未到达 Web 服务，或被端口、防火墙、负载均衡拦截。

检查应用进程，但不要先重启

先确认应用服务是否处于运行状态。由于服务名称和部署方式不同，不要直接猜测服务名：

systemctl --type=service --state=running

确认实际服务名称后再查看状态，例如：

sudo systemctl status your-app.service --no-pager
sudo journalctl -u your-app.service --since "15 minutes ago" --no-pager

如果使用容器，可以先查看容器状态：

docker ps

重点关注：

• 应用进程是否反复退出或被 OOM Killer 杀死；
• 应用监听端口是否与 Nginx proxy_pass 一致；
• 数据库、缓存、对象存储等依赖是否连接超时；
• 连接池、线程池或文件描述符是否耗尽；
• 应用是否只允许特定 Host、来源 IP 或协议；
• 健康检查路径是否需要认证，是否会触发昂贵的数据库操作；
• 发布后是否出现配置文件、环境变量或密钥读取失败。

重启可以暂时清理连接堆积，但也可能丢失现场、掩盖根因并造成更多连接失败。应先保存日志和指标；只有确认需要恢复服务时，才在维护窗口执行重启，并提前确认启动命令、配置版本和回滚方式。

六、按结果分支收敛故障范围

下面的分支表适合在完成基础测试后使用：

处理时坚持“一次只改一个关键变量”。例如先修正回源端口并验证，再处理 Host 头；不要同时修改 DNS、证书、防火墙和 Nginx，否则即使恢复，也很难确认真正原因。

七、修复后的验证与持续观察

按完整链路复测

修复后至少进行以下几类验证：

1. 从不同网络查询 A、AAAA、CNAME，确认没有旧入口、错误 IPv6 或意外的源站地址。
2. 通过正常域名访问首页、静态资源和一个只读健康路径。
3. 使用 curl -D - 检查状态码、响应头、证书和重定向链。
4. 在高防日志中确认请求命中正确的防护域名，并显示成功回源。
5. 在源站访问日志中确认请求来自预期的高防回源地址。
6. 检查源站 Web 错误日志和应用日志，确认没有同步出现 5xx、连接拒绝或超时。
7. 从允许的维护主机验证源站端口仍按预期开放，确认没有因临时规则导致源站被直接暴露。
8. 对登录、接口、上传等关键业务流程进行只读或低风险验证，而不是只打开首页。

可以用下面的命令观察完整响应：

DOMAIN="www.example.com"

curl -sS -D - -o /dev/null \
  --connect-timeout 5 \
  --max-time 15 \
  "https://${DOMAIN}/"

如果需要验证源站虚拟主机，必须在受控维护环境执行，且不要把源站 IP 公开：

ORIGIN_IP="203.0.113.10"
DOMAIN="www.example.com"

curl -skv \
  --connect-timeout 5 \
  --max-time 15 \
  --resolve "${DOMAIN}:443:${ORIGIN_IP}" \
  "https://${DOMAIN}/health"

--resolve 会让本次请求绕过 DNS，将域名解析到指定 IP，但仍使用该域名发起 TLS SNI 和 HTTP 请求。-k 只适合临时忽略源站证书校验以观察链路，不能作为正式修复方案。如果源站按设计只接受高防回源地址，那么从维护主机直接访问失败可能是正常的，不能据此判定源站服务异常。

保留持续观察指标

恢复访问后，不要立即关闭排查窗口。建议在一个业务观察周期内持续关注：

• 高防请求成功率、4xx、5xx 和回源失败率；
• 高防到源站的连接耗时、响应耗时和健康检查结果；
• 源站 Nginx 的 499、502、504 数量；
• 应用 5xx、数据库连接失败和缓存连接失败；
• CPU、内存、连接数、文件描述符和带宽；
• IPv4 与 IPv6 的访问比例和错误率；
• 不同域名、不同端口或不同源站节点之间的错误分布。

如果只是修改了 DNS，应结合实际 TTL 继续观察旧入口请求是否逐步下降；如果修改了回源端口或防火墙，应重点观察高防健康检查是否持续通过，而不是只看一次首页访问。

最终应把“域名解析目标、前端监听端口、回源地址、回源端口、协议、Host 头、源站放行网段、Nginx 配置版本”记录在变更单或运维文档中。下一次出现无法访问时，可以直接与当前生效配置比对，快速判断是 DNS 漂移、回源配置变化，还是源站内部服务异常。