nginx反向代理高可用核心在于“转发逻辑+健康保障+故障兜底”三层，需扎实配置upstream、精准传递请求头、并逐步演进至主备或集群架构。
用 Nginx 实现反向代理高可用，核心不是堆配置，而是理清“转发逻辑 + 健康保障 + 故障兜底”这三层。它不依赖复杂算法，关键在配置扎实、反馈及时、切换可靠。
反向代理是高可用的第一道防线
反向代理本身不是高可用，但它为高可用提供了基础结构：客户端只认 Nginx，后端服务器可随时增减或下线，只要 Nginx 能把请求正确转过去并拿回响应，服务就“看起来”在线。
- 隐藏真实服务地址，避免客户端直连单点，天然隔离故障面
- 所有流量经由 Nginx 统一入口，便于集中做限流、鉴权、日志审计
- 配合 upstream 模块，自然过渡到多实例部署，无需改业务代码
upstream 配置决定负载是否真正可用
光写几个 server 不等于负载均衡生效；真正起作用的是 upstream 块里的参数设计，尤其是健康检查和容错机制。
- 必须显式定义 upstream 块，不能只靠 proxy_pass 写死单个地址
- 每个 server 后建议加 max_fails=2 fail_timeout=30s，让 Nginx 主动踢出连续失败的节点
- 加上 backup 标记备用服务器，主集群全挂时自动切过去（非轮询模式下才生效）
- 若后端支持主动心跳，可配 health_check interval=3 fails=2 passes=2（需启用 stream 模块或 http health check 模块）
proxy_pass 和请求头传递必须精准
转发出去的请求如果丢了原始信息，后端可能无法正确路由、鉴权或记录日志，导致“看似通了，实则异常”。
- proxy_pass 的 URL 末尾斜杠影响路径重写：proxy_pass http://backend/ 会截掉 location 匹配前缀；proxy_pass http://backend 则原样拼接
- 必设三项 header：X-Real-IP $remote_addr（真实客户端 IP）、X-Forwarded-For $proxy_add_x_forwarded_for（保留原始链路）、Host $host（防止后端因 Host 不匹配返回 404）
- 如后端是 HTTPS 服务，还需加 proxy_set_header X-Forwarded-Proto $scheme，否则可能跳转出错或混合内容警告
单 Nginx 实例不是高可用，但它是可扩展的起点
Nginx 本身不提供集群同步能力，所谓“高可用”指的是整个链路具备故障转移能力。单台 Nginx 是常见起点，后续演进有明确路径：
- 先确保单台 Nginx + 多后端能稳定运行，并开启 access_log 和 error_log 定向分析
- 再用 Keepalived 或云厂商 VIP 实现 Nginx 主备，避免代理层单点
- 进阶可上 Kubernetes Ingress Controller 或 Nginx Plus，支持动态 upstream、API 管控和更细粒度健康检查
- 所有环节都要配监控：Nginx 状态页（stub_status）、后端响应时间、5xx 错误率、upstream 状态变化告警
