BunkerWeb开源WAF实战：部署、规则与运维全指南

开箱之后我先给结论：BunkerWeb 是一个可以自托管、代码开源、配置相对灵活的 Web 应用防火墙，也可以当作一个轻量 WAAP 入口来用。它适合个人站点、中小项目、科研机构，以及需要把 WAF 权限掌握在自己手里的团队；不适合那种完全没人维护、不想看日志、买了就想自动解决一切的人。下面我会按真实上线顺序，把部署、验证、规则、日志、运维、排查这些环节完整拆一遍。

1. BunkerWeb 定位：从开源 WAF 到 WAAP 入口

1.1 先分清 WAF 和 WAAP 的差别

很多人把 WAF 和 WAAP 混着叫，实际两者能力范围不一样。WAF 的职责更聚焦，主要是把 HTTP/HTTPS 流量过滤一遍，拦截常见的注入、跨站脚本、恶意请求特征等；WAAP 则是在 WAF 之上叠加了更多应用层防护能力，比如 API 防护、Bot 管理、限流、身份认证、数据风控、异常行为分析，甚至包括 DDoS 缓解层面的配合方案。

BunkerWeb 本身是基于 NGINX 扩展出来的开源安全代理，所以它天然具备反向代理、TLS 终止、静态资源服务这类基础能力，同时又在应用层做了很多安全扩展。它既能按传统 WAF 的思路去理解，也可以按 WAF 加反向代理加基础 WAAP 能力的方向去使用。实际部署时，你完全可以让它承担入口代理和安全网关两个角色。

1.2 谁能直接用，谁不能

先把自己代入场景再决定是否引入，这比折腾完再卸载重要得多。

适合的场景有这几类：

1. 你有一个或若干 Web 应用，希望统一入口收流量，再统一做访问控制和安全过滤。
2. 你不想把所有配置都暴露在商业云控制台里，希望规则、日志、证书、访问策略都在自己的机器上管理。
3. 你有等保或内部合规整改需求，需要在边界上明确有自己的 WAF 设备或服务，同时日志能够留存和追溯。
4. 你想学习 WAF 工作原理，想在本地跑一套真实规则集，看规则怎么命中、日志怎么落地。

不适合的场景也明确：

1. 你完全没有运维意识，只打算部署完以后不管，等出问题再说。
2. 你的业务本身逻辑漏洞一大堆，比如登录没限流、订单金额可改、权限校验缺失，这类问题不是 WAF 能修复的。
3. 你的团队没人会看 NGINX 日志或容器日志，遇到 502 都分不清是后端问题还是 WAF 问题。
4. 你希望免费版提供商业级服务保障，那这不现实，开源软件需要自己投入人力和时间。

1.3 开源免费不等于免运维

这一点要放在最前面说清楚。

BunkerWeb 的社区版可以自己下载、自己部署，没有授权成本，这是它的优势。但它没有商业产品那种“打电话有人帮你看”的服务体系。你获得的是代码、文档、配置能力和社区生态，同时也要承担版本升级、规则更新、日志备份、证书续期、故障排查这些责任。

如果团队里至少有一个人能看懂日志，能操作 Docker 或 Linux，再选它。如果完全没有，那更稳妥的做法是选托管型 WAF 或商业 WAAP 服务。

2. 部署前先把运行条件定下来

2.1 常见运行方式有哪些

BunkerWeb 的部署方式比较灵活。官方经常用的是容器化部署，适合单机和小集群；也支持基于 Linux 的安装方式，适合不想用 Docker 的环境；在 Kubernetes 或类似容器编排环境里也有对应的接入方案。普通入门阶段，我建议先用 Docker Compose 跑一个最小实例，不要一上来就上集群。

这样做的原因很直接：第一次测试的目的不是验证所有功能，而是确认三件事能不能成立，即容器能不能正常启动、域名配置能不能生效、日志能不能看到。如果这三件事都没问题，后面再扩展 UI、数据库、API 都不难。

2.2 资源要按“规则引擎会吃 CPU”来预估

很多人在部署 Web 项目时习惯只关注容器数量和端口，忽略资源预算。WAF 和普通反向代理的差别在于多了一层规则匹配，规则越多，CPU 消耗越明显。

给一个通用参考区间：

这里没有写具体版本要求，因为原始材料没有提供明确指标，实际参数要以你的环境和 BunkerWeb 当前版本为准。我一般会先按保守值给，再根据压测调整。

