在自建服务（如 Web、SSH、邮件、游戏服务器等）的过程中，是否能够识别真实访客 IP 是一个非常关键、但常被忽略的问题。
本文对两种常见方案进行对比分析：
- 家庭宽带公网 IP + 路由器端口转发
- VPS + FRP 内网穿透
重点讨论：后端服务究竟能看到什么来源 IP。
一、问题背景
常见的家庭或个人服务器部署方式主要有两类：
- 家庭宽带具备公网 IPv4，通过路由器将端口转发至局域网主机
- 家庭宽带无公网 IPv4，通过 VPS 搭配 FRP 等工具实现内网穿透
两种方案在“能否访问服务”上都可行，但在访问者 IP 可见性上存在本质差异。
二、结论先行
使用公网 IPv4 + 路由器端口转发时，
局域网服务通常可以直接看到访问者的真实公网 IP。
使用 VPS + FRP 时，
局域网服务只能看到 VPS 的 IP，无法直接获得真实访客 IP。
这是由网络连接模型决定的，而非配置错误。
三、公网 IP + 端口转发的工作机制
端口转发的本质是 DNAT（Destination NAT，目标地址转换）：
访问者公网 IP → 路由器公网 IP:端口
↓ DNAT
局域网主机 IP:端口
关键点：
- 路由器 只修改目标地址
- 源地址（访问者 IP）保持不变
因此：
- TCP/UDP 连接中的
source IP仍然是访问者的真实公网 IP - 后端服务（Nginx、SSH、SMTP、数据库、游戏服务器等）可直接获取真实 IP
四、实际表现
在这种架构下：
- Web 访问日志中记录的 IP 为真实访客公网 IP
- SSH、邮件服务器日志中的连接来源为真实 IP
- 防火墙、fail2ban、限速、封禁策略均可直接基于真实 IP 工作
这是网络层原生行为，无需额外配置。
五、VPS + FRP 的连接模型
FRP 属于反向隧道工具，其连接关系为：
访问者
↓
VPS 公网端口
↓（FRP 隧道）
局域网 frpc
↓
本地服务
在该模型中：
- 局域网主机 并未与访问者建立直接连接
- 局域网主机只与 VPS（frps） 通信
因此在内核层面：
连接来源 IP = VPS IP
这是设计决定的，无法通过简单配置绕过。
六、FRP 是否能“传递”真实 IP？
1️⃣ HTTP / HTTPS 场景（有限可行）
对于 Web 服务：
- VPS 可通过
X-Forwarded-For或 PROXY protocol 传递访客 IP - Web 服务器可在应用层解析真实 IP
但需要注意：
- 仅限 应用层
- 内核、防火墙、fail2ban 仍然无法识别真实 IP
2️⃣ 非 HTTP 服务（不可行）
以下服务无法获取真实访客 IP：
- SSH
- SMTP / IMAP / POP3
- 数据库服务
- 游戏服务器
- 任何基于 TCP/UDP 的非 HTTP 服务
原因是：
这些协议没有可信的“来源 IP 头部”机制。
七、为什么 VPS + FRP 不适合某些服务
在以下场景中，VPS + FRP 存在明显结构性缺陷：
- 邮件服务器（IP 信誉、25 端口、风控）
- 安全敏感服务（暴力破解防护）
- 基于 IP 的限速、封禁
- 希望获得精确访问来源分析的服务
这些问题并非“配置不当”，而是方案本身并非为此设计。
八、两种方案的对比总结
| 项目 | 公网 IP + 端口转发 | VPS + FRP |
|---|---|---|
| 是否可见真实访客 IP | ✅ | ❌ |
| 防火墙 / fail2ban | ✅ | ❌ |
| 邮件接收 | ✅ | ❌ |
| 架构复杂度 | 低 | 高 |
| 网络延迟 | 低 | 较高 |
| 成本 | 无额外成本 | VPS 月费 |
九、结语
FRP 并不是“更高级”的方案，
而是在没有公网 IP 时的“工程性妥协”。
当具备公网 IPv4 条件时，
直接端口转发不仅更简单，而且在安全、可观测性和长期维护上更优。
理解这一点，有助于避免在架构层面做无意义的复杂化选择。