2026 服务器租用 WAF 规则怎么配：ModSecurity CRS 误报与性能 实测避坑 + 干货手册

2026 服务器租用 WAF 规则怎么配：ModSecurity CRS 误报与性能 实测避坑 + 干货手册

很多人在自己租的物理机或云主机上装完 ModSecurity，编译通过、连接器挂上、服务起来了，看到日志里开始刷出告警，就认为防护已经生效。这个判断只对了一半：日志有输出，说明引擎在工作；至于拦得准不准、该拦的拦没拦住、不该拦的拦了多少，全在后面那段没人愿意做的调优期里。真正吃掉时间的从来不是安装，而是让规则集和你的业务形态对齐的过程——哪个接口收富文本、哪个字段天然带数据库关键字、哪个路径只接受固定枚举值、上传接口的体积分位数是多少。这些问题不回答清楚，规则集就只是一份通用策略库，跟你站点上跑的东西没有半点关系。

本文面向在自租服务器上用 Nginx 加 ModSecurity 加 OWASP CRS 自建 WAF 的运维与安全同学，把调优期里必然会遇到的几件事讲透：引擎和规则集的分工、异常评分到底怎么算、paranoia 等级的取舍、只检测阶段该看什么、误报按什么粒度排除、请求体上限怎么定、性能消耗集中在哪、审计日志怎么留存、规则集升级为什么不可以直接切、以及它到底不能替你做什么。

引擎负责执行判断，规则集才决定判断什么

ModSecurity 是一个开源的 Web 应用防火墙引擎。它最早是 Apache 的一个模块，后来的 v3 版本（libmodsecurity）被重写成独立库，通过连接器挂到 Nginx 等 Web 服务器上。这个重写带来了一个很关键的工程后果：引擎不再绑定某一个 Web 服务器，连接器负责把宿主的请求生命周期事件翻译成引擎能理解的事务，引擎只管按配置执行判断。理解这一点，后面排查"为什么 Nginx 起来了但没拦任何东西"就很快。

最常见的误解是：以为装上引擎就自带了防护能力。事实是引擎本身不自带规则，判断逻辑全部来自外部的 SecRule 配置。装完连接器之后如果你没有引入任何规则文件，引擎会正常加载、事务正常流转、日志里安安静静，因为它没有任何一条规则可以执行。所以"日志没报错"和"已经有防护"是完全不同的两个状态，前者只是说明配置没语法错误。

实际部署中最常用的规则集是 OWASP CRS，全称 Core Rule Set，即核心规则集，由社区维护，覆盖常见的注入、跨站、文件包含、命令执行、扫描器特征等类别。它按类别拆成多个规则文件，部署时按需引入，并配一份基础配置文件来放全局开关、阈值和模式。这套结构决定了两件事：一是你可以只加载你技术栈相关的那几类规则，二是升级是分层的——引擎升级改的是解析能力、连接器兼容性和执行效率，规则集升级改的是判断逻辑，两者互不绑定，故障归因时要先分清是哪一侧。

把关系说直白一点：引擎是执行器，规则集是策略库。引擎换了版本，你之前写的排除配置通常还能用；规则集换了版本，你之前写的排除配置可能集体失效，因为规则号和目标变量都变了。这个区别会直接决定你后面要花多少时间在回归上。

异常评分模型下，"命中一条规则"不等于"请求被拦了"

CRS 采用的不是"命中即拦"的模式，而是异常评分（anomaly scoring）：每条规则被命中时会给当前请求累加一个分数，分数按严重程度分级，请求走完全部规则后得到一个总分，总分超过设定阈值才触发阻断。这个设计是 CRS 能在通用场景下落地的前提——它容忍零星的低危命中，而不是一条规则说了算。

这个模型有一个必须建立的直觉：日志里出现一条命中记录，不等于那个请求当时被拦了。一条严重程度较低的规则命中，可能只是给总分加了几分，距离阈值还差很远，请求正常放行。所以排查时不能拎出单条告警就下结论，要看这个事务最终累计了多少分、以及审计日志里记录的最终处置动作是什么。很多团队把"告警条数"直接当成"被拦截数量"汇报，这个数字是失真的。

