企业官网建设流程全解析

1. 项目是什么，解决什么问题

1.1 一句话先理解这个项目

BunkerWeb 这个开源项目，头一回用它替换一台手工配置的入口服务器时，我就被它的“打包程度”惊到了。它不是一个新的 Web 服务器，也不是让你从零搭建的框架，而是把一套开箱即用的 Web 应用防火墙（WAF）能力直接封装成 Docker 镜像。启动之后，它会自动生成带安全策略的访问控制层，处理常见的扫描探测、暴力尝试、恶意特征请求，同时还能负责证书申请、访问名单维护、请求限速等工作。

我以前很长一段时间都是自己手工维护一台入口机器：安装、调内核参数、配缓存、挂各种防护规则、再写脚本定时封禁异常 IP。这套流程确实能行，但只要站点多了，规则一多，每次改配置都像在拆炸弹。BunkerWeb 最大的价值不是某个单点功能多强，而是它把“统一流量入口 + WAF 规则集 + 证书管理 + 可配置 UI”揉成了一个整体，让维护成本直线下降。

如果你正在跑个人站点、内部系统、实验项目，或者想把团队的一些小服务统一收口，这个项目很值得试试。下文我会按照从零安装、首次配置、常见问题排查到长期维护的顺序，把我实际踩过的坑和得到的经验写清楚。

1.2 我是在什么场景下决定换用它的

我之前管理过一个不算大的服务集群，里面跑着几个 Web 管理台和业务接口。入口规则分散在各处：有的服务自己带基础校验，有的靠外部网关转发，还有的直接裸奔暴露端口。每次安全通告一出来，我就要把所有可能受影响的入口捋一遍，非常累。

后来我决定把所有 HTTP/HTTPS 流量统一收到一台 BunkerWeb 容器前面，由它做一次总筛选，再把合法请求交给对应的内部服务。这么做的好处很明显：安全策略只需要在一个地方维护，不需要每个业务都重复实现一遍防护逻辑。尤其是像“某个 IP 短时间内连续请求失败多次”这类通用场景，交给 BunkerWeb 的规则比我自己写脚本要稳定得多。

如果你遇到的情况是“服务数量不多，但入口散落、规则不统一、缺少证书自动化”，那 BunkerWeb 几乎就是为这种场景设计的。哪怕你只有一个博客，把它放在前面也能得到一套比较完整的防护基调，后续不用再临时补安全措施。

1.3 它比“自己拼一堆规则”强在哪里

很多人第一反应是：我直接用成熟 Web 服务器再加第三方规则集不就行了？我在最初也是这么想的，但实际对比过之后，发现差距主要不在“能不能做”，而在“维护效率”。

自己拼方案时，你需要自己处理版本兼容问题。某个规则库更新了误报，需要手动测试；某个参数写法发生了变化，需要跟踪上游变更；多台机器之间规则不一致，排查起来更是麻烦。BunkerWeb 把这些东西收敛成了更统一的配置项，你可以通过环境变量、配置接口、静态配置文件三种方式来管理，且底层规则会随镜像更新一起迭代，减少了很多重复劳动。

同时，BunkerWeb 对“普通人”更友好。它不会逼你去理解每一个底层细节，而是给出清晰的开/关开关：内置 WAF 要不要开、黑名单要不要启用、自动封禁要不要参与、后台管理界面要不要打开。这种“以策略为中心”而不是“以配置文件为中心”的玩法，让没有太多安全背景的人也能快速把防护兜住。

2. 安装前的准备与 Docker 部署

2.1 安装前需要准备哪些基础条件

BunkerWeb 官方推荐用 Docker 方式部署，好处是依赖干净、升级简单、回滚也容易。安装之前先确认环境里有没有 Docker 和 Docker Compose 插件，我一般是先跑一下：

docker version docker compose version

如果这两条命令都没报错，基本就可以继续了。BunkerWeb 需要用到宿主机的 80 和 443 端口，因为容器本身就是对外入口。如果机器上已经跑着其他 Web 服务，先把它们停掉或者改到别的端口，否则容器启动会冲突。

再准备一个数据存放目录，比如/opt/bunkerweb/data。这个目录很重要，证书、配置、数据库、日志都会写在这里。如果容器不小心被删掉了，只要这个目录还在，重新拉一个容器起来就能接回状态。我这个老用户的第一条建议就是：挂目录比不挂目录重要得多，别图省事。

也需要一个真正能解析到这台服务器的域名。虽然可以用 IP 启动，但自动申请证书、多域名区分这些功能都依赖主机头，没有域名会遇到很多额外麻烦。测试阶段可以用app.example.org这样的占位域名，等真实域名准备好后再改。

