回源不通时高防侧与源站侧怎么分工排查，故障原因是什么

回源不通时，排查责任不该“先猜后查”，而应“先分后合”：高防侧先自证清白，源站侧再自查自纠，双方各守一段，用配置、日志和抓包说话，才能最快定位断点。

这是行业内处理高防回源故障的通用共识，很多团队在遇到网站打不开、接口超时时，第一反应是互相甩锅，高防服务商说源站没配白名单，源站运维说高防IP根本没转发，回源链路就像一条水管，高防机房和源站机房各握着一端，中间还有运营商线路，哪一端堵了、哪一段裂了,必须有条理地排查。

回源不通时，高防侧和源站侧的责任边界怎么划分

先明确回源链路的基本构成

一次完整的回源请求，从用户访问开始，要经过本地DNS解析、高防机房入口清洗、高防回源节点、运营商骨干网、源站接入线路，最后到达源站服务器，这中间任何一个环节出问题，表现都是“网站打不开”或“请求超时”。

行业共识认为，责任划分的核心依据是数据包的流向，高防侧负责把清洗后的流量安全送达源站机房入口，源站侧负责确保服务器能正常接收并响应这些流量，跨运营商线路那段，双方都有配合排查的义务,但通常由高防服务商协调解决。

分工排查的基本原则

• 高防侧先查：确认回源IP、回源端口、回源协议配置是否正确,防护策略是否误拦。
• 源站侧后查：确认防火墙、安全组、Web服务配置是否放行了高防回源IP段。
• 双方同步查：源站服务器同时抓包，高防侧同时查看回源监控，两边数据一对照,断点位置就清楚了。

常见的责任争议场景

实际工作中,最容易扯皮的是这几种情况：

• 高防IP ping不通，但源站直接访问正常大概率是高防侧IP封堵或线路问题。
• 高防IP ping得通，但域名访问超时可能是回源端口没配好,或者源站Web服务没起来。
• 源站CPU和带宽都跑满了明显是源站侧扛不住,高防侧再干净也没用。
• 时报时好，没有规律优先怀疑跨运营商线路丢包,或者源站防护软件有频率限制。

高防侧排查清单：先自证清白，别急着甩锅源站

高防侧排查的核心，是证明“流量我已经送到你家门口了”，这需要从配置、策略、线路三个维度逐一验证。

核对基础回源配置

登录高防控制台，逐项核对以下配置,这是首要排查点：

• 回源IP是否正确：检查是否填成了源站服务器的内网IP，或者写错了IP段，看是否填错了一位数字,这种情况占比不小。
• 回源端口是否一致：高防侧填的端口必须和源站实际监听端口完全一致，例如源站Nginx监听443，高防侧却配了8443,必然不通。



• 回源协议是否匹配：HTTP回源和HTTPS回源是两回事，如果源站强制跳转HTTPS，而高防配置了HTTP回源,就会出现循环重定向或404错误。

检查防护策略是否误拦

防护策略是回源故障的高发区，但往往被忽略,特别是以下两类情况：

• CC防护阈值过低：当攻击流量不大的时候，防护策略可能会把正常回源请求识别为攻击，直接丢弃，可以先临时调高阈值或观察模式,测试回源是否恢复。
• IP黑白名单冲突：检查是否在封禁列表里误加了源站IP或高防回源节点IP，统计表明,此类配置失误在回源故障中占相当比例。

验证高防节点到源站的线路质量

如果配置没问题，就要看线路，通常高防服务商的后台能看到回源监控数据,重点关注：

• 回源丢包率：大于5%的丢包率就可能造成明显卡顿或超时。
• 回源延迟：如果高防机房到源站的延迟比正常波动大了50毫秒以上,就要考虑绕路或骨干网拥塞。

这时候可以联系高防服务商的技术支持，要求他们提供回源链路的mtr或traceroute数据，这组数据是判断“流量到底送到了哪一跳”的关键证据。

高防侧自查操作步骤

1. 用高防IP直接访问源站（如果设置了端口映射，用映射后的端口测试）。
2. 在源站服务器上执行 tcpdump host 高防回源IP 或 tcpdump port 回源端口,看有没有来自高防IP的流量到达。
3. 在高防控制台查看“攻击日志”和“回源监控”,确认当时是否有攻击触发防护。
4. 如果抓包显示流量根本没到源站,那问题大概率出在高防侧或中间线路。

源站侧排查清单：别只看“我能打开”，要看“高防能不能打进”

源站侧最常见的误区是：运维直接在本地访问源站IP，发现网站正常，就认定源站没毛病，但高防回源是从特定的回源IP段发起的请求，源站侧必须确保自己能“认”这些来源。

检查源站防火墙和安全组

这是源站侧第一排查点,也是出问题最多的环节。

