开发者想说

“安全不应该是昂贵、封闭或让运维疲惫不堪的黑盒，而应该是一套透明、优雅且让人感到踏实的工程基础设施。”

写在前面的话

如果你正在阅读这篇文档，或许你正准备在自己的服务器上部署 CheeseWAF，或许你是在排查某个棘手的安全问题，又或许你只是一名对 Web 安全与应用架构感兴趣的同行或爱好者。

无论是哪一种，我都由衷地欢迎你。

这里没有冰冷的命令行参数、也没有晦涩的正则表达式语法，我想用自己简朴的话，和你聊聊为什么会有 CheeseWAF，以及在这个过程中我所坚持与思考的一切。

为什么要做 CheeseWAF

在确认立项并动手写下 CheeseWAF 的第一行代码前，我和许多网站运维与安全工程师一样，面对日益复杂的网络请求，在高价的商业 WAF 授权报价与传统开源项目的繁杂规则维护、误报漏报率高的困境中难以抉择。

我们常常陷入两个极端：

• 过度依赖传统正则特征：规则越堆越多，不仅维护成本成倍攀升，稍微遇到多层编码或字符嵌套就会被绕过；
• 盲目将大模型塞进实时路径：为了所谓的“智能化”，在同步反向代理链路中强行等待远程 LLM 返回，把一次简单的 HTTP 交互变成几百毫秒甚至数秒的等待，最终拖垮了整个业务系统。

我们坚信，精准性、低延迟和可维护性是数据平面的生命线，而深度的语义理解应当交给能自己解耦和自我成长学习的异步旁路。 这便是 CheeseWAF 诞生的起点——我们希望打造一款真正商用级、自包含、开箱即用的自托管 WAF，让每一位开发者和运维团队都能掌握自己的应用安全防护权，不受云端和高价商业授权束缚。

我们的设计执念

在 CheeseWAF 的演进历程中，有一些工程原则被我们视作底线：

1. 坚持单一二进制与自包含：把复杂的组件、Web 控制台和安全引擎凝聚在单一可执行文件中，无需先折腾半天数据库、中间件或外部依赖，主项目由 100% Go 语言编写，这使得 CheeseWAF 拥有先天的鲁棒性和极好的可移植性，可以在主流的 Linux、Windows、macOS 平台上直接运行。不仅如此，我们还兼容了龙芯架构（LoongArch），原生支持搭载国产龙芯芯片的设备上正常运行。
2. 请求路径绝不妥协：最快微秒级处理的请求检测管线源于清晰的抽象语法树（AST）语义解析，根据设备性能参数实时调优的检测管线，经过无数次打磨的 GC 调优和硬件加速，只在追求极致的性能与并发。
3. 把选择权交还给操作者：从防护等级（Paranoia Level）的逐级推进，到大模型研判结果的自动采纳，你可以在 AI 自动操作和告警人工审批中自主选择，最终防线的掌控和话语权永远在你手中。

给使用者的一封信

做一款严肃的 Web 应用安全产品并不容易，它需要面对瞬息万变的网络攻击手法、复杂的现代 Web 协议演进，以及现实部署环境中的种种严苛挑战。

CheeseWAF 作为一个初来乍到、涉世未深的个人维护开源项目，仍在不断成长中。如果它在某个深夜帮你挡住了一次突如其来的恶意攻击，帮助你的网站初创团队或小公司减轻了商业化 WAF 授权或云上防护的费用，亦或者只是让你的运维工作变得轻松了一点，觉得用起来还算顺手，那便已是我最大的荣幸。

欢迎有任何想法、批评或者建议的用户们通过 GitHub Issues 或 邮箱（[email protected]） 与我交流。

最后，由衷感谢您对 CheeseWAF 的认可和信赖，也致敬每一个热爱开源与安全技术的你。