端口转发经跳板机访问Web服务器时无法获取真实请求IP咨询

普通四层端口转发（iptables DNAT、默认SSH本地端口转发等）的工作逻辑是跳板机以自身IP为源地址，和目标Web服务器建立新的TCP连接转发流量，整个转发过程不会携带原始客户端的源IP信息，因此目标服务器侧读取到的连接源IP必然是跳板机IP，需要根据你的部署场景选择对应方案调整。

方案1：透明源转发（同内网场景首选，无额外协议开销） #

适用于跳板机和目标Web服务器处于同一二层内网、可调整路由的场景：

• 跳板机开启内核转发：执行sysctl -w net.ipv4.ip_forward=1写入临时配置，如需永久生效修改/etc/sysctl.conf对应参数
• 跳板机配置TPROXY透明代理规则，转发时不替换数据包源IP，保留原始客户端地址
• 调整目标Web服务器的路由规则，将响应流量的下一跳指向跳板机，避免非对称路由导致连接中断
  配置完成后目标Web服务器无需修改服务配置，直接读取TCP连接的对端地址就是真实客户端IP。

注意：如果目标Web服务器的默认网关不是跳板机，必须单独配置指向客户端网段的静态路由走跳板机，否则连接会直接超时。

方案2：Proxy Protocol透传（跨网络场景通用，兼容性强） #

适用于跳板机和目标服务器跨公网、无法调整路由的场景，是目前生产环境最常用的四层转发透传真实IP方案：

• 跳板机侧替换原有普通转发规则，使用支持Proxy Protocol的转发组件（HAProxy、Nginx Stream、socat均可），转发时开启Proxy Protocol v2版本发送，在TCP三次握手后第一个包携带原始源IP、源端口信息
• 目标Web服务器侧在对应监听端口开启Proxy Protocol接收，主流Web服务（Nginx、Apache、Caddy、Tomcat）均原生支持该配置
  配置生效后Web服务会自动解析Proxy Protocol携带的客户端IP，日志、业务逻辑中读取到的源地址就是真实客户端IP，无需调整路由。

方案3：七层代理注入XFF头（仅HTTP/HTTPS服务适用） #

如果转发的是Web类HTTP/HTTPS流量，不需要做四层转发，直接在跳板机部署七层反向代理即可：

• 跳板机Nginx/Caddy反向代理规则中添加请求头配置：proxy_set_header X-Forwarded-For $remote_addr;
• 目标Web服务配置信任跳板机IP，从X-Forwarded-For请求头中提取距信任源最近的IP值作为真实客户端IP

安全提示：必须配置Web服务仅信任跳板机发送的X-Forwarded-For头，禁止直接信任所有请求携带的该头，否则存在伪造客户端IP的风险。

不要尝试在不调整转发配置的前提下，仅在目标服务器侧通过抓包、日志分析获取真实客户端IP——普通四层转发的数据包中不会留存任何原始源IP信息，这类操作没有实际效果。

内容的提问来源于stack exchange，提问作者MOz