还有一点必须注意：WAF 不需要 GPU，也没有显存需求。搜索词里有人把 WAF 和模型推理混在一起讨论，那是赛道搞错了。如果一家公司说 WAF 需要依赖显卡，你要先怀疑是不是借安全名义卖算力。

2.3 网络和端口边界先确认

BunkerWeb 默认处理 HTTP 和 HTTPS，最常涉及的端口是 80 和 443。部署前需要确认以下几点：

• 服务器防火墙是否放行对应端口。
• 域名解析是否已经指到当前机器。
• 80 或 443 端口是否已经被其他服务占用。
• 如果前面还有云负载均衡、CDN 或云防火墙，是否需要设置回源白名单。
• 内网部署时，是否需要把管理端口单独隔离。

建议先在测试域名上操作，确认逻辑无误后再切换正式域名。不要一上来就把主域名解析到新部署的 WAF，然后一边看 502 一边怀疑人生。

2.4 数据目录和日志归属提前规划

日志是 WAF 的生命线。没有日志，你无法判断拦截是否有效，也无法在攻击事件或合规检查时提供证据。

部署之前先找一个稳定的目录，比如/opt/bunkerweb，在这个目录下建数据文件夹和配置文件夹。容器启动后需要把日志目录持久化到本地，否则容器一重启，所有访问记录和拦截记录就没了。

常见等保整改中，WAF 日志留存时间通常按半年以上准备。具体留存周期应以你正在应对的检查要求为准，但至少要做到“日志不因容器重启而丢失，能导出，能备份”。

3. 用 Docker Compose 搭一套最小可运行实例

3.1 先准备目录结构

我会在 Linux 服务器上做示例。Windows 和 macOS 也可以按同样的思路跑，只是路径和权限处理方式不同。

mkdir -p /opt/bunkerweb/bw-data mkdir -p /opt/bunkerweb/config cd /opt/bunkerweb

我一般会把配置目录单独拆出来，方便以后用 Git 管理版本，也方便做备份。不要把配置和容器卷混在一个不可追踪的目录里。

3.2 最小 compose 配置示例

下面是一个通用示例，只用于跑通最小链路。实际部署时请按官方文档的当前版本要求补充环境变量，不要把示例当作生产环境完整配置。

services: bunkerweb: image: bunkerweb/bunkerweb:stable restart: unless-stopped ports: - "80:80" - "443:443" environment: SERVER_NAME: www.example.com MULTISITE: "no" AUTO_LETS_ENCRYPT: "yes" USE_MODSECURITY: "yes" USE_MODSECURITY_CRS: "yes" volumes: - /opt/bunkerweb/bw-data:/data - /opt/bunkerweb/config:/etc/bunkerweb/configs

这段配置有几个关键点：

• 镜像标签没有写死版本号，实际使用时应该固定到你确认过的稳定版本，避免升级导致行为变化。
• SERVER_NAME需要改成你的实际域名。
• USE_MODSECURITY和USE_MODSECURITY_CRS表示是否启用 ModSecurity 和 OWASP 核心规则集，第一次测试可以开，但要做好误报准备。
• 映射到宿主机端口后，外部流量才能进入 WAF。
• 数据目录和配置目录已经持久化，容器重建后数据不会丢。

这里有个容易误解的地方：默认启动一个容器，不等于所有安全功能都已开启。BunkerWeb 很多能力是通过环境变量和配置来控制开关的。如果你只是把容器拉起来，没有正确配置站点，很可能出现“反向代理通了，但安全规则没生效”的情况。

3.3 启动和首次验证

执行启动命令：

docker compose up -d docker compose ps docker compose logs --tail=100 bunkerweb

正常启动后，应该能看到容器处于 running 状态，而不是反复重启。日志里有启动配置加载的记录，而不是一串报错循环。

第一次验证不要直接开浏览器，先跑命令行：

curl -I http://localhost/

如果能拿到 HTTP 响应头，说明配置加载没出大问题。如果你的站点配置了 HTTPS 但证书还没申请成功，访问http://localhost可能得到重定向或证书相关报错，这是正常现象。先确认 HTTP 状态、响应头、域名配置，再处理证书。

3.4 UI 和 API 模式可以晚点再上

