2026 WAF 应用层防护服务器租用：规则命中率/误拦截率/并发性能 6 家对比 + 避坑全攻略

2026 WAF 应用层防护服务器租用：规则命中率/误拦截率/并发性能 6 家对比 + 避坑全攻略

干了十来年 IDC 这行，我见过太多这样的对话：客户被打了，连夜买高防，第二天又被打，第三天网站还是慢，第四天运维发现订单接口被人刷了几万次。

问题出在哪？他把高防清洗当成了万能药。清洗设备在网络层、传输层干活，管的是流量洪泛；而真正让业务"看起来没事但账已经烂了"的那些请求——SQL 注入、XSS、越权查询、撞库登录、恶意爬站、应用层 CC——它们 TCP 三次握手正常、请求头合法、单个包也不大，清洗设备压根看不出来。这类活儿是 WAF 的。

这篇不吹产品，只想把一件事讲透：WAF 不是买了就安全，真正决定效果的是三个数字——规则命中率、误拦截率、以及它插进链路之后你付出的延迟与并发代价。面向做电商、金融类业务系统、政企门户、SaaS 的团队，往下看。

先把五条结论摆前面，赶时间的看完这段就走

1. 清洗和 WAF 是两笔预算，不是二选一。前者挡流量型攻击，后者挡应用层攻击。只买高防，等于给大门加了锁，窗户全开着。

2. 命中率和误拦截率天生打架。规则放宽，漏得多；规则收紧，正常下单被拦。哪个厂商跟你说"零误拦"，那基本是把开关拨到了只告警不拦截那一档。

3. 上线第一天必须开观察模式。新 WAF 直接切"拦截"，拦的第一个大概率是你自己的搜索框——因为用户在里面输了带有特殊符号的内容。

4. 源站真实 IP 藏不住，WAF 就是个摆设。这是最典型的失效方式，不是厂商不行，是部署没做干净。

5. 别忘算账。回源流量怎么计、攻击流量计不计进带宽费、日志留存要多少盘，这些才是上线三个月后真正让你肉疼的部分。

先分清两件事：DDoS 清洗挡的是流量，WAF 挡的是请求

很多人把安全预算一次性砸在高防上，觉得有了几百 G 的清洗能力网站就稳了。说实话，这两者的作战位置完全不同。

网络层/传输层攻击，典型是 SYN Flood、UDP 反射、ACK Flood 这类。特征是流量大、包速率高、源 IP 分散且伪造。这种攻击的目的是把你的带宽或连接表撑爆，让正常用户挤不进来。清洗设备的思路是把流量牵引到清洗中心，用特征过滤、速率限制、源认证（比如 SYN Cookie）把脏流量洗掉，干净流量再回注给你。

应用层攻击就鸡贼多了。它不追求把你的 pipe 打满，追求的是用最少的请求撬动最大的业务伤害：一条带构造参数的 URL 试图查库，一次登录请求试一千个密码组合，一个爬虫把你的商品价格和库存全爬走卖给同行，一个脚本反复调用发短信接口让你短信费爆表。这类请求从网络层看完全"合法"——源 IP 真实、握手正常、速率不高。清洗设备看到的是好人。

WAF 的工作层级是 HTTP/HTTPS，它看的是 URL、请求头、Cookie、Body。它做这几件事：

规则匹配——用特征库识别已知的注入、跨站、命令执行等特征；协议合规校验——请求头缺字段、Content-Length 对不上、编码异常这类畸形请求直接拦；频率与行为分析——同一 IP 或同一账号在单位时间里的行为是否像人；人机校验——JS 挑战、验证码，让脚本现形；访问控制——按地域、UA、接口白名单限制。

所以一个靠谱的部署是两层串起来：外层清洗挡洪流，内层 WAF 精筛请求。只有一层，不管你说这层多贵，都是瘸腿的。

规则命中率与误拦截率，为什么天生是死对头

这是本篇最核心的一段，讲清楚了后面所有部署思路都顺。

命中率高 ≠ 拦得多，它指的是"该拦的拦住了多少"

规则命中率，严谨点说是检出率（召回率）：在所有真实恶意请求里，你的规则抓到了多少。它的分母是攻击总量，不是请求总量。厂商宣传常在这里玩文字游戏——"日拦截攻击几百万次"，听着吓人，但他没告诉你真实攻击来了几千万次，也没告诉你这几百万次里有多少是同一个脚本刷出来的重复计数。

误拦截率，反过来：在所有正常请求里，你错杀了多少。分母是正常业务请求。误拦的可怕之处在于它直接等于资损——用户填了半天表单点提交，返回 403；支付回调被拦，订单状态一直不更新；SEO 收录突然掉光，因为搜索引擎蜘蛛被挡在门外。

这两个指标为什么是矛盾的？因为 WAF 判断恶意靠的是特征相似度，不是"读心"。想想 SQL 注入的特征：union select、单引号加上 or 1=1、-- 注释符。可这些符号组合，在一段正常的中文评论里、在一个 JSON 串里、在某个用户的姓氏（比如某些复姓或少数民族姓名的转写）里，也可能零星出现。规则写松了，攻击带着变形载荷溜过去；规则写紧了，一个正常的用户名里有敏感词的用户就永远注册不上。

所以结论是：不存在"两个都做到极限"的 WAF，只存在针对你的业务调到合适平衡点的 WAF。调平衡点的过程，靠的是观察和自定义规则，而不是靠厂商的默认策略包。

两个指标怎么盯，别只看厂商给的数字

