源站IP已泄露，切换高防IP后如何验收网站防护？看DNS、回源与直连结果

源站IP已经泄露，接入高防IP后是否安全，不能只看网站能否正常打开，也不能只看DNS解析是否改过。验收要同时确认：公网DNS把访客引向高防入口；高防节点能正常回源；外部用户不能绕过高防直接访问源站。三项都符合预期，才说明接入链路基本闭合；如果源站仍可被公网直连，攻击者就可能继续绕过高防。

建议在切换完成、DNS缓存逐步更新后，按“DNS解析—经高防访问—回源状态—源站直连—证据留存”的顺序检查。下面的命令以 Linux 或 macOS 常见终端为例，需将域名和 IP 替换为自己的实际值。测试时不要用压力流量验证防护，也不要仅凭一次本地访问结果判断全部用户的解析情况。

验收标准：三条链路都要核对

“解析到高防”不等于“源站已隐藏”，“源站直连失败”也不等于高防业务已经正常。验收结论应建立在三项结果相互印证的基础上。

1. 核对DNS：所有对外入口是否都已切换

先检查网站实际使用的主机名，例如主域名、www、API域名、图片域名等。不要只查一个域名；旧的子域名解析、单独的API入口，甚至未使用的测试域名，都可能仍然暴露源站。

dig +noall +answer example.com A
dig +noall +answer www.example.com A
dig +noall +answer example.com AAAA
dig +noall +answer example.com CNAME

将 example.com 替换为实际域名。A记录查询IPv4，AAAA记录查询IPv6，CNAME用于查看别名链路。不同服务的配置方式可能不同：有的高防接入提供IP地址，有的要求将域名指向指定的CNAME。判断标准不是“必须看到某种记录类型”，而是解析链路最终应符合服务商给出的接入方式，不能落回源站公网地址。

还应从不同的公共递归解析器查询，区分本地缓存和权威配置：

dig @1.1.1.1 +noall +answer example.com A
dig @8.8.8.8 +noall +answer example.com A

这里的解析器地址仅作为查询示例；也可以使用企业网络或其他公共DNS。若结果不一致，先看TTL和切换时间。递归解析器可能在TTL到期前继续使用旧记录，因此刚修改后短时间内出现新旧结果并不必然代表配置失败。但如果超过原记录TTL后仍有解析器指向源站，或权威DNS本身仍发布旧地址，就需要检查DNS记录是否改全、是否存在重复记录或错误的主机名。

DNS检查的异常分界

• A记录仍为源站IP：主站可能没有切到高防，或查询的是未切换的域名。先核对权威DNS中的记录及实际业务域名。
• A记录已切换，但AAAA仍指向源站：支持IPv6的访客可能绕过高防。确认是否需要IPv6接入；若暂不提供IPv6业务，应按实际架构处理相关记录，避免留下可用的源站入口。
• 主域名正确，子域名不一致：逐个检查网站实际对外提供服务的主机名，不要用主站结果代替全站结论。
• 本地查询与公共解析器不同：记录查询时间、解析器和TTL，等待缓存更新后复查；不要只清理自己的电脑缓存就宣布切换完成。

DNS只能说明用户通常会被引向哪里，不能证明高防一定接管了请求，也不能证明源站无法被直接访问。

2. 验证经高防访问：用户请求是否能完成业务闭环

使用正常域名访问首页、登录页、API或其他关键业务路径，检查页面内容、状态码和核心功能。只看到首页返回200并不足以验收：静态资源可能走另一域名，API可能仍指向旧入口，登录或提交操作也可能在回源时失败。

可先用只读请求查看响应状态和耗时：

curl -sS -o /dev/null \
  -w 'remote_ip=%{remote_ip} status=%{http_code} connect=%{time_connect}s total=%{time_total}s\n' \
  https://www.example.com/

remote_ip显示当前连接的目标地址，通常可用来辅助确认客户端连到哪个入口；若前面存在多层解析、代理或地址转换，应结合高防平台的请求日志和DNS结果判断，不能把单次输出当作唯一证据。status为200只是页面成功响应的一种表现，重定向、鉴权等业务也可能合理返回其他状态码，需按网站预期解释。

随后检查高防侧是否能观察到对应时间段的请求记录，以及源站是否有相应回源记录。正常情况下，请求应经过预期入口并由高防转发到源站；如果用户访问成功但高防侧没有对应流量，可能仍有其他DNS记录、缓存入口或备用域名在服务。

