frp 评测：用 Go 写的内网穿透工具，能撑起多大的场面
快速反向代理可帮助您将 NAT 或防火墙后面的本地服务器暴露给互联网。
秒懂
- 它是什么？
- frp 是一个用 Go 实现的反向代理，用于把 NAT 或防火墙后的本地服务暴露到公网。本文基于其 README 和仓库信息，分析它的工作机制、适用场景和已知边界。
- 适合谁用？
- frp 适合需要快速将内网服务暴露到公网的个人开发者和小团队，尤其是熟悉 Go 生态、愿意折腾配置文件的人。它不适合追求极致性能或需要企业级管理界面的场景，因为 v2 仍在重构且不兼容 v1，长期维护存在不确定性。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，谁需要它
很多开发者的本地服务跑在 NAT 后面，比如家里的 NAS、公司内网的数据库，或者一台临时搭建的 Web 服务器。公网无法直接访问这些服务，除非你拥有公网 IP 或者配置复杂的端口转发。frp 就是一个反向代理，它在有公网 IP 的服务器上运行 frps，在内网机器上运行 frpc，两者建立连接后，公网请求就能通过 frps 转发到内网服务。这个场景对远程办公、演示 demo、调试 Webhook 都很实用。它的定位很明确：解决内网穿透问题，而不是做一个通用的负载均衡器。
架构：frps 与 frpc 的分工
frp 采用客户端-服务器架构。frps 运行在公网服务器上，监听一个控制端口，frpc 主动连接这个端口并注册代理。每个代理定义了一种转发规则，比如把公网的某个 TCP 端口映射到内网的某个 IP 和端口。数据流是：公网客户端连接到 frps 的映射端口，frps 通过已建立的隧道把数据转发给 frpc，frpc 再转发给内网服务。这个设计的好处是内网机器不需要公网 IP，只需要能主动访问外网。README 提到 frp 支持 TCP、UDP、HTTP 和 HTTPS，还支持 P2P 模式。P2P 模式下，frps 只负责协助打洞，数据不经过服务器中转，这能降低延迟，但需要双方网络支持 NAT 穿透。
配置方式：从 TOML 到环境变量
frp 的配置写在 TOML 文件里。以 README 中的 SSH 穿透为例，frps 的配置大概是这样：bindPort 设为 7000，frpc 的配置里有一个 proxy 名为 ssh，type 为 tcp，localIP 为 127.0.0.1，localPort 为 22，remotePort 为 6000。启动 frps 用 ./frps -c frps.toml，启动 frpc 用 ./frpc -c frpc.toml。配置还支持环境变量引用，比如在配置里写 {{ .Envs.FRP_TOKEN }} 来读取环境变量。另外，frpc 支持热加载配置，修改配置后发送 SIGHUP 信号就能重新加载，不用重启进程。这个功能对调试很有用。
HTTP 和 HTTPS 的域名路由
对于 Web 服务，frp 不只是做端口转发，它还能根据域名路由。你可以在 frps 上配置一个 vhostHTTPPort，比如 8080，然后 frpc 里定义 type 为 http 的代理，指定 customDomains 为 example.com。这样，访问 http://example.com:8080 时，frps 会根据 Host 头把请求转发到对应的内网服务。类似地，HTTPS 需要配置 vhostHTTPSPort 和证书。这个功能让多个 Web 服务可以共享同一个公网端口，只需不同的域名。README 还提到可以设置自定义子域名，比如 subdomain: blog，frps 会自动生成 blog.yourdomain.com。对于没有独立域名的用户，这很实用。
安全与认证的取舍
frp 提供 token 认证和 OIDC 认证。token 是简单的共享密钥，配置在 frps 和 frpc 里，连接时校验。OIDC 更复杂，适合企业环境。此外，frp 支持 TLS 加密通信，可以防止中间人嗅探。但要注意，这些安全措施只保护 frps 和 frpc 之间的隧道，不保护最终用户和 frps 之间的连接。如果你暴露的是 HTTP 服务，数据在公网上是明文传输的，除非你配置 HTTPS。README 还提到可以设置代理协议（Proxy Protocol）来传递真实 IP，但需要上层负载均衡器支持。安全配置的粒度取决于你的威胁模型，如果只是临时演示，token 就够了。
性能与限制：哪些场景不合适
frp 是纯 Go 实现，性能对于大多数内网穿透场景足够，但它的架构决定了它不适合高并发或大流量传输。因为所有数据都要经过 frps 转发（P2P 模式除外），frps 的带宽和 CPU 会成为瓶颈。README 提到支持 TCP 流多路复用和连接池，这能减少连接建立的开销，但并不能解决带宽上限。另外，frp 的配置项很多，比如带宽限制、健康检查、负载均衡，但这些功能都需要你手动配置，没有默认的智能优化。如果你需要处理每秒数千请求的生产流量，可能需要考虑更专业的代理方案。还有一个限制是，frp 的 v2 版本正在开发中，且不兼容 v1，这意味着未来升级可能会破坏现有配置。
替代方案：与 WireGuard 和 nginx 的对比
frp 不是唯一的内网穿透工具。WireGuard 是一个 VPN 方案，它创建虚拟网络接口，让内网机器和公网服务器处于同一局域网，然后你可以通过 SSH 或 HTTP 直接访问。与 frp 的区别在于，WireGuard 是三层隧道，需要 root 权限和内核模块，配置更复杂，但它能转发所有协议，而 frp 是四层和七层代理，更灵活。另一个替代是 nginx 的 stream 模块，它可以做 TCP 转发，但需要内网服务本身有公网可达的 IP，或者配合其他隧道工具。frp 的优势在于它专门为内网穿透设计，开箱即用，而 WireGuard 和 nginx 需要更多网络知识。如果你的目标是简单暴露一个端口，frp 更直接；如果你需要完整的网络层连接，WireGuard 更合适。
维护与升级：v2 的不确定性
frp 的 GitHub 仓库显示最近一次提交在 2026 年 8 月，版本号到了 v0.71.0，说明项目仍在活跃维护。但 README 明确说 v2 正在开发中，且不兼容 v1。这意味着如果你现在基于 v1 部署，未来升级到 v2 可能需要重写配置和代码。v2 的设计目标是成为一个类似 envoy 的可扩展代理，但作者承认开发进度受限于个人时间，这增加了不确定性。许可证是 Apache-2.0，允许商用和修改，但如果你 fork 并修改，需要保留版权声明。对于生产环境，我的建议是固定版本，并跟踪 v2 的发布动态，不要过早依赖。
编辑结论
frp 适合需要快速将内网服务暴露到公网的个人开发者和小团队，尤其是熟悉 Go 生态、愿意折腾配置文件的人。它不适合追求极致性能或需要企业级管理界面的场景，因为 v2 仍在重构且不兼容 v1，长期维护存在不确定性。采用前应验证：你的网络环境是否允许 TCP 端口映射，是否需要 P2P 模式，以及是否接受 Apache-2.0 许可下的二次开发成本。具体来说，先跑通一个 SSH 穿透用例，确认 frps 和 frpc 的版本匹配，再决定是否投入生产。
社区笔记