多数情况下，高防没接稳的根源不是防御能力不够，而是源站真实IP被攻击者挖了出来，攻击流量绕过高防直接打在源站上,高防节点再能扛也无济于事。
高防没接稳的典型表现有哪些
高防接没接稳，从现象上就能判断出来，业内专家指出，高防没接稳的案例中，相当一部分问题出在源站与高防之间的链路上,而不是高防本身。
攻击流量绕过高防直连源站端口
最典型的表现是：高防控制台显示攻击量很小，但源站服务器的带宽和CPU占用已经爆表，正常接稳的情况下，攻击流量应该先被高防清洗，源站只会收到相对干净的流量，如果源站还是被打得喘不过气，那只有一种可能攻击者拿到了源站IP，并且请求直接打到了源站端口上,根本没有经过高防。
这种情况下，高防相当于一个形同虚设的门卫,攻击者早就从后墙翻进了院子里。
源站日志里出现大量异常扫描痕迹
查看源站nginx或Apache日志，如果发现如下规律,那源站IP基本已经暴露：
- 大量来自不同IP段的端口扫描记录
- 针对非标准端口的试探性连接
- 重复的Host头请求，尤其是用IP直接访问或换不同域名绑定同一IP的请求
- 固定UA标识的批量探测流量
攻击者拿到了真实IP之后，不会第一时间发起大流量攻击，而是先做一轮扫描踩点，确认端口开放情况、Web中间件类型、是否存在旁站风险，然后再决定用什么姿势打。源站日志里的扫描痕迹，往往比攻击本身来得更早。
回源链路带宽被打满，网站间歇性宕机
还有一种情况是攻击流量虽然经由高防转发，但回源链路的带宽不够，导致源站被大流量来回拖拽，高防清洗后的流量虽然少了攻击特征，但合法请求的瞬时并发依然会冲爆源站带宽，此时高防控制台看到的攻击数据并不大,但源站的网络出口已经堵死。
这类表现说明高防本身没有接错，但回源架构对请求峰值的承接能力太弱,同样会让网站处于半死不活的状态。
源站IP暴露怎么排查
要知道高防是不是没接稳，核心动作就是确认源站IP是否暴露，这个排查过程不需要用到多高级的工具,几步操作就能验证个大概。
用DNS历史记录反查真实IP
域名切到高防之前，通常有一段直接解析到源站IP的时间，这些历史解析记录会被第三方平台存档,攻击者花几十块钱买一份解析历史就能看到你老家在哪。
排查步骤：
- 在微步在线（ThreatBook）或SecurityTrails中搜索你的主域名
- 查看历史A记录，找出切换高防之前的解析IP
- 对比当前解析结果，看是否存在一个已在DNS停用但历史可查的源站IP
- 把查到的IP填入浏览器地址栏，带上Host头访问一次，如果返回的是你的网站内容，那源站IP基本实锤暴露
很多人换高防之后只改了DNS的A记录，但邮件解析（MX）、子域名解析（CNAME）里仍然残留着源站IP线索,这些旁路记录同样会被扫描工具关联出来。
用证书透明度日志锁定源站关联IP
SSL证书是排查源站IP的一条重要线索，CT日志系统（Certificate Transparency）记录了所有公开签发证书的域名和IP归属,攻击者通过查询证书日志能直接找到域名的历史IP和关联IP段。
排查方式：
- 打开crt.sh，搜索你的域名
- 查找证书中Subject Alternative Name字段绑定的域名
- 将这些域名逐一进行DNS解析，看是否指向高防IP以外的其他地址
- 通过IP反查工具确认该IP段下是否托管了你的网站
证书透明度日志骗不了人，只要证书签发过，就一定会被记录。如果源站IP关联过证书签发记录，且该IP当前解析的域名已经切换，这个IP就会被标记为“历史源站”，一旦被攻击者利用,高防形同虚设。
多节点拨测验证回源链路是否裸露
用拨测工具从不同地理位置的节点同时请求你的域名，观察返回的IP是否始终一致，同时用直连探测的方式，拿着疑似源站IP对80、443、8080等常用端口做TCP连接测试，如果连接成功且返回的Banner与你的Web服务匹配,那就说明源站端口对外敞开。
常见操作命令：
dig @8.8.8.8 yourdomain.com查看当前解析结果curl -I http://你的源站IP -H "Host: yourdomain.com"测试源站是否响应tcping 你的源站IP 443检查端口连通性
经过上述三步排查，如果确认源站IP已经暴露，那高防没接稳的问题就不是高防本身的问题,而是源站藏身位置出了问题。
高防和CDN怎么配合才能遮住源站
很多人选高防服务器的时候，先问一句价格，高防服务器多少钱一个月固然重要，但比价格更关键的问题是高防解决带宽攻击，CDN解决源站隐藏，两者职责不同,混为一谈就会出问题。
高防、CDN、源站三者的分工对比
| 层级 | 职责 | 常见误区 |
|---|---|---|
| 高防 | 流量清洗、DDoS防御 | 以为高防能顺带隐藏源站 |
| CDN | 内容加速、源站IP遮挡 | 以为挂了CDN就万事大吉 |
| 源站 | 业务请求处理、数据存储 | 直接暴露在公网，防火墙策略松散 |
高防是一个流量清洗节点，攻击流量进来之后被识别并丢弃，但高防节点IP本身就是公开的，攻击者不一定要打你的源站，直接打高防IP也可以消耗防御资源，CDN的作用则是把源站IP彻底藏到内容分发网络背后，让外界只能看到CDN节点IP,源站只在回源时与CDN建立连接。
源站防火墙只放行高防回源IP
不管用不用CDN，源站防火墙都应当只信任高防回源IP段或CDN回源IP段,具体操作：
- 在源站服务器安全组或iptables中，将入站规则设置为仅允许高防IP段或CDN的节点IP段访问80、443端口
- 22端口（SSH）只允许办公网IP访问，不开放给公网
- 关闭所有不需要的端口，只保留业务必需端口
- 若回源协议是HTTP，建议改成HTTPS回源，避免明文传输泄漏回源路径
配置完防火墙策略后，下一步操作是验证公网是否还能直连源站，如果不能连，说明源站已从公网上隐身；如果还能连,检查是否有防火墙规则遗漏或端口映射冲突。
别让小配置细节毁掉整套防线
有相当一部分高防没接稳的案例，问题不在架构,而在细节：
- 双线机房设置了端口映射，将高防IP的某些端口直接转发了源站
- 源站服务器上部署了多个站点，其中一个域名的解析记录还指回源站IP
- 邮件服务器和Web服务器共用同一IP，SPF记录和MX记录暴露了IP归属
- 子域名字典爆破得到了一个未加防护的子域名，解析到源站IP
这些细节看起来很琐碎，但攻击者只要抓住其中一条，就能顺藤摸瓜找到源站。源站暴露是一条链路的失效，而不是单个节点的防御失效。
秒拨IP轮换攻击下，高防怎么接稳才算真接稳
近年来，秒拨IP在攻击场景里出现得越来越频繁，所谓秒拨IP，就是攻击者利用拨号VPS或代理池，在极短时间内快速轮换出口IP，让高防的封禁策略形同虚设，这种情况下，高防的表现会非常诡异封禁了一个IP，下一秒又冒出来一批新的IP。
秒拨IP攻击的识别特征
秒拨IP流量有三个明显特征：
- 单个IP的请求量很小，通常只有几次到十几次
- 单位时间内的请求频率很高，整体攻击规模很大
- 攻击流量分布在大量C段和B段，地理位置分散
传统的高防封禁策略基于IP信誉库，碰到秒拨IP池基本失灵，因为每一个秒拨IP都是新鲜的，不在任何黑名单里，高防来不及建立信誉模型,攻击就换了一波新IP继续打。
应对秒拨IP的防御策略
- 在高防侧开启智能CC防护，以会话指纹、设备指纹、浏览器行为作为判定维度，而不是单纯依赖IP信誉
- 使用JS质询验证客户端，普通浏览器会自动通过验证，而脚本攻击会在质询阶段被拦截
- 对回源端口做连接数限制和速率限制，单IP连接数超过阈值直接丢包
- 在源站层面增加WAF规则，拦截非浏览器UA的请求以及特定API路径的异常高频访问
这些策略组合起来，即使攻击者可以无限更换IP，也很难模拟出真实浏览器的行为特征。高防是否接稳，看的不是能不能封完所有IP，而是能不能在IP轮换的间隙完成流量识别和清洗。
判断高防是否真正接稳的标准
一个简单有效的判断方式：高防控制台的攻击拦截趋势与源站服务器的带宽使用曲线应该呈反向关系，高防拦截的流量越大，源站接收的流量越小，如果高防显示风平浪静，源站却累得半死，那基本上可以断定高防没接稳；如果高防拦截曲线飙升时源站依然平稳,那才算真正接稳了。
关注高防的封禁频率和误杀率也有参考价值，秒拨攻击场景下，高防的误杀率若偏高，说明判定策略过激，正常用户会被误伤；若封禁数据极少但攻击依旧发生，说明流量没能经过高防,源站已经裸奔。
关于高防没接稳和源站暴露的常见问题
高防没接稳，网站被打了怎么办？
先切断源站的公网暴露面，立即在高防后台更换回源方式，同时修改源站防火墙规则为只允许高防回源IP段访问，紧接着排查源站IP是否被历史DNS记录或证书日志暴露，确认后更换源站IP并完成高防的新IP绑定,等新IP生效后再逐步恢复业务流量。
怎么确认源站IP已经暴露？
用DNS历史记录工具查询域名切换高防之前的A记录，同时检查证书透明度日志中该域名关联的所有IP，将查到的IP用浏览器直接访问并绑定Host头，如果返回你的网站页面，说明源站已经可以被外部直接访问,暴露状态确认。
高防和CDN都部署了，源站还会暴露吗？
会，如果源站IP通过历史解析记录、证书日志或邮件记录泄露，CDN和高防都无法阻止攻击者直连源站，源站IP一旦暴露，唯一的办法是更换新IP并将新IP严格控制在回源链路内部，不在公开DNS中发布,同时让CDN承担对外解析职责。