0. 事故背景
在已有 memos 和 siyuan 稳定运行的服务器上，尝试新增 blinko 服务，并通过 Nginx 容器实现 blinko.hessin.cn 的反向代理。
1. 事故现场（真实命令序列）
第一步：配置“抢跑” (致命诱因)
在 Blinko 业务容器尚未启动时，我先编写了 /etc/nginx/conf.d/blinko.conf，并直接要求 Nginx 加载新配置：
# 此时 blinko-website 容器还未创建/启动
docker exec nginx nginx -s reload
报错信息： nginx: [emerg] host not found in upstream "blinko-website"。
后果： Nginx 无法解析该主机名，导致重载失败，进程进入异常状态。
第二步：连锁反应 (全线瘫痪)
随后我尝试通过 docker-compose 启动服务：
docker-compose -f docker-compose.yml up -d
最终惨状： Nginx 监测到配置错误并不断尝试重启。由于它在启动瞬间无法解析 blinko-website，甚至因为网络抖动无法解析原本正常的 memos，导致 Nginx 彻底退出（Exited）。服务器上所有网站（Memos, SiYuan, Blinko）全部无法访问。
2. 深度原理分析：为什么会崩溃？
A. Nginx 的“连坐”启动检查
Nginx 默认在启动或 reload 时，会对 proxy_pass 中的所有主机名进行强制解析。
- 点名机制：如果你在名单（配置）上写了名字，点名时（启动时）人不在场，Nginx 就会认为这份名单“有毒”，直接拒绝服务。
- 关键点：在容器还没“出生”前，绝对不要在网关里“点名”。
B. Docker 网络孤岛 (The Island Effect)
每个 docker-compose 默认都会创建一个独立的虚拟网络。
- 现状：Blinko 在其默认网络中，而 Nginx 在
memos-net中。 - 结果：即便 Blinko 启动了，Nginx 所在的办公室也“看不见”它。必须通过
docker network connect建立联系。
C. 假死健康检查 (Healthcheck Trap)
Blinko 容器显示 unhealthy 但外部能访问。
- 报错日志：
wget: can't connect to remote host: Connection refused。 - 本质：容器内的自检脚本尝试通过容器名（Blinko-website）访问自己，结果请求在网络层被拦截。
3. 最终正确修复流程（SOP）
按照这个 “先起服务，后点名” 的顺序，可确保 100% 成功：
1. 启动业务容器（让 DNS 生效）
docker-compose up -d
2. 打通网关网络（加入“办公室”）
docker network connect memos-net blinko-website
3. 修正 Healthcheck (docker-compose.yml)
将自检目标锁定为 localhost，避免容器自检时走冤枉路：
healthcheck:test: ["CMD-SHELL", "wget --spider -q http://localhost:1111/ || exit 1"]interval: 30sstart_period: 30s
4. 安全重载 Nginx
# 检查语法（报错了千万别 reload）
docker exec nginx nginx -t# 确认无误后再执行
docker exec nginx nginx -s reload
4. 经验总结：防崩溃架构建议
为了防止未来某一个后端挂掉导致整个 Nginx 连坐崩溃，建议使用 Resolver（变量解析） 模式：
location / {resolver 127.0.0.11 valid=30s; # Docker 内部 DNS 地址set $target http://blinko-website:1111;proxy_pass $target;
}
原理：使用变量定义 proxy_pass 时，Nginx 会跳过启动时的严格 DNS 检查，仅在有人访问时才动态解析。即使后端容器被删了，网关依然稳如泰山。