高防服务接入后如何核对源站、DNS与回源配置

高防服务接入后，不能只看控制台显示“已生效”或业务页面能够打开就结束验收。真正需要确认的是：用户访问的域名是否已经指向高防入口，源站是否仍被其他解析或IPv6记录绕过，高防节点是否能够按预期访问源站，以及源站是否只接受允许的回源流量。

建议把验收分成两层：先在正式切换前核对源站、DNS和回源依赖，再在DNS切换完成后从实际访问链路复核。判断标准不是“某一次请求返回200”，而是访问路径、源站暴露面、协议参数、放行策略和异常证据都能互相对应。

一、先确定高防接入的验收标准

1. 明确一条合格的访问链路

常见的业务访问链路如下：

客户端
  ↓
业务域名
  ↓
高防服务入口
  ↓
高防清洗或转发节点
  ↓
回源地址或源站负载均衡
  ↓
应用服务器

验收时应确认每一段都符合设计，而不是只检查最后一段应用响应。

这里的“回源”通常指高防服务将业务请求转发到源站的过程。不同产品可能使用固定回源IP、专属回源网段、回源域名、源站负载均衡地址或私网连接，不能直接套用其他服务的配置方式。

2. 先区分服务形态

核对方法取决于高防服务处理的是哪类流量：

• HTTP或HTTPS业务：重点检查域名、Host、SNI、证书、请求头、健康检查和应用状态码。
• TCP业务：重点检查监听端口、连接建立、四层转发和源站返回数据。
• UDP业务：重点检查端口、协议报文、会话保持、回包路径和应用层响应，不能用HTTP状态码代替验收。
• 仅提供清洗或转发、不代理应用层请求的服务：不能默认存在X-Forwarded-For等HTTP请求头，也不能默认源站看到的是高防节点IP。

如果没有确认产品的工作层级，就容易出现“网页能打开，但真实客户端IP错误”“TCP端口通了，但应用协议不兼容”或者“HTTP检查成功，但UDP业务没有回包”等误判。

3. 设定放行和暴露边界

验收前应形成一份简短的边界说明：

• 哪些域名接入高防；
• 哪些端口需要提供服务；
• 哪些源站地址是正式地址，哪些只是测试地址；
• 高防侧使用哪些回源地址或网段；
• 源站是否允许直接公网访问；
• 管理端口是否与业务端口分离；
• IPv4和IPv6是否都在接入范围内；
• 是否存在跨地域、跨账号或第三方供应商管理的DNS和源站。

如果业务只接入HTTPS的443端口，源站防火墙不应为了测试而长期放开所有端口。测试期间可以临时增加范围受控的规则，但必须记录变更单、影响范围和回滚方式。

二、按照固定顺序核对，避免只查其中一项

推荐顺序是：

1. 盘点资产和权限；
2. 固化切换前源站基线；
3. 检查高防侧的源站与协议参数；
4. 检查权威DNS和递归解析结果；
5. 验证高防到源站的回源链路；
6. 验证客户端到高防的正式访问链路；
7. 对照日志判断实际来源；
8. 留存异常证据并安排复核。

这个顺序的目的，是先确认“应该访问哪里”，再确认“实际访问哪里”，最后确认“链路中的每个设备看到的是什么”。

三、第一步：盘点域名、源站和变更权限

1. 建立业务资产清单

不要只记录主域名。高防接入经常因为遗漏子域名、接口域名或IPv6记录而出现绕过。

可以按下面的字段建立清单：

如果一个域名存在多个A记录、AAAA记录或CNAME链路，应逐条登记，不能只抄一条查询结果。

2. 确认权限和依赖

正式变更前，至少需要确认以下权限可用：

• DNS服务商的解析修改权限；
• 高防控制台中添加源站、配置端口和查看日志的权限；
• 源站云安全组、防火墙或负载均衡访问控制权限；
• 应用团队查看访问日志和错误日志的权限；
• 证书管理权限，尤其是高防侧终止HTTPS时；
• 变更审批、值班和回滚联系人。

如果DNS由第三方托管，源站由另一家云平台提供，而高防服务又由独立账号管理，必须提前完成跨平台核对。否则即使技术参数正确，也可能因为没有权限修改某个AAAA记录或安全组而无法完成切换。

四、第二步：核对源站是否正确、完整且未被遗漏

1. 区分源站地址和高防入口

高防控制台中通常会同时出现“防护IP”“业务接入地址”“源站地址”“回源地址”等字段。验收时要确认每个字段的含义，不能把高防入口再次填成源站地址，也不能把临时测试地址误作为生产源站。

