rathole 与 frp：一个内网穿透用户的选型复盘

我用了 frp 三年多，2023 年开始在部分场景切换到 rathole。这篇文章不是一篇“谁更好”的结论式对比，而是把我踩过的坑、量过的数据和后来想明白的事情摊开来聊。

如果你在找一个“直接说选哪个”的答案，我先说结论：在 1 vCPU / 512MB 的 VPS 上，如果你只需要转发 TCP/UDP，rathole 是更合理的选择；如果你需要 HTTP vhosting、P2P 打洞或者一个能点开看的 Dashboard，frp 仍然是唯一答案。 但这个结论的推导过程，比结论本身更有意思。

性能数据能告诉你什么，不能告诉你什么

rathole 官方 benchmark 里那张表被引用得最多。核心事实是：在 QPS 1 到 3000 的区间，rathole 和 frp 的延迟差异在毫秒级波动范围内，frp 甚至在 1000–3000 QPS 区间略快。真正的分水岭在 QPS 4000：frp 开始报大量错误，延迟冲到秒级，rathole 稳在 2.5ms 左右。

这里需要说一句很多人忽略的话：这个测试是在 localhost 回环上跑的。 它测的是 CPU 调度和事件循环的效率，不是你家宽带到你 VPS 之间的真实链路质量。官方自己也提醒过，不要据此认为 rathole 能让你的转发“快上数倍”。

那 4000 QPS 这个数字对普通用户意味着什么？说实话，对大多数人来说什么都不意味着。 你转发一个 NAS 的 SSH，或者一个自建的 Jellyfin，QPS 常年是个位数。你感受不到 rathole 和 frp 在性能上的任何区别。

但有一种场景例外：你在做 API 网关或者反向代理大量微服务，流量是几十上百个并发连接持续不断。 这种情况下 Go runtime 的 GC 在高负载下引入的延迟抖动会变得可见，而 Rust 没有 GC，Tokio 的任务调度在这个量级上表现出更稳定的尾部延迟。这不是 rathole 比 frp “更快”，是它在接近系统瓶颈时更可预测。

资源占用：数字背后的真实体验

rathole 的二进制可以做到 ~500KiB，README 里写得很清楚，是给嵌入式设备用的。frp 的二进制通常在 15–18MB 这个量级。

我手头有一台 512MB 的 VPS 跑 frps，日常 RSS 在 80–100MB 左右。切到 rathole 之后，同一台机器上 rathole 的 RSS 稳定在 10–20MB。作者本人 2022 年发过一个帖子说“内存占用从 60–70MiB 减少到 10MiB 以下”，和我自己的观测基本吻合。

这个差距在小内存机器上是质变的。512MB 的 VPS 上，frp 吃掉将近五分之一的内存，剩下还要跑 nginx、数据库或者其他服务的时候，你会开始算账。rathole 吃掉的 10MB 基本可以忽略。

但这里有一个反直觉的点：二进制小不等于运行时省。 rathole 的 ~500KiB 是通过 opt-level = "z" 和 LTO 压出来的，对部署到路由器有意义，对你 VPS 上的内存占用没有直接影响。真正省内存的原因是 Rust 没有 GC，Tokio 的栈协程比 goroutine 的栈开销更紧凑——在 10 万并发任务这个量级上，goroutine 的内存开销大约是 Tokio task 的 3 倍。日常使用根本碰不到这个天花板，但如果你在压榨一台小机器的极限，这个差距是真实的。

热重载：一个被简化了的事实

之前我写过“frp 修改配置需要重启，所有连接断开”，这个说法是错的，我需要纠正自己。

frp 从 0.53 左右开始支持 frpc 热重载。通过 webServer 配置开启 admin 端口之后，frpc reload 可以在不重启整个进程的情况下应用配置变更，受影响的是被修改的 proxy，未修改的 proxy 连接会保持。

