「如果应用本身存在安全漏洞，却把安全希望完全寄托在 WAF 上，这就像把房子的门锁交给邻居保管一样危险。」

这句话来自 Hacker News 上一篇关于 Cloudflare WAF 的讨论，犀利又扎心。事情的起因是一个看似普通的配置问题，却引发了技术社区对「安全边界」的深度思考。

---

一个「合法」的绕过路径

事情的核心很简单：Cloudflare 的 Web 应用防火墙（WAF）在处理 .well-known/acme_challenge 这个路径时，存在一个特殊规则——它会放行这个路径的请求，让其直达源服务器。

为什么要有这个例外？因为 ACME 协议在申请 SSL 证书时，需要通过 HTTP-01 挑战验证域名所有权。证书颁发机构（CA）必须能够访问这个特定路径来获取验证文件。如果 WAF 拦截了它，证书申请就会失败。

但问题来了：如果攻击者知道这个「绿色通道」，他们能否利用它来绕过 WAF 的其他防护规则？

答案是：可以。

Next.js 的「404 页面秘密」

讨论中最让人哭笑不得的例子来自 Next.js 应用。有开发者把一些「内部配置变量」放在 404 页面上——这些信息对内部员工无害，但对外暴露就可能出问题。他们依赖 Cloudflare WAF 来过滤外部访问。

结果呢？当请求走 .well-known/acme_challenge 路径时，WAF 的规则被绕过，这些本应隐藏的信息直接暴露给了外界。

评论区有人吐槽：「这就像在后门挂了个『维修通道』的牌子，然后惊讶地发现小偷从这里进来了。」

为什么 Cloudflare 要「特殊照顾」这个路径？

这是讨论中最有意思的部分。有专家质疑：「用户完全可以自行设置缓存控制头，避免缓存问题，为什么 Cloudflare 要为这个路径单独设置规则？」

推测的原因是：早期用户在使用 ACME 协议时，经常因为 CDN 缓存了验证文件而导致证书申请失败。Cloudflare 为了「用户体验」，选择为这个路径开后门。

但这个「善意」的设计，反而成了安全隐患的源头。

相比之下，像 Caddy 这样的 Web 服务器默认就能正确处理该路径，不会将其转发到后端应用，从根本上避免了这个问题。根据 Caddy 官方文档，它内置了对 ACME 协议的支持，能够自主处理证书验证流程。

HTTP-01 的「古老」限制

更让人惊讶的是，HTTP-01 挑战必须使用 HTTP 协议，不能用 HTTPS。这是 ACME 协议的硬性规定——验证过程必须走 80 端口，且不能强制跳转到 HTTPS。

根据 Let’s Encrypt 官方文档，HTTP-01 验证明确要求使用明文 HTTP，这是为了确保证书颁发机构能够无障碍地访问验证文件。如果 80 端口被防火墙封锁，整个验证流程就会失败。

这也是为什么很多用户会选择 DNS-01 挑战——它不需要开放 Web 服务端口，只需在 DNS 记录中添加一条 TXT 记录即可。SSL.com 的对比文章 详细解释了两种验证方式的适用场景。

想想看：在 2026 年，我们还在为一个必须使用明文 HTTP 的验证机制设计特殊规则。这就像在高铁时代，为了兼容马车而保留一条土路。

WAF 不是「万能盾牌」

这场讨论最核心的共识是：WAF 不能替代应用自身的安全设计。

有评论指出，如果企业将 Cloudflare WAF 当作「零信任」解决方案（类似 Google IAP 的机制），那可能面临风险。但 Cloudflare 本身有专门的零信任产品，与 WAF 功能完全不同，不应混淆使用。Cloudflare Teams 计划 提供了完整的零信任网络访问（ZTNA）功能，与传统 WAF 的定位截然不同。

一位资深安全工程师总结道：「真正的安全不是靠单一防护层，而是多层防御。WAF 可以作为辅助，但绝不能替代应用自身的安全设计。」

这就像现代银行的安全体系：不仅有大门保安（WAF），还有内部监控、金库密码、员工权限控制等多层防护。依赖单一机制来掩盖应用漏洞，往往会导致「假安全」的错觉。

根据 Fortinet 的 WAF 介绍，WAF 主要用于拦截 SQL 注入、跨站脚本（XSS）等常见 Web 攻击，但它无法防御所有类型的安全威胁，特别是那些源于应用逻辑本身的漏洞。

延伸思考：自动化带来的新挑战

ACME 协议的出现，让 SSL 证书申请从「需要 1-2 天的手动流程」压缩到「几分钟自动完成」。工具如 acme.sh 只需简单指令就能完成整个流程：

acme.sh --issue -d example.com --webroot /var/www/html

根据 acme.sh 官方指南，这个工具能够自动处理账户注册、域名验证和证书签发的全过程，极大简化了运维工作。

但自动化也带来了新问题：配置错误、权限不当、频繁请求触发速率限制等。根据 Let’s Encrypt 的速率限制说明，过度频繁的证书申请请求会被暂时封禁，需要开发者特别注意操作规范。

安全不是「设置完就忘记」的事情，而是需要持续关注和调整的过程。

结语

这场讨论提醒我们：网络安全的关键在于整体架构设计。无论是 WAF、零信任、还是证书自动化，每一种工具都有其适用场景和局限性。

把敏感信息放在 404 页面，然后指望 WAF 来保护它——这种做法本身就值得反思。真正的安全，应该从代码层面开始，贯穿整个开发和运维流程。

正如一位 Hacker News 用户所说：「安全不是产品，而是过程。」