反过来，也正因为是累加制，会出现另一种容易被忽略的情况：单个请求在多条规则上各命中一次，每次都不算严重，但累加起来越过了阈值。这时候你在日志里看到的是一个被拦掉的请求，而逐条看它的命中记录，每一条单独拿出来都"看起来不像攻击"。判断请求为何被拦，必须从总分出发，而不是从某一条规则出发。

阈值怎么理解？它是整个站点对"可疑程度"的容忍线。调低，敏感度高，漏拦少，误杀多；调高，放行多，误杀少，漏拦风险上升。CRS 默认给的阈值是一个经过社区权衡的起点，不是最优解。真正合理的做法是在只检测阶段跑一段时间，看你的正常业务流量最高能累加到多少分，再决定阈值放在哪里——把阈值设在正常流量峰值之上、可疑流量常态之下，才有意义。凭感觉调数字，等于把判断交给运气。

此外还需要知道，CRS 里有一部分规则不是往单次请求的分数上累加，而是往会话或来源地址维度的计数器上累加，用来识别短时间内连续出现的可疑行为。这类计数是有时间窗口的，会随时间衰减。所以排查时看到"某地址分数很高"，要分清楚是单次请求累加出来的，还是一段时间内的累计结果——两者的处置方式完全不同，前者看请求内容，后者看行为模式。

paranoia 等级每抬一级，换来的是覆盖面还是误报

CRS 提供多个严格度等级，通常称为 paranoia level，从 1 到 4。等级越高，启用的规则越多，覆盖面越全，同时误报也越多。这不是线性的、也不是免费的：每抬一级，都会把一批"更严格但更容易在正常业务上触发"的规则纳进来。等级 1 的定位就是"绝大多数站点能直接跑"，更高的等级是给有明确需求、且愿意投入调优人力的场景准备的。

我的建议很明确：绝大多数站点从最低等级起步，只对特定路径临时抬高。不要一上来就开到 3 或 4，那不是更安全，那是给自己制造一堆要在业务高峰期处理的误报。高等级真正有价值的用法是局部的——比如后台管理路径、登录与鉴权接口、涉及资金或敏感数据的少数几个接口，在这些地方把等级抬上去，覆盖面提升带来的收益大于误报成本；而面向普通用户的内容类接口维持低等级。

抬等级的操作是可以按作用域做的，不是全局开关。CRS 支持在请求进入时按条件调整等级，常见的做法是按 URI 前缀、按请求方法、甚至按来源地址来分档。这样你可以在同一个站点上同时存在两种严格度：公开内容区宽松，管理区严格。这个能力被严重低估，很多团队要么全站一个等级，要么干脆不动。

决定要不要抬一级之前，先做一次对比统计：在只检测模式下，用当前等级跑一段时间记录命中分布，再切到目标等级跑同样长的时间，比较两个等级下新增的命中里，有多少最终被确认为是误报。如果新增命中里误报占了绝大部分，说明这一级对你的业务形态不划算。这个判断只能靠数据，不能靠"等级高应该更安全"的直觉。

DetectionOnly 阶段跑多久，日志里该盯哪几个字段

引擎的运行模式有三档：关闭、开启（拦截）、只检测（DetectionOnly）。只检测模式下规则照常评分、照常记日志，但不阻断任何请求。这是上线的必经阶段，不是可选项。跳过它直接切拦截，等于在没有基线的情况下拿真实业务做实验，几乎必然会在某个业务高峰把正常请求拦掉。

要跑多久？答案取决于你的业务周期，而不是日历天数。至少要覆盖一个完整的业务周期：工作日和周末的流量形态通常不同，月末结算、发版窗口、营销活动、爬虫活跃时段都会带来不同的请求形态。如果你的站点有月度性的业务高峰，只跑一个普通工作日是不够的，因为那天的请求样本里不会出现月度任务特有的参数组合。实践中更稳妥的做法是：跑满一个能覆盖所有主要业务动作的时间窗，并且在重大活动或发版之后补跑一段。