重点核对：

• 源站IP是否属于生产环境；
• 源站端口是否有服务监听；
• 源站使用的是单机、源站集群还是负载均衡；
• 源站域名解析是否会再次指回高防入口；
• 回源使用IP还是域名；
• 源站是否存在主备地址；
• 业务是否需要固定Host或SNI；
• 源站是否同时提供IPv4和IPv6。

如果高防回源填写的是域名，应特别检查这个域名的解析结果。回源域名若再次解析到高防入口，可能造成回源环路；如果解析结果受内外网DNS视图影响，也可能导致不同节点访问到不同地址。

2. 检查源站监听端口和协议

在已授权的源站上，可以使用以下方式核对监听状态。命令仅用于查看，不会修改服务配置：

ss -lntup

如果只需要查看特定端口，可以使用：

ss -lntup | grep -E ':(80|443|8443)\b'

输出中应确认：

• 端口处于LISTEN或相应的UDP监听状态；
• 监听地址覆盖高防回源可能访问的网络接口；
• 监听进程是预期应用，而不是旧服务或测试进程；
• 高防配置的端口与源站实际端口一致；
• HTTPS源站使用的证书和协议与高防回源设置匹配。

例如，高防侧配置回源端口443，但源站实际上只监听8443，除非高防侧明确配置了端口转换，否则访问失败是预期结果。不要因为源站本机通过某个内部端口可以访问，就认为公网回源参数已经正确。

3. 检查IPv4和IPv6是否存在绕过

很多接入问题不是A记录错误，而是AAAA记录仍然指向源站。客户端优先使用IPv6时，可能完全绕过高防。

分别查询：

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

判断时注意：

• A记录应指向高防要求的IPv4入口，或按照产品说明指向指定CNAME；
• AAAA记录应指向高防支持的IPv6入口；
• 如果高防接入范围不包含IPv6，应评估删除AAAA记录、关闭对应业务监听，或为IPv6建立等价的防护链路；
• CNAME目标不能与其他旧服务冲突；
• 记录中不能残留源站公网IP、旧CDN地址或测试地址。

删除或修改AAAA、A记录会影响客户端访问，属于有业务影响的DNS变更。变更前应导出原记录，记录原TTL，并准备按原值恢复的回滚方案。

4. 从源站日志确认真实来源

“源站防火墙放行了高防IP”并不等于应用日志一定能看到高防IP。需要分别确认网络层来源和应用层来源：

• 网络层日志记录的是建立连接的源IP；
• 应用日志可能读取X-Forwarded-For、X-Real-IP或产品专用字段；
• 四层转发可能通过透明转发保留客户端IP，也可能统一使用高防回源IP；
• 请求头可能由高防添加、覆盖或完全不传递。

不能直接让应用信任任意客户端提交的X-Forwarded-For。只有在源站确认请求来自可信高防回源地址时，才应按照产品说明恢复真实客户端IP，并在Web服务器、负载均衡和应用框架之间保持一致。

五、第三步：核对DNS是否真的已经指向高防

1. 先查权威DNS，再查递归DNS

普通查询只能反映当前查询位置看到的结果，不能证明权威记录已经正确。建议先查看域名的权威DNS：

dig NS example.com +short

得到权威DNS名称后，再向权威服务器查询：

dig @ns1.dns-provider.example www.example.com A +noall +answer
dig @ns1.dns-provider.example www.example.com AAAA +noall +answer
dig @ns1.dns-provider.example www.example.com CNAME +noall +answer

命令中的ns1.dns-provider.example只是示例，应替换为实际权威DNS。需要核对：

• 权威DNS返回的记录类型是否正确；
• 返回值是否为高防服务要求的目标；
• 是否存在多个旧值；
• TTL是否符合当前变更计划；
• CNAME是否还有未预期的后续跳转；
• 记录是否受到DNS视图、地域线路或健康检查策略影响。

然后从企业DNS、运营商递归DNS或其他授权测试网络分别查询：

dig @企业DNS服务器 www.example.com A +noall +answer
dig @企业DNS服务器 www.example.com AAAA +noall +answer

如果不同递归DNS结果不同，应先判断是缓存尚未过期、线路解析策略不同，还是权威配置存在多个视图。不能简单把所有差异都归因于DNS缓存。

2. 检查TTL，但不要把TTL当成切换时间承诺

TTL表示递归解析器在一定时间内可以缓存记录，但实际生效时间还可能受到以下因素影响：

• 递归DNS自身的最小或最大缓存策略；
• DNS服务商对TTL的限制；
• CNAME链路中各级记录的TTL；
• 企业网络或客户端的本地缓存；
• DNS线路、健康检查和分地域解析；
• 上游缓存异常或旧配置残留。