BunkerWeb 除了无界面轻量模式，也支持用管理界面统一管理。UI 模式适合多站点管理、规则查看、日志可视化更频繁的团队，但它不是一个必需项。

我的建议是，第一轮只跑无 UI 的最小实例，把所有精力放在“站点能通、日志能看、拦截能生效”这三件事上。等基础链路稳定后，再去接 UI 或数据库，不要一开始就堆服务组件。否则出了问题，你无法判断是 WAF 的问题还是数据库的问题。

4. 第一次验证到底怎么测，才能证明 WAF 在工作

4.1 先测正常请求，再测可疑请求

很多人在部署 WAF 后，第一件事就是拿真实用户流量去压。这是不对的。WAF 上线验证有一个固定顺序：先证明正常流量能通过，再证明异常流量能拦截。

正常请求验证：

curl -I "http://localhost/?page=home" curl -I "http://localhost/static/style.css"

如果正常页面返回 200，静态资源也能正常访问，说明反向代理链路是通的。如果这里就出现 404 或 502，先排查后端的站点配置和 Web 应用本身，不要急着怀疑安全规则。

4.2 用本地规则样本验证拦截

接下来构造一个包含典型攻击特征的可疑请求。注意，这是在你自己的测试环境和自己的实例上进行安全验证，不是对他人系统发起攻击。

curl -I "http://localhost/?id=1%27%20OR%20%271%27%3D%271" curl -I "http://localhost/?q=<script>alert(1)</script>"

如果规则集生效，这类包含 SQL 注入或 XSS 特征的请求大概率会被拦截，返回的状态码通常是 403、406 或类似的拒绝状态，同时日志里会留下拦截记录。

这里要特别说明：不同版本、不同规则集、不同默认策略下，具体返回码可能不一样。判断标准不是“必须返回某个固定状态码”，而是“请求应被 WAF 阻断，并且在日志中能查到原因”。

如果所有可疑请求都顺利通过，说明规则没有完全生效。这时不要先怀疑规则不够强，应该先检查 ModSecurity 是否启用、规则集是否加载、站点域名是否匹配，以及日志里有没有加载错误。

4.3 用日志确认拦截结果

验证不能被“好像拦截了”这种印象带过去，一定要落到日志。

常用命令：

docker compose logs --tail=200 bunkerweb

也可以进入容器或输出目录查看访问日志和错误日志。好的 WAF 部署，日志里应该能同时看到正常请求、被拦截请求、规则命中的标识、客户端 IP、请求路径、返回状态码等字段。

如果日志里没有拦截信息，说明请求可能没有进入 WAF 的规则处理链，或者请求走到了另一个不经过 WAF 的路径。

4.4 不要把验 WAF 当成攻击练习

这是必须明确的一条边界。

验证 WAF 的前提是“你拥有该系统或已经获得测试授权”，范围也只能限制在测试环境内部。网上很多围绕“绕过”展开的讨论，对真实防御团队来说没有多大价值。相反，真正值得关注的是：规则为什么没有命中、误报为什么变多、日志为什么缺失、告警渠道是否及时。一个能主动发现并确认误报的 WAF 使用方，比一个整天研究绕过技巧的人更接近真实安全能力。

5. 从基础 WAF 到 WAAP 能力：代理、认证、限流与 API 防护

5.1 反向代理和 TLS 管理是基础能力

BunkerWeb 放在站点前端后，用户请求不再直接到达后端 Web 服务器，而是先经过 BunkerWeb，再由它转发给后端应用。这一层本身就是收益：后端 Web 服务可以不直接暴露公网，减少攻击面。

同时，HTTPS 证书的申请和续期也可以放到这一层处理。域名通过自动证书申请后，TLS 生命周期可以集中管理，不用每个后端服务单独处理证书。不过自动申请证书依赖域名解析正常、端口访问可达，如果网络条件不满足，建议改用自有证书或先只跑 HTTP 测试。

5.2 认证和限流不是附加功能，是安全能力

很多中小站点出问题的点，并不是被高级攻击打穿，而是业务入口太容易被人反复试探。比如登录接口没有限流、管理后台没有访问限制、敏感路径没有加认证。

WAAP 思路里很重要的一部分就是提前定义“谁能进、能进多少、能做什么”。BunkerWeb 这类开源 WAF 通常能支持：