这一阶段要看的指标，按优先级排：第一是按规则号的命中分布 TOP 列表，它会告诉你绝大部分告警集中在少数几条规则上，调优要从这里入手；第二是按 URI 的分布，用来定位是哪几个接口在贡献告警；第三是按来源地址的分布，用来识别是扫描器还是真实用户；第四是告警总量占请求总量的比例，用来判断收敛进度。把这四张表交叉起来看，比盯着总告警数有用得多——总数下降可能只是流量下降，不代表调优有效。

还有一个贯穿全程的排障关键：引擎会给每个请求打一个唯一事务标识。排查任何一条告警，第一步是拿到这个标识，然后用它把 WAF 日志、Web 访问日志、应用日志三边串起来。没有这个标识，面对一大批告警你只能靠时间戳和 IP 去猜对应关系，在稍微有点并发量的站点上这基本做不到。所以接入阶段第一件要做的事，就是把这个标识写进 Web 访问日志格式里，让三边可关联。

切换拦截的判断标准也应该提前定好，而不是凭感觉。比较实用的条件是：告警密度降到可接受范围；命中 TOP 的规则逐条都有明确归类（确认是攻击特征，或确认是误报并已做排除）；剩下的未归类告警占比很低。满足这些再切，切换后依然要保留一小段时间的复核，因为只检测阶段覆盖不到的请求形态总会存在。

富文本 HTML、JSON 请求体、Base64、上传接口、超长参数名这五类误报

误报不是随机分布的，它高度集中在几类业务形态上。知道是哪几类，调优时就能直接按图索骥，而不是逐条告警去猜。

第一类是富文本编辑器提交的 HTML 片段。编辑器输出的内容天然包含标签、属性、样式，某些属性名本身就落在跨站类规则的检测特征里。用户在正文里粘贴一段带格式的内容，请求就命中了。这类误报的特征是：命中集中在内容发布的少数几个接口，命中目标是正文字段。

第二类是 JSON 请求体里含数据库关键字。业务字段的值或字段名里出现 select、order、union 这类词非常常见——比如排序字段名、状态枚举值、商品规格名、搜索关键词。注入类规则看到这些会累加分数。这类误报的特点是它和真实注入在表面形态上很像，区分点在于：业务请求的关键字出现在固定字段、取值来自有限的枚举集合，而可疑请求的关键字往往出现在不该出现的位置，或者带有结构性特征。区分不了的时候，按字段粒度排除是比放宽规则更安全的做法。

第三类是 Base64 编码内容。图片上传、令牌传递、签名串、序列化对象都会走 Base64，编码后的字符串里可能包含各类可疑片段，触发编码类与注入类规则。这里要注意一个取舍：完全不检查编码内容等于放弃一整类检测能力，所以更合理的做法是对明确可信的字段（比如前端固定的图片字段）做定向排除，而不是关掉整条规则。

第四类是文件上传接口。multipart 请求的边界处理、文件名里带的特殊字符、二进制内容里碰巧出现的字节序列，都会触发规则。上传接口还叠加了体积问题，下一节单独讲。

第五类是超长参数名或超长参数值。长度类规则和特殊字符类规则在这类请求上容易命中，尤其是某些前端框架生成的嵌套参数名会非常长，甚至带有会被当作分隔符解析的字符。这类误报的处理相对简单：确认长度上限的业务合理性，然后按参数名定向处理。

从整站移除规则到按参数名限定检查目标，三种排除粒度

排除手段有三类，粒度从粗到细。

最粗的是按规则号全局移除：在初始化阶段把某条规则从规则集中去掉，它对所有请求都不再生效。这种方式写起来最快，代价最大——一条规则被全局移除，等于它覆盖的那一类特征在整个站点上都不再被检查。它只适用于一种场景：你确认这条规则针对的技术栈在你的环境里根本不存在（比如某类后端语言、某类数据库的特定规则），那么留着它只是白白付出匹配开销。除这种情况外，不建议用。

