状态：推荐使用 · 适合自建中转和任意 TCP/UDP 服务
速读#
frp 做的是经典反向代理：在有公网 IP 的服务器上运行 frps，在内网机器上运行 frpc，由内网端主动连接公网端，再把本地服务映射出去。没有公网 IP、处在 NAT 后面，仍然可以从外面访问 SSH、远程桌面、Web、游戏服或其他 TCP/UDP 服务。
它和 Cloudflare Tunnel 的差别不只是品牌。Tunnel 更适合 HTTP 类入口并把中转交给 Cloudflare；frp 允许自己控制公网服务器、监听端口和原始协议。要的是网页服务和少运维，Tunnel 更短；要的是任意 TCP/UDP、自定义端口或完全自托管，frp 更直接。
链路很简单#
外部客户端 ↓公网 VPS：frps ↑ 长连接内网机器：frpc ↓SSH / Web / RDP / 游戏端口 / 其他本地服务真正的关键是连接方向：内网机器主动出站，所以路由器不需要给它分配公网 IP，也不用在每层 NAT 上做端口转发。公网 VPS 成为统一入口。
为什么推荐#
- 协议覆盖广：TCP、UDP、HTTP、HTTPS 等常见场景都能处理。
- 控制权完整：中转服务器、域名、端口、日志和升级节奏都由自己决定。
- 部署结构小：核心就是
frps和frpc两个程序加 TOML 配置。 - 适合非网页服务：SSH、远程桌面和游戏端口不必硬套 HTTP 隧道。
frp 的成熟之处还在于它没有把简单问题包装成平台。先建立一条可靠隧道，再按需要补 TLS、鉴权、域名路由、限速和监控；基础需求不必先部署控制台、数据库和账号系统。
安全边界要比配置先写#
内网穿透不是把端口「藏起来」，而是把入口搬到公网 VPS。映射出去的服务仍然暴露在互联网上，因此至少要处理：
- 为 frpc 与 frps 配置认证，不接受匿名客户端接入。
- 只开放实际需要的端口，并在 VPS 防火墙限制来源。
- SSH 使用密钥并关闭密码登录；管理服务不要直接映射弱口令页面。
- 对公网链路启用合适的 TLS，持续更新 frp 版本。
- 记录连接和错误日志，给中转服务加 systemd 守护与资源限制。
如果只是自己远程管理机器，Tailscale 或 WireGuard 往往比公开一个端口更安全；如果只是发布网页，Cloudflare Tunnel 能少守一台中转。frp 的优势在于自由，但自由的另一面就是这些责任没有平台替你接走。
不适合什么情况#
- 没有稳定公网 VPS，也不想维护中转节点。
- 只需要私有设备互访，不需要任何服务公开给互联网。
- 主要需求是带身份门禁的网页后台，现成零信任隧道会更省事。
- 不清楚被映射服务自身是否安全，只想用隧道绕过网络限制。
我的选择标准#
我会先按协议选工具，而不是先选名气：HTTP 服务优先看托管隧道；设备私网互联优先看 VPN；只有需要原始端口、自己掌控入口时才上 frp。这样每种工具只做自己最擅长的一层，链路也更容易排查。
frp 不是魔法，它只是让内网主动连出，再把公网入口转回来。理解这件事之后，配置不难；真正要认真的是，你究竟把什么服务暴露给了谁。