因此，切换前可以按变更方案提前降低TTL，例如从较长时间调整为几分钟级，但应以DNS服务商允许的范围为准。不要在切换窗口内临时把TTL改低后，就承诺所有客户端立即完成切换。

切换后应在多个解析环境重复查询，并记录查询时间、解析服务器和完整结果。若只有部分网络仍返回旧地址，应先确认旧值的TTL和查询路径，再决定等待、联系DNS服务商或执行回滚。

3. 检查容易被遗漏的DNS对象

至少要复核以下对象：

• www、api、m、upload、download等业务子域名；
• 登录、支付、后台、文件上传和接口域名；
• A和AAAA记录；
• 通配符记录，如*.example.com；
• CNAME指向的旧CDN或旧负载均衡；
• 用于健康检查或内部调用的域名；
• 邮件、验证、回调等不应切换到高防的记录；
• 内外网分离解析中的内部视图；
• DNSSEC、CNAME扁平化或线路解析策略。

不能为了“让所有域名都经过高防”而随意修改邮件或验证记录。应按照业务用途逐条决定是否接入，避免引入无关故障。

六、第四步：核对高防到源站的回源配置

1. 对齐回源地址、端口和协议

在高防控制台或配置导出中，逐项比对：

回源协议不能只看“端口号”。例如，源站443端口要求TLS握手，高防却按HTTP明文回源，即使端口填写正确也会失败；相反，源站80端口若被配置为HTTPS回源，也会出现协议错误。

2. 检查Host和SNI

一个IP上可能承载多个HTTPS站点。此时源站需要根据Host和SNI选择正确证书与应用路由。

从测试终端验证高防入口时，可以使用业务域名作为TLS名称：

curl -vkI --resolve www.example.com:443:203.0.113.10 https://www.example.com/healthz

这里的203.0.113.10为文档示例地址，应替换为经过授权的高防入口。--resolve会让本次请求连接指定IP，但仍使用www.example.com作为访问域名和TLS名称，适合验证高防入口是否正确处理Host和SNI。

如果要单独验证源站，可以在受控网络中使用源站地址：

curl -vkI --resolve www.example.com:443:198.51.100.20 https://www.example.com/healthz

198.51.100.20同样只是文档示例。源站若不应被公网访问，不要在公网终端直接执行这类测试；应从授权的运维网络、跳板机或内部测试环境进行。

结果判断包括：

• 返回的证书域名是否覆盖业务域名；
• HTTP状态码是否符合健康检查预期；
• 是否返回默认站点；
• 是否出现301、302跳转到错误域名；
• 应用是否因Host不匹配返回403或404；
• 源站和高防入口的响应头、响应体是否符合预期。

查看TLS握手时可以使用：

openssl s_client -connect 203.0.113.10:443 -servername www.example.com 

重点观察证书主题、证书链、TLS协商结果和握手是否成功。不要仅凭浏览器能打开页面就判定回源HTTPS正确，因为浏览器可能自动跟随跳转、使用缓存，或访问了不同的解析结果。

3. 核对源站放行范围

源站侧常见的放行方案有：

• 放行高防官方提供的回源IP段；
• 放行专属回源IP；
• 放行私网连接或专用网络；
• 通过源站负载均衡或安全组接收高防流量；
• 在高防侧使用回源认证，源站同时限制网络来源。

应以高防服务实际提供的回源地址为准，不要根据网上旧资料或其他产品的IP段配置。若回源IP会变化，需要确认变更通知机制和更新责任人。

防火墙规则应遵循“只放行业务所需端口和可信回源来源”的原则。例如业务只需要443端口，就不应为了方便把所有端口对所有来源开放。管理SSH、数据库、缓存和监控端口应保持独立限制。

修改云安全组、主机防火墙或网络ACL前，应完成当前规则备份，并记录：

• 修改前规则；
• 修改后规则；
• 影响的主机、负载均衡和端口；
• 预计生效时间；
• 失败时恢复原规则的方法；
• 执行人和审批单号。

不要在未确认已有带外登录或备用管理通道的情况下大范围收紧防火墙，否则可能把运维人员和回滚通道一起阻断。

七、第五步：用分层测试确认实际链路

1. 测试不应只看首页

建议准备最小化的健康检查路径，例如：

• 不依赖登录状态；
• 响应内容短；
• 能反映应用进程和关键依赖状态；
• 不执行写入、扣费或其他有副作用的操作；
• 能区分高防入口、源站直连和源站负载均衡。

