proxy_set_header X-Real-IP 仅传递客户端最原始IP，不记录代理路径；还原完整链路需依赖X-Forwarded-For逐层追加及realip模块可信段解析。
使用 proxy_set_header X-Real-IP 本身并不能还原“多层代理的真实路径”，它只能传递**客户端最原始的 IP 地址**（即用户直连第一层代理时的源 IP）。要还原完整代理链路（如 X-Forwarded-For 那样的路径），需配合其他头部和 Nginx 配置逻辑，且必须确保每层代理都正确透传、不覆盖关键字段。
理解 X-Real-IP 和 X-Forwarded-For 的分工
X-Real-IP 是 Nginx 常用的自定义头部，通常由最外层反向代理（如 CDN 或负载均衡器）设置为它看到的客户端真实 IP，并在转发给后端时通过 proxy_set_header X-Real-IP $remote_addr 传下去。但它只保留一个 IP，不记录中间跳数。
X-Forwarded-For 才是标准的“路径型”头部：每经过一层可信代理，就追加当前请求的 $remote_addr（逗号分隔），形成类似 203.0.113.5, 192.168.10.20, 10.1.1.1 的链路。
确保每层代理都正确追加 X-Forwarded-For
若想还原完整路径，所有中间代理（包括 Nginx、HAProxy、Cloudflare、ALB 等）必须：
• 不覆盖已有 X-Forwarded-For，而是追加（不是替换）
• 仅信任来自内网或已知上游的请求，避免伪造
• 在 Nginx 中典型配置如下：
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
set $xff $http_x_forwarded_for;
if ($xff = "") {
set $xff $remote_addr;
}
proxy_set_header X-Forwarded-For "$xff, $remote_addr";
⚠️ 注意：此写法仅适用于单层代理追加；多层部署时，更安全的做法是用 map 指令或启用 realip 模块做可信段解析。
用 realip 模块识别并还原真实客户端 IP
Nginx 的 ngx_http_realip_module 可根据可信代理网段，自动从 X-Forwarded-For 中提取最左/最右的有效客户端 IP，并重写 $remote_addr。这是还原“真实 IP”的推荐方式，比手动读取 X-Real-IP 更可靠：
- 在
http或server块中声明可信代理段：set_real_ip_from 10.0.0.0/8;<br>set_real_ip_from 172.16.0.0/12;<br>set_real_ip_from 192.168.0.0/16;
- 指定来源头部：
real_ip_header X-Forwarded-For;<br>real_ip_recursive on;
（启用递归解析，取最左非可信 IP） - 配置生效后，
$remote_addr就是真实客户端 IP，日志、限流、访问控制均可直接使用
后端服务如何安全使用这些信息
不要无条件信任任意 X-Real-IP 或 X-Forwarded-For 字段：
• 后端应只接受来自 Nginx（或最终反向代理）传入的头部，且该 Nginx 必须已启用 realip 模块做过滤
• 若后端语言为 Python（Flask/Django）、Node.js（Express）等，需配合中间件校验 X-Forwarded-For 长度与可信跳数，或直接读取经 realip 处理后的 REMOTE_ADDR
• 日志中建议同时记录 $remote_addr（已还原）、$http_x_forwarded_for（原始链路）、$http_x_real_ip（若存在）三者，便于审计追踪