厂商后台一般会给你攻击报表。但报表里的"攻击者数""攻击次数"你别当 KPI 看，那玩意儿往上走不一定是好事，也可能是规则误伤变多。

你自己要盯的是这三条：一是 4xx/5xx 里来自 WAF 拦截页的占比，突然往上跳说明误拦抬升；二是关键业务接口的可用率与平均耗时，特别是登录、搜索、下单、支付回调这几个；三是观察模式下的告警分布，看被命中的 URL 集中在哪些路径，如果是集中在富文本提交、搜索框、个人信息修改，八成是规则太糙。

硬件六维拆解：被保护的源站服务器本身该怎么配

WAF 大多挡在前面，但真正干活的源站服务器如果配置没跟上，一样出事。下面按 CPU、内存、硬盘、带宽、线路、机房六个维度拆，全部站在"这台机器/这批机器是 WAF 后面的源站"这个前提上讲。

CPU：TLS 握手、正则匹配、JS 挑战，每一环都在吃 CPU

先说一个反直觉的点：证书放哪一层卸载，直接决定你源站 CPU 空闲多少。

HTTPS 的开销大头是非对称加密握手。如果你选择回源也走 HTTPS（链路加密到源），那么每一条新建连接都要在源站 CPU 上做一次 RSA/ECDHE 运算。ECDHE 比 RSA 便宜得多，但便宜不等于免费——在短连接、大量新连接的场景里（比如移动端 App 频繁重连、CDN 回源没开长连接），握手的 CPU 占比能压到整个 Web 层开销里很显眼的一块。

实际建议很朴素：ECC 证书优先，TLS 会话复用（Session Ticket / TLS 1.3 的 0-RTT 视场景谨慎开启）必须开，回源链路开长连接。如果你的业务允许，把证书卸载放在 WAF/CDN 边缘节点，源站只处理 HTTP，源站 CPU 负担会轻松很多；但这条路要求你的链路里中间那一跳是你完全可信的自有网络或专线，否则等于把明文请求裸奔在中间网络上。安全和便利这里要自己权衡。

第二个 CPU 消耗是源站侧的正则匹配与 Lua/规则引擎。有些团队除了商业 WAF，还会在 Nginx 层挂一层开源规则（比如 ModSecurity 那一类），这时 Nginx worker 每个请求要跑几十上百条正则。正则写得差（回溯严重的那种），单个请求能吃掉几毫秒 CPU，在高 QPS 下直接把 worker 拖死。经验是：源站别跑重型规则，把规则交给专用的 WAF 引擎，源站只留轻量校验。

第三个是JS 挑战的计算。如果这一层放在边缘/专业设备做，源站不用管；如果你们自己实现（比如在源站中间件里做 JS 挑战），那 PoW 类的计算会明显吃 CPU，且这一类计算不得不做——它本身就是靠"让脚本算不起"来工作的。

落到型号上：源站如果是高并发 API 型（电商接口、SaaS 后端），我一般建议核心数优先，主频别太低，Nginx + 应用层的 TLS 卸载至少需要 8 核起步，中大型业务配 16 核以上；如果是门户/表单型，主频比核心数更重要。一万网络这边可定制的裸金属如 E5-2698v4 双路这类高核数平台（¥3999 起，以官网实时价为准）就适合做日志聚合型源站或自建 WAF 网关，核多、线程多，正则引擎和日志管线都跑得开。

内存：连接表、会话状态、日志缓冲，三块都要留

内存这块经常被低估。我拆成三个消耗点：

连接表。TCP 连接本身要占内存，一个 ESTABLISHED 连接在内核里大约占几 KB（取决于收发缓冲区设置）。如果你的源站要扛十万级并发连接，光内核态的连接表就要预留一两 GB。keepalive 开太久、连接回收策略不对，TIME_WAIT 堆积起来同样吃表。

会话状态。WAF 要判断"这个会话是不是真人"，就得记住这个会话前几步干了什么——比如先访问首页、再点列表、再点详情，这是人；上来直接对着 /api/sms/send 狂发，这是脚本。这类会话状态的存储，如果放在源站本机内存里，就要按"并发会话数 × 单会话数据量"去估；量大的话应该放到 Redis 一类外部存储，别堆在 Web 层。

日志缓冲。Nginx 的 access log buffer、应用层日志队列、Filebeat/Fluentd 之类采集 agent 的内存缓冲，这些中间件是"平时看不见、流量一来先崩你"的典型。特别是 WAF 命中日志，攻击高峰期日志量可能是平时的几十倍，缓冲不够就丢日志——而恰恰攻击窗口的日志是你事后取证最需要的。

落到配置：源站建议 32G 起步；带本地日志缓冲 + 采集 agent + 会话缓存的中大型节点，64G–128G 是常态。别用 Swap 兜底，内存交换一旦开始，延迟直接不可控。

硬盘：访问日志落盘与留存，是容量规划的重灾区

硬盘维度最容易被忽略，但它决定你两件事：高峰期会不会因为写不动日志而拖垮响应，以及出事之后能不能拿出证据。

先估算容量。一条完整的 HTTP 访问日志（含 UA、Referer、请求耗时、上游地址、响应大小）大概 0.5–1KB。一个日请求量千万级的站点，每天原始访问日志就是 5–10GB；如果开了 WAF 全量命中日志、再叠加上应用层的审计日志（谁在什么时间改了哪条数据、调了哪个接口），翻一倍很轻松。记住 Pareto 原则的反面：安全场景里你恰恰需要那些 1% 的异常请求的完整上下文。