但限制在于：添加新的 proxy 块是安全的，修改已有的 proxy 配置会导致该 proxy 的连接断开。 有一个 2025 年的 Issue 记录了精确的场景：在一个已有的 HTTPS proxy 的 customDomains 里加域名，执行 reload 后浏览器直接报错。如果新建一个独立的 proxy 块，reload 就不会影响原来的连接。

rathole 的热重载在这一点上确实更干净，README 说的是“Services can be added or removed dynamically by hot-reloading”，没有提到“修改已有服务”会出问题。但这不意味着 rathole 的热重载没有边界——它的 HTTP API 至今还标着 WIP，热重载主要靠监听配置文件变更来触发，生产环境里可靠性还需要自己验证。

社区与维护：一个绕不开的权重

这一块我需要说得直白一些，因为它直接影响你的长期使用体验。

frp 的 release 节奏非常稳。0.71.0 是 2026 年 8 月发布的，往前 0.70 是 7 月，0.69 是 5 月，基本上一到两个月一个版本。OpenSSF 的评分是 Maintained 10/10。十年积累下来，GitHub Issues 里几乎任何你遇到的问题都能找到前人踩过的痕迹。

rathole 的 release 节奏完全是另一回事。v0.5.0 是 2023 年 10 月发布的，到今天将近三年没有新的正式版了。README 里还留着“HTTP API is WIP”的标注，Planning 板块的内容看起来也没有最近更新的迹象。GitHub Star 数从 2022 年的 ~10k 涨到了现在的 ~14.3k，说明项目本身没有被遗忘，但维护者的精力显然已经不在这个项目上了。

这不是说 rathole 不能用。它已经足够稳定，核心功能不会突然坏掉。但你要接受一个事实：如果你遇到一个 rathole 特有的 bug，修复可能不会来了。 2023 年有人报告 443 端口上的隧道每 24 小时断开一次，必须重启服务才能恢复。这个 Issue 到现在没有明确的根因分析，也没有修复。如果你把生产流量挂在 443 上，这意味着你可能需要自己写一个 cron job 去定时重启。

frp 在同样的问题上不会让你等——即使某个版本引入了 regression，fatedier 通常在几周内就会修掉。

我的实际选择，以及为什么

我现在的情况是：一台 1 vCPU / 512MB 的 VPS 跑 rathole server，转发三个 TCP 服务（SSH、一个自建 API、一个游戏服务器）。 frp 被我从这台机器上撤掉了，不是因为性能，是因为内存。rathole 在这台机器上的 RSS 常年不到 15MB，frp 要吃掉将近 100MB。多出来的 85MB 我可以跑一个小的 PostgreSQL 实例。

但我没有在所有场景下放弃 frp。 另一个场景里我需要把几个内部 HTTP 服务暴露到公网，带域名和自动 HTTPS。这种情况下 frp 的 vhosting + ACME 插件是开箱即用的，rathole 需要我在前面再套一层 nginx，配置复杂度反而上升了。XTCP 的 P2P 打洞也是 frp 独有的——如果你的两端 NAT 类型允许打洞，数据可以完全绕过中转服务器，这是 rathole 的中转架构做不到的。

如果你要做选型，我的建议

看你的 VPS 内存，而不是看 benchmark。 512MB 及以下，rathole。1GB 以上，frp 的生态优势会压倒 rathole 的资源优势。

看你的功能需求。 纯 TCP/UDP 转发，rathole 够用且更省。需要 HTTP 路由、域名管理、P2P、Dashboard，frp 没有对手。

看你对“维护风险”的容忍度。 rathole 三年没发新版本，这意味着你选择的是一个冻结状态的工具。它现在能工作，以后也能工作，但出了问题你要有能力自己修。frp 的维护是活跃的，你为它的内存开销付的“成本”，买到的是持续的 bug 修复和功能迭代。

我自己的判断是：rathole 适合作为一个嵌入式的、一次配置就不动的底层转发层。frp 适合作为一个需要经常调整、有明确运维界面的服务网关。它们不是竞争关系，是两种不同的部署哲学。选哪个，取决于你把隧道放在架构的哪个位置。