如果现有健康检查路径会访问数据库、对象存储或第三方接口，应明确它代表的是应用整体可用性，还是仅代表Web进程存活。高防侧健康检查过重，可能把短暂的后端依赖异常放大为大范围摘除源站。

2. 先测试源站，再测试高防入口

源站直连测试用于判断源站本身是否能够按预期提供服务，高防入口测试用于判断接入后的完整链路。两者结果可以组成简单的判断矩阵：

高防入口测试可以使用：

curl -sS -D /tmp/highdefense.headers \
  -o /tmp/highdefense.body \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/healthz

printf 'status: '
awk 'NR==1 {print $2}' /tmp/highdefense.headers

这是示例命令，实际应替换域名、入口地址和健康检查路径。输出文件中可能包含Cookie、请求标识或内部响应头，保存和传递时应按敏感信息处理。

3. 检查TCP或UDP业务时不要套用HTTP方法

TCP业务至少应验证：

• 连接是否能够建立；
• 连接建立后的协议握手是否成功；
• 长连接是否被异常提前关闭；
• 高防侧和源站侧是否都能看到对应会话；
• 多源站情况下会话是否按预期保持。

UDP业务应由应用团队提供最小测试报文和预期响应。需要同时观察发送方向和回包方向，因为“UDP端口可发送”不代表回源和回包路径完整。若高防服务支持会话保持、源端口保留或特定协议识别，应将这些参数纳入验收记录。

4. 查看源站日志中的时间和请求标识

测试时同时记录：

• 发起时间，建议统一使用带时区的时间；
• 测试域名、端口和路径；
• 测试终端出口地址；
• 高防入口地址；
• 请求ID或Trace ID；
• 源站日志中对应的连接来源；
• 高防控制台中的转发或拦截记录。

如果请求在客户端返回成功，但源站没有对应日志，可能是高防缓存、边缘响应、访问了错误入口，或请求没有真正完成回源。此时不能直接把“200”当成源站回源成功。

八、根据结果分支处理，不要盲目重复切换DNS

1. DNS已指向高防，但源站仍有直接访问

这通常说明存在以下情况之一：

• 源站公网IP仍被直接暴露；
• 旧的业务子域名或备用域名未切换；
• AAAA记录绕过了高防；
• 负载均衡公网地址未纳入防护；
• 应用或第三方系统硬编码了源站地址；
• 内外网DNS返回不同结果。

下一步应先完成资产补查和访问路径确认，再决定是否收紧源站公网访问。不能直接删除源站地址或关闭监听，尤其当仍有未迁移的内部系统依赖它时。

2. 高防入口失败，但源站直连成功

优先按照以下顺序核对：

1. 高防侧源站地址是否正确；
2. 回源端口是否正确；
3. 回源协议是否正确；
4. 源站安全组是否放行高防回源地址；
5. Host和SNI是否正确；
6. 源站证书校验名称是否匹配；
7. 健康检查路径是否存在；
8. 回源超时是否明显短于应用正常响应时间；
9. 多源站中是否只有部分节点配置错误。

不要先反复修改DNS，因为此类问题通常发生在高防到源站的链路，DNS切换无法修复回源协议或防火墙问题。

3. 高防入口成功，但源站日志显示请求来源异常

可能的解释包括：

• 高防使用固定回源IP，源站看不到客户端IP；
• 高防使用透明转发，源站看到的是客户端IP；
• 负载均衡在高防和源站之间再次改写了来源；
• 应用读取了不可信的转发请求头；
• IPv4和IPv6请求经过了不同链路；
• 测试请求实际访问了缓存或静态边缘响应。

应分别查看网络设备日志和应用日志，确认真实链路。若业务依赖客户端IP进行风控、审计或限流，必须在正式放量前确定可信字段、可信来源和多级代理解析顺序。

4. 部分网络仍返回旧解析

先保存不同解析服务器的结果，再判断：

• 查询是否命中了旧缓存；
• 权威DNS是否存在不同线路；
• 查询的域名是否相同；
• A和AAAA是否只有一类完成切换；
• CNAME链路中是否有旧目标；
• DNS服务商是否对TTL做了限制。

如果权威DNS已经返回新值，而个别递归DNS仍返回旧值，通常需要等待缓存过期并持续观察；如果权威DNS本身仍返回旧值，则应回到DNS配置和线路策略核对，不能只等待。

九、异常必须留证，才能支持回滚和复盘

1. 每次测试至少保存五类证据

建议建立一个按时间命名的验收目录，例如：

2025-03-08-high-defense-acceptance/
├── dns/
├── source-baseline/
├── origin-test/
├── edge-test/
├── logs/
└── change-record/