磁盘选型上，日志是典型的顺序写、随机读（查证时才读）。SATA SSD 写日志够用且性价比高；如果本地要跑检索（比如在现场直接 grep 几百 GB 或者跑轻量分析），NVMe 明显更舒服，随机读延迟差一个量级，排查事故时那个体感差距非常大。机械盘我就一句话：别用于日志写，随机 IO 一上来你就知道什么叫"网站好好的但监控全红"。

留存期要对齐合规与取证需要。金融类业务系统往往要求访问与操作审计留痕较长周期，政企门户也有自己的归档要求，这些按你所在行业的监管口径执行，不要拍脑袋定七日。规划方式：本地 SSD 存热数据（一般 7–30 天），再往对象存储或日志平台转冷归档。千万别把三个月的日志堆在源站系统盘，系统盘写满导致的故障，比被攻击还可耻。

如果你们的合规要求里明确写了留存时长，本地盘按"热窗口 × 日增量 × 冗余系数（建议 1.5–2）"去买。

带宽：清洗前后口径必须讲清，回源流量和攻击流量算不算钱

这一段建议所有采购同学拿荧光笔划出来，因为纠纷基本都出在这。

一条带防护的链路，流量要过好几个环节，每个环节的"带宽"含义都不一样：

攻击流量进入清洗中心的量——这是最大的那个数，动辄几十上百 G。多数清洗服务的计费模式是按防护带宽档位包月（你买 100G 的清洗能力，实际来 80G 就洗掉，来 200G 触发黑洞或降级），而不是按实际清洗掉的字节数计费。但这一条各服务商规则不同，签合同前一定把"超出防护档位怎么处理"问清楚。

回源流量（清洗后回注到源站的干净流量）——这个是真正打到你的源站服务器网卡上的量。如果你买的是"服务器 + 防护"，回源流量多半计入你服务器的带宽计费；如果是"云 WAF/CDN + 源站"，源站出网流量就是回源流量。这里有个坑：哪怕攻击流量被清洗了 99%，剩下 1% 也可能是平时的好几倍，源站带宽照样可能被打满。

攻击流量是否计入带宽费——这是必须在售前白纸黑字确认的点。有的方案按"入方向清洗、前端计费、攻击流量不计"，有的按"服务器网卡进出总流量计费"，后一种在持续攻击月份你会收到一张很难看的账单。还有一些按 95 计费（取月度峰值区间平均）的方式，被打的那一两天会把整月账单拉高。不要听口头承诺，要合同附件里的计费口径条款。

一万网络这类 IDC 服务商的做法相对直接——官网明示提供 5–20G 免费 DDoS 防护，服务器带宽按套餐档位走，具体档位与是否区分攻击流量，以官网实时价与合同条款为准。你在咨询时只要问一句"被打的时候会不会产生额外带宽费用"，答案就清楚了。

还有个容易忘的：回源是哪一路流量走的。如果源站 IP 对外直接可达，回源流量走公网，就要付公网带宽；如果走内网/专线/VPC 对等连接，成本和暴露面都小得多。

线路：BGP 多线与 CN2 GIA 的差别，以及最要命的源站真实 IP

先看线路。BGP 多线解决的是"跨网访问慢"这件事——联通用户访问电信机房，中间要绕道互联互通节点，延迟抖得一塌糊涂。BGP 多线机房同时向多家运营商宣告路由，各家用户进来各走各家的最优路径，跨网延迟和丢包明显改善。这是国内业务（尤其是用户分布全国、运营商混杂的电商和门户）的刚需。

CN2 GIA是另一回事。它是面向跨境优质回国的精品线路，特点是路由跳数少、优先级高、晚高峰拥堵程度远低于普通国际出口。如果你的业务用户主要在中国大陆，而服务器放在中国香港、新加坡、美国等境外节点，普通国际线路在晚高峰的延迟抬升和丢包是肉眼可见的，CN2 GIA 的价值就体现在这里——当然价格也明显更高。特别注意：节点位于中国香港、中国澳门、中国台湾以及海外地区的，法律适用、数据出境、备案要求都与大陆节点不同，采购前要跟法务对齐。

选线路的判断标准很简单：用户在哪。用户在大陆且分布全国，选大陆 BGP 多线；用户在大陆但业务必须放境外，选 CN2 GIA 回国优化线路；用户全球化，就别指望单条线路解决，前面加 CDN。

接下来说全篇最重要的部署红线：源站真实 IP 绝对不能被知道。

WAF 生效的前提是——所有流量必须经过它。只要攻击者知道了你源站服务器的真实 IP，就可以完全绕过 WAF 和清洗设备，直接对着源站打。这时候你前面那套几十万的防护等于零。

真实 IP 是怎么漏出去的？常见几条：历史 DNS 解析记录（你接过 WAF 但没换 IP，A 记录还指向源站）；邮件服务器发信时带出源站 IP；SSL 证书透明度日志里能查到关联域名解析；CDN 没配好导致某些子域名或图片域名直接解析到源站；源站主动对外发起的请求（调用第三方 API、回执通知）暴露了出口 IP；以及最常见的——换过 IP 但老 IP 没下线，或者换了 IP 之后源站安全组还是 0.0.0.0/0 全通。

怎么做到？三条硬要求：第一，接 WAF/高防时同步更换源站 IP，别偷懒；第二，源站防火墙/安全组只允许来自 WAF 回源 IP 段的流量，其他一律丢弃，这是唯一真正有效的一招；第三，检查所有对外暴露面——子域名、邮件 MX 与发信服务、第三方回调地址、对象存储的回源配置，全部过一遍。

