nginx生产环境upstream配置须置于http块内，命名语义化（如api_production_v2），按业务选算法（ip_hash会话保持、weight适配性能差异、least_conn应对长连接），必配max_fails=3 fail_timeout=30s健康检查及backup/down容错，并支持混合地址类型与dns动态解析。
在生产环境中用 upstream 块定义后端服务器集群，核心是兼顾稳定性、可维护性与业务适配性。它不只是罗列几台 IP，而是要结合健康检查、容错机制、负载策略和部署实际来配置。
必须放在 http 块内，且命名需语义清晰
upstream 不能写在 server 或 location 里，必须置于全局 http 块中（如 /etc/nginx/nginx.conf 的 http { ... } 内部）。名称建议体现用途和环境，比如：
upstream api_production_v2 { ... }upstream dashboard_backend_stable { ... }
避免用泛化名如 backend 或 server1，方便后续排查和多集群共存。
根据业务选合适的负载算法
默认轮询适合节点性能一致的场景；但生产中更常按需选择：
- 需要会话保持（如登录态依赖本地 session）→ 启用
ip_hash;，注意此时不能配weight或backup - 后端节点性能差异大（如 2 台 8C16G + 1 台 4C8G）→ 用加权轮询：
server 192.168.2.10:8080 weight=4;、server 192.168.2.11:8080 weight=2; - 长连接多、响应时间波动大 → 优先用
least_conn;，让新请求落到当前连接最少的节点
必配健康检查与容错参数
生产环境不能只靠“转发就完事”，要让 Nginx 主动识别并隔离故障节点：
-
max_fails=3 fail_timeout=30s：30 秒内连续失败 3 次，该节点被标记为不可用，30 秒内不再转发请求 -
backup：为关键服务配 1 台备用机，仅当所有主节点都不可用时才启用（慎用于有状态服务） -
down：维护前手动加，如server 192.168.2.12:8080 down;，无需 reload 即刻生效 - 若后端通过域名注册（如 Kubernetes Service 或云厂商 SLB）→ 加
resolve并配合resolver指令实现 DNS 动态更新
支持混合地址类型，适配不同部署形态
一个 upstream 组可混用多种后端地址，灵活对接各类基础设施：
- 物理机或 ECS：
server 10.0.1.5:3000; - K8s ClusterIP 或 Headless Service：
server myapp-svc.default.svc.cluster.local:80; - 本地 UNIX socket（高性能低延迟场景）：
server unix:/var/run/app.sock; - Docker 网络别名：
server app-container:8080;（需确保 Nginx 与容器同网络）
注意：使用域名时，必须在 http 块顶部配置 resolver，例如 resolver 10.0.0.2 valid=30s;，否则启动会报错。