中间一档是按规则号在特定作用域移除：限定在特定的 URI 前缀、或特定的参数名、或特定来源地址上，让这条规则不生效。它把敞口从"全站"收窄到"某几个接口"，是实践中最常用的一档。写的时候作用域要尽量收窄——能用 URI 前缀限定的就不要用全站，能用具体路径的就不要用前缀。

最细的是调整某条规则的检查目标：不动规则本身，而是改变它检查哪些变量。典型用法是把某条规则从"检查所有参数"改成"只检查指定名称的参数"，或者反过来，把某个特定参数从这条规则的检查目标里剔除。这档最贴近业务语义，也最安全，因为它保留了规则在其他字段上的检测能力。代价是费人工——你需要把业务字段名逐个枚举出来，并且跟着接口迭代维护。

三者的取舍很清楚：粒度越细越安全，也越费人工。我的建议是默认从最细的一档开始试，只有当字段无法枚举（比如完全动态的键名）时才退到作用域级，全局移除留给技术栈无关的规则。还有一个容易被忽略的运维要求：每一条排除都要写注释，写清楚为什么排、对应哪个业务场景、谁确认的。三个月后规则集升级时，你会感谢自己写了这些注释；没写的话，那份排除清单就是一堆无法复查的魔法数字。

请求体检查上限：设小了等于那段没防，设大了性能付账

请求体检查是有体积上限的，超过上限的部分不会被检查。这句话读起来平淡，但它是一个实实在在的敞口：如果你把上限设得很小，那么所有超过这个体积的提交，超出部分的内容对 WAF 是完全不可见的。注意这不等于整个请求都不检查——请求头、URI、参数名通常仍会检查，但请求体主体那一段是被跳过的。

上传型接口最容易踩这个坑。一个能收几 MB 文件的接口，如果请求体上限只有几百 KB，那么绝大部分文件的主体内容根本没进检查流程。这个配置在功能上完全正常，日志也不会报错，你甚至看不到任何异常提示，只是那段防护安静地不存在。检查上限必须和业务接口的实际请求体体积对齐，否则等于那个接口裸奔。

那是不是设得越大越好？不是。请求体要能被检查，就得先被完整接收和缓冲，这通常意味着占用内存，超过一定体积后转为落临时磁盘。体积上限越大，单请求占用的内存越多，并发高时峰值内存是"上限乘并发数"的量级；同时大体积内容要做全量正则匹配，CPU 也要付账。把上限开到很大而不控制并发，内存压力和 CPU 压力会同时上来。

怎么定？按业务接口的请求体体积分位数来定。统计普通 API 提交（表单、JSON）的实际分布，取一个能覆盖住绝大多数正常提交的数值，让常规接口的内容完整进入检查；然后对上传接口单独配置——上传接口用路径级配置区分对待，给它一个能覆盖典型文件大小的上限，同时配合应用侧的文件大小限制，避免单个超大文件把资源吃满。也就是说，不要用同一个上限覆盖所有路径，普通接口和上传接口应该分成两档。

还有一个配套项容易被忘：缓冲机制要落哪里。内存缓冲快但吃内存，磁盘缓冲省内存但引入 IO，高并发下临时目录所在的磁盘可能成为新的瓶颈。如果上传接口量大，临时目录放在独立磁盘上是值得的；同时要留意临时文件的清理，异常中断的连接可能留下残留文件。

正则匹配、请求体解析、审计日志写入，先优化哪一个

性能消耗主要在三处，理解它们各自的量级关系，才能决定优化顺序。