一万网络这边 BGP 多线 + CN2 GIA 是官网明示的网络能力，做策略收缩和回源 IP 白名单时，直接找 7×24 中文工单要回源 IP 清单就行，平均 5 分钟响应，不用发邮件等半天。这类"清单要得到"的服务能力，在真出事的时候才显出价值。

机房：清洗节点分布与容量，只认官网明示项

选防护节点看三个东西：清洗节点在哪、单节点清洗容量多大、超出容量之后的降级策略是什么。

节点位置决定了防护流量的绕路成本。如果你的用户全在华南，防护节点却在华北，每一次访问都要多绕几百公里、多出十几到几十毫秒。分布式部署的意义在于"就近清洗"——流量在离攻击者最近的节点被吸收掉，正常用户走最近节点进来。

容量这块不要只看宣传的最大数字，要看单 IP 能分到多少。一个清洗中心总容量看着很大，但同一时刻被打的可能不止你一家。真正该问的是"我这个 IP 被打时，承诺给我多少"以及"超过之后是黑洞（直接丢弃所有流量）还是降级（保留部分）"。黑洞时长、黑洞触发阈值、解除方式，这三条必须写进合同附件。

一万网络官网明示的能力是5–20G 免费 DDoS 防护、深圳南山自营机柜、多线接入，更高防护档位或专线方案要按实际攻击面去单独询定制，以咨询为准。我不会在这里替任何厂商编一个漂亮的数字——防护能力这类参数，纸上写的和你被60G流量砸的时候实际表现的，很可能不是一回事，一定要让对方出具书面口径。

上线姿势：观察模式灰度，是唯一正确的第一步

新 WAF 上线，我给所有客户的建议都只有一句：先只告警不拦截，跑够一个完整业务周期。

什么是观察模式（也叫监控模式、只告警模式）？就是规则照常匹配，命中了记日志、发告警，但不真的返回拦截页，请求原样放过去。这样你可以在零业务风险的前提下，把"哪些正常请求会被误伤"看得一清二楚。

观察期要跑多久？至少一个完整业务周期。做电商的，至少要覆盖一次大促或至少一个月内的流量高峰；做 SaaS 的，要覆盖每周忙时；做政企门户的，要覆盖工作日上午的集中访问。只跑两天上线，等于埋雷。

灰度策略我一般这么排：第一周，全站观察，收集告警；第二周，把确认无误伤的规则（比如明显畸形请求、扫描器特征）转拦截，核心交易链路保持观察；第三周，加入针对特定路径的严格规则，同时加白名单；第四周，逐步打开人机校验与频率控制。每一步都要有回滚开关，且要保证五分钟内能切回观察。

自定义规则的养护是长期活。业务上线了新接口，WAF 不知道，就可能把它当未知行为拦掉；大促前加的活动页有大量跳转参数，也可能触发篡改类规则。建议把"新功能上线同步评估 WAF 规则"写进你们的发布流程，运维和安全负责人一起签字。这一步做不到的团队，迟早会在某个周二的下午被自己的新页面拦住。

CC 防护 ≠ 频率限制：两者别混为一谈

这两个概念被混用的程度，堪比"备份"和"容灾"。

频率限制（Rate Limit）是静态阈值。规则很简单：同一个 IP，60 秒内请求超过 100 次就处置。它便宜、确定性强、资源消耗小，缺点也明显——会误伤 NAT 出口、企业出口、移动基站这种大量用户共用一个公网 IP 的场景；反过来，慢速攻击（每 IP 每分钟三次，但有一万个 IP）它完全拦不住。

CC 防护是行为分析。它看的不只是"多少次"，还有访问的是什么、顺序是什么、像不像人。典型判断因子包括：请求是否命中动态资源而非静态资源；Referer 是否连续；是否加载了 JS 和图片资源（爬虫通常不加载）；UA 与 TLS 指纹是否匹配声称的浏览器；访问路径是否符合真实的业务流程（登录—列表—详情—下单）。命中嫌疑之后，处理手段也是分级的：静默拦截、JS 挑战、验证码、慢速放行、乃至临时加入隔离名单，而不是简单返回拒绝。

为什么 Web 层的 CC 防护属于应用层？因为它必须能理解"业务的语义"——哪个接口昂贵（比如导出、搜索、发短信），哪个接口便宜（静态图）。一个好的 CC 策略一定会先按接口分级：对昂贵的敏感接口设更严的阈值和更强的人机校验，对静态资源放宽。一刀切的频率限制只会把搜索引擎蜘蛛和用户隐私保护类的代理流量一起打死。

还有个点要注意：CC 防护的有效性高度依赖真实客户端 IP 的还原。如果前面串了多层代理、CDN，源 IP 处理不对，所有频率统计都是错的。这一层要做清楚，通常依赖标准转发头的一致性管理和只信任可信代理层的配置。

API 场景与站点场景：载荷检测差在哪

很多团队的 WAF 规则是从"保护官网门户"那套直接搬到 API 上的，然后发现要么不生效，要么天天误伤。

站点场景的特征：请求主体是 HTML 表单、URL 查询串，内容类型常见 application/x-www-form-urlencoded、multipart/form-data；请求内容以自然语言、用户输入为主；攻击者目标是注入、跨站、上传 Webshell。

