nginx在多级代理链中需显式配置每层职责：首层还原真实ip，中间层仅透传头信息，末层设置x-real-ip并禁用x-forwarded-for自动拼接；硬编码转发、头字段错传、超时参数未对齐是三大典型错误。
Nginx 在多重多级虚拟代理链中，没有“自动理清”的能力，所有转发行为、头信息处理、IP识别都依赖显式配置。所谓“完美理清”，本质是厘清每一跳的职责边界，并让每层只做它该做的事——不越界、不遗漏、不叠加。
以下从实际表现细节出发，聚焦 Nginx 基础核心模块（http_core、ngx_http_proxy_module、ngx_http_realip_module）在多级链路中的关键控制点：
明确每层代理的唯一角色定位
多级链路不是“越多越好”，而是“每层必有明确身份”。常见错误是中间层既改头又修 IP，导致后端拿到混乱字段。
-
首层（接公网/CDN）：负责还原真实客户端 IP，信任上游可信段（如 Cloudflare 的
173.245.48.0/20），启用real_ip_recursive on，把$remote_addr替换为链路末端的真实用户 IP。 -
中间层（如网关/Nginx LB）：只做路由分发或鉴权，不追加
X-Forwarded-For，不启用real_ip，仅透传头：proxy_pass_request_headers on;+ 精确覆盖Host和X-Real-IP。 -
末层（直连应用）：必须设置
proxy_set_header X-Real-IP $remote_addr;，且$remote_addr应已是上一层修正后的值；同时禁用X-Forwarded-For的自动拼接（避免a,b,c多段）。
硬编码转发实例中必须规避的三个典型错位
硬编码指在 proxy_pass 或 set 指令中写死 IP/域名/路径，看似稳定，实则极易在多级下失效：
-
proxy_pass http://10.0.0.5:8080;写死内网地址 → 若后端迁移或扩缩容，需逐台改配置，无法与服务发现联动；建议用upstream块封装，配合健康检查。 -
proxy_set_header Host $host;放在中间层 → 可能将 CDN 传来的源站域名（如origin.example.com）透传下去，后端生成重定向 URL 出错；应改为proxy_set_header Host $http_host;或按业务需要固定为backend.example.com。 -
set $backend "http://$arg_env.app.internal";用变量拼接proxy_pass→ Nginx 不支持变量在proxy_pass中用于 HTTP 协议（会报错或降级为字符串匹配），必须用map预定义或改用upstream+split_clients。
头字段传递必须遵循“单向可信链”原则
X-Forwarded-For 不是日志字段，是参与逻辑判断的输入源；但它的值不可信，除非你控制整条链。
- 后端程序绝不能直接解析
X-Forwarded-For字符串取第一个 IP。正确做法是：只读取 Nginx 注入的X-Real-IP（由real_ip模块修正后生成），或直接信任$remote_addr。 - 所有中间层若需透传原始
X-Forwarded-For，应使用proxy_set_header X-Forwarded-For $http_x_forwarded_for;（注意是$http_x_forwarded_for，非$proxy_add_x_forwarded_for），后者会无条件追加当前$remote_addr，造成累加污染。 - 若某层是透明代理（如运维调试用的临时跳板），务必在该层禁用所有
proxy_set_header和real_ip，避免干扰链路语义。
超时与连接参数必须逐层对齐而非默认继承
一个请求经过 A→B→C 三层 Nginx，若只有 C 层设了 proxy_read_timeout 300;，A 和 B 仍用默认 60 秒，则 A 层 60 秒就断开连接，返回 504，B/C 根本没机会响应。
- 每层都应显式设置：
-
proxy_connect_timeout 10; -
proxy_send_timeout 60; -
proxy_read_timeout 60;
-
- 同时确保
keepalive_timeout与后端服务的连接复用策略兼容（如 Spring Boot 默认 keep-alive 是 60 秒，Nginx 也应设为 ≤60）。
不复杂但容易忽略。