2.2 使用 Docker Compose 启动最小实例

我习惯用 Docker Compose 而不是裸的docker run，因为 Compose 文件可以放进 Git 做版本管理，改了什么一目了然。这里先给一份最小可用的配置，不是拿来跑生产，但足够让你看到 BunkerWeb 长什么样。

services: bunkerweb: image: bunkerity/bunkerweb:lts container_name: bunkerweb ports: - "80:80" - "443:443" environment: AUTOCONF: "yes" USE_BUNKERWEB_UI: "yes" SERVER_NAME: "app.example.org" MULTISITE: "no" volumes: - /opt/bunkerweb/data:/data restart: unless-stopped

先不要急着加一堆安全参数，我建议先按最小配置跑起来，确认基础链路通，再逐步把 WAF、限速、名单这些打开。上面的AUTOCONF=yes会让 BunkerWeb 根据环境变量自动生成入口配置；USE_BUNKERWEB_UI=yes是打开管理界面，方便你在浏览器里改东西；SERVER_NAME填你真正要对外服务的域名。

启动命令比较简单：

cd /opt/bunkerweb docker compose up -d

启动后可以这样看日志：

docker compose logs -f bunkerweb

第一次启动会拉镜像、初始化数据目录、生成默认配置，日志输出会明显比平时多。耐心等十几秒，看到服务进入正常运行状态后，就可以试着访问http://你的域名看看默认反馈了。

2.3 启动后要立刻检查哪几项

第一件事是确认数据目录有没有生成内容。正常启动后，/opt/bunkerweb/data下面会出现证书目录、配置目录和数据库文件。如果这些目录是空的，说明容器没有往这个路径写东西，很可能是权限问题，或者数据目录挂错位置了。

第二件事是检查 80 和 443 端口是否真的被容器占用。用docker compose ps查看容器状态，再在宿主机上访问域名，看看返回内容。很多新手一开始就卡在这：容器起来了，但宿主机防火墙没有放行端口，外部访问就是不通。

第三件事是访问后台管理界面。BunkerWeb 的管理界面一般在你的域名/ui路径下，比如http://app.example.org/ui。第一次登录时需要输入管理员账号，密码如果在环境变量里没有特别指定，建议先在启动日志里找一下有没有临时初始凭据信息。我碰到过不少版本在第一次登录后会强制要求改密码，这是正常的安全策略，不是 bug。

这三个检查做完，基本可以确定容器是健康的。接下来再去配置具体站点和安全规则，你会发现思路清晰很多。

3. 策略配置与日常使用

3.1 请求入口的配置思路

BunkerWeb 本身不是一个业务应用，它的职责是站在所有请求前面做筛选。在配置上，核心思路是：先确定“我要为哪些域名服务”，再确定“每个域名后面的内部服务是谁”，最后才是安全策略怎么套。

单站点场景最好理解，SERVER_NAME填一个域名，MULTISITE=no，系统就会把该域名的请求都收进来。如果你后面还有具体的业务服务，只要在后台把访问路径和内部服务地址绑定起来，比如把根路径指到某个内网容器的 8080 端口，剩下的事情就交给 BunkerWeb。

多站点的思路也类似，只是把“域名”这个维度拆开。每个站点可以有不同的证书、不同的转发目标、不同的安全等级。比如一个站点是公开的业务页面，可以开完整的 WAF 规则；另一个站点是内部运维后台，可以额外加一层允许来源 IP 限制。这种隔离很重要，它让安全策略不再是一刀切。

初次配置的人容易搞混一个概念：BunkerWeb 的“站点”说的是对外入口，不是业务容器。你不能把它理解成“应用本身”，而是要理解成“大门”。大门后面是什么服务，那是你做入口配置时指定的。

3.2 我需要重点打开哪些安全功能

BunkerWeb 默认自带了一些安全基线，但很多人刚上手时会纠结“到底要不要全部打开”。我的建议是分级开启，不要一上来就把所有高强度规则全打开。

先打开内置 WAF 开关，让请求过一遍核心规则集，拦截掉常见注入、跨站脚本、恶意文件上传特征。这一步是最值得开的，因为它对大多数业务伤害最小，也没有额外的人工运维成本。

再考虑启用请求限速。比如对一个登录接口，允许每个客户端每秒最多 20 个请求，突发量允许 40 个。这个参数要结合业务实际情况调，太松等于没限，太紧会把正常用户也卡住。我自己就会先观察一段时间的正常请求量，再取一个峰值偏上的值。