API 场景完全另一回事：请求体是 JSON（也有 XML，金融、政企的老系统里 SOAP/XML 还不少）；字段数量多、嵌套深；客户端不是浏览器，是 App、小程序、服务端脚本——没有浏览行为、不加载 JS、不跑验证码；攻击形态也不同，重点在于越权（改别人家的数据 ID）、批量枚举（遍历用户/订单号）、参数篡改（把金额、数量在本地改了重放）、以及业务逻辑滥用（反复调用高成本接口）。

差异落到检测上有四条：

一是解码深度。JSON 要解析到字段级再查载荷，光看整个 Body 的字符串特征远远不够；嵌套结构、Base64 或压缩编码的多层封装，要能逐层解开。二是体量限制。API 的 Body 可能很大（批量接口、文件上传），要设最大检测深度和最大 Body 大小，超过就有性能风险；这里也存在服务资源被大请求拖垮的隐患，必须限。三是人机校验不适用。API 里塞不了验证码，替代手段是 mTLS 客户端证书、请求签名、App 端加固、设备指纹、Token 行为序列。四是正负向模型。站点场景多用黑名单（拦特征），API 场景更适合白名单（先定义每个接口允许哪些字段、字段类型是什么、枚举取值范围是什么），也就是所谓的接口参数基线。这一步做起来最费人工，但效果也是最稳的。

做金融类业务系统的尤其注意： XML 场景要处理外部实体引用这一类解析风险，配置上要确保解析器禁止外部实体加载；同时要有深度限制和实体展开上限，防止一次请求把服务器 CPU 打满。这些是开发侧配置，别指望 WAF 全兜。

证书与回源加密：SNI、回源 HTTPS 这些通用做法

这一段只讲通用工程做法，不针对任何具体产品。

SNI（Server Name Indication）是什么？简单说：一台服务器 IP 上放了多个 HTTPS 站点，握手阶段服务器得知道你要访问哪个域名才能给出对应的证书。SNI 就是客户端在握手第一步把这个域名明文带上的机制。它带来两个工程含义：一是同 IP 多站点的证书匹配依赖它；二是它是明文的，所以在需要域名级隐私保护的场景里会用到加密 SNI（ECH）这类方案，注意它对中间网络设备的可见性有影响，改造前要评估。

回源要不要走 HTTPS？取决于你对链路可信度的判断。如果中间经过的是不可控的公网路径，回源 HTTPS 能防窃听和篡改，代价是源站 CPU 要承担加解密；如果链路已经处在可信的专线/VPC 环境里，可以在评估后选择回源 HTTP 换来性能，但要把这个决策写成明确的安全假设并定期复查。

几个一定要做的细节：证书到期监控必须独立于厂商告警，我见过多次"证书过期 + WAF 厂商告警也过期"的组合事故；证书链要完整，缺中间证书在部分客户端上会直接失败；回源时的域名校验别关——图省事关掉校验等于让人随便伪造源站；统一 HTTPS 的推荐协议版本与套件，老加密套件既不安全也慢。

还有一点容易被忽视：证书透明度（CT）日志是公开的，签发记录会暴露域名与关联信息，历史上不少源站 IP 泄漏就是从这里顺藤摸瓜出来的。不要以为"对外明细不可见"就等于"查不到"。

日志留存与取证：出事之后你靠什么还原现场

攻击发生后的黄金两小时，最贵的不是防护产品，是你手上有没有完整的日志。

至少三层日志要对齐留存：网络/清洗层（谁、什么时候、多大的量、从哪个节点来的）；WAF 层（命中哪条规则、原始请求头与 Body 摘要、处置动作、请求唯一 ID）；源站层（应用访问日志、错误日志、数据库慢查询、业务审计日志）。三层要能用同一个请求 ID 串起来，否则事后你只能看着三份互相对不上的表格发呆。

取证时的三个硬需求：时间同步——所有机器强制 NTP，时钟偏差会让你的时间线分析全废；原始请求的完整上下文——包括 Cookie、Referer、UA、完整 URI；不可篡改——重要场景考虑把日志实时推送到独立存储并做只追加写入，本地日志在主机被攻陷时是不可信的。

隐私边界也要说清：日志里可能含有个人信息（手机号、身份证片段、收货地址）。留存越长，自身的数据合规义务越重。建议做字段级脱敏后再长期归档，且明确访问审批流程。金融、政务这类监管较严的行业，按所属行业监管口径执行，不确定就找合规同事确认，不要自行发挥。

6 家服务商横向对比：防护类型、带宽口径、规则处理、回源与日志

下面这张表不是跑分排名——坦白说，WAF 的效果高度依赖业务形态，跨厂商做客观横评本身就不严谨。这张表的价值在于帮你问对问题：每一列都是你在售前必须问清楚、且必须写进合同的点。

表格里的价格与防护带宽，凡官网有明示的请以官网实时价为准；凡我们按行业情况估的，一律标「（预估，以下单核算为准）」，不要当成报价。

怎么读这张表？我的用法是：先定部署形态（云 WAF 还是硬件/自建），再定线路与节点，最后才比价格。形态选错了，价格再便宜也是白花。比如你的业务跑在自有物理服务器上，硬套一个只能 CNAME 接入的云 WAF，源站 IP 保护这件事就得你自己补；反过来，你只有两台云主机，却去买一套硬件盒子，运维成本和闲置率都很难看。

一万网络推荐配置：两套我们常给客户的组合

#1 一万网络「华南 BGP 多线源站 + 5–20G 免费防护」——国内电商/政企门户的主力款

