云 WAF 与单机 WAF 的区别：一篇讲透选型思路的技术大纲

摘要：本文系统对比云 WAF 与单机 WAF 两种部署形态，从基础概念、架构与接入方式、核心防护能力、成本与运维、典型适用场景五个维度展开分析。云 WAF 以 SaaS 化、DNS/CNAME 接入和边缘节点清洗为特征，具备分钟级接入、弹性扩容和托管运营优势；单机 WAF 以本地串接、旁路镜像或反向代理方式部署，在数据不出域、超低时延和强合规场景中不可替代。文章还给出云 WAF 接入实操要点、选型决策流程图与场景对照表，帮助读者按业务形态与合规要求做出组合选型，而非简单二选一。

一、引言：为什么需要区分云 WAF 与单机 WAF

从 Web 攻击面变化切入，说明 WAF 在应用安全防护中的定位，并点明部署形态差异带来的能力、成本与运维方式差异。

• Web 攻击的常见类型与防护诉求
• WAF 的核心价值：拦截、审计、合规
• 本文要回答的问题：两者到底差在哪，什么场景该选谁

二、基础概念与形态界定

2.1 什么是 WAF

说明 WAF 的工作层次（应用层）、常见检测手段（规则匹配、语义分析、机器学习）与部署位置。

2.2 云 WAF 的定义与典型形态

以 SaaS 化、DNS 或 CNAME 接入、边缘节点清洗为主要特征。

2.3 单机 WAF 的定义与典型形态

以软件或硬件设备形式部署在本地，串接或旁路在业务链路中。

2.4 概念边界澄清

• 云 WAF 与云上自建 WAF 的区别
• 单机 WAF 与反向代理类防护组件的区别
• 与 CDN、负载均衡、API 网关的关系

三、架构与部署方式对比

3.1 云 WAF 的架构

边缘节点、调度中心、规则下发、日志回流等模块的协作关系，可用一张流程图说明流量路径。

flowchart LR U[用户浏览器] -->|1. 发起请求| DNS[DNS / CNAME 解析] DNS -->|2. 解析到 WAF 边缘节点| E1[边缘节点 A<br/>规则匹配 + CC 防护] DNS -->|2. 就近调度| E2[边缘节点 B<br/>规则匹配 + CC 防护] E1 -->|3. 清洗后回源| O[源站业务集群] E2 -->|3. 清洗后回源| O E1 -.->|日志回流| C[调度与规则中心] E2 -.->|日志回流| C C -.->|规则下发| E1 C -.->|规则下发| E2 O -.->|回源 IP 白名单| E1

图注：用户请求先经 DNS/CNAME 解析到就近的边缘节点，由边缘节点完成规则匹配、CC 防护与恶意流量清洗，仅将合法流量回源至业务集群；调度与规则中心负责统一下发规则并回收日志，源站则通过回源 IP 白名单确保只有 WAF 节点可直连，避免被绕过。

3.2 单机 WAF 的架构

串接模式、旁路镜像模式、反向代理模式的差异与适用条件。

flowchart TB subgraph M1[串接模式] A1[用户] --> W1[单机 WAF<br/>在线阻断] --> S1[业务服务器] end subgraph M2[旁路镜像模式] A2[用户] --> SW[交换机] --> S2[业务服务器] SW -. 镜像流量 .-> W2[单机 WAF<br/>仅检测告警] end subgraph M3[反向代理模式] A3[用户] --> W3[单机 WAF<br/>代理转发 + 清洗] --> S3[业务服务器] end

图注：串接模式将 WAF 直接串入链路，可实时阻断但存在单点故障风险；旁路镜像模式通过交换机镜像流量做旁路检测，只告警不阻断，对业务零影响；反向代理模式由 WAF 终结连接并代理转发，兼具清洗与隐藏源站能力，但需承担全部转发性能压力。

3.3 接入方式对比

3.4 云 WAF 接入实操要点

云 WAF 的接入本质是一次 DNS 解析权的迁移，看似只是改一条 CNAME 记录，实际涉及 TTL 预调、灰度切流、回源白名单、源站收敛与回滚预案等多个环节。下面按可执行顺序给出操作流程，每一步都附上检查项，建议在变更窗口内逐项打勾后再进入下一步。