回源异常时，重点区分“入口正常、源站未响应”和“用户请求根本没到预期入口”。例如高防侧出现回源连接失败、超时或源站返回异常状态，需检查源站服务、回源地址、端口、Host头和TLS配置；若高防侧没有该请求，则回头核对DNS、访问域名及客户端缓存。不要为了让回源恢复而直接放开所有公网来源，这会削弱源站隔离。

3. 验证源站直连：确认已泄露的IP不能绕过高防

这一步是判断“源站IP已经泄露”后防护是否闭环的关键。测试应从不在源站管理白名单中的外部网络进行；如果只在办公室或运维出口测试，而该出口已被允许回源，结果可能误判为公网开放。

通过 curl --resolve 可以在保留域名、Host和TLS SNI的情况下，指定连接到源站IP。它不会修改DNS，也不会向其他目标发起压力测试：

curl -k -sS -o /dev/null \
  --connect-timeout 5 \
  --resolve www.example.com:443:203.0.113.10 \
  -w 'remote_ip=%{remote_ip} status=%{http_code} connect=%{time_connect}s\n' \
  https://www.example.com/

将 203.0.113.10 替换为已泄露的源站IP。-k会跳过证书校验，只适合这项连通性核对，不能据此判断证书配置正确；如果希望同时检查证书，应去掉 -k，并把证书错误单独记录。也可以在源站提供HTTP业务时，将端口和URL改为实际配置，但不建议在验收时扫描无关端口。

如何解释直连结果

• 连接超时或被拒绝：可能是源站防火墙已限制公网访问，也可能是该端口没有服务。结合防火墙策略和源站日志确认原因，不能单凭超时证明高防规则正确。
• 返回403、仅允许名单访问的页面或其他预期拒绝结果：说明请求到达了某个服务并被拒绝。确认拒绝来自源站访问控制，而不是应用本身碰巧返回403。
• 正常返回网站页面或业务API数据：源站仍可被直连，验收不通过。应检查公网入站规则，确保业务端口只接受高防回源地址及必要的运维、监控来源，并复测。
• 返回其他站点、默认页或证书异常：仍需按“连接到了源站服务”处理。即使没有展示目标网站，也可能暴露服务器入口或其他虚拟主机，不能将其直接视为安全。

源站有管理、监控或健康检查需求时，确实可能保留特定来源的访问权限。验收时应明确这些白名单的用途和范围，并确保不包含所有公网地址。修改防火墙前先保存现有规则、确认带外管理或控制台可用，限定变更端口和来源；若规则影响业务，应按预先保存的配置回滚，避免误封管理入口。

4. 结合日志判定：把DNS、回源和直连结果对起来

建议用同一时间窗口检查三处记录：客户端或测试终端结果、高防访问/回源记录、源站访问及防火墙日志。记录时使用统一时区，最好精确到分钟或秒，并保留测试域名、测试出口、请求路径和结果。

如果经高防访问成功，高防日志中有对应请求，源站日志也出现由预期回源来源发起的访问，同时外部直连源站被访问控制拒绝，证据链较完整。若源站日志显示请求来自任意公网地址，或直连请求返回正常业务内容，应继续核查访问控制，而不是仅凭DNS已切换判定完成。

注意客户端IP传递方式。经过高防后，源站网络连接的对端通常可能是高防回源地址，真实访客地址则可能通过约定的请求头传递。确认源站只信任可信回源来源提供的客户端IP头，不能无条件相信任意互联网请求附带的同名头部，否则直连请求可能伪造来源信息，造成日志和访问控制判断失真。

5. 留存验收证据并复核

每次检查至少保存以下信息，便于交付确认和后续变化追踪：

• 检查时间、时区、测试网络出口和操作人员。
• 每个业务域名的A、AAAA、CNAME查询结果，查询所用解析器及TTL。
• 经高防访问的目标域名、URL、状态码、连接地址和高防侧对应记录。
• 源站直连测试的目标IP、端口、返回结果，以及源站或防火墙日志中的对应时间点。
• 当时生效的源站公网访问控制规则；敏感信息如令牌、账号、完整内部地址应按内部规范脱敏保存。

证据宜保留原始终端输出或日志导出文件，并附上截图或简短记录说明。截图要能看出时间、测试对象和结果，避免只截取“成功”字样而缺少上下文。对外共享时不要公开源站IP、管理地址、访问令牌等敏感信息。

切换后复核一次DNS缓存更新，再在后续维护窗口重复检查关键域名和直连结果。DNS记录、回源地址白名单、防火墙规则或业务域名发生变化后，也应重新验收。只要发现源站IP仍能从非授权公网来源正常访问，就应将“源站直连”标记为未通过；在确认入口、回源和访问控制均符合预期前，不要把DNS切换本身当作防护完成。