Nginx配置方法是什么-负载均衡如何获取真实IP

教程大全 2026-02-24 09:04:24 浏览次

在负载均衡架构下，后端服务器默认只能获取到负载均衡节点的IP地址，要准确获取客户端真实IP，必须根据传输协议层级（七层HTTP或四层TCP），分别配置 HTTP头字段传递 或 Proxy Protocol协议 ，并在后端服务器上严格设置可信代理列表以防止IP伪造，这不仅是日志记录的需求，更是基于IP访问控制、安全审计及用户画像分析的基础设施保障。

为什么默认获取不到真实IP

在标准的负载均衡部署模式中，客户端请求并不会直接发送给后端服务器，而是先到达负载均衡器（如Nginx、HAProxy、F5或云厂商的SLB），负载均衡器作为反向代理，接收客户端请求后，会与后端服务器建立新的TCP连接，在这个新连接中，源IP地址自然变成了负载均衡器的内网IP，而后端服务器看到的 remote_addr 也就是负载均衡器的IP，这种机制是TCP/IP协议栈的天然行为，因此需要额外的“透传”机制来携带原始客户端IP信息。

七层HTTP/HTTPS解决方案

对于基于HTTP或HTTPS协议的七层负载均衡，获取真实IP最通用的方案是利用HTTP头字段，这不需要修改底层网络栈,通过应用层协议扩展即可实现。

X-Forwarded-For（XFF） 是目前事实上的行业标准，当负载均衡器接收到客户端请求时，它会将客户端的IP追加到XFF头中，格式通常为： X-Forwarded-For: <客户端IP>, <上一级代理IP> ，如果请求经过了多层代理，这个列表会不断增长，后端服务器在解析时,通常取该列表的第一个IP作为客户端原始IP。

除了XFF，头字段也常被使用，与XFF记录链路不同，X-Real-IP通常只记录直接发起连接的客户端IP，在单层代理架构中，X-Real-IP往往更直观，但在多层CDN或代理穿透场景下,XFF能提供更完整的链路信息。

四层TCP/UDP解决方案

在四层负载均衡（如LVS、TCP模式的ELB）中，流量是基于IP包和TCP端口转发的，负载均衡器无法修改HTTP内容，因此XFF方案完全失效，此时必须采用 Proxy Protocol 协议或 TOA（TCP Option Address） 模块。

Proxy Protocol 是HAProxy提出的一种协议，在TCP连接建立时，代理会在发送真实数据前，先发送一段包含源IP、目的IP、源端口和目的端口的小文本头或二进制头，这要求后端服务器（如Nginx或HAProxy）必须开启Proxy Protocol解析功能,否则会将这段头信息当作正常数据处理导致错误。

TOA（TCP Option Address） 则是腾讯云等部分云厂商提出的内核级解决方案，它通过在TCP协议头的Options字段中携带客户端IP信息，后端服务器通过加载特定的内核模块（如），在系统调用层面直接获取真实IP，这种方式对应用层完全透明，性能损耗极低,但需要修改服务器操作系统内核。

安全防护与最佳实践

获取真实IP最大的风险在于 IP伪造 ，HTTP头字段是可以被客户端随意伪造的，如果后端服务器直接信任XFF头中的任意IP,攻击者可以轻易绕过基于IP的安全限制。

必须遵循 可信代理原则 ，后端服务器应配置一个“可信IP列表”，仅当请求的物理连接IP（即 remote_addr ）位于该列表中（例如是已知的负载均衡器内网IP）时，才去解析XFF头或Proxy Protocol中的IP，如果物理连接IP本身就是外网IP，说明请求并未经过负载均衡，此时应直接使用物理连接IP，忽略XFF头,防止欺骗。

在日志分析中，建议同时记录 物理连接IP 和 解析出的真实IP ，这有助于在排查故障时,区分是客户端问题还是负载均衡器本身的连接问题。

常见配置实战（Nginx环境）

在Nginx作为后端接收流量时，正确配置是关键，确保安装了 ngx_http_realip_module 模块。

在Nginx配置文件的段或具体段中,设置负载均衡器的内网IP为可信：

set_real_ip_from 192.168.1.0/24; # 假设这是负载均衡器的网段set_real_ip_from 10.0.0.1;# 或者是具体的SLB IPreal_ip_Header X-Forwarded-For; # 指定使用XFF头real_ip_recursive on;# 递归查找，从右向左匹配最右侧的非内网IP

配置完成后，Nginx的 $remote_addr 变量就会自动替换为经过验证的客户端真实IP，日志格式无需修改即可生效，对于四层Proxy Protocol，则需在Nginx的块中配置 listen 80 proxy_protocol; 。