内容摘要：某省政务云招标文件里，WAFWeb应用防火墙）的技术参数赫然写着“支持与下一代防火墙联动”。供应商一看就明白，这又是拿防火墙的规格来卡WAF的脖子。更离谱的是，有的标书直接把下一代防火墙的硬件指标——

某省政务云招标文件里，招标WAF（Web应用防火墙）的排除技术参数赫然写着“支持与下一代防火墙联动”。供应商一看就明白，下代这又是防火拿防火墙的规格来卡WAF的脖子。更离谱的招标是，有的排除标书直接把下一代防火墙的硬件指标——比如吞吐量、并发连接数——原封不动套在WAF头上。下代结果呢？防火正经WAF厂商投标时发现，自己产品在“SSL解密性能”这一项上永远差一截，招标因为下一代防火墙的排除SSL吞吐测试标准，压根不是下代给WAF这种七层代理设备设计的。

这事的防火根源在于采购方把安全设备当成同类项合并了。WAF和下一代防火墙分工完全不同：WAF盯着HTTP/HTTPS流量里的招标SQL注入、XSS攻击，排除工作在应用层，下代得逐个请求做深度解析；下一代防火墙主要管网络层访问控制，靠的是包过滤和状态检测，偶尔看看应用特征。你把防火墙的“新建连接数”指标套到WAF上，就像用卡车的载重标准去要求跑车——跑车确实能上高速，但人家不是干这个的。

我见过一个真实案例。某银行采购WAF，技术参数里写了“支持IPv6隧道封装”，这本来是下一代防火墙常见的功能要求。结果有三家WAF厂商因为这个条款被废标，理由是不满足“实质性参数”。实际上，WAF部署在负载均衡后面，IPv6隧道由前置设备处理，WAF根本不需要直接解封装。采购方被供应商误导，把网络层功能硬塞给应用层设备，最后只能买到功能冗余、价格翻倍的“四不像”——既做不好WAF的细粒度防护，又比不上正经防火墙的网络性能。

要排除这种干扰，最直接的办法是删掉技术参数里所有带“网络层”属性的条目。你只需要问三个问题：这功能是处理单个HTTP请求的吗？需要解析Cookie和表单吗？要针对URL路径做规则匹配吗？如果都不是，那就是防火墙的活，别写进WAF标书。比如“支持OSPF动态路由”“支持VLAN间路由”这类条款，直接划掉——WAF要是真支持了，反而说明它把太多资源耗在非核心功能上。

另一个坑藏在性能测试方法里。很多招标文件要求WAF的“吞吐量”必须达到XX Gbps，但没说清测试流量是纯HTTP还是混合流量。有些供应商拿UDP小包去冲吞吐量，数字好看，实际防护时一遇到真实HTTPS流量就掉到几分之一。写标书的人应该明确：性能指标必须基于“模拟真实Web攻击流量”的测试环境，并且要单独标注“启用全部安全规则后的吞吐量”。否则，下一代防火墙的线速转发成绩，会让WAF显得像个废物。

最后提醒一句：别让“联动”这个词成了摆设。有些标书写“WAF需与下一代防火墙实现联动封锁源IP”，听着合理，但真联动起来，WAF检测到攻击后要调用防火墙的API去封IP，延迟可能超过100毫秒——攻击早就打完了。真正靠谱的做法是让WAF自己具备IP黑名单功能，而不是指望外部设备。如果非要写联动，加个限定条件：“联动响应时间不得超过50毫秒”，这一条就能筛掉一半只会做接口对接、不懂安全实效的厂商。

说白了，招标文件是写给懂行的人看的。把WAF当防火墙来要求，只会逼着厂商堆硬件、刷参数，最后买回来的东西，既防不住针对Web业务的攻击，又浪费了网络层设备的预算。下次写标书，先分清“这活到底该谁干”，再谈参数——省下来的钱，够多买两台正经WAF了。