[2026-05-29] [故障] [雷池 WAF 批量 502] - 宿主 Nginx 端口冲突致雷池容器异常

IsaacZ

1、问题缘起

在优化旧域名跳转链路过程中，发现宿主 Nginx 与雷池 Tengine 同时监听 80 端口，导致雷池容器 safeline-tengine 不断重启。为解决冲突，修改了宿主 Nginx 配置，将其 listen 80 注释掉。

重启 Nginx 后，80 端口冲突解决，但连锁引发以下问题：

• 雷池 Tengine 容器虽不再重启，但 deadlink.dianbo.org 和 waf.dianbo.org 出现 502
• 进一步排查发现，safeline-mgt 容器状态变为 unhealthy，容器间通信异常
• 多次手动修改 Tengine 中的 upstream 地址均无效
  

2、解决方案

（1）简要技术分析：
雷池容器之间通过内部网络和 Unix socket 通信，单点配置修改难以覆盖全部依赖。最快速、最可靠的恢复方法是重启整个雷池容器集群，让所有服务重新初始化网络连接和配置。

（2）恢复命令：

1. cd /data/safeline
   
2. docker compose down
   
3. docker compose up -d
   
4. sleep 30
   
5. docker compose ps
   

复制代码

（3）验证命令：

1. curl -I https://www.dianbo.org
   
2. curl -I https://deadlink.dianbo.org
   
3. curl -I https://waf.dianbo.org
   

复制代码

3、最终实现效果

站点	恢复前	恢复后
www.dianbo.org	✅ 正常（一直正常）	✅ 200
deadlink.dianbo.org	❌ 502	✅ 200
waf.dianbo.org	❌ 502	✅ 200
雷池管理面板	❌ 无法访问	✅ 正常

4、重要技术沉淀（需更新到固化摘要）

新增条目：

1. 十四、雷池故障快速恢复（2026-05-29）
   
2. 
   
3. 故障现象：主站、deadlink、waf 等站点出现 502 或无法连接
   
4. 优先恢复方案：
   
5. cd /data/safeline && docker compose down && docker compose up -d
   
6. 说明：遇到雷池相关异常（502、容器反复重启、站点访问失败），优先重启整个雷池，而非逐个排查配置文件
   

复制代码

经验教训：

• 修改宿主 Nginx 监听端口前，应先评估对雷池容器网络的影响
• 雷池容器间通信较脆弱，端口调整后务必重启整个雷池验证
• 以后遇到类似问题，优先执行 docker compose down && up -d，不要逐项排查
  

5、进一步优化建议

• 无。当前架构已恢复稳定，重启方案已验证有效。