beego本身不提供反向代理或upstream管理能力，仅作为纯后端http服务节点运行，所有负载均衡逻辑由nginx的upstream块承担；upstream必须独立配置在nginx.conf中，beego只负责监听本地端口、暴露/healthz接口并正确处理nginx透传的请求头。
Beego 本身不提供反向代理或 upstream 管理能力，所谓“配合 Nginx”，本质是让 Beego 作为纯后端 HTTP 服务节点运行，所有负载均衡逻辑由 Nginx 的 upstream 块承担。你不能在 app.conf 或启动代码里写服务器列表，也不能指望 Beego 自动发现其他实例。
Beego 启动方式必须匹配部署模型
开发时用 bee run 固定监听 :8080 没问题，但生产环境必须改用二进制直接运行，并确保每个实例绑定不同端口或由容器动态分配：
- 多个 Beego 实例需分别监听如
:8080、:8081、:8082—— 不能都抢同一个端口 - 若用 Docker，建议用
EXPOSE声明端口，但实际映射由docker run -p或编排工具控制 - 务必禁用 Beego 的自动重启（如
bee run -d）；生产应交由systemd或 Kubernetes 管理进程生命周期 - 检查
ListenAddr和HTTPPort配置项是否被硬编码成127.0.0.1:8080，线上应允许绑定0.0.0.0且端口可注入
Nginx upstream 配置必须独立写在 nginx.conf 里
upstream 块不能出现在 Beego 代码或配置文件中，它只属于 Nginx 部署层。典型错误是把 upstream backend { server 127.0.0.1:8080; } 写进 Beego 的模板或日志配置里——Nginx 根本不会读取。
- 正确位置：在
/etc/nginx/nginx.conf的http块内，或/etc/nginx/sites-enabled/beego.conf - 示例片段：
upstream beego_backend { server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; server 127.0.0.1:8081 max_fails=3 fail_timeout=30s; server 127.0.0.1:8082 max_fails=3 fail_timeout=30s; } - 别漏掉
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，否则单个 Beego 实例卡住（比如 GC STW 或 DB 连接池耗尽）会导致用户直面超时或 502 - 若用
ip_hash，必须同步加proxy_set_header X-Real-IP $remote_addr，否则ctx.Input.IP()取到的是127.0.0.1
Beego 必须暴露 /healthz 供 Nginx 被动健康检查
Nginx 默认不主动探测后端存活，靠请求失败次数踢节点。但 Beego 默认 panic 不 recover，一次未捕获 panic 就导致进程退出，Nginx 下次请求直接 502 —— 这不是负载均衡，是单点雪崩。
- 在 Beego 路由中注册一个轻量健康接口，例如：
beego.Router("/healthz", &HealthController{}, "get:Check") // Check 方法只 return nil，不查 DB、不调外部服务 - Nginx 配置中可配合
proxy_pass http://beego_backend/healthz做人工巡检，但更推荐用被动检查 + 合理的max_fails/fail_timeout - 确保 Beego 的
Recovery中间件已启用（默认开启），避免 panic 波及整个进程 - 不要在
/healthz里做 DB 连接检测——它应该秒级返回，否则反而拖慢 Nginx 探测节奏
最易被忽略的一点：Beego 日志里的客户端 IP、Host、协议信息，全依赖 Nginx 正确透传 X-Real-IP、X-Forwarded-For、X-Forwarded-Proto。少配一个头，就可能让鉴权、重定向、CDN 缓存策略全部失效。这不是“能跑就行”的配置，而是每条请求上下文的基石。