然后是封禁名单和放行名单。对于明确异常的 IP，直接加入封禁名单，让它连入口这一层都进不来；对于自家办公网段或者合作伙伴出口 IP，可以放到放行名单里，减少误伤。这里有一个容易被忽略的点：名单不只是“管 IP”，它应该配合日志一起看，才能知道哪些 IP 是真正需要处理的。

还可以考虑打开 GEO 级别的访问限制，但这要看业务需求。如果你的站点只服务特定区域，关闭其他区域的访问是有效的收敛手段；如果业务本身就是面向全球的，那就没必要给自己找麻烦。

3.3 证书与 HTTPS 的处理方式

BunkerWeb 对证书的处理是我个人比较喜欢的一部分。它支持自动化申请证书，原理就是 ACME 协议：外部证书机构会通过 HTTP 方式验证你对域名的控制权，验证通过后签发证书，BunkerWeb 再把证书自动部署到入口上。

要做到这一步，有两件事必须满足：第一，域名必须解析到当前服务器，解析错了就拿不到证书；第二，容器的 80 端口必须能对外访问，因为 ACME 验证请求需要通过这个端口进来。只要这两点没问题，开通 HTTPS 基本上是一键的事。

如果业务已经在使用 CDN，情况会稍微特殊一点。因为 CDN 会挡在 BunkerWeb 前面，ACME 验证请求可能到不了 BunkerWeb，这时可以手动把已有证书导入 BunkerWeb，并把自动申请关闭。否则 BunkerWeb 会反复尝试申请证书，日志里会出现一堆验证失败记录，容易干扰排查。

证书到期前的自动续期也不用太操心，流程和首次申请类似。我踩过最大的坑是：服务器本地时间不准，导致 ACME 验证握手失败。后来我在宿主机上启用了时间同步服务，这个问题就没再出现过。

3.4 使用配置界面维护配置的注意事项

BunkerWeb 提供了可视化界面，这对不习惯看配置文件的人帮助很大。但我还是要提醒一句：界面改了配置之后，一定要确认它确实生效了，最好到页面或者容器日志里再核对一遍。

我在实际使用中发现，界面操作和容器环境变量之间有时会出现“互相覆盖”的情况。如果你之前用过环境变量指定某个参数，后来又在界面里改了另一个参数，重启后界面里的设置可能会被环境变量重新拉回去。这个行为不同版本会有差异，避免踩坑的最好办法是：统一管理入口，要么主要用界面，要么主要用环境变量，不要混着来。

另一个注意事项是“变更前做好快照”。BunkerWeb 的配置会持久化到数据目录，界面操作本质上是在改这些持久化内容。你在界面上连续修改多次后，如果发现某个配置不对，想回退到之前的状态，没有备份就会很被动。我自己会在每次大改动前，把数据目录做一次简单备份：

tar czf bunkerweb-backup-$(date +%F).tar.gz /opt/bunkerweb/data

这个动作成本很低，却能让你在改崩的时候快速恢复，比事后查日志抢救要省心太多。

4. 常见问题与排查技巧实录

4.1 容器起不来怎么办

最典型的启动失败原因是端口冲突。如果还有另一个进程占用了 80 或 443 端口，容器会不断重启或者直接退出。可以用下面命令快速确认：

ss -lntp | grep -E ':80|:443'

如果看到其他进程占用，要么停掉它，要么把 BunkerWeb 的外部映射端口改成别的。但改端口会影响自动证书申请，所以能不动 80/443 就尽量不要动。

还有一种情况是数据目录权限不对。BunkerWeb 需要往/data写入大量文件，如果你把目录挂载到了一个只读路径，或者目录权限太严格，容器也会启动失败或报初始化错误。遇到这类问题，先检查目录所有权和读写权限：

ls -ld /opt/bunkerweb/data

把目录权限调整到容器内用户可写即可。经验是：不要为了安全把数据目录做成只读，BunkerWeb 需要靠它保存证书和运行时状态。

4.2 证书一直申请不成功怎么排查

证书申请失败，百分之八十和外部连通性有关。先确认你的域名确实解析到了这台服务器，可以用解析工具查一遍，别用记忆里的地址想当然。接着确认容器是否在 80 端口正常监听，以及服务器的外部防火墙有没有拦截外部到 80 的访问。

如果域名解析正确、端口也正常，还失败的话，就要看日志里 ACME 验证的具体报错信息。BunkerWeb 会把验证请求的路径打印出来，你可以手动模拟一次请求，看看返回内容是否正常。多数情况下，是前面套了 CDN 或者内部有重定向，导致验证请求没有原样到达容器。

