为什么我在2026年把部分流量从 Cloud WAF 移走

Source: Dev.to

（请提供需要翻译的正文内容，我将为您翻译成简体中文并保持原有的格式。）

大多数人使用的默认架构

如果你现在运行的是典型的网络服务，架构大概是这样的：

Internet
   │
   ▼
Cloud WAF / CDN
   │
   ▼
Origin server
   │
   ▼
Application

好处

• 隐藏了源站 IP
• 大规模 DDoS 防护
• 全球缓存
• 自动 WAF 规则

云 WAF 也很容易部署，因为流量只需经过代理网络——通常只需要一次 DNS 更改。对于公共网站和 API 来说，这种便利性很难被超越。

然而，在使用这种架构运行了多个服务后，我开始遇到一些模型并不理想的边缘情况。

问题 1 – 并非所有服务都应放在 CDN 后面

首个问题出现在我们开始处理 非传统网络流量 时：

• 通过 VPN 暴露的内部仪表盘
• 开发者工具
• webhook 端点
• 大文件上传
• 内部 API

这些工作负载的行为与公共网站不同。它们通常涉及：

• 已认证的客户端
• 大请求体
• 长连接
• 异常的请求头或协议

针对 CDN 优化的 WAF 可能会显得不太合适。例如，许多 WAF 引擎仅检查到一定大小的请求体（取决于套餐）。这对普通网页流量来说没问题，但如果你的应用经常处理 大负载，你可能会发现安全层只进行部分检查或绕过某些检查。

问题 2 – “黑盒子”问题

云安全平台功能强大——但它们也 抽象化。你通常只能看到：

• 仪表盘
• 规则切换
• 聚合日志

……但很少能看到 原始请求行为 的细节。在调试攻击流量时，我经常需要回答以下问题：

• 是哪个精确的负载触发了规则？
• 请求体是什么样的？
• 是哪个扫描器生成的？
• 请求被阻止前发生了什么？

云仪表盘通常只显示 决策结果，而不是完整的上下文。这种抽象是有意为之——它让事情更简单——但有时你想要更多的控制。

问题 3 – 将所有流量通过单一网络的成本

当所有流量都通过云 WAF 时，以下组件会紧密耦合：

• DNS
• 流量路由
• 安全
• 缓存
• （有时）负载均衡

大多数情况下这样没问题，但有时你需要灵活性，例如：

• 临时暴露某项服务
• 直接路由特定流量
• 运行私有端点
• 在没有代理层的情况下测试基础设施

当单一边缘网络拥有所有这些部分时，这些实验就会变得更困难。

我最终采用的混合方案

与其完全移除云端 WAF，我最终采用了 分层架构：

Internet ─────► Cloud WAF / CDN ─────► Public Web Apps
                     │
                     ▼
               Internal Gateway
                     │
                     ▼
               Self‑Hosted WAF Layer
                     │
                     ▼
                    Services

公共流量仍然走边缘网络，而部分服务则绕过该网络，直接通过本地安全层。该方案保留了云边缘的优势——全球性能、强大的 DDoS 防护、便捷的缓存——同时为 专用服务 提供了更多的控制权。

本地自托管 WAF 仍然出彩的地方

当我再次开始尝试本地过滤层时，我想起了在云 WAF 取代之前它们为何如此受欢迎。自托管的 WAF 直接位于你的基础设施中：

Internet
   │
   ▼
Reverse Proxy + WAF
   │
   ▼
Application

这种部署方式为你提供了云平台并不总能提供的优势：

完整请求可视化

• 原始负载
• 请求头
• 请求体
• 完整流量日志

这使得调试攻击要容易得多。

精细化控制

因为它运行在你的环境中，你可以实现如下规则：

• 针对特定端点的策略
• 按服务的速率限制
• 基于内部逻辑的行为规则

云 WAF 支持自定义规则，但通常受限于平台约束。自行部署一层可以消除这些限制。

本地流量过滤

许多攻击根本不需要到达你的应用程序。常见的探测包括：

GET /.env
GET /.git/config
GET /wp-login.php
GET /phpmyadmin

本地 WAF 可以立即拦截这些请求，而无需经过上游服务。

我在自托管 WAF 中寻找的特性

在尝试了几种方案后，我发现对小团队来说最有用的功能其实相当简单：

• 机器人挑战
• 请求过滤
• 速率限制
• 良好的流量可视性

你并不一定需要企业级的安全设备；只需要一个能够位于服务前端、帮助降低噪音的工具即可。

最近我在实验 SafeLine WAF，它将这些功能打包成一个相对易于运行的自托管系统。有趣的地方并不是它取代了云 WAF，而是它能够很好地融入上文描述的 混合模型，为那些不适合通过 CDN 的流量提供安全层。

如果你感兴趣，可以查看他们的网站。

Safepoint Cloudline 已上线：

当你绝对应该坚持使用云 WAF 时

明确地说，云 WAF 在许多情况下仍然是最佳选择。

如果你的应用是：

• 公开网站
• 全球 SaaS 产品
• 高度可缓存
• 全球范围内对延迟敏感

那么边缘网络的优势是巨大的。像 Cloudflare 这样的提供商的全球规模是本地无法复制的。

最终思考

从运行生产服务中得到的最大教训是 安全架构很少保持静态。对小型 Web 应用有效的方案未必适用于：

• 内部工具
• APIs
• 大文件上传
• 专用基础设施

云 WAF 为开发者解决了许多问题，但它们也引入了一种新模式： 所有流量都通过边缘网络。

• 有时这很完美。
• 有时则不尽如人意。

对我而言，解决方案并不是在两种模型之间做出选择，而是 在适当的地方同时使用两者。