服务器获取客户端IP地址并非单一维度的读取操作，而是根据网络架构的不同，分为直接连接获取与代理转发获取两种核心模式，在无代理环境下，服务器通过TCP连接直接获取真实IP；而在存在负载均衡、CDN或反向代理的复杂架构中，服务器则必须解析特定的HTTP头部字段（如X-Forwarded-For）。最关键的技术难点在于如何从这些头部字段中精准剔除伪造IP，并正确解析出经过可信代理链路的真实客户端IP。
直接连接模式下的IP获取
在最为简单的网络拓扑中，客户端直接向服务器发起请求，中间不经过任何代理设备或CDN加速,获取客户端IP地址是最为可靠和直接的。
在这种场景下，服务器操作系统通过TCP/IP协议栈的三次握手建立连接，在连接建立过程中，服务器能够直接从底层的Socket接口中读取对端的网络层地址，在Web服务器（如Nginx、Apache）或后端编程语言（如Java、PHP、Go）中，这个地址通常对应于环境变量或对象属性中的REMOTE_ADDR。
REMOTE_ADDR 是服务器端收到的来自客户端连接的源IP地址，由于这一步发生在TCP握手阶段，它是基于网络连接建立的，因此无法通过伪造HTTP头部来篡改，如果客户端声称IP是A，但TCP连接来自B，服务器会记录B，在直接连接模式下，REMOTE_ADDR是绝对权威且可信的,它代表了与服务端建立物理连接的那个设备的IP地址。
代理与反向代理环境下的IP获取
在现代高并发、高可用的Web架构中，直接连接的情况非常少见，绝大多数企业级应用都会在服务器前端部署Nginx、HAProxy等反向代理，或者使用Cloudflare、阿里云CDN等加速服务，服务器收到的TCP连接请求的源IP不再是客户端的真实IP,而是中间代理设备的IP。
如果继续读取REMOTE_ADDR，服务器得到的将永远是代理服务器的IP，这显然无法满足业务需求（如地理位置定位、防刷攻击），为了解决这个问题，代理服务器在将请求转发给后端服务器时,会将原始客户端的信息添加到HTTP请求的头部字段中。
最常用的头部字段包括：
- X-Forwarded-For (XFF)：这是最通用的标准，用于记录经过的每一个代理节点的IP，格式通常为：
客户端IP, 代理1 IP, 代理2 IP,排在最左侧的是原始客户端IP。 - X-Real-IP：通常用于记录真实的客户端IP，但这需要代理服务器（如Nginx）明确配置该头部。
- CF-Connecting-IP：这是Cloudflare CDN特有的头部,用于传递真实IP。
- X-Forwarded-Proto：虽然主要记录协议（http/https）,但有时也配合IP校验使用。
在这种架构下，后端服务器的获取逻辑必须调整为：优先检查并解析X-Forwarded-For等头部字段，仅在头部不存在时才回退到REMOTE_ADDR。
真实性校验与IP伪造的防御
仅仅读取X-Forwarded-For头部是不够的，甚至可能带来严重的安全风险，因为HTTP头部是由客户端发送的，恶意攻击者可以轻易构造一个包含虚假IP的X-Forwarded-For头部，攻击者手动发送请求头 X-Forwarded-For: 8.8.8.8，如果服务器盲目信任该字段，就会误认为请求来自谷歌的DNS服务器,从而绕过基于IP的白名单限制。
专业的解决方案必须包含“可信代理链路”的验证机制。
- 配置可信IP段：服务器必须明确知道哪些前端代理是受信任的，在Nginx配置中，使用
set_real_ip_from指令指定CDN或负载均衡器的内网IP段。 - 覆盖而非追加：当请求来自受信任的代理时，服务器才去解析X-Forwarded-For；如果请求直接来自不可信的互联网IP（即攻击者直连后端），服务器必须忽略X-Forwarded-For,强制使用REMOTE_ADDR。
- 从右向左解析：X-Forwarded-For是一个链路，最右侧的IP是最近的一个代理，正确的逻辑是：从右向左遍历这个IP链，剔除所有在“可信IP列表”中的代理地址，剩下的第一个非可信IP,即为真实的客户端IP。
多层架构下的获取策略与代码实现
在多层代理架构中，获取逻辑的严谨性直接决定了数据的准确性,以下是一个通用的专业获取逻辑流程：
判断REMOTE_ADDR是否在内部受信任的代理网段内，如果不在，说明请求是直连的，直接使用REMOTE_ADDR作为真实IP，并忽略所有X-Forwarded-For信息（防止伪造）。
如果在，说明请求经过了我们的代理，此时开始解析X-Forwarded-For，将XFF字符串按逗号分割成IP数组，从数组的末尾（即最近的一跳）开始向前遍历，如果遇到的IP在受信任列表中，则跳过（这是我们的代理设备），直到遇到第一个不在受信任列表中的IP,这个IP就是真实的客户端IP。
以Nginx配置为例的解决方案：
在Nginx作为反向代理时，需要在Location块中配置：
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
在后端应用服务器（如Node.js/Express）中，应使用成熟的中间件而非手动解析，例如express-ip或自行编写逻辑：
function getClientIp(req) {
// 检查是否来自受信任的代理（此处省略具体IP判断逻辑）
let ip = req.headers['x-forwarded-for'] || req.connection.remoteAddress;
if (ip && ip.includes(',')) {
ip = ip.split(',')[0].trim(); // 取第一个IP，前提是前端已清洗伪造
}
return ip;
}
注意： 上述代码仅适用于前端代理已经做了严格清洗的情况,最安全的做法是在应用层也维护一份代理IP白名单进行二次校验。
IPv6与特殊场景的处理
随着IPv6的普及，服务器获取到的IP地址格式可能发生变化，IPv6地址通常包含冒号，且可能带有IPv4映射的格式（如:ffff:192.168.1.1），在处理逻辑中，必须兼容这两种格式，必要时进行标准化转换，将其统一转为IPv4格式存储,以避免数据库字段长度不足或格式校验失败的问题。
在WebSocket连接建立过程中，获取IP的逻辑与HTTP略有不同，通常需要在握手阶段（Upgrade请求头）应用上述HTTP头部的解析逻辑，因为一旦连接升级为WebSocket协议,后续的数据帧中将不再包含这些头部信息。
相关问答
Q1：为什么有时候获取到的客户端IP是内网地址（如192.168.x.x）？
这种情况通常发生在客户端与服务器处于同一个局域网内，或者请求经过了NAT网关，如果服务器位于负载均衡后面，且配置不当，可能会获取到负载均衡器的内网IP，如果攻击者伪造了内网IP头部，且服务器未进行外网IP校验，也会导致此问题，正确的处理逻辑应判断获取到的IP是否为回环地址或私有网段，如果是,通常需要进一步排查链路配置。
Q2：在Cloudflare CDN加速下，如何准确获取访客真实IP？
Cloudflare会将真实IP存放在CF-Connecting-IP头部中，虽然X-Forwarded-For也存在，但建议优先读取CF-Connecting-IP，因为这是Cloudflare明确保证经过其边缘节点验证过的IP，在Nginx或后端代码中，应将CF-Connecting-IP的优先级置于X-Forwarded-For之上，或者使用Cloudflare官方提供的模块（如nginx的ngx_http_cloudflare_module）来自动替换REMOTE_ADDR。
能帮助您深入理解服务器获取客户端IP的机制，如果您在实际部署中遇到了特殊的网络环境配置问题，欢迎在评论区分享您的架构细节,我们可以共同探讨具体的配置方案。