第一处是正则匹配本身。规则越多、请求体越大，匹配开销越高。这里有两个放大因素：一是 paranoia 等级越高，启用的规则越多；二是请求体上限越大，需要扫描的内容越多。两者是相乘关系，高等级加超大请求体上限是最贵的一种组合。另外，加载了与技术栈无关的规则文件也是纯浪费——你的环境里根本不存在某类后端或某类数据库，那批规则只会消耗 CPU，不会带来任何防护收益。

第二处是请求体解析。XML 和 JSON 需要额外解析才能被规则检查，这一步本身就消耗 CPU 和内存。如果你的业务主体是简单的表单提交，却开启了完整的 XML 或 JSON 解析，那部分开销是白付的。反过来，如果业务确实重度依赖 JSON 接口，那么解析开销是必要成本，只能靠减少规则数量去对冲。

第三处是审计日志写入。审计日志会完整记录请求与响应，同步写盘在高 QPS 下会成为瓶颈——这不是理论风险，是自建 WAF 最常见的性能塌方点。原因也很直白：磁盘 IO 的吞吐和延迟跟内存里的正则匹配不在一个量级，一旦每个请求都要同步落一次盘，整体吞吐会被 IO 拖住。

先优化哪一个？我的排序是：先审计日志，再规则数量，最后才是正则与解析的深度优化。理由是审计日志的改动风险最低、收益最确定，把同步写盘改成只记录需要关注的请求、或把日志挪到独立磁盘，几乎不影响防护效果；其次是清理无效规则、降低 paranoia 等级，这步需要回归验证但收益明显；正则与解析的深度优化最费人力且最容易引入配置错误，放在最后。判断依据也要提前准备好——在只检测阶段就开启处理耗时的相关记录，分别开关上述三项，比较前后的耗时变化，用实测数据而不是经验决定优化方向。

审计日志的留存周期、磁盘分区与轮转策略

审计日志会完整记录请求与响应。它的排查价值极高：一个请求被拦了、为什么被拦、命中了哪条规则、最终分数是多少、请求头和请求体是什么，全在里面。可以说没有审计日志，前面讲的所有调优工作都无法进行——你连"这条告警对应什么请求"都还原不出来。

但它的问题同样突出：体积增长很快。完整记录请求与响应意味着单条记录的体积远大于普通访问日志，如果全量记录所有请求，磁盘会在很短时间内被写满。而磁盘写满的后果不只是日志丢失——如果日志和系统在同一块盘上，可能连带影响服务本身。

常见的做法有两个方向，可以叠加使用。一个是只记录被判定需要关注的请求：按处置动作或分数阈值过滤，只把被拦的、或分数达到某一水平的请求写进审计日志，正常请求只留访问日志。这样日志体积会下降几个量级，同时保留了排查所需的全部信息——你排查问题时关心的本来就是那部分异常请求。另一个是把日志挪到独立磁盘并配置轮转：独立分区意味着写满不会拖垮系统盘，轮转策略控制保留周期与单文件大小。

留存周期怎么定？看两个约束：一是排查需要，出问题时要能回溯到足够早的日志，跨周甚至跨月的排查并不罕见；二是合规与隐私约束。审计日志里包含请求头，其中可能有凭据类信息，请求体里可能包含个人信息——它是敏感资产，不只是日志文件。所以留存周期、访问控制、谁能查看、能不能下载，这些要和应用日志的敏感数据治理放在同一套规则里定，而不是默认"先存着再说"。

还有一个实践细节：日志要能关联。前面提到的唯一事务标识，必须同时写进审计日志和 Web 访问日志。遇到线上反馈"某个操作失败"，先用访问日志按时间和路径定位到事务标识，再用标识去审计日志里取完整上下文，这条链路一旦打通，排查时间会从小时级降到分钟级。没打通的话，每次排查都要在两份日志之间人工比对。

规则集升级等于换了一批判断逻辑，必须重走只检测

规则集升级不是打补丁，是换判断逻辑。一次版本升级可能同时带来：新增规则、已有规则的匹配逻辑调整、严重程度重新分级、规则号变化、旧规则被移除。这些变化会让升级前那份精心调好的排除清单部分失效。

