nginx多级代理需分层分工：边缘层缓存静态资源并净化头信息，中心层做流量仲裁与缓存锁控制，源站校验请求合法性；会话保持应优先用业务标识（如cookie中的user_id）哈希路由，而非ip_hash；需统一规范头信息透传与purge主动失效机制。
Nginx 在多级代理环境下实现请求分发与保持，关键在于明确各层角色、隔离缓存职责、保障会话连续性，并避免头信息污染或策略冲突。不是简单堆叠 proxy_pass，而是按“边缘→中心→源站”逐层分工，让每层只做它该做的事。
分层定位与核心职责划分
边缘代理层（如 CDN 节点或区域 Nginx）面向终端用户，专注高频静态资源缓存与快速响应；中心代理层（如骨干网 Nginx 集群）不追求高命中率，而是做流量仲裁：控制回源节奏、执行灰度路由、统一健康检查、下发 purge 指令；源站只响应可信请求，返回带明确 Cache-Control 的响应，不处理 If-Modified-Since 等协商逻辑。
- 边缘层禁用对带 Cookie 或 Authorization 头的响应缓存，防止用户态数据混入共享缓存
- 中心层启用 proxy_cache_lock on，避免缓存失效时大量并发穿透打垮源站
- 源站通过校验 X-Forwarded-By: nginx-center 确认请求合法性，拒绝直连
会话保持需分场景设计
并非所有场景都适合 ip_hash。真实生产中，NAT 环境、IPv6、移动端 IP 频繁变化都会导致会话漂移。更稳妥的方式是结合业务标识做路由锚点：
- 对登录态强依赖的服务，建议由上游服务注入唯一 trace_id 或 user_id 到 Cookie，再用 map 指令提取并 hash 路由：
map $cookie_user_id $backend_key { default "default"; ~.+(?P<id>\d+) $id; }</id>
然后 upstream 中使用 hash $backend_key consistent - 若必须用客户端 IP，应改用 $binary_remote_addr（而非 $remote_addr），减少 IPv6 地址哈希散列偏差
- 无状态 API 接口无需会话保持，直接用 least_conn 更利于负载均衡
多级转发中的请求头净化与透传
每层代理都可能添加或覆盖请求头，若未统一规范，会导致后端误判来源、缓存 key 错乱或安全策略失效：
- 边缘层应清除 utm_*、__t、_ga 等跟踪参数（用 proxy_cache_key 过滤），但保留 X-Real-IP 和 X-Forwarded-For
- 中心层需重写 X-Forwarded-For：追加自身 IP，同时确保不重复拼接（用 $proxy_add_x_forwarded_for 而非手动拼）
- 所有层级统一设置：
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
缓存一致性与主动失效协同
多级缓存天然存在 stale 窗口，仅靠 max-age 无法满足发布一致性要求：
- 发布新版本时，向中心代理发送 PURGE /static/js/app.js 请求（需加载 ngx_http_cache_purge_module）
- 边缘层配置 proxy_cache_use_stale updating，后台更新缓存时继续返回旧内容，不阻塞用户
- 对首页 HTML 等关键资源，源站返回 Cache-Control: private, no-store，强制跳过所有代理缓存
