你在一台 VPS 上跑着一个 Web 应用。访问日志里全是针对 /wp-admin 的登录尝试、查询字符串中带 UNION SELECT 的请求，以及来自那些根本没理由访问你站点的数据中心 IP 段的持续流量。你想在这些明显的垃圾抵达应用之前就把它们过滤掉。
大多数人正是在这个时刻第一次接触到 WAF SaaS 这个词。对很多读者来说，"WAF"和"Cloudflare"是一回事，因为 Cloudflare 是他们最先遇到的那个。两者并不相同。WAF SaaS 是一个品类：由云端交付的 Web 应用防火墙，在服务商的边缘节点检查你的 HTTP 流量，然后再转发到你的源站。Cloudflare 只是这个品类里的一款产品。
本文将梳理 WAF SaaS 的工作方式、主流服务商的收费、它在实际使用中的短板，以及什么时候在 Linux VPS 上自建 WAF 才是更好的选择。
TL;DR（太长不看版）
- WAF SaaS 是由云端交付的 Web 应用防火墙。你要么把流量导向服务商，要么把 WAF 关联到受支持的云资源上；在受保护的应用处理请求之前，该服务会先评估 HTTP(S) 请求。
- 主流服务商的定价大致分三种形态：订阅档位（Cloudflare 和 Sucuri）、按用量计费（AWS WAF），以及销售报价（Imperva 和 Fastly）。按用量计费的成本会随处理的请求数和可选功能上升，而订阅套餐通常更可预测。
- 关于 WAF SaaS 有一份成文的批评意见，本文下面会正面回应。它指出的问题包括延迟、误报、不透明的拦截，以及数据要经过第三方。
- 在 VPS 上自建 WAF 是一个真实可行的选项。目前有势头的开源项目是 SafeLine 和 BunkerWeb 这两个。它们以反向代理的形式运行在你的应用前面。
- 如果应用自身的安全已经成熟、暴露面受控、监控到位，并且剩余风险已被记录并接受，那么完全不用 WAF 也可以是站得住脚的选择。
WAF SaaS 如何运作
发往 example.com 的请求会先抵达服务商的边缘节点，因为你的 DNS 指向那里。边缘节点终止 TLS，解析 HTTP 请求，把它送进规则引擎，然后决定转发到你的源站、直接拦截、发起质询（CAPTCHA、JavaScript 检测），或者对来源限速。如果转发，你的应用看到的请求就像来自服务商的 IP，原始客户端 IP 则通过 X-Forwarded-For 或 CF-Connecting-IP 之类的请求头带过来。
许多 WAF SaaS 产品使用由服务商托管的反向代理或边缘集成，但并非每种服务都靠改 DNS 来部署。Cloudflare、Sucuri 和 Fastly 通常位于边缘的请求路径上。而 AWS WAF 则是关联到 CloudFront，或关联到 受支持的 AWS 资源 例如 Application Load Balancer、API Gateway 的 API 以及 AppSync 的 API。无论哪种方式，HTTP(S) 请求都会在受保护的应用处理之前先被评估。
WAF 检查第 7 层数据，例如请求头、路径、查询字符串、方法、Cookie 以及配置范围内的请求体。传统网络防火墙主要在第 3、4 层依据地址、协议和端口做判断。 我们的硬件防火墙与软件防火墙对比指南 更全面地讲了两者的区别。
托管型 WAF 的防护通常来自三类规则来源：
- OWASP Core Rule Set （CRS）是面向 ModSecurity 及兼容 WAF 引擎的开源基线规则集。它覆盖了常见的攻击类别，例如 SQL 注入、跨站脚本、命令注入和本地文件包含。基于 ModSecurity 构建的产品往往会自带 CRS，而不少云服务商则改用自家的托管规则。
- 厂商托管规则集是由服务商持续更新维护的专有规则。Cloudflare 的"Managed Rules"、AWS WAF 的"AWS Managed Rules"以及 Imperva 的威胁情报源都属于这一类。
- 自定义规则是你自己写的那些。比如"拦截不是来自这个 IP 段的 /admin 请求"、"把 /api/login 限制为每个 IP 每分钟 5 次"。
一条 SQL 注入规则可能会命中查询参数或请求体里 ' OR 1=1 -- 这类熟悉的模式。这能抓住偷懒的探测，但 WAF 依然可能漏掉混淆过的载荷、逻辑漏洞，以及看起来跟正常应用流量没两样的恶意请求。它评估的是请求中可观测的信号，而不是业务意图。
说白了，它能挡住这些：
- 载荷能匹配已知特征的注入攻击
- 来自已知扫描器的机器人流量
- 简单的暴力破解模式
- 流量型 DDoS，前提是服务商同时提供 DDoS 清洗
- 基础的 API 滥用
它做不到的事：
- 替你的应用打补丁
- 替代你代码里的输入校验
- 拦下那些看起来跟正常流量一样的攻击
应用安全终究还是来自应用本身。WAF 能把面对常见攻击和自动化攻击时的下限抬高，但真正决定上限的是安全编码、及时打补丁、授权控制、输入处理、监控和事件响应。
WAF SaaS、本地硬件设备与在 VPS 上自建的对比
2026 年常见的 WAF 部署形态有三种：云端 WAF SaaS（Cloudflare、AWS WAF、Fastly 等）、物理或虚拟设备（包括 F5 和 Imperva 的产品），以及在 VPS 或自有服务器上自建的软件。
这三种形态的差别可以归到四个实际问题上：谁来运行检查层、谁为处理能力买单、谁来调规则，以及当 WAF 拦下了本不该拦的东西时会怎样。本文后面就用这四点作为比较框架。
云端 WAF SaaS
你把流量导向服务商的边缘节点，或者把 WAF 关联到受支持的云资源上。服务商负责运行检查能力和托管规则更新，你负责挑选规则、编写针对本应用的策略、调整例外。常见选项包括 Cloudflare、AWS WAF、Imperva、Sucuri 和 Fastly。
取舍在于：容量和运维成了别人的事，但每一个 HTTP 请求也都要走别人的基础设施。你的 HTTP 流量会经过服务商的基础设施，请求元数据或命中规则的载荷片段是否被记录，取决于服务商、产品和日志设置。
本地部署的硬件 WAF
一台物理或虚拟设备直接串在你的网络路径上。买家通常是那些已有成熟网络安全运维团队、容量需求固定、部署管控严格，或者原本就跟某家厂商有合作关系的组织。容量、升级、高可用和调优仍然由客户自己负责。
对不少中小团队来说，采购设备、容量固定加上运维负担，让这条路成了最不切实际的一条。但对于需要把控制面放在网络内部、并且有人手来运维的组织，它依然合适。
在自己 VPS 上自建的 WAF
你在一台 Linux VPS 上装好 WAF，把 DNS 指向这台 VPS，WAF 就以反向代理的身份坐在你的应用前面。是你在运行它。是你在调它。托管规则更新拦下一个合法请求、又没有别人可以打电话的凌晨两点，登录进去的人也是你。
目前有势头的开源项目有两个：SafeLine，一款用语义分析引擎而不是纯正则匹配的开源 WAF；以及 BunkerWeb，一款基于 NGINX、自带 ModSecurity 的 WAF。它们的许可证、部署方式和资源占用留到后面的自建章节再讲。
这里的取舍跟 SaaS 模式正好相反。检查层、容量、日志和调优都由你掌控。这降低了对第三方 WAF 服务商的依赖，但上游网络和主机商依然在承载流量。基础设施上限、带宽、打补丁和事件响应，现在都是你的事。
SaaS WAF 与在你 VPS 上自建的 WAF 对比
下面这张对比表聚焦于系统管理员真正要去运维、要去做预算的那些差别。
| 标准 | 云端 SaaS WAF | 在 VPS 上自建的 WAF |
|---|---|---|
| 谁来运行检查层 | 服务商，在网络边缘 | 你自己，在你的 VPS 上 |
| 谁为处理能力买单 | 服务商，再按订阅或按请求数向你收回 | 你自己，VPS 的固定成本 |
| 谁来调规则 | 你负责配置，托管规则更新由服务商发布 | 全程都是你自己 |
| 误报时你能做什么 | 在服务商提供的控制范围内调整规则和例外；平台层面的问题往上升级 | 自己改规则，几分钟内重新部署 |
| 数据流向 | 请求要经过服务商的检查基础设施 | 请求在抵达源站之前，先经过你自己掌控的基础设施 |
| 流量高峰时成本会怎么走 | 按用量计费的部分会随请求量上涨 | 通常更可预测，但带宽和扩容仍可能带来额外成本 |
| 运维负担 | 低，只限于配置和调优 | VPS 和 WAF 都由你自己运维 |
2026 年 WAF SaaS 的定价
WAF SaaS 的定价通常是订阅档位、按用量收费和销售报价的组合。公开价格没法直接拿来比较，因为各家把托管规则、机器人控制、日志、支持和 DDoS 功能打包的方式各不相同。
| 提供商 | 定价模式 | 起步价 | 入门档包含什么 | 注意事项 |
|---|---|---|---|---|
| Cloudflare | 订阅档位 | 免费；Pro 年付每月 20 美元、月付每月 25 美元；Business 年付每月 200 美元、月付每月 250 美元 | Free Managed Ruleset；更全面的控制项因付费套餐而异 | 购买前先核对当前的规则、限额和所含的安全功能 |
| AWS WAF | 按请求计费 | $5 per web ACL/month plus $1 per rule or rule group/month plus $0.60 per million requests | 自管规则；AWS Managed Rules 可以作为托管规则组加进来 | 额外容量、请求体检查、高级托管规则组、CAPTCHA、Challenge、Bot Control 和 Fraud Control 都可能另外收费 |
| Imperva | 企业报价 | 联系销售 | 托管规则、威胁情报和 API 安全选项 | 没有可直接比较的公开自助 WAF 价格 |
| Sucuri Platform | 订阅档位 | Basic Firewall 每月 9.99 美元；Basic Platform 每年 229 美元 | firewall 套餐提供 WAF/CDN；Platform 套装另加扫描和清理服务 | 独立的防火墙和按年计费的 Platform 套装是两个不同的产品 |
| Fastly | 通过销售洽谈 | 联系销售 | 边缘或分布式检查、托管规则和 API 防护 | 没有可直接比较的公开自助 WAF 价格 |
AWS WAF 公开各个组件的价格，Cloudflare 和 Sucuri 公开自助套餐价格。Imperva 和 Fastly 在同类 WAF 产品上采用销售报价。
截至 2026 年 7 月 29 日核对， Cloudflare 套餐价格页 上，Pro 年付为每月 20 美元、月付为 25 美元，Business 年付为每月 200 美元、月付为 250 美元。 Sucuri 防火墙价格页 lists Basic Firewall at $9.99 per month and Basic Platform at $229 per year. The firewall and platform bundles are different products. The AWS WAF figures above come from AWS WAF 定价 as of the same date.
Imperva 和 Fastly 都不公开可直接比较的自助 WAF 价格，所以把这两家当作需要联系销售的选项，不要去信第三方的估价。
AWS WAF 的定价页面 列出的基础费用是：每个 web ACL 每月 5 美元、每条规则或规则组每月 1 美元，以及每百万次处理请求 0.60 美元。额外容量、更大的请求体检查、CAPTCHA 或 Challenge 动作、高级托管规则组以及反欺诈或反机器人控制，都可能另外收费。所以攻击流量确实会推高账单，但影响多大取决于流量规模、持续时长和启用了哪些功能。基于速率的规则保护的是应用；它并不能让已经被 WAF 处理过的请求变成免费。
WAF SaaS 的短板在哪里
第一个实际限制是误报。一次正常的文件上传、API 调用或表单提交，都可能长得像攻击特征，从而触发某条托管规则。接下来运维的人就得找出命中的规则，把它收窄或加例外，再确认这个例外没有顺手开出一条更大的绕过口子。
WAF 是根据请求里的信号做判断的，而不是根据业务意图。规则太严会拦下正常流量；例外开得太宽又会削弱防护。云服务通常提供事件日志、规则覆盖和自定义响应，但你能拿到多少可见性和调优手段，因套餐和服务商而异。
专业提示。 新规则或改动较大的规则，先跑在检测模式或计数模式下。观察有代表性的真实流量，把关键流程和不常走的流程都测一遍，逐条看误报，加上范围收得很窄的排除项，然后再打开拦截。 现行的 CRS 调优指南 建议观察一到两周，或者一直到峰值流量和所有关键流程都跑过一遍为止。
第二个限制是性能开销。 2023 年的一项 ModSecurity 基准测试 测得：开启 CRS 时上传 9,462 个小文件耗时 7.36 秒，关闭时为 4.55 秒。吞吐从每秒 2,079 个请求降到 1,285 个，nginx 的 CPU 峰值则从 8 % 涨到 73 %。这只是一种配置、一种负载下的结果，所以应当把它当成「检查有代价」的佐证，而不是一个通用的容量换算比例。
第三个限制是数据流向。每一个 HTTP 请求，连同请求体，都要经过服务商的基础设施。对于处理个人身份信息、金融交易或医疗数据的应用，这就是一个实打实的数据主权问题。一个托管在欧盟、却把客户请求送经美国 WAF 服务商的应用，要交代的审计链条更重，要额外签的合同条款也更多，相比之下同一个应用如果用的是同一司法辖区内 VPS 上自建的反向代理，就简单得多。
第四个限制是调优负担。 WAF 调优面临的挑战 包括误报、缺乏应用上下文，以及规则必须跟上频繁的代码改动。这个来源是厂商视角，但它描述的运维模式是真实的：团队要么持续投入调优，要么把更多规则一直留在只检测不拦截的模式里。
同一篇 2023 年的批评文章主张，当团队把 WAF 当成不修应用的借口时，它就会沦为安全表演。这个论点对应用安全已经成熟的团队最有说服力：数据库访问参数化、授权做得扎实、定期扫描依赖、部署不可变、监控真的在用。而在成熟度还不够的环境里，WAF 确实能降低被常见自动化探测打到的概率。这两点可以同时成立。
WAF 只是纵深防御里的一层。它替代不了应用自身的安全，但也不是安全表演。对某些团队来说 WAF 的边际价值很高，对另一些团队则很低。真正决定这一点的，是底下那个应用长什么样。
什么时候自建 WAF 才划算
自建在三种情况下更划算，在另外三种情况下更吃亏。先说划算的那三种。
自建更划算的情形是：合规政策或数据主权要求不允许外部 WAF SaaS 中间方来检查流量；流量形态让按用量计费不如自己跑一套专用设施来得划算；以及团队想直接掌控拦截决策和误报的修复。
自建吃亏的情形是：根本没有运维人手；应用跑在某个托管平台上，而它的路由方式让外挂一个代理变得别扭；或者服务商托管的免费档已经用更小的复杂度覆盖了你需要的那些控制项。
对于本来就在用 Cloudflare 的 DNS 或 CDN、也接受它那套流量检查方式的中小团队来说，免费套餐是个务实的起点。而当数据流向、对规则的直接掌控，或者可预测的基础设施成本，比「少干点运维活」更重要时，自建就更有吸引力了。
SafeLine 与 BunkerWeb
有两款可以自建的开源 WAF 值得了解。
SafeLine 采用 GPL-3.0 许可，用 Docker Compose 部署，核心是语义分析而不是一套纯粹的 CRS 规则集。 SafeLine 的代码仓库 给出的数字是：Balance 模式下检出率 71.65 %、误报率 0.07 %、整体准确率 99.45 %，来自项目自己那份 33,669 个样本的评测。这是项目维护者自测的结果，不是独立的第三方基准，不应推广到那个测试集之外。
BunkerWeb 采用 AGPL-3.0 许可，底层用的是 NGINX。它把 ModSecurity 与 OWASP Core Rule Set 集成在一起，并支持多种部署方式，包括 Linux、Docker、Swarm 和 Kubernetes。
这两个项目都应该按实测的请求量、启用的防护、TLS 的工作量和日志保留时长来定容量。对于流量不高的 SafeLine 部署，2 vCPU 加 4 GB 内存是个留有余地的保守起点，高于安装的最低要求。 现行的 BunkerWeb 快速上手指南 建议：用于测试或只有很少几个服务时，至少 2 vCPU 加 8 GB 内存；生产环境要保护很多服务时，4 vCPU 加 16 GB 内存。存储主要取决于日志速率和保留时长，所以要实测，而不是许诺一个固定的月数。
专业提示。 尽量把自建的 WAF 跑在和应用源站相同的区域。代理放得远，每个请求就多一次跨区域的网络往返，会悄悄把延迟拖坏。切到生产之前，先从用户所在区域测一遍端到端的响应时间。
WAF 是你自己在运维，这意味着底下的基础设施也归你负责：可用性、安全补丁、TLS 证书、备份、日志轮转、监控、容量和恢复。故障时的行为要和过滤规则一样认真地测，别让 WAF 变成整条链路上的单点故障。
决策框架
一共四条路：Cloudflare 的免费档、付费的云端 WAF SaaS、在 VPS 上自建的 WAF，以及干脆不用 WAF。挑中每一条路的条件都不一样。
如果可用的托管规则和限额与应用的风险相称、数据流经的方式你能接受、而且首要目标就是少干运维活，那就选免费的云 WAF 档位。在断定默认配置够用之前，先拿真实的业务流程跑一遍。
当你需要的托管规则、日志、自定义控制、机器人或 API 防护、技术支持或处理能力超出免费档能给的范围时，就选付费的 WAF SaaS。要比的是具体的功能和限额清单，而不是套餐叫什么名字。AWS WAF 最占优势的场景，是应用本来就跑在受支持的 AWS 资源上，而且团队有把握预估这种按组件计费的账单。
如果前面说的那些自建条件都成立，而且你的团队能把这个代理稳稳地跑起来，那就选自建 WAF。首先值得评估的两个项目是 SafeLine 和 BunkerWeb。
当应用自身的安全已经成熟、暴露面是有意收窄的、监控扎实，并且剩余风险已被写清楚并接受时，完全不用 WAF 也是站得住脚的选择。但不能只因为框架做了输入校验，就把它当成默认答案。
结语
想让服务商包下处理能力、把运维负担降下来，就选 WAF SaaS。想要直接掌控，而且团队能把代理稳稳跑起来，就选自建。无论走哪条路，规则都要分阶段上线，延迟和误报都要实测，应用自身的安全始终排在第一位。
如果自建符合你的需求，那就从一台与源站同区域的 Linux VPS 开始。Cloudzy 还提供一键的应用市场部署，可用于 SafeLine 和 BunkerWeb，让你不用手动搭一整套底层环境就能开始测试。
在拥有 root 权限、NVMe 与 AMD EPYC 强大性能的 Linux VPS 上构建应用。
查看 Linux 套餐常见问题
什么是 WAF as a Service？
WAF as a Service 是由云端交付的 Web 应用防火墙。流量通过 DNS 或反向代理路由、边缘集成，或者关联到受支持的云资源，进入这项服务。服务商负责运行检查能力和托管规则更新；你负责挑选策略、调整例外，并补充针对本应用的规则。
Cloudflare 算是 WAF 吗？
算。Cloudflare 把 WAF 功能放在一个更大的边缘平台里，这个平台还包括 DNS、CDN 和 DDoS 防护。免费套餐会拿到 Cloudflare Free Managed Ruleset；更全的规则集、各类控制项、分析功能和机器人管理能力，则取决于你选的套餐和加购项。
Cloudflare 的免费 WAF 够用吗？
要看应用的攻击面、需要哪些规则、日志和留存的要求、API 或机器人控制、对技术支持的需求，以及你能容忍多少误报。Free Managed Ruleset 可以当个有用的底子，但有认证、有支付、有受监管的数据，并不自动等于该买某个付费套餐。把当下的功能限额逐条比一遍，再拿自己的威胁模型去验证。
WAF 和普通防火墙有什么区别？
传统网络防火墙主要靠第 3、4 层的信息来过滤流量：地址、协议和端口。WAF 则在第 7 层评估 HTTP(S) 请求，包括配置范围内的请求头、路径、参数和请求体内容。现在的安全产品有时会把这条界线弄模糊，但这两种控制手段依然是互补关系，而不是可以互相替代。
什么是 WAAP，它和 WAF 有什么不同？
WAAP 是 Web Application and API Protection 的缩写。它比传统 WAF 的范围更宽：厂商通常把 WAF 规则和 API 发现或策略执行、机器人管理，以及应用层的 DDoS、滥用防护打包在一起。具体打包了什么各家都不一样，所以别把 WAAP 当成一套标准化的功能集合。
如果框架已经做了输入校验，我还需要 WAF 吗？
不一定。框架自带的校验能降低风险，但覆盖不了所有自动化滥用的套路。只有当 WAF 能解决一个说得清楚、且值得它那份成本和调优工夫的风险时，才把它加上。
