业务侧部署应用防火墙（WAF）不是装上就完事，真正的挑战在配置和运维环节，部署前想清楚防护范围、流量切换、误封策略和应急回退，才能避免上线即事故的尴尬。
很多团队把WAF当成一个普通软件，装好、连上、开默认规则就宣告完成，等线上出现误封用户、业务接口被拦截、日志爆量才发现问题，下面结合真实场景,把部署前后那些容易踩的坑逐一梳理。
部署前先摸清家底：资产盘点决定防护覆盖面
WAF的保护逻辑是“你告诉它看哪里，它才看哪里”，如果连自己的暴露面都不清楚,WAF配置得再精细也是瞎子摸象。
梳理所有对外业务域名和API接口
先回答三个问题：公司现在有多少个对外域名？哪些是PC端、哪些是移动端？有多少个API接口是给内部系统用的、哪些是给第三方合作伙伴调用的？大多数企业在这个环节会漏掉两类资产：一类是测试环境或灰度环境用的子域名，另一类是给老客户兼容用的旧版API，漏掉这些，它们就成了攻击者绕开WAF的“免费通道”。
确认业务是否涉及HTTPS证书卸载
如果业务已经用了HTTPS，那么需要提前决定SSL证书卸载放在哪一层，现在主流的WAF部署方案都支持证书上传或透明转发，但对于某些自研网关，证书卸载后传到后端的流量变成了明文HTTP，这会引入新的安全风险，行业共识认为，证书卸载尽量放在WAF这一侧，让WAF能看到解密后的完整请求,才能做深度检测。
流量接入模式：旁路还是串联，直接影响业务连续性
“WAF旁路部署还是串联部署”是上线前必须拍板的问题,两种模式对业务的影响完全不同。
串联模式：防护最彻底，但故障影响面大
串联部署，也就是流量先经过WAF再到达源站，所有请求都要被WAF过滤一遍，好处是检测能力百分之百生效，坏处是WAF一旦宕机或性能瓶颈,整个业务跟着瘫痪。
适合串联模式的场景包括：新上线业务、数据敏感度高的金融或电商交易链路、对安全要求高于对连续性要求的系统。
旁路模式：不挡路，但防护能力打折
旁路部署通常用镜像流量或者DNS解析切换来实现，业务流量不经过WAF，WAF只做分析和告警，好处是WAF挂了不影响主线业务，坏处是无法实时阻断攻击,更像一个监视器而不是门卫。
大多数中小团队在资源紧张时会选旁路，但业内专家指出，如果业务有PCI-DSS或等保合规要求，旁路模式基本过不了审，因为你拿不出“实时阻断”的证据。
混合部署：兼顾安全与稳定的折中方案
具体实操中，很多团队采用“串联WAF + 后端健康检查 + 自动Bypass”混合模式，WAF以透明网桥方式串联，同时配置上游交换机的心跳检测，当WAF连续丢心跳超过10秒，自动切换到直连链路，先保业务,再排查WAF故障。
| 对比维度 | 串联部署 | 旁路部署 | 混合部署 |
|---|---|---|---|
| 防护实时性 | 实时阻断 | 事后告警 | 实时阻断 |
| 业务连续性 | 受WAF故障影响 | 不受影响 | 故障时自动切换 |
| 部署复杂度 | 中 | 低 | 高 |
| 合规适配 | 满足 | 较难满足 | 满足 |
防护策略配置：web应用防火墙怎么配置才不误伤业务
“web应用防火墙怎么配置”是百度上被问烂了的问题，核心难点不在功能开关,而在规则的取舍。
先用观察模式跑通业务
别一上来就开阻断模式，把WAF的策略配置成“只记录不拦截”的观察模式，至少跑一个完整的业务发布周期，比如3到7天，期间重点看两个数据：一是WAF产生了多少告警,二是其中有多少条指向正常业务请求。
实操路径：在WAF控制台→防护策略→全局设置→将“执行动作”从“阻断”改为“仅记录”,同时开启告警日志全量存储。
白名单和例外规则要前置
需要加白名单的往往不是攻击者，而是你自己的开发人员，常见的误封场景包括：内网办公IP段被拦截、手机App的固定UA被拦截、特定接口的Content-Type被判定异常，把这些规则提前写进白名单,比事后被投诉再处理体面得多。
配置时记住一个原则：白名单粒度越小越好，一个IP段对应一个业务模块,不要图省事直接放行整个网段。
核心防护规则按业务类型裁剪
针对不同的业务形态,规则侧重点要调整：
- 电商/交易类：重点跟踪精准打击、恶意爬虫和下单接口的频次控制，社区类：重点防护SQL注入、XSS攻击和垃圾评论的提交接口。
- API开放平台：重点管理认证鉴权、Token保护和API滥用检测。
通用规则集虽然能防住大多数通用攻击，但对业务逻辑层的攻击几乎无感，批量注册”“撞库登录”“薅羊毛”这类攻击，必须结合业务场景单独写阈值,才能看到效果。
日常运维不能松：日志、告警和回退预案
部署只是第一公里,后续的运维水平和应急能力才是拉差距的地方。
日志存储要提前规划
WAF全量记录请求日志非常占存储，一个日均PV百万的站点，每天产生几十GB日志是常态，如果日志存储空间规划不足，要么被迫提前滚动删除，要么额外增加存储成本，建议根据业务峰值估算日志量，保留至少90天,满足溯源和合规要求。
告警要降噪，别让同事拉黑你
把所有告警都推到钉钉或企业微信群，最终结果就是大家把群消息设为免打扰，真正的高危攻击反而没人看,需要做分级处理：
- P0级（源站被入侵、大规模扫描）：即时电话通知
- P1级（单IP高频攻击、特定漏洞利用）：企业微信推送
- P2级（低频扫描、合规性告警）：日报汇总
回退预案要演练过才有效
WAF上线、规则变更、版本升级都有可能导致业务中断，每次变更前，准备好回退方案，具体到操作人、操作步骤、预估恢复时间，常见做法是在变更窗口前拍下当前所有策略的配置文件快照，一旦出问题，
5分钟内恢复上一版配置。
不少团队只在攻击事件后想起WAF的价值，平时却从不关注它的健康状态，定期（建议每月）登录WAF控制台查看引擎版本是否过期、规则库是否需要更新、后端源站IP是否泄漏,这些细节决定了在关键时刻WAF是顶上去还是掉链子。
Q&A：部署应用防火墙注意事项延伸解答
WAF部署后业务出现卡顿，怎么排查是不是WAF所致？
先确认WAF的接入模式，如果是串联模式，直接在WAF侧查看处理延迟，正常应在个位数毫秒级别，如果延迟正常，再检查后端源站响应耗时、数据库慢查询、业务代码是否有死循环，用这种方法层层剥离,能快速定位瓶颈归属。
使用云WAF还是硬件WAF，二者主要差在哪里？
差别集中在交付方式和运维成本上，云WAF无需采购硬件、分钟级接入，适合云上业务和资源有限的中小团队；硬件WAF需部署在机房的流量入口，处理性能固定，适合对延迟极其敏感、环境必须隔离的大型线下业务，价格方面，云WAF大多是按年付费，硬件WAF一次买断还要考虑后续的防护规则升级续费，选择前先评估业务所在的网络环境和运维人力,再去比单价才合理。
业务侧部署了WAF，源站IP是否还需要隐藏？
依然需要，WAF只是过滤层攻击，并不能防止攻击者通过其它渠道定位源站IP，比如历史DNS解析记录、邮件头信息泄露、代码仓库中的配置文件，隐藏源站IP需配合防火墙只放行WAF的回源IP段,并定期检查源站的直接暴露情况。
WAF的价值在于让攻击者需要花更长时间破解防护，而不是在攻击者面前裸奔，部署前的资产梳理、传输模式的取舍、规则集的耐心调优、运维期的持续关注，这几步都做到位，WAF才能真正扛住事，如果你正在评估WAF选型或部署效果，不妨把这篇里的检查项拉成清单，逐条过一遍,比盲目跟风购买更实用。