Nginx反向代理丢失真实IP3行配置搞定X-Forwarded-For转发问题最近在帮客户排查一个API网关问题时发现日志里所有请求的客户端IP都显示为内网地址。这显然不对劲——用户明明是从公网访问的为什么后端服务看到的全是反向代理服务器的IP如果你也遇到过类似问题这篇文章就是为你准备的。1. 为什么反向代理会丢失真实IP当Nginx作为反向代理工作时默认会将客户端请求转发给后端服务器但后端服务看到的客户端实际上是Nginx本身。这就好比快递员代收包裹时商家只能看到快递站的信息而不知道原始寄件人是谁。这种设计在大多数场景下没问题但当我们需要记录真实用户行为实现基于IP的访问控制分析地域分布数据防止恶意请求时获取真实IP就变得至关重要。以下是典型的错误日志表现2024/03/15 10:23:45 [error] 1234#1234: *5678 client 192.168.1.100 tried to access /admin, while 192.168.1.100 is our internal LB address!2. 核心解决方案X-Forwarded-For机制HTTP协议通过X-Forwarded-For(XFF)头部传递原始客户端IP其工作原理如下客户端(1.2.3.4) → 代理1(10.0.0.1) → 代理2(10.0.0.2) → 你的服务器 X-Forwarded-For: 1.2.3.4, 10.0.0.1在Nginx配置中我们需要确保接收请求时保留已有XFF信息追加当前客户端IP将完整信息传递给后端2.1 基础配置模板location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://backend; }关键点解释$remote_addr是直接连接的客户端IP$proxy_add_x_forwarded_for会自动处理已有和新增的XFF信息3. 实战验证与排错技巧3.1 使用curl测试配置验证配置是否生效的最佳方式curl -H X-Forwarded-For: 8.8.8.8 http://your-nginx-server/test然后在后端服务检查日志应该看到类似Received request from 8.8.8.8 via 10.0.0.1 (X-Forwarded-For: 8.8.8.8, 192.168.1.100)3.2 常见问题排查表现象可能原因解决方案看到多个IP存在多级代理取XFF第一个IP全是内网IP配置未生效检查proxy_set_header位置显示为::1IPv6回环地址检查listen指令4. 高级场景配置指南4.1 处理多级代理的情况当请求经过CDN→LB→Nginx时建议set_real_ip_from 10.0.0.0/8; real_ip_header X-Forwarded-For; real_ip_recursive on;这样Nginx会自动解析最外层的客户端IP。4.2 安全注意事项IP伪造防护# 只信任特定代理 set_real_ip_from 192.168.1.0/24;日志格式优化log_format main $remote_addr - $http_x_real_ip [$time_local] $request;限制XFF长度proxy_set_header X-Forwarded-For $http_x_forwarded_for, $remote_addr; if ($http_x_forwarded_for ~* ^(.{1,100},){10}) { return 403; }5. 性能优化建议虽然XFF处理很轻量但在超高并发场景下使用变量缓存map $http_x_forwarded_for $client_real_ip { default $http_x_forwarded_for; $remote_addr; }减少正则匹配# 不推荐 if ($http_x_forwarded_for ~* spammer) { return 403; } # 推荐使用geo模块 geo $bad_ip { default 0; 1.2.3.4 1; include blacklist.conf; }考虑使用$binary_remote_addr替代文本IP最近在帮一个电商客户优化日志系统时发现他们的IP解析消耗了15%的CPU资源。改用上述方案后不仅解决了真实IP问题还提升了8%的请求处理能力。