Beego 服务不参与 upstream 配置，仅监听本地端口；upstream 必须由 Nginx 独立配置，二者完全解耦。需避免硬编码端口、漏配 proxy_next_upstream、激进健康检查等三大误区，并提供 /healthz 健康接口配合 Nginx 被动检查。
Beego 服务本身不参与 upstream 配置
Beego 是一个 Go 语言 Web 框架，它运行时只监听本机某个端口（比如 :8080），不提供服务发现、健康检查或动态 upstream 管理能力。所谓“集成 Nginx”，其实是部署层面的配合：Nginx 做反向代理和负载分发，Beego 实例只管处理 HTTP 请求。
常见误区是试图在 app.conf 或 Beego 启动代码里写 upstream 地址——这毫无意义，Nginx 的 upstream 块必须写在 /etc/nginx/nginx.conf 或 sites-enabled/ 下的配置文件中，与 Beego 代码完全解耦。
- Beego 启动后只暴露一个本地监听点，水平扩展靠起多个进程/容器，每个绑定不同端口或由宿主随机分配
- Beego 的
Router、MiddleWare、Recovery等机制无法替代 Nginx 的连接复用、SSL 卸载、缓冲区控制等网络层功能 - 如果你用
bee run启动开发服，端口固定；生产环境务必改用./myapp启动，并配合 systemd 或 Docker 管理生命周期
upstream 配置必须避开的三个硬伤
Nginx 主动踢节点依赖探测反馈，而 Beego 默认对 panic 不做 recover，一次未捕获 panic 就导致整个进程退出，Nginx 探测失败后立即摘除该节点——但若没配好容错策略，用户会直接看到 502 Bad Gateway。
- 漏配
proxy_next_upstream error timeout http_500 http_502 http_503 http_504：当 Beego 因 GC STW、DB 连接池耗尽或慢查询卡住时，Nginx 不会自动重试其他节点 -
max_fails=1 fail_timeout=10s太激进：Beego 启动初期可能有短暂不可用（如 DB 连接未就绪），建议设为max_fails=3 fail_timeout=30s - 用了
ip_hash却没加proxy_set_header X-Real-IP $remote_addr：Beego 的ctx.Input.IP()取到的是 Nginx 本机地址，不是真实客户端 IP
Beego 实例端口不能写死在代码里
开发期和生产期的端口管理逻辑完全不同。硬编码 beego.BConfig.Listen.HTTPPort = 8080 会导致多实例冲突或 Nginx 配置频繁变更。
- 开发调试：用
http.ListenAndServe(":0", nil)让系统自动分配空闲端口，再通过l.Addr().Port打印出来，人工填入 Nginx 配置 - Docker 部署：Dockerfile 中不写
EXPOSE 8080，运行时用-p 8080让宿主随机映射，然后用docker port <container>查实际端口 - Kubernetes：Beego 应用走 Service ClusterIP，Nginx Ingress Controller 自动同步 endpoints，
upstream列表完全不用手动维护
健康检查接口要自己暴露并返回结构化状态
Nginx 自带的 TCP 层健康检查（仅连通性）不够用。Beego 需主动提供一个轻量级 HTTP 健康端点，比如 /healthz，返回 JSON 并包含关键指标。
- 响应体示例：
{"status":"ok","mem_percent":65.2,"db_connected":true,"uptime_sec":1247} - 在 Beego 路由中注册：
beego.Router("/healthz", &HealthController{}, "get:Health") - Nginx 配置中启用主动检查需用
nginx-plus或lua-resty-healthcheck模块，标准版 Nginx 只支持被动检查（靠失败请求计数） - 若用 passive 检查，确保 Beego 在 panic 时能快速退出进程（靠 systemd 的
Restart=always或 Kubernetes 的 livenessProbe 触发重建）
proxy_next_upstream 的组合使用——没这俩，再多的 Beego 实例也撑不住真实流量冲击。 