这是我给国内业务客户最常首推的一套，理由很实在：华南节点，深圳南山自营机柜，离大多数华南/华中用户近，跨网问题交给 BGP 多线解决。起步价 ¥799/月（华南节点，以官网实时价为准），机器本身通过了 5–20G 免费 DDoS 防护这一层打底。

具体怎么配才顺手：

Web 源站——8–16 核 CPU / 32G 内存起步，TLS 在边缘卸载、回源走内网或白名单 IP 段，源站只跑应用；日志节点——独立一台中型配置，NVMe 系统盘 + SATA SSD 数据盘，专门跑日志管线，别和应用抢 IO；数据库——和 Web 层分离，且只在内网可见，公网端口一律不通。

这套的意义在于把那些不必要的攻击面统统收掉。说人话就是：公网只留 80/443 给回源 IP，其他全关，IP 白名单是 MySQL、Redis、Elasticsearch、Kibana 的统一答案。很多团队用了最好的 WAF，Redis 却开着公网端口且没密码——那防护再好也没用。

另外两条官网明示的能力记得用起来：每日 3 份免费快照、30 秒回滚——在改 WAF 配置或发布新接口之前，先打快照，五分钟内能回滚；7×24 中文工单、平均 5 分钟响应——需要回源 IP 清单、需要临时加带宽、需要做策略调整的时候，走工单比打电话给销售靠谱得多。还有一个容易被忽略的：免费备案协助，做国内节点门户上线的时候能省不少跑腿。

#2 一万网络「中国香港 CN2 GIA 源站 + IP 隔离」——有跨境访问诉求的业务

第二条常给的是跨境场景。用户在大陆、节点在境外，普通国际线路晚高峰的体验自己测一次就知道了。CN2 GIA 的价值就是晚高峰还能稳得住，代价是价格明显高于普通国际带宽。

配置组合建议：中国香港节点，E3 平台 ¥1500–1599/月（以官网实时价为准），作为 WAF/CDN 之后的源站。核心要点三条：第一，CN2 GIA 带宽成本不低，务必把静态资源、图片、视频全部前置到 CDN，只让动态请求回源，这样回源带宽能压到很低；第二，源站 IP 严格白名单化，境外节点的暴露面比境内更危险，因为节点级别的边界防护通常依赖你自己的策略；第三，数据合规先过法务——涉及个人信息、金融数据存储与出境的，务必先确认适用规则，再谈选型。

还有一类客户我会推荐裸金属 E5-2698v4 双路（¥3999 起，以官网实时价为准）：核心多、线程多，适合在内部自建 WAF 网关 + 日志分析平台 + SIEM 的组合，尤其是金融和政务客户要求"日志不出自家网络"的时候。这种不被虚拟层打扰的物理机，跑正则引擎和日志流水线比同价位虚机舒服太多了。

最后一句，是朋友的建议不是广告：你真要上线一套防护，先在测试环境跑满一周，用真实流量副本喂一遍。参数表写得再漂亮也只是纸面数据。跑出来的数据才属于你自己。

避坑指南：六条血泪级别的错误

坑一：以为上了高防就不需要 WAF

为什么坑：高防清洗在网络层/传输层工作，看的是包速率、连接数、协议合法性。一条构造好的 SQL 注入请求，从网络层看就是一个再正常不过的 HTTP GET，包不大、速率不高、握手正常。你买了 300G 清洗能力，攻击者用三个肉鸡、每秒十次请求，就能把你的用户表拖走，清洗设备全程零告警。混淆这两层是国内安防采购里最贵的一个认知错误。

怎么避：预算里写两行，一行给清洗（抗流量型攻击），一行给应用层防护（抗请求型攻击）。如果预算实在紧张，至少保证应用层能力存在——哪怕先用反向代理层压制的轻量级规则 + 严格的频率控制，也比裸奔强。顺序上是先保应用层，因为严重的资损大多发生在应用层。

坑二：源站真实 IP 暴露，WAF 形同虚设

为什么坑：WAF 靠"所有流量必经我来"生效。只要攻击者拿到源站真实 IP，就能直接对着源站打，前面所有设备全部跳过。最常见的泄漏方式很土：接了高防但没换 IP；换了 IP 但老 DNS 记录还在；源站安全组 0.0.0.0/0 对公网全开；某个测试子域名直接解析到源站；邮件系统发信带出源站地址。

怎么避：三件事必做——接入时同步更换源站 IP；防火墙/安全组只允许来自回源 IP 段的流量（这是唯一真正有效的手段）；做一次暴露面自查，把历史 DNS 解析、证书透明度记录、子域名列表、第三方回调地址、邮件发信路径全过一遍。做完之后从外部对你的源站 IP 做一次可达性验证，通了就是没封干净。

坑三：攻击流量也计入带宽费，账单比攻击更吓人

为什么坑："清洗服务免费/低价"和"带宽不额外收费"是两件事。有的方案对清洗掉的攻击流量不计费，但回源流量、以及超出防护档位后的处置流量照样产生费用；有的按带宽峰值或 95 计费，被打的那两天直接把整月账单拉高一档。还有一种情况是攻击没打进来但产生了大量回源请求（比如 CC），源站出网流量翻倍。

怎么避：签约前把这四个问题白纸黑字问清楚：防护档位是多少？超档之后是黑洞还是降级？黑洞阈值和解除时长？攻击流量和回源流量分别怎么计？并把答案写进合同附件。另外加两条财务护栏：设置带宽费用告警阈值，异常流量第一时间通知到人；提前谈好临时扩容的价格，别等到被打的时候再议价，那时候你没有议价能力。