• 按路径或站点启用基础认证。
• 配置访问规则，限制来源 IP 或地区范围。
• 配置限流策略，限制单个 IP 的请求频率。
• 对敏感接口单独做更严格的策略。

这些策略要结合你的业务特点去配置。比如登录接口的限流阈值，就不能和首页静态资源采用同一套参数。先按照业务最低要求给一个保守值，再根据实际访问日志调整。

5.3 ModSecurity 与 OWASP 核心规则集怎么配合

ModSecurity 是应用层规则匹配引擎，OWASP 核心规则集（CRS）则是社区维护的一套通用规则。BunkerWeb 可以将这两者结合，在代理层做通用 Web 攻击检测。

使用规则集时要注意一个工程问题：规则集强调通用覆盖，不等于天然适配你的业务。默认规则可能对某些业务参数产生误报，比如参数值包含特殊字符但业务上合法。上线初期建议先在测试环境观察一段时间，把误报样本整理出来，再决定是否需要调整规则等级、排除路径或关闭特定规则。

这里的节奏应该是：先开规则，再看日志，再调阈值，最后再让规则全量接入。

5.4 API 防护是现在的重点

现在很多 Web 站点的核心流量已经不是页面，而是 REST API、JSON 请求、小程序调用。API 的认证方式、参数结构、调用频率都跟传统网页请求不一样，所以只套网页 WAF 规则往往不够。

要往 WAAP 方向走，需要关注的是：

• API 路径与普通站点路径分离管理。
• 对 API 请求单独做频率限制，而不是和页面请求混在一起。
• 对请求体大小、Content-Type、JSON 结构设置边界。
• API 密钥认证与访问日志能形成追踪链路。
• 能区分正常客户端和自动化调用。

BunkerWeb 作为代理层有能力介入这些场景，但最终能不能做好，取决于你对自己的 API 流量是否清楚。先梳理出 API 的路径列表、方法、正常调用频率，再去做限制，会比凭空设定阈值靠谱得多。

6. 正式接生产前，必须先处理这份运维清单

6.1 证书来源和续期方式

如果使用自动证书申请，需要确认域名解析正确、80 或 443 端口能访问、证书续期逻辑正常。如果网站有多个域名，要分别确认每个域名都能通过验证。

如果使用自有证书，则需要规划证书文件存放位置、更新方式、重启或重载流程。证书快过期时，WAF 可能不会报错，但客户端会直接提示不安全，这种事最容易在节假日发生。

6.2 日志留存和备份策略

我需要再强调一次：日志不是可有可无的附件，而是 WAF 最重要的产物。

建议至少做到：

• 容器日志默认输出到本地目录，而不是只停留在 Docker 标准输出。
• 定期备份日志目录或日志数据库。
• 日志内容包括时间、客户端 IP、请求路径、方法、响应码、规则命中标识。
• 保留周期明确，能应对合规检查。
• 日志目录要保证足够的磁盘空间，避免写满后影响业务。

如果日志只放在容器里，容器重建后等于什么都没发生，这是最可惜的部署方式。

6.3 版本升级与回滚

开源项目迭代速度相对快，但升级不能随手docker compose pull就完事。正确的姿势是：

• 先看变更日志，确认规则和配置项是否有变化。
• 先在测试环境跑一遍同样的请求集。
• 备份当前数据目录和配置文件。
• 升级后观察 10 到 30 分钟，确认日志、站点访问、拦截行为都正常。
• 如果异常，能快速回滚到旧镜像。

建议把镜像标签固定下来，不要长期使用latest字样。否则哪天一次升级改了默认行为，线上规则突然大变，你根本来不及准备。

6.4 管理面自身的访问控制

拿到一个安全产品后，第一件事就是不要把自己的管理入口暴露到公网。

如果你需要使用管理界面或管理 API，请做到：

• 管理服务只监听内网或本机地址。
• 通过访问控制列表限制可管理 IP。
• 不使用出厂默认密码或弱密码。
• 管理日志单独保留。
• 定期检查管理端访问记录。

安全产品的管理端一旦失守，攻击者直接把规则一关，整个 WAF 就只剩下反向代理功能了。这比没有 WAF 更危险，因为你会误以为它在保护你。

6.5 灰度上线顺序

我比较推荐的顺序是：