1. 第一步：接入前评估与备案

   梳理待接入域名清单、业务归属方与流量规模，确认 WAF 实例规格、防护带宽与计费方式能够覆盖峰值；同时确认域名已完成 ICP 备案，且证书可导出或支持托管。

   • 检查项：域名清单与业务负责人已确认，无遗漏子域名。
   • 检查项：WAF 实例的防护带宽、QPS 规格不低于当前峰值并留有余量。
   • 检查项：HTTPS 证书已上传至 WAF 或确认可自动签发，证书有效期覆盖切换窗口。

2. 第二步：预调低 DNS TTL

   在正式切换前至少提前一个原 TTL 周期（建议提前 24 至 48 小时），把域名 TTL 调整为 60 至 300 秒。这样切换后各地递归 DNS 能快速收敛，回滚时同样能快速生效。

   • 检查项：权威 DNS 中 A/CNAME 记录的 TTL 已改为 300 秒以内。
   • 检查项：已等待超过原 TTL 时长，确认旧缓存基本过期。
   • 检查项：记录变更前的解析结果已截图存档，作为回滚依据。

3. 第三步：配置回源 IP 白名单与源站安全组收敛

   先在源站侧放行 WAF 回源 IP 段，再逐步收敛源站安全组，只允许 WAF 回源地址访问 80/443 端口，避免攻击者通过真实 IP 直连绕过防护。收敛动作应在解析切换之前完成，但保留原有入口一段时间作为回滚通道。

   • 检查项：WAF 控制台提供的回源 IP 段已完整加入源站防火墙或安全组。
   • 检查项：源站安全组已限制公网直接访问 80/443，仅放行 WAF 回源段与运维跳板机。
   • 检查项：源站真实 IP 未在证书透明日志、历史 DNS 记录或邮件头中泄露，必要时评估更换 IP。

4. 第四步：灰度切流

   不要一次性切换全部流量。优先选择低峰时段，从非核心子域名或小比例流量开始，例如先切测试域名或按地域、按权重逐步放量，观察回源成功率、时延与拦截日志后再扩大范围。

   • 检查项：灰度域名解析已指向 WAF 提供的 CNAME，且解析结果符合预期。
   • 检查项：WAF 侧已开启观察模式或宽松规则，避免上线即误拦截。
   • 检查项：灰度期间源站访问日志中出现来自 WAF 回源 IP 的请求，说明链路已打通。

5. 第五步：切换后验证

   全量切换后需要从多个维度验证业务可用性与防护有效性，包括解析生效范围、HTTPS 握手、核心接口返回、静态资源加载以及攻击拦截效果。

   • 检查项：多地 dig 或在线拨测确认解析已全部指向 WAF，无残留旧记录。
   • 检查项：核心页面与关键 API 返回码正常，登录、支付等主流程可走通。
   • 检查项：WAF 控制台可见实时请求与攻击日志，拦截规则按预期生效。
   • 检查项：源站带宽与连接数下降，说明流量确实经过 WAF 清洗。

6. 第六步：回滚预案

   切换前必须准备好可一键执行的回滚方案：保留原解析记录，明确回滚触发条件与决策人，并确认回滚后源站安全组能同步放开原入口。

   • 检查项：原 A 记录或源站入口信息已备份，回滚操作步骤已书面化。
   • 检查项：已定义回滚触发条件，例如错误率超过阈值、核心接口不可用持续 5 分钟以上。
   • 检查项：回滚演练已在测试域名上验证通过，回滚后源站安全组同步调整。

切换期间如何避免业务中断：核心思路是让新旧链路在一段时间内并存，而不是做非此即彼的硬切换。具体做法包括：把 TTL 提前调低，使解析变更与回滚都能在分钟级收敛；采用灰度放量而非全量切换，先小流量验证回源链路与规则效果；在 WAF 侧先以观察模式运行，确认无误拦截后再开启阻断；源站安全组收敛与解析切换分步进行，保留原入口作为回滚通道；同时安排业务、运维与安全三方在变更窗口内联合值守，实时盯住错误率、时延与拦截日志，一旦触发回滚条件立即执行预案。这样即使某一环节出现问题，也能在影响面扩大之前快速恢复。

