开箱之后我先给结论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 谁能直接用谁不能先把自己代入场景再决定是否引入这比折腾完再卸载重要得多。适合的场景有这几类你有一个或若干 Web 应用希望统一入口收流量再统一做访问控制和安全过滤。你不想把所有配置都暴露在商业云控制台里希望规则、日志、证书、访问策略都在自己的机器上管理。你有等保或内部合规整改需求需要在边界上明确有自己的 WAF 设备或服务同时日志能够留存和追溯。你想学习 WAF 工作原理想在本地跑一套真实规则集看规则怎么命中、日志怎么落地。不适合的场景也明确你完全没有运维意识只打算部署完以后不管等出问题再说。你的业务本身逻辑漏洞一大堆比如登录没限流、订单金额可改、权限校验缺失这类问题不是 WAF 能修复的。你的团队没人会看 NGINX 日志或容器日志遇到 502 都分不清是后端问题还是 WAF 问题。你希望免费版提供商业级服务保障那这不现实开源软件需要自己投入人力和时间。1.3 开源免费不等于免运维这一点要放在最前面说清楚。BunkerWeb 的社区版可以自己下载、自己部署没有授权成本这是它的优势。但它没有商业产品那种“打电话有人帮你看”的服务体系。你获得的是代码、文档、配置能力和社区生态同时也要承担版本升级、规则更新、日志备份、证书续期、故障排查这些责任。如果团队里至少有一个人能看懂日志能操作 Docker 或 Linux再选它。如果完全没有那更稳妥的做法是选托管型 WAF 或商业 WAAP 服务。2. 部署前先把运行条件定下来2.1 常见运行方式有哪些BunkerWeb 的部署方式比较灵活。官方经常用的是容器化部署适合单机和小集群也支持基于 Linux 的安装方式适合不想用 Docker 的环境在 Kubernetes 或类似容器编排环境里也有对应的接入方案。普通入门阶段我建议先用 Docker Compose 跑一个最小实例不要一上来就上集群。这样做的原因很直接第一次测试的目的不是验证所有功能而是确认三件事能不能成立即容器能不能正常启动、域名配置能不能生效、日志能不能看到。如果这三件事都没问题后面再扩展 UI、数据库、API 都不难。2.2 资源要按“规则引擎会吃 CPU”来预估很多人在部署 Web 项目时习惯只关注容器数量和端口忽略资源预算。WAF 和普通反向代理的差别在于多了一层规则匹配规则越多CPU 消耗越明显。给一个通用参考区间场景CPU内存磁盘说明测试环境只保护 1 个测试域名1 核即可1 GB 左右可用预留 10 GB 日志空间只做功能验证不要开太多规则生产环境保护中小型站点2 核及以上2 GB 以上按日志量和使用时长预留要开启 OWASP 核心规则集的场景内存建议再往上提生产环境多站点并开启 API 防护4 核或更高4 GB 或更高按日志留存半年以上规划还要考虑数据库存储和备份空间这里没有写具体版本要求因为原始材料没有提供明确指标实际参数要以你的环境和 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 --tail100 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/?pagehome curl -I http://localhost/static/style.css如果正常页面返回 200静态资源也能正常访问说明反向代理链路是通的。如果这里就出现 404 或 502先排查后端的站点配置和 Web 应用本身不要急着怀疑安全规则。4.2 用本地规则样本验证拦截接下来构造一个包含典型攻击特征的可疑请求。注意这是在你自己的测试环境和自己的实例上进行安全验证不是对他人系统发起攻击。curl -I http://localhost/?id1%27%20OR%20%271%27%3D%271 curl -I http://localhost/?qscriptalert(1)/script如果规则集生效这类包含 SQL 注入或 XSS 特征的请求大概率会被拦截返回的状态码通常是 403、406 或类似的拒绝状态同时日志里会留下拦截记录。这里要特别说明不同版本、不同规则集、不同默认策略下具体返回码可能不一样。判断标准不是“必须返回某个固定状态码”而是“请求应被 WAF 阻断并且在日志中能查到原因”。如果所有可疑请求都顺利通过说明规则没有完全生效。这时不要先怀疑规则不够强应该先检查 ModSecurity 是否启用、规则集是否加载、站点域名是否匹配以及日志里有没有加载错误。4.3 用日志确认拦截结果验证不能被“好像拦截了”这种印象带过去一定要落到日志。常用命令docker compose logs --tail200 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 灰度上线顺序我比较推荐的顺序是先用测试域名部署最小实例。观察日志确认站点访问正常。开启规则集等一个观察周期收集误报。挂一个低流量子域名进入真实流量。确认稳定后再切主域名。保留后端直接访问的能力作为回退方案但日常不让流量绕开 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不是部署完之后不管而是每天都在看日志和响应状态。 
长河君 · 2026/8/27 20:41:39 · 阅读 1.2k 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 谁能直接用谁不能先把自己代入场景再决定是否引入这比折腾完再卸载重要得多。适合的场景有这几类你有一个或若干 Web 应用希望统一入口收流量再统一做访问控制和安全过滤。你不想把所有配置都暴露在商业云控制台里希望规则、日志、证书、访问策略都在自己的机器上管理。你有等保或内部合规整改需求需要在边界上明确有自己的 WAF 设备或服务同时日志能够留存和追溯。你想学习 WAF 工作原理想在本地跑一套真实规则集看规则怎么命中、日志怎么落地。不适合的场景也明确你完全没有运维意识只打算部署完以后不管等出问题再说。你的业务本身逻辑漏洞一大堆比如登录没限流、订单金额可改、权限校验缺失这类问题不是 WAF 能修复的。你的团队没人会看 NGINX 日志或容器日志遇到 502 都分不清是后端问题还是 WAF 问题。你希望免费版提供商业级服务保障那这不现实开源软件需要自己投入人力和时间。1.3 开源免费不等于免运维这一点要放在最前面说清楚。BunkerWeb 的社区版可以自己下载、自己部署没有授权成本这是它的优势。但它没有商业产品那种“打电话有人帮你看”的服务体系。你获得的是代码、文档、配置能力和社区生态同时也要承担版本升级、规则更新、日志备份、证书续期、故障排查这些责任。如果团队里至少有一个人能看懂日志能操作 Docker 或 Linux再选它。如果完全没有那更稳妥的做法是选托管型 WAF 或商业 WAAP 服务。2. 部署前先把运行条件定下来2.1 常见运行方式有哪些BunkerWeb 的部署方式比较灵活。官方经常用的是容器化部署适合单机和小集群也支持基于 Linux 的安装方式适合不想用 Docker 的环境在 Kubernetes 或类似容器编排环境里也有对应的接入方案。普通入门阶段我建议先用 Docker Compose 跑一个最小实例不要一上来就上集群。这样做的原因很直接第一次测试的目的不是验证所有功能而是确认三件事能不能成立即容器能不能正常启动、域名配置能不能生效、日志能不能看到。如果这三件事都没问题后面再扩展 UI、数据库、API 都不难。2.2 资源要按“规则引擎会吃 CPU”来预估很多人在部署 Web 项目时习惯只关注容器数量和端口忽略资源预算。WAF 和普通反向代理的差别在于多了一层规则匹配规则越多CPU 消耗越明显。给一个通用参考区间场景CPU内存磁盘说明测试环境只保护 1 个测试域名1 核即可1 GB 左右可用预留 10 GB 日志空间只做功能验证不要开太多规则生产环境保护中小型站点2 核及以上2 GB 以上按日志量和使用时长预留要开启 OWASP 核心规则集的场景内存建议再往上提生产环境多站点并开启 API 防护4 核或更高4 GB 或更高按日志留存半年以上规划还要考虑数据库存储和备份空间这里没有写具体版本要求因为原始材料没有提供明确指标实际参数要以你的环境和 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 --tail100 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/?pagehome curl -I http://localhost/static/style.css如果正常页面返回 200静态资源也能正常访问说明反向代理链路是通的。如果这里就出现 404 或 502先排查后端的站点配置和 Web 应用本身不要急着怀疑安全规则。4.2 用本地规则样本验证拦截接下来构造一个包含典型攻击特征的可疑请求。注意这是在你自己的测试环境和自己的实例上进行安全验证不是对他人系统发起攻击。curl -I http://localhost/?id1%27%20OR%20%271%27%3D%271 curl -I http://localhost/?qscriptalert(1)/script如果规则集生效这类包含 SQL 注入或 XSS 特征的请求大概率会被拦截返回的状态码通常是 403、406 或类似的拒绝状态同时日志里会留下拦截记录。这里要特别说明不同版本、不同规则集、不同默认策略下具体返回码可能不一样。判断标准不是“必须返回某个固定状态码”而是“请求应被 WAF 阻断并且在日志中能查到原因”。如果所有可疑请求都顺利通过说明规则没有完全生效。这时不要先怀疑规则不够强应该先检查 ModSecurity 是否启用、规则集是否加载、站点域名是否匹配以及日志里有没有加载错误。4.3 用日志确认拦截结果验证不能被“好像拦截了”这种印象带过去一定要落到日志。常用命令docker compose logs --tail200 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 灰度上线顺序我比较推荐的顺序是先用测试域名部署最小实例。观察日志确认站点访问正常。开启规则集等一个观察周期收集误报。挂一个低流量子域名进入真实流量。确认稳定后再切主域名。保留后端直接访问的能力作为回退方案但日常不让流量绕开 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不是部署完之后不管而是每天都在看日志和响应状态。