目录名称仅作示例，实际日期应使用真实变更日期。证据内容包括：

• 权威DNS和递归DNS查询结果；
• A、AAAA、CNAME及TTL；
• 高防侧源站、端口、协议和健康检查配置；
• 源站监听状态和防火墙规则快照；
• 源站直连与高防入口测试结果；
• 证书、Host和SNI验证结果；
• 高防转发、拦截或健康检查日志；
• 源站访问日志和错误日志；
• 变更单、执行人、时间和回滚记录。

命令输出可以保存为文本：

{
  date -Is
  dig NS example.com +short
  dig www.example.com A +noall +answer
  dig www.example.com AAAA +noall +answer
  dig www.example.com CNAME +noall +answer
} | tee dns-check.txt

保存日志前应脱敏Cookie、Authorization、用户手机号、内部IP段、管理地址和其他业务敏感信息。不要把带有访问令牌的完整请求头直接上传到工单或公开协作空间。

2. 使用“现象—判断—下一步”记录异常

异常记录不应只写“访问失败”。可以采用以下格式：

这样的记录能够避免不同团队各自重复修改配置，也便于判断一次变更究竟解决了哪一层问题。

十、按两个时间点复核，而不是只验收一次

1. 切换前复核

正式修改DNS前，至少确认：

• 源站地址和端口已经在高防侧登记；
• 源站服务正常监听；
• 高防回源地址已经加入受控放行规则；
• 源站直连测试结果已保存；
• 高防入口测试结果已保存；
• A、AAAA、CNAME和TTL已经导出；
• 健康检查路径和预期响应已确认；
• 业务联系人、DNS联系人和网络联系人同时在线；
• 回滚记录、审批和变更窗口已经准备好。

如果此时高防入口还无法成功回源，不建议直接切换正式DNS。先修复链路问题，通常比切换后再靠缓存和用户流量定位更可控。

2. DNS切换后复核

切换完成后，应在多个时间点执行复核，例如：

• 切换后立即查询权威DNS；
• 数分钟后查询企业递归DNS；
• TTL对应的缓存周期后再次查询；
• 业务低峰或观察窗口结束前检查一次；
• 下一次业务高峰前确认源站日志、错误率和回源量。

每次复核都应同时检查A和AAAA，不要只执行一次dig A。还要从实际业务入口访问关键页面、接口和静态资源，确认没有部分域名仍走旧链路。

3. 稳定后再收紧源站访问

如果切换后已经确认所有正式流量都经过高防，可以根据业务依赖逐步收紧源站公网访问。推荐采用过渡方式：

1. 保留旧放行规则，增加高防回源规则；
2. 切换DNS并观察高防流量和源站日志；
3. 确认内部系统、监控和第三方回调没有遗漏；
4. 在变更窗口内限制非必要公网来源；
5. 继续保留可快速恢复的原规则；
6. 观察稳定后，再删除不再使用的旧规则。

不要在高防刚切换、DNS仍处于缓存过渡期时立即删除所有旧放行规则。部分用户可能仍访问旧入口，过早收紧会把DNS缓存问题表现成业务中断。

修改防火墙或安全组后，应从高防入口重新执行业务测试，并从授权管理通道确认运维连接仍然正常。若回滚需要恢复旧规则，必须使用此前保存的版本，不要依赖临时记忆手工重建。

十一、最终交付时保留一份可复查的验收记录

交付给业务、网络和安全团队的记录，至少应包含：

• 接入域名和端口范围；
• A、AAAA、CNAME及权威DNS结果；
• 高防入口和源站地址；
• 回源协议、Host、SNI和证书校验方式；
• 健康检查路径、端口和预期结果；
• 高防回源IP或网段；
• 源站放行规则及生效时间；
• 客户端真实IP的传递和解析方式；
• 源站直连、高防入口和日志对照结果；
• 未解决的风险、负责人和复核时间；
• DNS和防火墙的回滚版本。

验收完成不代表后续无需检查。源站IP变更、证书更新、DNS线路调整、高防回源地址变化、负载均衡替换或新增IPv6，都可能使原有链路失效。每次涉及这些对象的变更，都应重新核对“域名指向哪里、请求从哪里进入、由谁回源、源站放行谁、日志记录什么”。

真正可交付的结果，不是控制台上的“已接入”状态，而是一套能够被复查的证据：DNS记录指向明确，源站没有遗漏的绕过入口，回源参数与协议一致，源站放行范围受控，客户端和源站日志能够解释同一笔请求，异常时还有完整的回滚依据。