内网穿透的Web服务如何获取真实的客户IP地址

共计 1529 个字符，预计需要花费 4 分钟才能阅读完成。

概述

内网服务器结合内网穿透技术将服务暴露至公网，是一种经典的服务部署架构。然而在实际应用中，此方案常面临一个典型问题：由于流量经过代理转发，后端服务获取到的客户端IP往往变为穿透节点的内网地址，导致真实源IP丢失。本文旨在探讨并解决这一源IP透传问题，确保服务端能够准确识别访客的真实来源。

在内网穿透架构中，“流量是如何被转发的” 直接决定了后端服务能否、以及如何获取客户端的真实IP。不同的穿透方式处于OSI模型的不同层级，因此透传真实IP的技术手段完全不同。
以下是三种主流穿透方式及其对应的真实IP获取方案的深度解析：
1.反向代理模式（Layer 7/ HTTP层）
2.TCP端口映射模式（Layer 4/ 传输层）
3.TUN/TAP 虚拟组网模式（Layer 3/网络层）

本篇文章以第一种方式为例进行实验。

反向代理模式（Layer 7/ HTTP层）

这是最常见的Web服务穿透方式（如Nginx、Caddy、Cloudflare Tunnel、frp的http/https模式、nps的http/https模式）。由于工作在应用层，代理服务器会终止原始TCP连接，并与后端建立一条新的TCP连接。

核心问题： 后端看到的TCP源IP永远是代理服务器的内网IP。

解决方案： 通过HTTP请求头传递真实IP。

• X-Forwarded-For: 标准字段，格式为 client, proxy1, proxy2。每经过一层代理就追加一个IP。注意： 该字段可被客户端伪造，不能直接信任第一个值，需配合可信代理列表使用。
• X-Real-IP: 非标准但广泛使用的字段，通常由最外层可信代理写入，仅包含客户端真实IP。
• CF-Connecting-IP: Cloudflare专用字段，当使用Cloudflare Tunnel时，这是获取真实IP的最可靠来源。

后端配置要点： Web服务器（Nginx/Apache）或应用框架必须显式配置“信任的代理地址”，才会从这些Header中提取真实IP并覆盖默认的RemoteAddr。否则出于安全考虑，服务器会忽略这些Header。

如何配置

本篇案例以WordPress为例，使用nps内网穿透服务，讲解如何让WordPress获取到真实的客户IP地址。

首先，在内网穿透服务方面，nps要使用“域名转发”功能，而不是TCP隧道，需要修改请求头信息。

Cache-Control: no-cache   //告诉浏览器别缓存这个页面，每次都要重新从服务器拉最新内容（生产环境不要写）
X-Forwarded-For: %remote_addr%   //X-Forwarded-For标准字段，%remote_addr% 是NPS的变量，代表真实访客的公网IP

在内网服务器端：

首先要启用启用mod_remoteip模块

sudo a2enmod remoteip

⚠️如果 sudo a2enmod remoteip 报错说模块不存在？

sudo apt update && sudo apt install libapache2-mod-remoteip
sudo a2enmod remoteip
sudo systemctl restart apache2

然后直接编辑Apache主配置文件

sudo nano /etc/apache2/apache2.conf

在文件末尾（最后一行之前），添加这几行：

# 启用 RemoteIP 模块（获取真实 IP）
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 192.168.1.0/24   //修改为你的内网IP网段

最后，重启Apache服务

sudo systemctl restart apache2

此时进入WordPress，可以看到已经正确识别到客户IP地址了。