坑四：忽视误拦截对下单链路的影响

为什么坑：WAF 的收益是"拦住了多少攻击"，看不见；它的代价是"拦错了多少正常请求"，第二天销售就找上门。而且误拦的分布很不均匀——越是富文本输入、复杂表单、跳转参数多、需要重放的链路越容易被拦，恰好这就是注册、搜索、下单、支付回调。一个"看起来更安全"的严格规则，在双十一当天可能直接打掉你几个点的转化率。这笔账比任何安全 KPI 都实在。

怎么避：三条：核心交易链路单独建策略组，规则强度比 marketing 页面低一档；支付与回调接口加入白名单，并对第三方回调 IP 做授信；建立业务指标联动告警——把下单成功率、支付回调成功率、搜索无结果率接进监控，一旦 WAF 改策略后这些指标抖动，立刻回滚。记住：衡量 WAF 的不是拦截报表，是转化率。

坑五：只保护网页，忽视 API 与移动端流量

为什么坑：现在大多数业务的真实流量在 App 和小程序上，走的全是 API。网页那套规则对 JSON 载荷查不动，安全检查形同虚设；而 API 上的典型风险也和网页不同——越权读取他人数据、ID 批量枚举、参数篡改、重放、接口滥用——这些在网页场景里不太出现，在 API 场景里天天发生。还有更尴尬的：App 不涉及浏览器渲染，你那套"JS 挑战 + 验证码"在这里根本没人理。

怎么避：把 API 当作独立防护对象：先做接口清单，再对每个接口的字段类型、取值范围、枚举值做基线（也就是参数合法性校验）；客户端侧加固 + 请求签名；服务端做幂等与 anti-Replay（时间戳窗口 + 一次性 nonce）；对高成本接口单独配额（导出、批量查询、发短信、发邮件）。别指望一个"全站防护开关"解决问题。

坑六：把 WAF 当成漏洞修复的替代品

为什么坑：WAF 是虚拟补丁，不是真补丁。它能把外部到达那条特定路径的攻击挡住，但代码里的漏洞还在——换个参数位置、换个接口、或者直接打内网，防护就失效了。更危险的是心理层面：有了 WAF 之后团队对漏洞修复的紧迫感会明显下降，漏洞在代码里躺三年没人管，直到某天被人从内部攻破。安全圈有句老话：WAF 拉长了你的反应时间，不是消灭了你的欠债。

怎么避：把 WAF 的告警当成漏洞情报而不是护身符——每次命中都要回查代码那条路径并真正修复；建立虚拟补丁到期机制，规则上线时就登记对应的修复排期，修完把规则下线；持续做依赖与组件的漏洞扫描，尤其是 Struts、Log4j 这类历史重灾区。一句话：WAF 争取时间，工程师负责还债，两者缺一不可。

FAQ：八个被问过无数次的问题

Q1：我们公司就一个官网 + 一个小商城，真的需要单独上 WAF 吗？

要看你的商城有没有数据库和真实存货。纯展示型官网，内容每天更新、没有用户中心、没有数据库写出动作，那么做好基础防护（打补丁、关端口、用 CDN、开免费层的基础防护）通常够用。但只要涉及用户注册登录、订单、支付、会员积分，哪怕规模很小，我建议都上应用层防护——原因不是你重要，而是攻击是自动化的全网扫描，脚本不会因为你公司只有二十个人就跳过你。撞库和拖库这种事对小商城反而更致命，因为你连发现它的能力都没有。预算紧的话，优先选带自定义规则和观察模式的方案，先把慢速撞库和明显的畸形请求挡住，性价比最高。

Q2：云 WAF 和硬件 WAF 到底怎么选？销售都说自己好。

按三个条件判断就行。第一，你的服务器在哪：在公有云上，云 WAF 接入最省事，改个 CNAME 或配个回源就完事；在自建机房或物理服务器上，硬件/软件一体化的方案更合适。第二，有没有运维能力：云 WAF 厂商替你管引擎升级和规则库，硬件方案要自己养策略，没人管的话半年就荒废了。第三，日志能不能出门：金融、政务、能源这类要求日志留存本地、策略自控的场景，硬件或自建方案是硬需求。别听销售讲功能清单，先回答这三个问题，答案自己就出来了。中小团队我一般推荐云 WAF 起步，等业务稳了再考虑下沉到自建。

Q3：观察模式到底要跑多久才敢切拦截？

我的底线是一个完整业务周期，不是日历上的七天。具体看你的业务节奏：电商至少覆盖一次促销（哪怕只是店铺自己搞的小活动）以及一个完整的周内高峰；SaaS 看你的忙时是全周的还是集中在工作日上午；政企门户通常集中在工作时段，要覆盖几个完整工作日。切的时候也别一刀切：先转明显无误伤的规则（畸形请求、已知扫描器特征），保留核心交易链路继续观察一到两周，然后才逐步加严。最关键的是回滚开关要随时可用，而且要保证能在五分钟内切回去——做不到这一点，就别急着开拦截。

Q4：误拦截率降到多少才算合格？

这个问题没有统一标准，但我给一个可操作的框法：核心交易链路的误拦必须接近于零，这是硬指标；非核心页面允许极低比例的误伤，但要有清晰的反馈通道。判断方法不是看厂商给的百分比，是看你自己三个业务指标：下单成功率、API 错误率里属于防护拦截页的比例、以及用户反馈渠道里"I 提交时被提示非法"的工单数量。这三个数稳定了，你的策略就是合格的。要警惕的是厂商宣称的"零误拦"——通常意味着规则放得很松或者压根没在拦截模式下工作，那种"零"没有意义。

