Nginx 中 X-Forwarded-For 链的处理机制
在 nginx 处理多级代理时，x-forwarded-for (xff) 头部的处理逻辑是追加客户端 ip 到现有头部末尾。默认情况下，nginx 不会自动清理或覆盖已有的 xff 值，而是将当前请求的源 ip 附加到该列表之后。这意味着如果上游代理已经设置了 xff，nginx 会保留原有内容并追加新 ip；若未设置，则直接创建新的 xff 字段。这种追加行为确保了 ip 链的完整性，但也可能导致伪造或重复 ip 的问题，需通过配置干预来保证安全性。
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
# 关键配置：追加客户端真实IP到XFF
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}上述配置展示了标准做法。变量 $proxy_add_x_forwarded_for 会自动检查请求中是否已存在 X-Forwarded-For 头。如果存在，它将原值与当前连接地址拼接，用逗号分隔；如果不存在，它仅包含当前连接地址。这构成了多级代理的基础链路。
如何防止客户端伪造 XFF 头部
为了防止恶意客户端直接发送伪造的 X-Forwarded-For 头部来隐藏真实 IP，Nginx 需要配置为忽略不可信的来源 IP 所携带的 XFF 头。通常的做法是结合 real_ip 模块或使用条件判断，只信任来自已知反向代理（如负载均衡器）的请求。当请求来自非信任 IP 时，应丢弃其自带的 XFF 信息，重新构建干净的链条。
# 假设后端应用位于 192.168.1.100 # 此配置用于第二层代理，信任第一层代理传来的IP set_real_ip_from 192.168.1.100; real_ip_header X-Forwarded-For; real_ip_recursive on;
这段代码片段演示了如何使用 ngx_http_real_ip_module。指令 set_real_ip_from 指定了受信任的上游代理 IP 地址。当请求来自该 IP 时，Nginx 会解析 X-Forwarded-For 中的最后一个 IP 作为客户端真实 IP，并更新 $remote_addr。配合 real_ip_recursive on，它可以递归地处理多层嵌套的代理情况，确保最终获取的是最前端的真实用户 IP，而不是中间跳过的代理 IP。
特定输入下 XFF 链的最终结果验证
基于上述程序，当客户端 IP 为 1.2.3.4，经过第一层代理（IP: 5.6.7.8），再到达第二层代理（IP: 9.10.11.12）时，最终的 XFF 链取决于各层的配置。如果所有层都使用默认的 $proxy_add_x_forwarded_for，且没有启用 real_ip 模块进行重写，那么最终后端收到的 XFF 将是 1.2.3.4, 5.6.7.8, 9.10.11.12。然而，如果第二层代理启用了 real_ip 并信任第一层，它可能会将 $remote_addr 重置为 1.2.3.4，然后在传递给后端时再次追加，导致链的正确性依赖于每一层的正确配置。
# 模拟测试脚本 (Python requests)
import requests
headers = {'X-Forwarded-For': '10.0.0.1'}
response = requests.get('http://nginx-proxy/api', headers=headers)
print(response.headers.get('X-Forwarded-For'))
# 输出取决于 Nginx 配置:
# 若未过滤: 10.0.0.1, [Nginx_IP]
# 若过滤非信任IP: [Nginx_IP]这个测试用例展示了客户端主动注入 XFF 头的情况。如果 Nginx 配置了严格的信任列表，且客户端 IP 不在其中，Nginx 可能会忽略 10.0.0.1，只记录自己的 IP。反之，如果配置宽松，该伪造 IP 将被追加到链中。开发者应根据实际网络拓扑调整 set_real_ip_from 和 proxy_set_header 的组合，以确保安全与准确。
