frp

frp(Fast Reverse Proxy)是一款用 Go 编写的高性能内网穿透与反向代理工具,广泛用于把位于 NAT 或防火墙之后、没有公网 IP 的内网服务,安全地暴露到公网供外部访问。其典型场景是:家里或公司内网有一台无公网 IP 的设备(运行 Web 服务、SSH、远程桌面、NAS、Webhook 接收等),通过 frp 借助一台有公网 IP 的中转服务器,使外部用户得以访问这些内网服务。frp 以配置简单、协议丰富、性能稳定、社区活跃著称,是国内外开发者做内网穿透时最常用的自托管工具之一。

背景与由来

家用宽带与企业内网普遍处于 NAT 之后,运营商日益普及的 CGNAT(运营商级 NAT) 更使家庭几乎不可能获得真正的公网 IP,外部无法主动连入内网设备。传统做法依赖路由器端口映射(需公网 IP)或搭建 VPN(门槛较高),都不够通用。frp 提供了一种简洁而通用的方案:在内网运行一个客户端(frpc),由它主动向外连接公网服务器上的服务端(frps)建立长连接隧道;之后所有来自外部的请求由 frps 接收,经隧道转发给 frpc,再由 frpc 投递到真正的内网服务——这就是反向代理式的穿透,巧妙地利用了出站连接通常不被 NAT/防火墙阻拦这一特性。

设计目标

• 穿透 NAT/防火墙:让没有公网 IP、无法被主动连入的内网服务可被公网访问。
• 多协议支持:覆盖 TCP、UDP、HTTP、HTTPS 等常见服务类型,适配各种应用。
• 高性能与稳定:Go 实现,支持连接池、数据压缩、TLS 加密,适合长期无人值守运行。
• 易部署易扩展:配置文件直观,功能模块化,可按需启用鉴权、面板、插件等。

工作原理:frps 与 frpc

frp 采用服务端 frps + 客户端 frpc 的双端架构:

• frps 部署在有公网 IP 的服务器上,监听一个控制端口(bindPort)接收 frpc 的连接与控制信令,并按配置监听对外暴露的各类端口或基于域名的 HTTP(S) 入口。
• frpc 部署在内网,启动后主动出站连接 frps 建立控制隧道(因此完全不要求内网有公网 IP 或开放入站端口),并在配置中声明要暴露哪些本地服务——指定本地地址端口、代理类型,以及对外的远程端口或绑定域名。
• 当公网用户访问 frps 暴露的端口或域名时,frps 通过与 frpc 之间已建立的隧道把请求反向转发到内网对应服务,服务的响应再沿原路返回给用户。frps 通常会复用控制连接并按需建立工作连接(配合连接池减少时延)。

对于 HTTP/HTTPS,frp 支持基于域名的虚拟主机路由(vhost):多个内网站点可共享公网的 80/443 端口,frps 按请求的 Host 头分流到不同 frpc/服务,还可统一处理 TLS、自定义二级域名、basic auth 等;对 TCP/UDP 则做端口级转发。frp 还提供 STCP/XTCP/SUDP 等模式:STCP 为加密的点对点隧道,需访问端也运行 frpc 并用相同密钥配对,流量不暴露公网端口;XTCP 在此基础上尝试 P2P 打洞使两端直连、绕过服务器中转(成功与否取决于双方 NAT 类型)。此外支持连接加密(TLS)、token 鉴权与 OIDC、连接池、负载均衡、健康检查,以及带 Web 面板的可视化管理。

理解 frp 的关键,在于把握由内向外建立、再反向使用这一核心:NAT 与防火墙通常允许内网设备主动发起出站连接并放行其返回流量,却阻止外部主动连入。frp 正是利用这一不对称性,让 frpc 抢先建好通往公网的隧道,公网请求便可借这条已存在的通道反向抵达内网,从而在不改动路由器、不申请公网 IP 的前提下完成穿透。相比之下,P2P 的 XTCP 则更进一步,试图让两个内网节点彼此打洞直连,把服务器仅当作信令协调者,以省去中转带宽——但能否成功高度依赖双方 NAT 类型,对称型 NAT 往往难以打通。

传输特性

• 控制连接为客户端主动出站的长连接,天然适配 NAT 与受限网络。
• 支持 TCP、UDP、HTTP、HTTPS 等多种代理类型,以及 tcpmux 端口复用(多服务共享一端口)。
• 提供 TLS 加密、数据压缩、连接池以提升安全性与性能、降低建连时延。
• XTCP 在 NAT 条件允许时进行 P2P 打洞,使两端直连、减轻中转服务器的带宽与负载压力。

演进关系与对比

• 相对 ngrok:frp 同为内网穿透工具,但更偏向自托管(自备公网服务器),可控性、隐私与长期成本更优;ngrok 偏向 SaaS、开箱即用但受其服务与额度约束。
• 相对 WireGuard/Tailscale:后者是组建私有网络让授权设备整体互联;frp 则专注于把特定的内网服务定向暴露给公网的不特定用户,目标人群与用途不同。
• 相对 反向代理(Nginx/Caddy):frp 解决的是跨 NAT 的连通问题,而非同主机的流量分发;实践中二者常互补,如 frps 之后再接 Nginx 做更复杂的路由与 TLS。

实现与生态

frp 是活跃的开源项目(Go 语言),提供各平台预编译二进制,配置采用 TOML(新版)或 INI(旧版)。它拥有庞大社区与完善文档,并具备 dashboard 管理面板、插件机制(如静态文件服务、HTTP basic auth、unix socket 转发)等扩展点。常见用途包括个人 NAS / 家庭服务器对外、远程开发调试、接收第三方 Webhook 回调、远程 SSH/RDP、自建网站从家庭宽带对外等。围绕 frp 也涌现了大量图形化面板、一键脚本与教程。在国内自托管圈子里,frp 几乎是内网穿透的代名词,许多 NAS 与软路由系统(如部分群晖套件、OpenWrt 插件)也内置或便捷支持 frp。

需要厘清的是,frp 解决的是连通性而非安全策略本身:它能把内网服务搬到公网,却不会替你判断该服务是否适合暴露。因此把内网管理后台、数据库、未鉴权接口等通过 frp 直接挂上公网,是常见的安全事故来源。稳妥做法是只暴露必要服务、为隧道与服务都启用强鉴权与 TLS、限制来源、并配合防火墙与最小权限原则。把 frp 视为一把锋利的工具而非自带防护的方案,是安全使用它的前提。

适用与局限

frp 适合需要把内网服务稳定、灵活地暴露到公网、并愿意自备一台廉价公网服务器(VPS)的场景,协议全面、可控性强。其局限在于:它需要一台有公网 IP 的中转服务器(P2P 的 XTCP 受双方 NAT 类型限制不一定成功,常仍需回退中转);把内网服务暴露到公网本身扩大了攻击面,必须认真做好 token/OIDC 鉴权、TLS、最小化暴露与访问控制,否则易被扫描攻击;且它解决的是连通问题,不提供组网级的设备整体互访体验。总体而言,frp 是内网穿透领域成熟、流行、功能完备的代表性自托管工具。