失效的方式通常有两种。一种是规则号漂移：你排除的是某个具体规则号，升级后那条规则的编号变了，你的排除配置指向了一个不存在的编号，规则重新生效，误报回来了——而且这次是在拦截模式下回来的，直接变成线上故障。另一种是目标变量变化：规则号没变，但它检查的变量集合变了，原来按参数名做的定向排除不再覆盖新的检查目标。这两种失效都不会有任何报错提示。

所以流程必须是：升级规则集之后，重新走一遍只检测模式，不能直接升完就切拦截。重新统计按规则号的命中分布，对比升级前后的差异；逐条复查排除清单，确认每条排除对应的规则号仍然存在、检查目标是否变化；再看有没有新规则带来了新的误报面。这一步做完，才谈得上切拦截。

这里再次体现出"给排除写注释"的价值。如果你的排除清单只是一串规则号，升级后你无法判断每一条当初是为了解决哪个业务场景；如果写了注释，复查就变成一次可执行的核对——按注释里的场景重新验证一遍即可。也建议把排除清单纳入版本管理，让它和应用代码一样可追溯、可回滚。

边缘侧挡扫描与泛洪，源站侧懂业务语义，两层是叠加不是替代

自建 WAF 和边缘或 CDN 侧的防护不是二选一。它们的能力模型不同，正确关系是叠加。

边缘侧的优势是容量和位置：它靠近接入侧，能在流量到达源站之前就吸收掉大流量的扫描与泛洪。这类流量的特征是量大、特征相对通用，边缘侧用较通用的策略就能过滤掉绝大部分，而且它扛得动。让源站去硬扛这类流量是浪费——你的自租服务器 CPU 和带宽是有限的，用来跑正则匹配去挡扫描非常不划算。

源站自建 WAF 的优势是懂业务语义。它知道哪个接口该收什么参数、哪个字段的取值应该是有限枚举、哪个路径只接受特定请求方法、哪个参数的长度上限是多少。这些是边缘侧不可能知道的，只有贴近应用的一层才能表达。所以真正有价值的自定义规则，几乎都写在源站这一层。

两层叠加时要注意几个衔接问题。第一个是来源地址：源站看到的地址可能是边缘节点地址，如果不把原始客户端地址透传过来，所有基于地址的计数、累计评分和封禁都会作用在边缘节点上，结果是误伤一片真实用户。接入阶段就要确认地址透传是否生效。第二个是规则触发表：边缘侧已经过滤过一轮，到达源站的请求形态会发生变化，某些泛化规则的触发特征也随之变化，调优时要基于源站实际看到的请求做判断，不能照搬边缘侧的经验。第三个是日志对齐：两层各记一份无法关联的日志，等于排查时要做两次人工比对，最好让两边使用可对齐的请求标识。

WAF 属于补偿性控制：参数化查询、输出转义与输入校验都不能省

需要说清楚一个边界：WAF 是补偿性控制，不是修复。它在应用之外加一层过滤，用来降低漏洞被利用的概率、为修复争取时间，但它不能替代参数化查询、输出转义、输入校验和身份认证。把它当唯一防线，是最常见的认知错误。

为什么不能替代？因为 WAF 工作在请求的外层，它看到的是字符串形态，不知道这个参数最终会进入哪个上下文。同一个值，拼进 SQL、输出进 HTML、写进命令行，风险完全不同——只有应用代码知道上下文。所以在应用层做正确的处理（参数化查询、输出转义、按业务规则校验输入）是根本，WAF 是外面加的一层兜底。

在自租服务器上的落地顺序建议是这样：先把应用侧该修的修掉，再上 WAF 做兜底；先只检测，再切拦截；先小范围（单个路径、单个站点）验证，再全站铺开；每次规则集升级都回到只检测重新走一遍。这个顺序看起来慢，但它避免了"上线即故障、回滚即裸奔"的循环。反过来，先上拦截再救火，往往会在业务压力下把规则一条条关掉，最后剩下一个"装了但基本不生效"的 WAF——比没装更危险，因为它会给人虚假的安全感。