Q5：CC 防护和限流是不是重复建设？能不能只留一个？

这两个建议都留，用途不同。限流是确定性保护：给每个接口一个明确上限，超过就拒，逻辑简单、开销小、结果可预期，防止自己被自己人（比如某个 bug 导致的重试风暴）打崩——这个价值不可替代。CC 防护是概率性识别：对付慢速分布式、会话行为缓慢漂移这类肉眼看不出异常的攻击。只留限流，慢速攻击过；只留 CC 防护，你没有明确的上限保护，运营成本也不确定。建议做法：先用限流定一个保底水位，再用 CC 防护做精细识别，两者叠加，且对高成本接口（导出、发短信、搜索）单独设更严的阈值。

Q6：源站 IP 换了之后真的就安全了吗？

换 IP 只是第一步，只换 IP 等于换汤不换药。新 IP 如果不做访问控制，扫一遍端口照样被发现。真正的做法是三件套一起做：换 IP + 防火墙只允许回源 IP 段 + 全面清理历史暴露面。第三件最容易被跳过，但恰恰是泄漏大户——历史 DNS 解析记录、证书透明度日志、邮件 MX 与发信记录、未接入防护的测试子域名、第三方回调地址、以及从源站主动发起的外部请求。做完之后要做验证：从外部网络对你的源站 IP 做端口可达性测试，80/443 之外应当全部不可达。还有一个常态问题：团队新增机器时忘了把策略复制过去，安全这一手一定要固化到这条流程里。

Q7：回源到底要不要走 HTTPS？会不会很慢？

取决于中间链路你信不信。如果中间要经过不可控公网，那一定要走 HTTPS，防窃听和篡改，这一步不能省。如果链路已经在你自己的专线或可信内网环境里，可以在评估后选择回源 HTTP，用性能换简化，但这个决定要写成书面的安全假设并定期复查。至于慢不慢：代价主要落在 CPU 上，用 ECC 证书、开启会话复用、回源开启长连接，这三项做完，握手开销会被摊到很薄。真要说影响，多数团队最后的性能瓶颈不在 TLS，而在 路由跳数、DNS 解析、以及回源链路自身的跨网质量——这几样比 TLS 重要得多。别为了省几个百分点的 CPU，把链路明文裸奔。

Q8：我们已经上了 WAF，是不是就不需要修补漏洞了？

必须补丁，这个是常识，也是最常被违反的一条。WAF 挡的是"外部到达特定路径的已知特征"，漏洞在代码里原地没动。换个参数、换个接口、或者通过内网别的路径进来，防护就失效了。更要命的是心理效应：有了 WAF 之后，团队对漏洞的紧迫感会明显下降，漏洞在代码里躺到被人从内部打穿。我的做法是：把每一次 WAF 命中都当成一条漏洞情报，回查对应代码路径并真正修复，同时给规则登记"虚拟补丁到期日"，修复完成后把对应规则下线。原则是：WAF 争取时间，工程师负责还债。另外持续做组件依赖扫描，很多事故的源头不是你的代码，是第三方库。

写在最后：选的时候记住一句话

如果你只能从这篇记住一件事，那就记住这句：看 WAF 好不好，别看它宣称拦了多少，看它拦错了多少，以及它在你的链路里加了多少毫秒。

规则命中率是可以靠加规则硬堆上去的，误拦截率是藏不住的——它会在你的转化率、你的客服工单、你的大促当晚准时出现。而延迟和并发开销是每天都在付的税，一笔七年都不提价的持续账单。

具体落地的顺序我也说清楚：先分清清洗和 WAF 是两层预算 → 把自己的 API 清单和参数基线整理出来（这一步不做，后面全白搭）→ 接入 CDN/高防，同时更换源站 IP 并做白名单 → 在测试环境用真实流量副本跑满一周 → 转正式前先跑够一个完整业务周期的观察模式 → 监控里接上转化率而不是只看拦截报表。这套顺序做下来，比多花三倍预算买更贵的盒子有用得多。

选服务商的时候，别被花哨的功能清单带走。问清楚四件事：防护档位与超档后怎么处理、攻击流量和回源流量怎么计费、规则能不能自定义且有没有观察模式、日志能不能留存够你取证。这四个问题回答得干脆并愿意写进合同的，通常也不会差到哪去。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部，官网明示的能力是 5–20G 免费 DDoS 防护、BGP 多线 + CN2 GIA、7×24 中文工单平均 5 分钟响应、硬件故障 10 分钟自动迁移、每日 3 份免费快照 30 秒回滚、免费备案协助、自营机柜最快 1 分钟上架——这些都是能查证、能写进合同的条目，比任何口头承诺都实在。

数据来源

本文涉及的一万网络服务能力与基础报价，参考其官网各产品介绍页与服务说明页：https://www.idc10000.net/（含服务器租用、裸金属、中国香港节点、网络线路与增值服务相关页面）。文中标注「以官网实时价为准」「以咨询为准」「（预估，以下单核算为准）」的条目，均非固定成交价，具体以签约时最新报价与合同为准。涉及清洗节点容量、防护带宽档位、超档处置与计费口径的内容，建议在签约前与服务商书面确认并写入合同附件。文中关于 WAF 工作层级、部署方式与容量规划的描述属于通用工程实践，不构成对任何第三方产品的性能背书。