这是一个关于网络地址转换（NAT）和应用层代理工作层级差异的经典问题。根本原因在于 数据包处理发生的网络层级不同 以及 谁真正发起了到内部Web服务器的TCP连接。

让我们分解一下原因：

📍 1. 路由器端口转发（DNAT）的工作原理（保留真实IP）

• 工作层级： 网络层（IP层）或传输层（TCP/UDP层）。

• 过程：

  • 外网访客发送一个数据包到路由器的公网IP地址（假设是 WAN_IP:80）。

  • 路由器检查其端口转发（Destination NAT， DNAT）规则，发现目标端口 80 需要转发到内网服务器 LAN_SERVER_IP:80。

  • 关键操作： 路由器只修改数据包的目标IP地址（从 WAN_IP 改为 LAN_SERVER_IP）和目标端口（如果需要）。源IP地址（访客的真实公网IP）保持不变。

  • 修改后的数据包被路由到内网Web服务器。

• Web服务器视角： Web服务器看到这个TCP连接的源IP地址就是外网访客的真实公网IP。因为从Web服务器的角度看，这个连接直接来自那个公网IP（虽然经过了路由器修改目标地址，但源地址没变）。

• 连接建立者： 从Web服务器的TCP栈角度看，连接是外网访客直接发起的（源IP是访客IP）。路由器只是在中间修改了目标地址，没有中断这个连接。

📍 2. Porttunnel 类软件端口映射（通常是反向代理）的工作原理（显示Porttunnel内网IP）

• 工作层级： 应用层（通常是HTTP层，但也可以是其他应用层协议）。

• 过程：

  • 外网访客发送一个数据包到运行Porttunnel软件的电脑的公网IP（PORTTUNNEL_IP:PortX）。

  • Porttunnel软件（作为服务端）完整接收这个传入的连接和数据。

  • 关键操作： Porttunnel软件创建一个全新的、独立的TCP连接，从它自己（PORTTUNNEL_LAN_IP）指向内部Web服务器（LAN_SERVER_IP:80）。

  • Porttunnel软件将访客发来的数据读取出来，然后通过它自己新建的这个连接转发给Web服务器。同样地，它也会把Web服务器的响应读出来，通过它接收到的访客连接发送回去。

• Web服务器视角： Web服务器看到的这个TCP连接的源IP地址是运行Porttunnel软件的电脑的内网IP地址（PORTTUNNEL_LAN_IP）。因为从Web服务器的角度看，这个连接是Porttunnel软件自己主动发起的。

• 连接建立者： Web服务器的TCP栈确认连接是由 PORTTUNNEL_LAN_IP 发起的。原始的访客连接只到达了Porttunnel软件，并未直接到达Web服务器。Porttunnel软件充当了中间人（代理）的角色。

📍 总结关键差异

📍 为什么Porttunnel不保留源IP？（技术难点）

1. TCP连接状态： TCP是一个有状态的协议。当Porttunnel终结了访客的连接，那个连接的状态就结束了。它需要一个新的TCP连接状态机来与后端服务器通信。

2. 应用层协议理解（可选但常见）： 像Porttunnel这样的工具，特别是配置为HTTP端口映射时，通常会理解HTTP协议。这使得它们能够添加像 X-Forwarded-For 这样的头（见下文解决方案），但核心的TCP连接源IP仍然只能是Porttunnel本身的IP。

3. 防火墙/NAT限制： 如果Porttunnel运行在Windows上，它本身可能位于另一个NAT设备（如家用路由器）后面，它甚至没有公网IP来接收连接（除非做了端口映射到它），更不用说将原始源IP直接路由到内部服务器了。

📍 如何在Porttunnel场景下获取真实IP？（解决方案）

既然Web服务器只能看到Porttunnel的IP，要获取真实访客IP，必须依赖应用层协议传递信息：

1. X-Forwarded-For HTTP Header： 这是最通用的方法。配置Porttunnel（或任何反向代理，如Nginx, Apache, HAProxy）在新建到后端Web服务器的连接时，在HTTP请求头中添加一个 X-Forwarded-For 头，其值设置为原始访客的IP地址。Web服务器应用程序（如Apache, Nginx, IIS, 应用代码）需要配置为读取并信任这个头（来自已知代理的IP），并用这个头的值来记录或处理访客IP，而不是使用TCP连接的源IP。

2. 代理协议（Proxy Protocol）： 这是一个更底层的标准（最初由HAProxy提出），在TCP连接建立之初，代理服务器就在发送应用数据之前，先发送一行包含原始连接信息的文本（包括源IP/端口、目标IP/端口）。Web服务器需要明确支持并配置理解Proxy Protocol。它不依赖于特定的应用层协议（如HTTP），但需要代理和后端服务器都支持。

3. Windows防火墙日志（间接/不推荐）： 如果Porttunnel运行在Windows上，且Windows防火墙记录了传入连接，你可能在防火墙日志中找到原始IP和Porttunnel收到的连接。但这非常不便于集成到Web日志中，且依赖防火墙配置。

📍 结论

路由器端口转发工作在底层（网络层），通过简单的目标地址修改直接透传连接，使Web服务器能看到原始源IP。Porttunnel等软件工作在应用层，作为代理终结客户端连接并新建服务器端连接，因此Web服务器看到的是代理自身的IP地址。要获取真实IP，必须使用应用层机制如 X-Forwarded-For 头或Proxy Protocol。理解这个差异对于正确配置日志记录、访问控制和安全分析至关重要。🛡️

相关教程：

​采用端口转向软件映射到局域网内的另外一台WEB服务器时，利用Nginx实现抓取访客真实外网IP[2]
　 http://31874.oa22.cn