网站安全中，源IP伪造是攻击者隐藏真实身份、绕过访问控制或发起DDoS攻击的常见手段，而通过反向代理获取真实IP则是防御的关键。当用户请求经过CDN、负载均衡器或WAF等反向代理时，服务器默认看到的只是代理IP，这会使基于IP的访问限制、日志审计和攻击追踪失效。要解决这个问题，核心在于配置反向代理将真实IP传递到后端，并在后端应用中正确读取。例如，在Nginx中，可以使用X-Real-IP或X-Forwarded-For头部来携带用户IP，后端则需信任这些头部并处理多级代理情况。同时，必须注意安全风险：攻击者可能伪造这些头部，因此代理列表的信任配置至关重要。

一、源IP伪造的原理与常见攻击场景

源IP伪造是指攻击者修改网络数据包中的源IP地址，使其看起来来自其他地址。这通常发生在网络层（如IP协议），利用的是TCP/IP协议本身不验证源IP真实性的缺陷。常见场景包括：

1. DDoS攻击中伪造海量IP以分散流量或绕过基于IP的速率限制；

2. 渗透测试或恶意扫描中隐藏攻击源；

3. 绕过IP黑名单或地域访问控制。例如，SYN Flood攻击可以轻易伪造随机源IP，使服务器无法响应合法请求。需要注意的是，在HTTP层面，IP伪造更复杂，因为TCP连接需要完成三次握手，但这并不妨碍攻击者在网络层滥用伪造IP进行洪水攻击。

二、反向代理如何影响真实IP获取

现代网站架构普遍使用反向代理（如Nginx、Apache、CDN服务）来提高性能或安全性。当用户请求到达时，先由代理服务器处理，然后转发给后端应用服务器（如Tomcat、Node.js）。此时，后端服务器看到的TCP连接来自代理IP，而非用户真实IP。例如，用户IP是203.0.113.5，经过代理后，后端日志可能只记录代理IP10.0.0.1。这导致：访问日志失去用户地理信息；安全策略（如IP封禁）无法针对真实攻击者；业务功能（如投票限制）可能出错。解决之道是让代理在转发时添加特定HTTP头部，将用户IP“告诉”后端。

三、主流反向代理的真实IP传递配置方法

配置反向代理传递真实IP需两步：代理端设置头部，后端应用读取并信任这些头部。以下以Nginx和Apache为例：

对于Nginx，在代理配置中添加proxy_set_header指令：

location / {
    proxy_pass http://backend_server;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
}

这里X-Real-IP直接携带用户IP，而X-Forwarded-For是一个IP链，记录各级代理IP，Nginx会自动追加当前$remote_addr。若有多级代理，需确保每级都传递该头部。

对于Apache，使用mod_remoteip模块或mod_proxy的头部设置：

ProxyPass / http://backend_server/
ProxyPassReverse / http://backend_server/
RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}s"

云服务如阿里云CDN或Cloudflare，通常会自动添加X-Forwarded-For等头部，但需在后端验证其格式。

四、后端应用获取真实IP的编程实现

后端应用必须从HTTP头部读取IP，并优先于直接TCP连接IP。以下为常见语言示例：

在PHP中，检查X-Forwarded-For并处理逗号分隔的IP链：

function getRealIP() {
    if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
        $ipChain = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
        return trim($ipChain[0]); // 取第一个IP（原始用户IP）
    }
    return $_SERVER['REMOTE_ADDR'];
}

在Node.js（Express框架）中，可通过中间件获取：

app.use((req, res, next) => {
    const forwardedFor = req.headers['x-forwarded-for'];
    req.realIP = forwardedFor ? forwardedFor.split(',')[0] : req.connection.remoteAddress;
    next();
});

对于Java Spring Boot，可从HttpServletRequest解析：

public String getClientIP(HttpServletRequest request) {
    String xff = request.getHeader("X-Forwarded-For");
    if (xff != null && !xff.isEmpty()) {
        return xff.split(",")[0].trim();
    }
    return request.getRemoteAddr();
}

关键点：始终验证IP链，避免取到伪造值；优先使用最左侧IP（原始IP），但需根据代理顺序调整。

五、安全风险：头部伪造与防御策略

依赖HTTP头部获取IP存在风险，因为攻击者可直接发送伪造的X-Forwarded-For。若后端盲目信任，可能导致IP欺骗，例如绕过IP白名单。防御措施包括：

1. 配置反向代理只信任内部网络IP，并清空外部传入的相关头部。Nginx中可设置：

proxy_set_header X-Forwarded-For $remote_addr; // 覆盖而非追加

2. 使用可信代理列表，后端仅接受来自这些代理的头部。例如，在Nginx中通过set_real_ip_from指定可信代理IP段，并启用real_ip_header：

set_real_ip_from 10.0.0.0/8;
set_real_ip_from 172.16.0.0/12;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

这样Nginx会从X-Forwarded-For中排除可信IP，提取最右侧不可信IP作为真实IP；

3. 结合其他验证手段，如客户端证书或会话令牌，增加攻击门槛。

六、高级场景：多级代理与云环境下的处理

在复杂架构中，请求可能经过CDN、WAF、负载均衡器等多级代理，每级都会添加X-Forwarded-For值。此时IP链如203.0.113.5, 10.0.0.1, 192.168.1.1，需明确哪一级是用户IP。最佳实践是：第一级代理（最靠近用户）设置X-Real-IP为真实IP，后续代理只传递不修改。同时，所有代理应记录原始头部以供审计。在云环境（如AWS ALB或Azure Front Door）中，服务商通常提供自定义头部，例如AWS的X-Forwarded-For已自动处理，但需注意其可能添加端口信息。务必查阅云文档，并测试IP获取逻辑。

七、日志记录与监控建议

正确获取真实IP后，应将其纳入日志系统。例如，在Nginx日志格式中添加$http_x_real_ip变量：

log_format main '$http_x_real_ip - $remote_user [$time_local] "$request"';
access_log /var/log/nginx/access.log main;

同时，监控异常IP行为：如单个IP请求频率突增、来自非常见地区的访问等。使用ELK或Splunk等工具分析日志，可快速识别伪造IP攻击模式。此外，定期审计代理配置，确保未意外暴露真实IP头部给外部。

八、总结：平衡便利与安全的最佳实践

获取反向代理后的真实IP是运维基础，但不可牺牲安全。总结关键步骤：

1. 配置所有反向代理传递标准头部（X-Forwarded-For或X-Real-IP）；

2. 后端应用优先从头部读取，并处理多值情况；

3. 严格限制可信代理范围，防止头部伪造；

4. 在日志和监控中集成真实IP。对于高安全场景，可考虑使用协议如PROXY协议，它能在TCP层传递连接信息，避免HTTP头部篡改。最终，结合网络层防火墙和应用层验证，才能有效抵御源IP伪造威胁。