• 云服务器安全组：确认入方向规则是否放行了高防回源IP段，很多安全组只放行了80和443端口，却限制了来源IP范围，高防IP段不在白名单内,全部被拒。
• 源站本地防火墙：执行 iptables -L -n 或 firewall-cmd --list-all 查看规则，重点看INPUT链的DROP和REJECT规则,确认没有把高防回源IP段挡在外面。
• 宝塔面板等可视化工具：检查防火墙插件里是否启用了“仅允许国内IP访问”或“云盾”之类的一键防护,这些功能经常会屏蔽高防回源节点。

检查Web服务配置和监听状态

防火墙放行只是第一步，Web服务本身也得正常工作,用以下命令快速验证：

• 执行 netstat -tlnp | grep 端口号 确认Nginx或Apache在监听。
• 确认Web服务配置里的 server_name 是否包含了当前访问的域名,否则会返回403或444。
• 确认站点目录是否存在且权限正确，很多回源“成功但打不开”的情况是文件权限导致的403错误。

检查源站带宽和性能瓶颈

如果高防回源IP能ping通，端口也通，但请求就是超时,多半是源站本身压力太大。

• 带宽跑满：登录源站服务器执行 iftop 或 nload，观察实时流量，如果带宽占用接近上限，回源请求处理不过来,就会出现响应缓慢或丢包。
• CPU和内存占用过高：执行 top 查看负载，如果负载持续超过核心数，说明源站计算资源不足，可能被刷了,也可能业务量突增。
• 连接数耗尽：执行 ss -s 查看socket统计，当TIME_WAIT或ESTABLISHED连接数达到系统上限时，新连接会被丢弃,高防回源自然不通。

源站侧自查操作步骤

1. 在源站防火墙里临时放行所有IP（仅限测试环境），测试高防回源是否恢复，如果恢复,就是白名单配置问题。
2. 抓包查看是否有来自高防的回源流量，使用 tcpdump -i eth0 host 高防回源IP -nn。
3. 如果抓到了SYN包但没回包，检查源站内核参数 net.ipv4.tcp_tw_recycle 是否开启（高并发下建议关闭）。
4. 如果回包发出去了但高防侧没收到,检查源站上行带宽是否被打满。

高防回源失败排查中的联动验证方法

分工不等于孤立，高防侧和源站侧在各自排查完清单项之后，需要做一次联动验证，这是最快定位问题的手段,很多复杂故障靠这一步就能水落石出。

静态验证：两边配置对拍

拉一个表格,把高防侧的配置和源站侧的配置逐项对照：

对照时往往一眼就能发现“端口写错了”或“IP填成了内网地址”这类低级错误。

动态验证：同一时间点双侧抓包

• 高防侧联系技术支援,导出当时回源请求的日志和转发记录。
• 源站侧同步执行抓包,记录同一时间窗口内的数据包。
• 双方对比时间戳和数据包特征，如果高防侧有转发日志，但源站侧抓不到包，说明流量丢在了中间链路或运营商侧，如果源站侧抓到包但没回包,说明源站服务器没正确处理。

验证时的注意事项

• 测试时间尽量选在业务低峰期,避免业务流量干扰判断。
• 修改完配置后，等待2-3分钟再测试，因为高防节点配置下发有延迟,DNS解析也有缓存。
• 每次只改一个变量，不要同时修改防火墙和高防配置,否则无法判断是哪一项生效了。

Q&A：高防回源排查常见疑问

高防回源失败为什么ping不通，但网站部分区域能打开？

ping不通通常说明高防IP的ICMP协议被禁ping了，或者高防节点线路有问题，但页面能打开说明TCP的80或443端口是通的，回源链路本身没有断，这种情况多数是禁ping策略导致，不影响业务，无需特殊处理，如果页面打开也时好时坏，重点排查运营商线路丢包,建议联系高防服务商对回源链路做一次mtr测试。

网站回源超时怎么处理，是源站的问题还是高防的问题？

先看超时现象集中在哪个环节，在高防控制台查看回源监控，如果显示回源失败率或超时率高，再排查源站，操作方法很简单：在源站上用 curl -I http://回源IP 测试本地响应，如果本地秒开，说明源站Web服务正常，接下来抓包看高防回源流量是否到达，流量到了但超时，检查防火墙或安全组；流量没到，问题在高防侧或运营商线路，以统计来看，大部分回源超时是安全组或本地防火墙设置不当导致的，运维在执行 iptables -L 查看规则时,经常发现高防回源IP被误放进DROP列表。

更换高防IP后回源不通，需要改源站什么配置？

主要检查防火墙白名单，新的高防IP对应新的回源IP段，需要把新增的回源IP段加入源站防火墙和安全组的放行规则，注意不要删掉旧的回源IP段，部分高防服务商在切换IP后有一个新老IP段并行期，删掉旧的会导致切换失败，其次检查CDN或WAF等其他安全产品里是否写死了旧高防IP，如果有,同步更新。

回源排查说到底是两边拿数据对齐的过程，高防侧提供转发日志和回源监控，源站侧提供抓包结果和Web日志，两相对照，断点位置立现，下次再遇到回源不通，别急着下结论，先按上述清单走一遍，多数问题在配置核对阶段就能解决，剩下的疑难杂症,联动验证几乎都能兜住。