1. 先用测试域名，部署最小实例。
2. 观察日志，确认站点访问正常。
3. 开启规则集，等一个观察周期，收集误报。
4. 挂一个低流量子域名进入真实流量。
5. 确认稳定后再切主域名。
6. 保留后端直接访问的能力作为回退方案，但日常不让流量绕开 WAF。

不要在大促前夜切换，不要在毫无准备的情况下把全部流量切进来。

7. 上线后容易踩的坑和排查顺序

7.1 常见的三个理解误区

误区一：上了 WAF 业务就安全了。实际上，WAF 偏向过滤外部 Web 请求特征，对业务逻辑漏洞、内部越权、数据接口权限缺失的修复能力有限。安全建设是一整套流程，WAF 只是其中一环。

误区二：规则全部开启就等于防护最强。规则全开后，很大概率开始出现各种误报。业务被误拦截，比少量漏报更快让团队崩溃。规则不是越多越好，而是越贴合业务边界越好。

误区三：线上报 502 一定是后端不可用。很多 502 发生在 WAF 和后端之间。证书失效、后端地址配置错误、访问超时、规则错误拦截、代理转发配置不对，都可能导致客户端看到 502。

7.2 四层排查法

我在排线上问题时会按固定顺序走，尽量不做跳跃式猜测，这能省不少时间。

第一层，看现象。先确认是连接超时、明文报错、页面打不开、还是部分请求被拦截。现象决定下一步方向。

第二层，看输入。访问日志里记录的原始路径是什么，客户端 IP 是什么，请求参数里有没有特殊字符，请求体大小是不是超限。很多所谓被 WAF 误杀的问题，其实请求内容和实际参数本身就存在问题。

第三层，看配置。站点名是否匹配，证书是否过期，代理目标地址是否写错，规则等级是不是太敏感，限流阈值是不是压到了正常用户。配置问题是最常见也最容易忽视的一层。

第四层，看资源与版本。确认 CPU、内存、磁盘、日志目录是否正常，确认容器版本、规则版本是否与文档说明匹配。如果磁盘满了，日志写不进去，WAF 可能会出现各种奇怪表现。

7.3 误报和漏报要分开处理

误报是指正常业务请求被拦截。一旦出现误报，先不要急着把整条规则关闭，而是把被拦截样本导出，看它命中哪条规则，再看有没有办法通过白名单路径、规则调整或参数归一化解决。

漏报则是指疑似攻击请求没有被拦截。出现这种情况，先确认请求是否真的经过 WAF，再确认规则集是否覆盖了对应攻击类型，最后再看请求是否被特殊编码或分段传输导致解析结果不同。

这里要守住一个底线：解决漏报不是靠寻找绕过技巧，而是靠补规则、补日志、补检查点。作为一个防御方，你永远更关心规则有没有失效、日志有没有缺漏，以及告警有没有送达。

8. 中小站点推荐的落地节奏

8.1 第一阶段：旁路观察

新团队第一次引入 WAF 时，不要立刻要求“必须拦截一切”。先用一个测试域名接入，把它当作前置代理，观察访问日志和规则命中日志。这个阶段的重点是熟悉日志结构、熟悉规则行为、建一个可复用的配置模板。

8.2 第二阶段：接管单域名

第一个正式域名接入时，优先选择业务影响面最小的域名，最好配合一个可回退方案。比如提前准备好切换 DNS 或修改后端入口的方法。上线后连续观察几天，重点看正常用户会不会被误拦，后端 Web 应用会不会因为代理头信息变化而产生问题。

8.3 第三阶段：多站点和集中管理

多个站点都接入后，单靠环境变量管理会变得繁琐。这时再看是否需要引入管理界面、数据库或集中配置能力。多站点的最大问题是每个站点的规则、证书、日志、限流参数都不一样，如果没有统一管理手段，很容易出现某个站点配置过期自己还不知道。

到这一步，BunkerWeb 才真正从“一个容器”变成“一套边界安全基础设施”。你的运维节奏也应该固定下来：每周看一次日志和规则更新，每个月做一次配置备份恢复演练，每次升级前做一次回归测试。

我在最后留一个建议：如果你只在找一个能演示的 WAF 项目，跑通最小实例就够了；如果你要把 BunkerWeb 当作生产入口，就要提前把日志、备份、规则调优和升级回滚这些环节放在同一天做完。真正能长期用下来的开源 WAF，不是部署完之后不管，而是每天都在看日志和响应状态。