源站负载均衡的客户端IP透传，使用X-Forwarded-For

源站负载均衡场景下，客户端真实IP地址丢失是一个常见问题，因为流量经过负载均衡器转发后，源站服务器看到的请求IP往往是负载均衡器的IP，而非终端用户的真实IP。这直接影响日志记录、访问控制、数据分析等关键功能。解决此问题的核心方法是在负载均衡层启用X-Forwarded-For（XFF）头部透传，并在源站进行正确解析。

X-Forwarded-For的工作原理与标准格式

X-Forwarded-For是一个事实标准的HTTP请求头部，用于在代理或负载均衡环境中传递客户端的原始IP地址。其工作原理是：当请求经过第一个代理设备时，该设备会将客户端的真实IP地址添加到X-Forwarded-For头部中。后续经过的每个代理或负载均衡器，都会将上一跳的IP地址追加到该头部值的末尾，用逗号和空格分隔。因此，最左侧的IP地址就是最初的客户端IP。例如，一个请求经过客户端（IP: 203.0.113.10）、负载均衡器（IP: 198.51.100.1）到达源站，那么源站收到的请求头中可能包含：X-Forwarded-For: 203.0.113.10, 198.51.100.1。源站需要从该字段中提取最左边的IP（203.0.113.10）作为客户端真实IP。

在主流负载均衡器上配置X-Forwarded-For透传

配置的关键在于让负载均衡器在将请求转发给后端源站服务器时，自动添加或修改X-Forwarded-For头部。以下是几种常见负载均衡软件的配置示例。

Nginx负载均衡配置

在Nginx作为负载均衡器（反向代理）时，需要在代理站点的配置文件中使用 proxy_set_header 指令。

http {
    upstream backend_servers {
        server 10.0.1.101:80;
        server 10.0.1.102:80;
    }

    server {
        listen 80;
        server_name yourdomain.com;

        location / {
            proxy_pass http://backend_servers;
            # 核心配置：透传真实客户端IP
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;
            # 其他代理设置...
        }
    }
}

其中，"$proxy_add_x_forwarded_for" 变量会自动将 "$remote_addr"（即Nginx直接连接的客户端IP）追加到已有的X-Forwarded-For头部值后面，如果请求原本没有该头部，则直接创建。"X-Real-IP"是另一个常用头部，通常只携带最原始的客户端IP。

Apache负载均衡配置

当使用Apache的mod_proxy模块做负载均衡时，需要使用"ProxyPreserveHost"和"RequestHeader"指令来设置头部。

<VirtualHost *:80>
    ServerName yourdomain.com

    ProxyPreserveHost On
    ProxyPass / balancer://mycluster/
    ProxyPassReverse / balancer://mycluster/

    <Proxy balancer://mycluster>
        BalancerMember http://10.0.1.101:80
        BalancerMember http://10.0.1.102:80
        # 添加X-Forwarded-For头部
        RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}s, %{X-Forwarded-For}i"
    </Proxy>

</VirtualHost>

这里"%{REMOTE_ADDR}s"代表Apache接收到的客户端IP，"%{X-Forwarded-For}i"代表传入的XFF头部值。这条指令会将当前客户端IP追加到现有XFF头部的开头。

云服务商负载均衡服务配置

主流云平台（如阿里云、腾讯云、AWS、Azure等）的负载均衡服务通常都提供了开启“获取真实客户端IP”或“X-Forwarded-For透传”的选项，一般是一个开关。以阿里云SLB为例，在监听配置中开启“开启X-Forwarded-For”即可。云服务的优势在于它们通常不仅传递XFF，还会传递X-Real-IP等头部，并自动处理多级代理的情况，用户无需编写复杂配置。

源站服务器如何正确解析客户端IP

仅仅在负载均衡器上配置了头部透传还不够，后端的源站服务器（Web应用）必须被修改为优先从X-Forwarded-For头部读取客户端IP，而不是直接从TCP连接中获取远程地址。这是一个至关重要的安全编程实践。

Web应用层解析逻辑（以常见编程语言为例）

应用代码需要遵循一个通用的解析顺序：首先检查是否存在X-Forwarded-For头部，如果存在，则提取其值，并按逗号分割成列表，取第一个（最左边）的IP地址。同时，必须考虑该头部可能被伪造，因此在可信的网络架构（负载均衡器与源站处于私有网络）内，此方法是可靠的。如果架构中存在不可信的代理，则需要结合信任代理列表进行验证。

