当攻击报文还在进源站时，问题往往出在DNS解析、回源策略、WAF规则、源站IP防护以及业务侧回源适配这五个环节中的一处或多处配置上。很多站长会遇到一个迷惑场景：明明给网站套了CDN和WAF，攻击流量却还是直接打到了源站服务器上，这说明防护链条看着完整，实际在某个节点上开了个口子，下文按排查优先级拆解。
攻击报文还能到源站？先按这五个环节排查配置
第一道防线失效：DNS解析和回源链路没守住
首先要确认域名解析是否真正指向了防护节点,行业共识认为，相当一部分“攻击打到源站”的案例，根源在于域名解析配置错误，导致防线的第一道门就没关。
具体步骤：
- 使用
dig或nslookup命令解析域名，检查A记录是否指向CDN或WAF服务商的节点IP，而非源站服务器的公网IP。 - 确认根域名和
www子域名是否都完成了解析生效。 - 检查是否有多条A记录同时存在,若源站IP和CDN节点IP同时配置在DNS记录里，就会触发“源站IP直接暴露”和“CDN回源失败怎么办”的连带问题。
如果解析没问题,下一步看回源链路，进入CDN控制台的“回源配置”页面，核对回源地址是否写成了源站的内网IP，或者错误填写成了域名但未做内部解析，这些细节会导致CDN回源失败，但攻击流量却依然能直连源站。
第二道防线漏风：回源策略被绕过
配置了CDN但攻击报文仍抵达源站,另一个高发原因是回源方式选择不当或回源HOST头配置冲突。
看下你的回源模式：
- 回源到域名：适合源站是简米云、酷番云等云厂商负载均衡的场景。
- 回源到IP：适合源站IP固定的场景。
- 回源HOST头：默认应与访问域名保持一致。
实操中容易踩坑的点是：源站Nginx配置了多个server_name，而回源HOST头填成了默认站点或空值，此时攻击报文通过CDN转发至源站时，可能被Nginx的默认server块接收，绕过了针对特定域名的安全规则，反过来，若源站服务器上的防火墙只允许来自CDN回源IP段的访问，而回源HOST头配置错误导致请求被转发至其他后端，同样会出现攻击流量绕过防护直接命中业务的情况。
第三道防线失灵：WAF配置成了摆设
很多朋友以为开了WAF就万事大吉,但WAF规则为什么不生效，主要出在下面几个被忽视的配置细节上。
拦截模式误配成“观察”
WAF的防护模式一般分“观察”和“拦截”两种，观察模式只记录攻击日志不阻断请求，如果你在测试阶段开启了观察模式，上线后忘记切回拦截模式，攻击报文自然能长驱直入。
规则未启用，蜜罐也没开
部分高防IP服务商提供的WAF默认规则集可能处于关闭状态，需要手动启用，进入WAF控制台的“防护规则”或“规则组管理”页面，确认基础防护、Web攻击防护、CC防护等开关是否处于开启状态。
特殊路径白名单过宽
某些CMS系统后台或API接口需要放行,于是有人把整个目录都加进了白名单，比如你因为后台编辑器上传图片，把/uploads目录设为“所有规则不检测”，那么攻击者把恶意PHP脚本上传到该目录并直接访问，报文就不会触发任何WAF告警，先查一下白名单列表，重点关注是否包含上传目录、静态资源目录或.php、.asp等可执行文件后缀。
协议层绕过：畸形报文穿透检测
还有一种相对少见但更隐蔽的情况：WAF节点已检测并拦截了HTTP层攻击，但
攻击者使用分片报文、畸形Content-Length或编码混淆技巧，让WAF无法正确还原攻击载荷，这种情况下，报文到达源站后由Web服务器解析，进而利用源站中间件漏洞。
源站IP泄露，防护直接被绕开
当你排查完以上配置后,攻击报文还能到源站，那就要考虑一个残酷事实：源站IP可能早已暴露，攻击者只需绕过CDN，直接访问源站IP，所有在CDN、WAF层做的防护配置便形同虚设。
怎么确认源站IP是否泄露？
- 查看历史DNS解析记录,使用微步在线或SecurityTrails的被动DNS库反查域名过去解析过的所有IP地址。
- 检查邮件头信息,登录站点后台，检查是否有来自源站IP段直接发出的服务邮件，暴露源头多为邮件服务器配置不当。
- 检查子域名,攻击者常通过爆破子域名，找到未接入CDN的二级域名（如
test.yourdomain.com、old.yourdomain.com），再通过它解析出真实源站IP。
一旦确认泄露,处理思路如下：
- 登录Web服务器提供商后台,更换源站公网IP。
- 为源站服务器配置安全组,仅放行来自CDN回源IP段和本地运维IP端口的访问。
- 检查是否有用于建站的其他子域名未接入防护,并统一接入。
业务侧回源适配出错，最后一道门开了
机房与网站架构的兼容性问题也会被忽视,比如你在源站做了HTTPS双向认证，但CDN回源时只传了证书、没传私钥；或者源站Web程序（如WordPress、Discuz）后台写死了网站域名的解析路径，这类情况会导致CDN回源到源站时，源站程序内部执行了重定向，最终暴露其真实IP。
一个典型的场景：
CDN回源失败怎么办的问题解决了，但网站启用HTTPS后，站内所有静态资源链接仍写死为源站IP，攻击者抓包就能看到页面源码里的IP地址，处理方式：
- 全局搜索数据库中的源站IP字段,替换为站点域名。
- 检查
.env文件或wp-config.php中的WP_HOME与WP_SITEURL常量配置。 - 使用类似
Really Simple SSL插件或自行修改.htaccess，确保前端资源全部走HTTPS域名加载。
按层剥茧才能堵住漏洞
遇到攻击报文还在进源站,别急着换更高配置的WAF，按以下顺序排查：确认DNS解析、核实回源策略、检查WAF拦截模式与白名单、追查源站IP泄露、调整业务侧回源适配，多数情况下，问题出在最基础的一两层配置里，解决后建议登录源站服务器，查看安全日志中是否存在绕过WAF“中转到源站”的访问记录，以此确认攻击链路是否已断开。
“攻击报文还在进源站”排查Q&A
问题1：源站日志里能看到WAF节点的IP，但攻击来源还是大量涌入，说明什么？
说明WAF层可能只做了转发,没做拦截，先检查WAF的防护模式是否为“拦截”，再检查源站访问日志里是否有高频的相同UA或相同参数攻击特征，如果有，说明WAF规则完全没有对该攻击类型生效。
问题2：源站IP没泄露，解析也正确，为什么攻击报文还能绕过CDN直连源站？
检查源站服务器上是否运行着其他域名服务,且该域名未经过CDN，攻击者可利用旁站或同IP上的其他域名，通过IP反查找到源站，处理方式是隔离业务，将建站服务与邮件服务、API服务拆分到不同端口或不同服务器，并仅对Web服务端口开放CDN回源白名单。