proxy_pass本身不提供会话保持，需配合ip_hash（依赖ip稳定性）或sticky cookie（推荐nginx-sticky-module-ng模块，基于srv_id cookie实现用户粒度粘性）等机制确保同一用户请求路由至同一后端。
理解 proxy_pass 与会话保持的关系
proxy_pass 本身只是将请求转发给后端服务器，不自带会话保持能力。在集群环境下，多个后端节点共享用户状态（如登录态）时，若请求被轮询到不同机器，会导致 session 丢失、反复登录等问题。因此需配合其他机制实现“同一用户始终打到同一台后端”。
使用 ip_hash 实现基于客户端 IP 的会话绑定
这是最简单直接的方式，Nginx 根据客户端真实 IP 的哈希值决定转发目标，确保同一 IP 的请求总落在同一台后端。
- 仅适用于四层负载场景，要求客户端 IP 稳定（不经过多层 NAT 或代理）
- 配置示例：
upstream backend { ip_hash; server 192.168.1.10:8080; server 192.168.1.11:8080; } - 注意：如果用户通过公网出口 NAT（如企业网关、移动网络），大量用户可能映射为同一个公网 IP，导致负载严重倾斜
启用 sticky cookie 实现应用层会话粘性
利用第三方模块 nginx-sticky-module 或官方商业版的 ngx_http_upstream_module（含 sticky 指令），让 Nginx 在响应中注入一个加密 cookie（如 route=xx），后续请求携带该 cookie 即被固定路由。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 推荐使用开源增强版：nginx-sticky-module-ng（兼容较新 Nginx 版本）
- 配置示例：
upstream backend { sticky name=route expires=1h domain=.example.com path=/; server 192.168.1.10:8080; server 192.168.1.11:8080; } - 优点：不受 IP 变化影响；支持失效自动重选；可配合健康检查
后端统一管理 Session（更现代的解法）
真正高可用的集群应避免依赖前端粘性，而是把 session 存到外部存储（如 Redis、Memcached），所有后端实例共享读写。
- Nginx 不需要做任何特殊配置，正常 proxy_pass 即可
- 后端应用集成 Spring Session、PHP Redis 扩展或自研 session 中间件
- 优势明显：扩容缩容无感知；单点故障不影响会话；便于灰度和 AB 测试
- 注意点：确保 session 序列化兼容、过期策略一致、Redis 高可用部署
补充：获取真实客户端 IP 并透传
若后端需识别真实用户 IP（用于日志、风控、限流等），不能只靠 $remote_addr（可能是上一跳代理地址），需配置：
- 在 proxy_pass 前添加头信息：
proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;
- 后端应用需从这些 header 中读取原始 IP，而非直接用 remote_addr
- 生产环境建议限制 trusted IPs，防止伪造（使用 set_real_ip_from + real_ip_header）
