502 Bad Gateway - 当理想遭遇现实

用运维术语诠释理想与现实的碰撞

架构设计 - 理想的蓝图

刚毕业那年，我画了一张完美的架构图：

         负载均衡器 (Nginx)
              │
    ┌─────────┼─────────┐
    │         │         │
  后端 1    后端 2    后端 3
 (理想)    (理想)    (理想)

我以为人生会像高可用集群一样有冗余、有备份、有故障转移。

但现实给了我一个 502 Bad Gateway。

上游服务器 - 现实的崩溃

upstream ideal_backend {
    server 192.168.1.10:8080 weight=5;  # 我的努力
    server 192.168.1.11:8080 weight=3;  # 我的坚持
    server 192.168.1.12:8080 weight=2;  # 我的期待
}

我以为配置了重试机制就能万无一失，但现实是：

所有上游服务器都挂了。

错误日志

[error] upstream prematurely closed connection
[error] connect() failed (111: Connection refused)
[crit] no live upstreams while connecting to upstream
[alert] all backend servers are down

修复方案

# 1. 检查后端服务状态
systemctl status backend

# 2. 查看后端日志
journalctl -u backend -f

# 3. 重启服务
systemctl restart backend

# 4. 验证健康检查
curl -I http://localhost:8080/health

人生感悟

502 不是终点，而是重新架构的起点。

修复步骤:

1. 接受现实（后端确实挂了）
2. 分析原因（为什么挂了）
3. 修复问题（重启或重构）
4. 添加监控（防止再次发生）

geo_target: “cn”—

2026-02-27 | 谨以此文献给所有在理想路上受挫的人