PHP示例代码

function getClientIP() {
    $ip = '';
    // 1. 优先从X-Forwarded-For头部获取
    if (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) {
        $xForwardedFor = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
        $ip = trim($xForwardedFor[0]); // 取第一个IP
    }
    // 2. 如果XFF为空，则尝试X-Real-IP
    if (empty($ip) && !empty($_SERVER['HTTP_X_REAL_IP'])) {
        $ip = $_SERVER['HTTP_X_REAL_IP'];
    }
    // 3. 最后使用PHP默认的远程地址（这很可能是负载均衡器的IP）
    if (empty($ip)) {
        $ip = $_SERVER['REMOTE_ADDR'];
    }
    // 可选：过滤和验证IP地址格式
    return filter_var($ip, FILTER_VALIDATE_IP) ? $ip : '0.0.0.0';
}

Node.js (Express) 示例代码

app.use(function(req, res, next) {
    let clientIP = req.ip; // Express默认可能已处理

    // 自定义解析逻辑
    const xForwardedFor = req.headers['x-forwarded-for'];
    if (xForwardedFor) {
        // x-forwarded-for格式： "client, proxy1, proxy2"
        const ips = xForwardedFor.split(',').map(ip => ip.trim());
        clientIP = ips[0];
    } else if (req.headers['x-real-ip']) {
        clientIP = req.headers['x-real-ip'];
    }
    // 将解析出的IP挂载到req对象上供后续使用
    req.clientRealIP = clientIP;
    next();
});

Nginx作为源站时的日志记录配置

如果源站服务器也使用Nginx，可以在其日志格式中嵌入"$http_x_forwarded_for"变量，以便在访问日志中记录真实客户端IP。

http {
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log main;

    server {
        listen 80;
        # 应用代码仍应进行解析，此配置主要用于日志记录
        # 如果负载均衡器是唯一可信代理，也可用以下方式重写$remote_addr变量
        # set_real_ip_from 10.0.0.0/8; # 信任的负载均衡器IP段
        # real_ip_header X-Forwarded-For;
        # real_ip_recursive on;
    }
}

使用"set_real_ip_from"、"real_ip_header"和"real_ip_recursive on"指令，可以让Nginx用X-Forwarded-For中的可信IP替换掉连接层面的"$remote_addr"变量，这样所有使用"$remote_addr"的模块都会自动获得真实客户端IP。

安全考量与最佳实践

在实施X-Forwarded-For透传方案时，必须将安全放在首位。X-Forwarded-For头部的内容完全由客户端或上游代理控制，极易被伪造。一个恶意的用户可以直接在请求中携带一个伪造的"X-Forwarded-For: 8.8.8.8"头部。如果负载均衡器只是简单地追加而非覆盖，并且源站无条件信任该头部的第一个IP，就会导致IP欺骗。

实施可信代理链

最佳实践是构建一个“可信代理链”。只有你完全控制的网络设备（如你的负载均衡器、CDN边缘节点、内部代理）才被允许修改或设置X-Forwarded-For头部。在源站服务器上，你应该配置一个信任的IP列表（例如，你的负载均衡器所在的私有IP段）。对于来自这些可信IP的请求，应用才去解析X-Forwarded-For；对于来自互联网的直接请求，则应忽略该头部。上文Nginx配置中的"set_real_ip_from"正是这一理念的体现。

使用更安全的专用头部

在一些严格的环境中，可以考虑使用自定义的、非标准的头部来传递IP，并在负载均衡器和源站之间通过共享密钥等方式进行验证，但这会增加系统复杂性。通常，在负载均衡器与源站处于同一私有网络或通过安全通道连接的前提下，使用X-Forwarded-For并配合可信IP列表验证是行业公认的可靠方法。

总结与扩展应用

客户端IP透传是构建可观测、可管理、安全的现代Web架构的基础一环。成功实施X-Forwarded-For方案需要负载均衡层和源站应用层的协同配置。此方案不仅解决了日志记录问题，还为基于IP的速率限制、地域访问控制、个性化内容推送等功能提供了准确的数据基础。在更复杂的架构中（如同时使用CDN和负载均衡），需要确保CDN也将原始客户端IP正确地传递到负载均衡器，形成完整的IP透传链。始终记住，任何从HTTP头部读取的信息都必须在一个明确的信任边界内进行验证，这是保障系统安全性的铁律。

源站负载均衡的客户端IP透传，使用X-Forwarded-For

服务指南

帮助中心