在互联网架构中，服务器获取客户端IP地址是一个看似简单实则涉及网络协议、代理架构及安全策略的复杂过程。核心上文归纳在于：服务器不能仅依赖单一的网络层连接信息，而必须结合HTTP头部字段（如X-Forwarded-For）与反向代理配置，通过多层级验证逻辑来提取真实IP，同时需警惕IP伪造风险。
直接通过TCP连接获取的源IP通常仅代表直接连接到服务器的上一跳设备地址，而非真实的用户客户端，在现代Web架构中，用户请求往往经过CDN、WAF、负载均衡器等多层中间节点，获取真实IP的核心在于追踪请求的完整链路，并正确解析代理服务器添加的头部信息。
网络传输层基础：REMOTE_ADDR的局限性
在最基础的网络通信层面，服务器通过TCP/IP协议接收数据包，当TCP三次握手完成后，服务器操作系统可以获取到对端的Socket地址，在Web服务器（如Nginx、Apache）或应用语言环境（如Java、PHP）中，这个地址通常被映射为环境变量 REMOTE_ADDR。
REMOTE_ADDR 是最底层、最无法伪造的地址来源，因为它是由操作系统内核基于网络包物理连接确定的，它的局限性在于：它永远只代表直接与服务器建立连接的客户端IP，如果用户直接访问服务器，这就是真实IP；但如果用户经过了代理，REMOTE_ADDR 就会变成代理服务器的IP,单纯依赖此参数在复杂的网络拓扑中无法满足业务需求。
HTTP头部协议：X-Forwarded-For 与 X-Real-IP
为了解决代理掩盖真实IP的问题，业界制定了标准的HTTP头部字段来传递原始客户端信息，其中最关键的是 X-Forwarded-For (XFF) 和 X-Real-IP。
X-Real-IP 通常只包含一个IP地址，即发起请求的客户端真实IP，它通常由离用户最近的第一层代理（如Nginx）设置。
X-Forwarded-For 则更为复杂且强大，其格式为：X-Forwarded-For: clientIP, proxy1IP, proxy2IP，这是一个逗号分隔的IP列表，记录了请求经过的每一个节点，最左边的IP是最原始的客户端IP，向右依次是经过的各级代理IP，在获取逻辑中,我们通常取该列表中最左侧的非内网IP作为候选真实IP。
反向代理配置：Nginx 与 HAProxy 的正确设置
要让服务器能够获取到正确的头部信息，反向代理服务器必须被正确配置，以最常用的Nginx为例，默认情况下它不会自动传递这些头部,需要在配置文件中显式声明。
在Nginx的 location 或 server 块中,需要配置以下指令：
proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
这里，$proxy_add_x_forwarded_for 变量非常关键，它会将客户端发来的原有XFF内容与当前层的 REMOTE_ADDR 拼接，形成完整的链路记录，如果缺少这一步，后端服务器将只能看到负载均衡器的IP，导致链路断裂，对于HAProxy或其他负载均衡设备，也有类似的 forwardfor 选项需要开启。
应用层获取逻辑与代码实现
在应用服务器端，获取IP的逻辑应当遵循“信任链验证”原则，开发者不能盲目信任HTTP头部，因为HTTP头部可以被客户端伪造，攻击者可以手动发送带有虚假 X-Forwarded-For 的请求。
专业的获取逻辑应包含以下步骤：
- 检查 REMOTE_ADDR 是否为内网IP或已知的可信代理IP。
- REMOTE_ADDR 是可信代理，则检查 X-Forwarded-For 头部。
- 解析 X-Forwarded-For 列表，从右向左遍历，剔除掉已知的可信代理IP（如CDN节点IP、公司内网网关IP）。
- 剩下的最左侧IP即为真实客户端IP。
以Java Spring Boot为例,一个健壮的获取工具类逻辑如下：
public String getClientIp(HttpServletRequest request) {
String ip = request.getHeader("X-Forwarded-For");
if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
ip = request.getHeader("X-Real-IP");
}
if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
ip = request.getRemoteAddr();
}
// 处理多级代理的情况，取第一个非内网IP
int index = ip.indexOf(',');
if (index != -1) {
ip = ip.substring(0, index).trim();
}
return ip;
}
安全挑战与IP伪造防范
在获取IP的过程中，安全性是重中之重。X-Forwarded-For 最大的隐患在于它是客户端可控的。 如果攻击者发送请求时直接设置 X-Forwarded-For: 1.1.1.1，而服务器没有经过代理直接接收，或者配置不当，服务器就会误认为客户端IP是 1.1.1.1。
为了防范这一点，必须实施严格的白名单机制，服务器应当只信任来自特定IP段（如CDN服务商提供的IP段）的 X-Forwarded-For 信息。REMOTE_ADDR 不在白名单内，服务器应当忽略 X-Forwarded-For 头部，直接以 REMOTE_ADDR 为准，对于涉及风控、计费等敏感操作的IP获取，建议结合IP地理位置库进行逻辑校验，如果IP归属地与用户行为偏差过大,应触发二次验证。
IPv6 环境下的兼容性处理
随着IPv6的普及，获取IP的逻辑也需要兼容IPv6格式，IPv6地址较长，且可能包含 符号（用于标识网卡区域），在存储和显示前需要进行标准化处理，在代码层面，需要确保解析逻辑能够正确识别冒号十六进制格式，并在数据库字段设计时预留足够的长度（通常建议39个字符以上）以容纳完整的IPv6地址。
服务器获取客户端IP并非简单的读取一个变量，而是一个系统工程，它要求运维人员正确配置反向代理链路，要求开发人员编写具备白名单校验能力的健壮代码，并时刻警惕HTTP头部的伪造风险，只有建立起从网络层到应用层的完整信任链，才能准确、安全地获取用户真实IP。
相关问答
Q1：如果客户端使用了VPN，服务器获取到的是VPN的IP还是真实IP？
A： 服务器获取到的是VPN出口网关的IP地址，VPN本质上充当了代理服务器的角色，它将客户端的原始IP封装在其隧道内部，服务器端看到的TCP连接源是VPN服务器的IP，要获取真实IP，通常需要VPN客户端在建立连接后通过特定的HTTP头部传输真实IP，但这取决于VPN服务的具体实现和协议支持,且同样存在伪造风险。
Q2：为什么有时候获取到的客户端IP是 127.0.0.1 或 ::1？
A： 这通常发生在服务器架构中存在本地转发的情况，请求先到达本机的Nginx或端口转发工具（如iptables），再由其转发给后端的Java或Python应用，对于后端应用而言，直接连接的“客户端”是本机的回环地址（127.0.0.1），解决此问题需要确保转发层正确设置了 X-Forwarded-For 或 X-Real-IP 头部，并且应用层优先读取这些头部而非 REMOTE_ADDR。
如果您在配置服务器获取IP的过程中遇到特定的报错或异常情况，欢迎在评论区留言,我们将针对具体的架构环境为您提供详细的排查建议。