四、核心能力对比

4.1 防护规则与检测能力

规则更新频率、0day 响应速度、自定义规则灵活度。

4.2 性能与容量

云 WAF 的弹性扩容与共享带宽，单机 WAF 的硬件上限与性能瓶颈。

4.3 高可用与容灾

云 WAF 的多节点冗余与故障切换，单机 WAF 的单点风险与双机热备方案。

4.4 日志、审计与可视化

日志留存周期、报表能力、与 SIEM 的对接方式。

4.5 数据主权与合规

流量是否出网、敏感数据是否经过第三方节点，是合规场景的关键考量。

五、成本与运维对比

5.1 成本结构

• 云 WAF：订阅费用、流量费用、增值功能费用
• 单机 WAF：设备采购、许可、机房与带宽、人力运维

5.2 运维复杂度

规则调优、误拦截处理、版本升级、应急响应的责任边界差异。

5.3 隐性成本

割接风险、故障定位链路变长、跨团队协作成本。

六、典型适用场景

6.1 适合云 WAF 的场景

• 业务已上云、域名可灵活解析
• 流量波动大、需要弹性防护
• 安全团队人力有限，希望托管运营

6.2 适合单机 WAF 的场景

• 内网系统、无法暴露公网解析
• 数据不出域的强合规要求
• 超低时延要求的核心交易链路

6.3 混合部署思路

边缘云 WAF 做通用防护，核心链路本地 WAF 做深度防护的分层策略。

七、选型决策清单

给出一组可勾选的问题，帮助读者快速判断：

1. 业务域名是否可自由切换解析？
2. 是否存在数据不出网或等保合规约束？
3. 峰值 QPS 与带宽规模如何？
4. 安全团队是否具备规则运营能力？
5. 可接受的故障恢复时间是多少？

flowchart TD S[开始选型] --> Q1{域名是否可自由切换解析？} Q1 -->|否| R1[单机 WAF<br/>本地部署，不依赖公网解析] Q1 -->|是| Q2{是否存在数据不出网<br/>或等保合规约束？} Q2 -->|是| Q3{核心链路是否同时需要<br/>通用防护与深度检测？} Q3 -->|是| R3[混合部署<br/>边缘云 WAF + 本地 WAF] Q3 -->|否| R1 Q2 -->|否| Q4{峰值 QPS 与带宽规模<br/>是否波动大或难以预估？} Q4 -->|是| R2[云 WAF<br/>弹性扩容，按量付费] Q4 -->|否| Q5{安全团队是否具备<br/>规则运营能力？} Q5 -->|否| R2 Q5 -->|是| Q6{可接受的故障恢复时间<br/>是否以秒计？} Q6 -->|是| R1 Q6 -->|否| R2

图注：流程图按“先合规、后能力、再成本”的顺序逐层判断。第一层看域名能否自由切换解析，不能切换则直接落到单机 WAF；第二层看是否存在数据不出网或等保合规约束，存在时若核心链路还需通用防护与深度检测叠加，则选混合部署，否则选单机 WAF；第三层看峰值 QPS 与带宽是否波动大或难以预估，波动大则优先云 WAF 的弹性能力；第四层看安全团队是否具备规则运营能力，人力不足时交由云 WAF 托管运营更稳妥；最后一层看可接受的故障恢复时间，若要求以秒计且链路时延敏感，则回到单机 WAF 双机热备方案。需要强调的是，该图给出的是默认判断路径，实际选型仍应结合第六节的场景清单与上表逐项核对。

把上面的问题与下表对照，可以更快落到具体形态。下表覆盖第六节提到的典型场景，并给出对应的推荐形态与理由：

需要说明的是，表中推荐形态是默认起点而非硬性结论。当同一业务同时存在“域名可切换”与“数据不出域”两类约束时，应优先满足合规底线，再考虑用混合部署补齐通用防护能力。

八、常见误区与避坑建议

• 认为上了云 WAF 就无需本地防护
• 忽视回源 IP 白名单导致绕过
• 只关注拦截率，忽略误报对业务的影响
• 单机 WAF 上线后长期不更新规则

九、总结

归纳两者在架构、能力、成本、合规上的核心差异，强调按业务形态与合规要求做组合选型，而非简单二选一。