先说个具体的：新加坡那台车
去年 11 月，一个做跨境独立站的客户找我帮忙看设备选型。他们主力在新加坡 ap-southeast-1，两个 AZ，日均订单 12 万单左右，大促能冲到 40 万。安全团队一共三个人，还要兼着做风控。当时他们的方案是买两台高端防火墙开 IPS 模块，双机热备，供应商给的配置单上写着「IPS 吞吐 40Gbps，威胁防护吞吐 18Gbps」，看起来绰绰有余——他们的出口带宽才 2Gbps。
结果实测下来，开了 TLS 解密、App-ID 和 IPS 之后，单台的混合流量处理能力掉到 4Gbps 出头，CPU 有个核常年跑在 85% 以上。更尴尬的是 latency 从 0.3ms 涨到了 2.1ms，他们那个实时库存查询接口的 P99 直接从 180ms 干到 340ms。后来复盘，问题不在设备本身，在于他们拿「大包线速」的数字去套「小包 + 加密 + 应用识别」的真实流量，这两件事差着好几倍。
这篇就把我当时给他们整理的选型笔记复述一遍。不敢说通用，至少是我踩过或者近距离看别人踩过的。
坑一：吞吐量的单位游戏，Mbps 和 Mpps 不是一回事
Datasheet 上的「40Gbps IPS 吞吐」几乎都有一个脚注，条件通常是 RFC 2544 的 1518 字节大包、单一 UDP 流、关闭所有高级功能。而真实的 Web 流量是 iMIX 分布，平均包长 400-600 字节，小包占比高。这就意味着同样的 40Gbps 硬件，如果你按包转发率（pps）算，可能只有标称值的 1/3。
选型的时候一定要问三个数：IPS 开启状态下的 IMIX 吞吐、新建连接速率（CPS）、并发会话数。这三个数缺一个，报价单就没法评估。我见过一家标 800 万并发会话，但 CPS 只有 12 万，大促秒杀的时候新建连接直接打满，连接排队，表现出来就是「设备没跑满但业务卡」。
给你一个粗略的换算经验值：单颗主流 x86 多核 CPU（16-24 核），跑 Suricata 这类开源引擎，HTTP 混合流量下大概能到 8-15 Gbps，pps 在 300-500 万左右。商用一体机的 ASIC/NP 架构会高不少，但贵出来的钱买的其实是确定性和运维省心，不是单纯的速度。
坑二：TLS 解密，一开就把性能砍到脚踝
现在超过 90% 的流量是加密的，如果 IPS 不解密，它只能看 SNI 和证书字段，等于闭着眼睛抓贼。但 TLS 解密对性能的消耗，供应商在彩页上一般不会写。
我实测过的几台机器，开解密之后的 IPS 吞吐普遍掉到原来的 15%-30%。原因有两个：一是握手阶段的非对称运算，RSA 2048 的一次完整握手大概要 0.5-1ms 的单核时间，QPS 高了以后握手就是瓶颈；二是解密之后数据要在用户态和内核态之间多搬几次，缓存命中率变差。
所以如果你的业务是以 HTTPS API 为主，选型时务必要求供应商在「TLS 解密 + IPS + 应用识别」三个功能全开的状态下跑一遍你们的真实流量回放。别接受「理论值」，也别接受只用 curl 打几个请求的演示。另外还要提前想清楚解密的合规问题，比如欧盟很多国家不允许企业随意解密员工流量，跨境业务里还有密钥托管在哪里的问题。
坑三：云上部署，GWLB 的 GENEVE 封装会咬人
如果 IPS 是部署在 AWS 上做南北向流量的透明串联，基本绕不开 Gateway Load Balancer。它的原理是用 GENEVE 封装，目的端口 UDP 6081，把流量引到你的虚拟设备上。听起来很干净，实际上有几个细节会让人熬夜。
第一是 MTU。GENEVE 封装会给每个包加上大概 100 多字节的头部，如果你的实例 MTU 还是默认的 9001 或者 1500，封装后就会超，触发分片或者依赖 PMTUD。而 PMTUD 在现实网络里经常被中间设备丢 ICMP 给废掉，表现出来就是「小请求正常、大响应卡死」，尤其是导出报表、上传图片这类场景。标准做法是把实例的 MTU 调到 8500，同时在安全组和 NACL 里放行 ICMP。
第二是健康检查。GWLB 的健康检查是主动发 GENEVE 探针，如果你的设备只监听了业务端口没处理探针，会被判不健康然后整个 AZ 的流量绕开你——你以为在防护，其实流量裸奔。这个坑我在两个客户那里都见过。
第三是成本。GWLB 本身按小时和流量计费，加上跨 AZ 的数据传输费，如果你的 IPS 实例只部署在一个 AZ，另外两个 AZ 的流量都算跨 AZ 传输，账单会很难看。建议按 AZ 对称部署，别省这个钱。
坑四：规则库更新，跨境带宽是笔隐形账
商用 IPS 的规则库和威胁情报一般走厂商云，一天更新几次到几十次不等。如果你的防护节点分布在法兰克福、圣保罗、孟买、东京，每次全量更新可能几十到几百 MB，增量包小一些但也有几 MB。乘以节点数乘以更新频次，跨境专线的成本要算进去。
开源方案这边，Suricata 配 ET Open 规则集，全量大概 4 万多条规则，开起来内存占用 2-4GB 不等，取决于你有没有开 stream.memcap 调优。ET Pro 是收费的，一年几百美金起，规则质量和误报率比 Open 版好一截。Snort 3 的规则语法兼容性跟 2.x 有差异，迁移的时候别想着一把梭。
还有个容易被忽略的点：规则更新和引擎重启。有些设备更新规则需要重启检测进程，重启期间流量是「bypass」还是「drop」，这个策略一定要提前定，别等出事才发现默认是 drop 然后全站挂了 30 秒。
坑五：误报成本，在大促当天会被放大十倍
IPS 的误报在平时只是烦人，在大促当天就是事故。我印象最深的一次，某电商的筛选 URL 里带了 ?filter=price'，一个单引号，被一条老的 SQLi 规则命中，直接拦了。那天下午的转化率掉了 8%，排查花了 40 分钟。
所以上 IPS 之前，一定要有一段「只记录不阻断」的观察期，我一般建议至少两周，覆盖一次小流量峰值。观察期结束时把命中量 Top 50 的规则逐条看一遍，确认哪些是业务正常流量触发，然后把对应的源 IP 段或 URL 路径加白名单。
另外规则集的「严重级别」管理也很重要。真正需要立即阻断的规则可能只占 5%-10%，剩下的都应该是告警或者降级处理。把所有规则都设成阻断，等于给自己埋雷。Suricata 里可以通过 threshold.config 做限速和抑制，商用设备一般在策略里能配，但界面藏得比较深，销售演示的时候不会给你看。
坑六：合规和日志出境，比技术选型更卡人
出海业务做安全，绕不开数据驻留。GDPR 要求个人数据出境有合法性基础，印尼的 PDP Law（2022 年第 27 号法）和越南的 Decree 13 对数据本地化也有要求，沙特 NCA 的 ECC 框架对日志留存和安全监控有明确条款。
这些法规落到 IPS 上，具体就是两件事：告警日志和 PCAP 存哪里、谁能访问。如果你的 IPS 部署在法兰克福，日志却统一汇总到新加坡的 SIEM，这个链路本身可能就构成数据出境。稳妥的做法是每个区域一套日志存储，只把脱敏后的统计指标（不是原始 payload）汇总到中心。
另外欧盟对员工流量的监控有额外限制，TLS 解密的范围要写进员工手册和隐私政策，不是技术上能做就能做。这块建议找当地律师过一遍，比买什么设备重要得多。
坑七：最后也是最要命的——谁来响应告警
我见过太多团队，花了几十万买设备，结果没人看告警。IPS 一天产生几千到几万条 event，没有分级、没有工单流程、没有 7x24 值班，等于买了个会闪灯的盒子。
现实一点的建议是：中小出海团队（安全人力 1-3 人）别追求「全流量全解密全检测」，先把边界做窄——只对回源流量、管理后台、支付回调这几类高价值路径做深度检测，其余走 WAF 和 CDN 的边缘防护就够了。把有限的精力放在「告警来了谁在 15 分钟内能判断真伪」这个流程上，比堆设备有用得多。
如果你问我出海场景下 IPS 到底还需不需要买，我的答案是：混合云回源、数据中心东西向、以及有硬性合规要求的场景，需要；纯公有云 + 标准 Web 业务的初创团队，先用云厂商的 WAF 和网络防火墙顶着，等业务量到了瓶颈再说。设备是手段，不是目的。