我自己的排查顺序是：解析 -> 端口 -> 访问路径 -> 日志，按这个顺序走一遍，基本能在十分钟内定位问题。不要一上来就去翻底层证书配置，那样只会让自己更累。

4.3 修改配置后不生效的常见原因

BunkerWeb 有些配置是启动时读取的，有些是运行中通过调度器同步的。如果你修改了某个环境变量，却只是对容器执行了docker compose restart，有时候会发现参数没变。这不是 BunkerWeb 坏了，而是这一类变量需要在创建容器时重新注入。

所以遇到“改了没反应”，第一步是重建容器：

docker compose down docker compose up -d

这样环境变量才会重新被读取。如果你修改的是界面上的业务配置，大概率会在界面里看到保存成功提示，但真正生效还需要等到下一次配置同步周期。碰到紧急改动，可以去容器日志里主动触发一次重新加载，或者重启容器来缩短等待时间。

还有一个容易被忽略的点：浏览器缓存。界面样式或者有些页面状态看起来没变，往往是浏览器缓存导致的。我排查这类问题时，会顺手开一个无痕窗口再看一次，很多时候“不生效”只是你自己看到的不是最新结果。

4.4 如何靠日志定位误拦截

BunkerWeb 的日志信息量很大，刚开始看会觉得吵。但想用好它，就必须学会从里面捞出有效字段。被拦截的请求通常会有明确的规则命中记录，会告诉你命中了哪个规则类别、请求来自什么 IP、路径是什么。

当你觉得某个正常请求被规则挡掉了，不要直接把安全功能关掉，而是先根据日志判断是哪个环节拦截的。是 WAF 规则命中？是限速触发？是来源名单拒绝？不同环节对应不同处理手段。如果只是某个路径被误伤，可以为这个路径设置更精确的排除规则；如果是某个客户 IP 被误封，可以把它加入放行名单。

我觉得调试期间最忌讳的是“一棍子打死”。因为安全产品的误杀本来就很难完全避免，直接关闭规则等于把防护拱手让出去。正确做法是把日志当作第一手排查依据，先搞清楚为什么拦，再决定要不要放行。

5. 长期维护中的经验与建议

5.1 别急着把所有规则一次性全开

我在第一次部署 BunkerWeb 时，抱着“既然要上就全上”的心态，把能打开的高强度规则全都打开了。结果第二天就有同事反馈页面数据加载不出来，排查了很久才发现是其中一条规则对某个内部接口的请求特征产生了误判。

后来我调整了策略：部署后先把 WAF 等高强度规则放在“记录”模式，观察几天正常业务流量，确认没有明显误伤后再切换到拦截模式。这个过程听起来保守，但对生产环境来说非常值得。宁可让安全规则晚生效两天，也不要在业务高峰期因为误拦把自己折腾到半夜。

5.2 镜像版本要固定，不要盲目追新

BunkerWeb 更新速度不慢，但“新”不等于“稳”。我建议在测试环境先试新版本，确认与你自己的配置、数据目录和业务场景兼容之后，再逐步应用到生产机器。Compose 文件里的镜像标签最好固定到一个具体版本，而不是长期用latest。

这样做还有一个好处：出问题的时候回滚容易。比如我这台机器用的是lts系列里的某个具体版本，如果升级后日志出现异常，我只要把镜像标签改回上一个版本，再重新创建容器，业务就能快速恢复。盲目追新的代价，往往比省那点升级时间大得多。

5.3 把告警接入日常沟通渠道

BunkerWeb 能拦截很多攻击请求，但如果没人看日志，这些拦截记录就只是静静躺在文件里，价值大打折扣。我建议把安全告警接入你日常会看的沟通渠道，比如企业内部的消息通知或邮件组。这样一旦出现异常量级波动，你能第一时间知道。

刚开始接入告警时要注意阈值设置。如果阈值太低，你会被大量低风险扫描记录轰炸；如果阈值太高，真出问题时又可能漏报。我的一般做法是先看一周基线，再把告警阈值定在基线的一定倍数以上，让告警真正成为“异常信号”，而不是噪音。

5.4 最后一句话经验

这套东西我用了蛮久之后，最大的感受是：BunkerWeb 不是装完就能一劳永逸的“银弹”，但它能把安全运维的起点拉高很多。对于没什么安全团队的小项目来说，与其自己搭摇摇欲坠的规则组合，不如基于一个成熟的 WAF 底座去做配置。只要保持“先观察、后拦截、常备份、会看日志”这几个习惯，它完全可以成为你对外服务前面一道非常可靠的防线。