防护生效的标志是攻击包被丢弃（或返回拦截响应），而不是被转发到源站。只要攻击流量还在往你的服务器上送，哪怕页面显示正常，防护也等于没生效，这个结论适用于WAF、CDN、云防火墙等绝大多数场景。
防护生效的标志：攻击包被丢弃还是转发，核心看源站流量
判断防护是否真正在干活，不能光看控制台里拦截了多少条日志。最硬核的标准只有一条：攻击请求有没有触达源站。
丢弃和转发分别意味着什么
用一个生活场景来理解，你家装了道防盗门,快递员送了个可疑包裹。
- 丢弃：门卫直接拒收，包裹没进你家门，攻击包被防护设备拦下，返回403或连接重置，源站服务器什么都没收到,这就是防护生效。
- 转发：门卫收了包裹，原封不动放进你家里，攻击包穿透防护直达源站，由你的服务器去硬扛，无论门卫后来有没有“标记”这个包裹，它都已经进了家门。这就是防护失效。
两者对源站的影响天差地别，攻击包被丢弃时，源站CPU、带宽、数据库连接数几乎没有波动，攻击包被转发时，源站日志里会留下完整的攻击记录，响应速度变慢,严重时直接宕机。
为什么说转发等于防护失效
业内专家指出，多数云防护产品的检测引擎都存在“放行误判”的可能，无论规则库写得多完善，总有绕过手法能让攻击流量伪装成正常请求，在这种情况下，防护设备会把攻击包转发回源站,源站就成了最后的防线。
如果此时源站本身没有额外的安全软件，攻击就成功了，而防护设备还在控制台里把这次请求记录为“已拦截”因为它以为自己在拦截,实际上包已经转发走了。
这里有个关键误区：“拦截”和“丢弃”在语义上有区别。
- 拦截并阻断：设备直接丢弃连接,源站无感知。
- 拦截并放行：设备记录了日志，但请求仍然转发到源站，常见于观察模式、测试模式或规则配置为“记录”而非“阻断”。
不少站长在后台看到“已拦截”的统计，就以为防护在生效，结果源站访问日志里赫然躺着带union select和<script>标签的完整请求。凡是到了源站的，都算没拦住。
WAF防护日志怎么看丢弃与转发标记
要学会确认攻击包被丢弃还是转发,第一步是学会看日志。
看WAF日志的关键字段
无论是简米云WAF、酷番云EdgeOne还是开源ModSecurity,日志里都会有一个核心字段：
- action（动作）：取值为
block、drop、deny时，说明攻击包在WAF这一层就被丢弃了，源站没收到，取值为allow、pass、log时，说明攻击包被放行转发,源站收到了。 - status_code（返回码）：WAF丢弃攻击包时，客户端通常收到403或444（Nginx关闭连接），如果源站返回了200,说明请求已经到达源站并被正常处理。
- upstream_addr（上游地址）：这个字段尤其重要，如果日志里存在
upstream相关字段，且值非空，说明请求被转发到了源站，如果该字段为空,则说明请求在WAF层被终结。
源站日志里的“真话”
WAF日志可能因为配置失误说谎，但源站访问日志永远不会说谎，以Nginx为例，进入源站服务器的每个请求都会记录在access.log里。
判断方法非常简单粗暴：
- 在WAF控制台发起一条测试攻击，比如
/?id=1 AND 1=1。 - 等一分钟后，去源站服务器执行
tail -f /var/log/nginx/access.log查看实时日志。 - 如果看到了刚才那条请求的记录，说明攻击包被转发到了源站,防护没有生效。
- 如果没有任何记录，说明攻击包在防护层被丢弃了,防护生效。
这条实操路径适用于任何防护产品，因为源站日志是最终的事实标准。
常见误判：控制台显示拦截了，但攻击包仍被转发到源站
这是最坑的一种情况，你明明看到拦截数据在涨，源站却还是被拖垮了,多数情况下是以下三种原因导致的。
真实IP绕过防护
防护配置只对经过CDN或WAF的流量生效，但如果攻击者拿到了源站真实IP，直接绕过防护打源站，那么所有攻击包都会绕过WAF直接转发到源站。
这种情况下，防护设备日志里干干净净，源站却被打得满目疮痍，此时防护是否生效，和攻击包丢弃还是转发无关,因为攻击包根本没经过防护设备。
解决方案：在源站服务器上配置防火墙策略，只允许防护节点IP访问80/443端口，业界统称“源站IP保护”,是云防护场景下必不可少的一环。
规则配置成了“观察模式”
很多防护产品默认或推荐新手先开启观察模式（也称作“预警模式”“记录模式”）,目的是先看效果再决定要不要阻断。
在观察模式下，攻击包会被原样转发到源站，同时生成一条“拦截日志”，页面显示是拦截了，实际上攻击包已经打到你的业务代码上了，除非源站自身有防SQL注入和XSS的措施,否则观察模式期间被打穿是大概率事件。
图片验证码与JS质询的例外场景
防护产品在处理CC攻击时,常见策略是返回JS质询页面或图片验证码。
此时攻击包同样不会被丢弃，而是被防护设备拦截并返回了一个“质询页面”，如果客户端通过验证，后续请求会被放行转发；如果没通过,则不会转发。
这里要明确一个边界：质询响应本身属于“防护生效”的范畴，因为源站没收到攻击请求，攻击包被丢弃还是转发，在CC防护场景下的判定标准是源站是否收到大量高频重复请求,而非客户端是否收到403。
防护配置是否生效的验证步骤
按照下面的实操流程，五分钟内就能确认你的防护到底是在丢弃攻击包,还是在转发。
- 确认防护模式：进入WAF或CDN控制台，找到防护规则配置页，确认全局防护模式为“拦截”（Block）而非“观察”（Observe/Log）。
- 发起测试攻击：使用浏览器或curl模拟一次攻击请求，例如
curl -k "https://你的域名/?id=1%20AND%201=1",观察HTTP返回码。 - 查看源站日志：去源站服务器执行
tail -f /var/log/nginx/access.log，等待数秒,检索是否存在对应的请求记录。 - 对比源站监控：开启源站的带宽监控和CPU监控，在连续发起几十条测试攻击后，观察源站监控曲线是否有明显波动,波动明显则说明流量穿透到了源站。
- 核查拦截日志字段：在防护控制台的拦截日志列表里，筛选刚才测试攻击的请求ID，确认action字段为
BLOCK且不包含upstream信息。
如果上述步骤发现攻击包被转发到源站,优先排查：
- 防护规则是否选择了正确的域名和路径。
- 源站是否开启了HTTPS回源导致证书校验失败被跳过防护。
- 是否配置了HTTP/2或WebSocket等协议的白名单放行策略。
网站防护日志怎么看出攻击包被丢弃了
结合基础篇，再补充几个细节特征，帮助你从日志里快速读出“攻击包被丢弃”的结论。
-
无源站响应日志
：源站完全无感知,没有产生任何访问日志。 - 无TCP连接建立：防护设备直接丢弃SYN包或返回RST，源站上
ss -ant | grep :443看不到来自攻击IP的ESTABLISHED连接。 - 客户端收到拦截页或403：用户端浏览器显示的是防护产品提供的拦截页面,而非源站自定义错误页。
- 响应时间极短：防护设备直接返回403时，整个请求耗时常在50ms以内，如果请求耗时长达数百毫秒，说明经过了源站处理,攻击包大概率被转发过去了。
答疑：攻击包被丢弃还是转发怎么判断
问：WAF显示拦截了，但源站还是收到了攻击流量，这是为什么？
答：可能原因有三，一是WAF运行在观察模式下，只记录不阻断，流量被转发到源站；二是攻击者绕过了WAF，直接访问源站IP，流量根本没经过防护节点；三是请求命中了白名单规则，WAF主动放行，攻击包被转发，可在WAF日志中检查action字段，并在源站防火墙中配置只允许WAF回源IP访问,以确认具体原因。
问：源站是HTTPS协议，WAF回源失败会丢弃攻击包吗？
答：如果WAF与源站的HTTPS证书握手失败，WAF无法将请求转发到源站，此时攻击包自然会被丢弃，客户端会收到502错误，但这不属于防护策略主动拦截，而是链路故障导致的请求失败，这种状况下应优先排查回源证书配置，避免正常用户请求也被丢弃，判断依据是：只有设备主动返回403或重置连接才算防护生效，502错误代表请求没能到达源站，但也不代表防护规则起到了作用。
问：为什么攻击包被丢弃了，源站带宽还是被占满了？
答：如果源站带宽被占满但访问日志中没有对应攻击记录，优先排查是否遭受了UDP Flood或SYN Flood等网络层攻击这类攻击不依赖完整HTTP请求，不会产生应用层访问日志，这属于DDoS防护范畴，与WAF的应用层拦截是两套独立机制，若已接入云DDoS高防，需要检查高防实例的转发配置是否正确覆盖了源站IP；若未接入，攻击流量会直接打向源站,应用层防护设备对此无能为力。
防护生效的标志从来都不是控制台里的数字，而是源站服务器是否真的清静了，记住一条原则：攻击包到不了源站，才是有效防护，凡是转发出去的，无论日志怎么标，都不算数，配置完防护后，亲自发几条测试攻击，看一眼源站日志和监控曲线,比什么都可靠。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/654130.html