还有一点要提前纳入资源规划：WAF 是要吃 CPU、内存和磁盘 IO 的。它不是零成本组件，规则数量、paranoia 等级、请求体上限、审计日志策略这四个参数共同决定了它吃掉多少资源。选型服务器时把这部分余量算进去，比上线后发现资源不够再扩容要省事得多。

把容量账算清之后再谈机型

在自租服务器上自建 WAF，第一件事不是挑规则，而是算清楚它会占用多少资源。CPU 这一项主要由并发请求数、启用的规则数量和请求体大小共同决定：规则匹配是逐请求、逐规则执行的，请求体越大要扫的内容越多，paranoia 等级越高要执行的规则越多。这三项叠起来，再乘以并发峰值，就是你在峰值时段需要的计算余量。如果站点本身的应用已经把 CPU 吃到相当高的水平，再加一层 WAF 就会出现互相争抢，表现为两类请求同时变慢，而不是某一类单独变慢——这种症状很容易被误判成应用问题。

内存这一项主要由请求体缓冲决定。请求体要被完整检查就必须先被完整缓冲，单请求占用乘以并发数就是峰值内存需求。这里最容易被低估的是上传接口：一个允许收较大文件的接口，在并发上传时会在很短时间内堆出可观的内存占用。如果内存规划没留够，表现为缓冲区落盘或直接失败，两种结果都不理想。所以上传接口要么限制并发、要么限制体积、要么单独部署，不能和应用主流程共用一份不设防的资源池。

磁盘这一项容易被忽略但后果最严重。审计日志的写入是持续且量大的，如果它和系统盘共用，写满之后影响的不只是日志。比较稳妥的做法是在规划阶段就把日志放到独立分区，并按前面讲的策略控制写入量。把这三笔账——CPU 余量、内存余量、日志磁盘与轮转——算清楚之后，再去谈具体要什么配置的机型、要不要拆分部署、要不要给 WAF 单独一层，顺序才是对的。先定机型再往里塞组件，往往会在上线后发现某一项资源不够，而这时能做的选择都很贵。

上线前需要确认的几件事

从工程流程上看，自建 WAF 上线前的确认清单并不长，但每一项都不能跳过。第一，确认引擎与规则集都已正确加载而不是只加载了引擎——看启动日志里规则文件是否被读取、规则条数是否符合预期，而不是只看服务有没有起来。第二，确认运行模式处于只检测而不是拦截，并且这个状态在配置文件重启后依然保持，避免某次配置变更把它带成拦截模式。第三，确认唯一事务标识已经写进 Web 访问日志，让 WAF 日志、访问日志、应用日志三边可关联。第四，确认请求体检查上限与业务接口的体积分布对齐，尤其是上传接口要用单独的一档。第五，确认审计日志的写入策略、所在磁盘与轮转配置已经就位，而不是全量同步写到系统盘上。第六，确认来源地址透传在多层架构下生效，否则基于地址的计数与封禁会误伤。

清单之外还有一件更重要的事：确认有人负责持续的调优。规则集不是一次配置就结束的东西，业务接口会迭代，规则集会升级，误报面会随业务变化而移动。把它当成一个需要持续投入的运维对象，而不是一个装上就完事的组件，是这个方案能不能长期有效的分水岭。如果需要在中国香港、海外或国内多地节点上做一致部署，把规则配置和排除清单纳入版本管理、用同一套流程分发到各节点，能省掉大量重复劳动。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

最后再强调一次边界：这套东西是补偿性控制，它上面承载的期望不应该超过它能给的。真正让站点安全的是参数化查询、输出转义、输入校验和健全的身份认证，WAF 是在这些都做到之后、为尚未发现和尚未修复的问题提供的一层缓冲。把这个顺序摆正，规则调优时做的每一个取舍才会有清晰的判断标准——知道哪些拦截是真防护，哪些只是在给应用的欠账打补丁。