内网穿透工具选型，frp 和 ngrok 用的人最多，但两者都有各自的痛点：frp 配置繁琐、内存占用不低；ngrok 免费版限制多、商业版价格不友善。

rathole 是一个用 Rust 写的内网穿透工具，GitHub 13.3k+ Star，定位很明确——做一个更快、更省、更安全的 frp/ngrok 替代品。

项目地址：https://github.com/rathole-org/rathole

rathole 是什么

一句话概括：轻量级、高性能的安全内网穿透工具 。和 frp 一样是 C/S 架构，但用 Rust 实现，自带 Noise Protocol 加密，资源占用极低。

核心思路就是：在有公网 IP 的服务器上运行 Server 端，在内网机器上运行 Client 端，Client 主动连接 Server 建立隧道，外部流量通过 Server 转发到内网服务。和 frp 的原理相同，区别在实现层面。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/ruoyi-vue-pro

• 视频教程：https://doc.iocoder.cn/video/

四大核心优势

1. 高性能：Rust 的零成本抽象在网络密集型场景下优势明显

基准测试中吞吐量高于同类 Go/Python 实现的工具，高并发下延迟更稳定。对于需要大量并发连接的场景（比如多人同时访问内网 Web 服务），这个优势是实打实的。

2. 低资源消耗：部署在 1C1G 小机器上毫无压力

内存占用远低于 frp。空闲状态下只占几 MB 内存，对于那些跑在低配云主机上的穿透服务来说，这是关键优势。

3. 安全性强：每个服务单独强制鉴权

Server 端和 Client 端各自管各自的配置，每个被穿透的服务都必须配置 Token 才能建立隧道。传输层支持 Noise Protocol 加密（不需要自签证书），同时也支持 TLS。frp 的鉴权是可选的，rathole 是强制的——安全默认值更高。

4. 热重载：改配置不用重启进程

修改端口转发规则后直接热重载生效，不会断开已有连接。这在生产环境中非常实用——frp 改配置得重启，穿透中的所有连接全部断开。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/yudao-cloud

• 视频教程：https://doc.iocoder.cn/video/

rathole vs frp vs ngrok：怎么选

|
对比维度
| rathole | frp | ngrok |
| — | — | — | — |
|
语言
|
Rust
|
Go
|
Go
|
|
内存占用（空闲）
|
~3 MB
|
~20 MB
|
~15 MB
|
|
加密方式
|
Noise Protocol / TLS
|
TLS（可选）
|
TLS
|
|
鉴权
|
强制 Token
|
可选 Token
|
账号体系
|
|
热重载
|
✅ 支持
|
❌ 需重启
|
N/A
|
|
配置复杂度
|
简洁 TOML
|
TOML/INI
|
命令行参数
|
|
免费版限制
|
无（完全开源）
|
无（完全开源）
|
限速 + 随机域名
|
|
Dashboard
|
❌ 无
|
✅ 有 Web UI
|
✅ 有 Web UI
|
|
社区生态
|
中等
|
非常活跃
|
商业生态
|

选型建议 ：

• 资源敏感（1C1G 小机器） ：rathole，内存占用碾压级优势

• 需要 Web 管理面板 ：frp，Dashboard 功能成熟

• 临时公网隧道、不想自建服务器 ：ngrok，一行命令搞定

• 安全要求高的生产环境 ：rathole，安全默认值最高

快速上手

Server 端配置 （有公网 IP 的机器）：

# server.toml

[server]

bind_addr = "0.0.0.0:2333"


[server.services.my_web]

token = "your-secret-token-here"

bind_addr = "0.0.0.0:8080"

Client 端配置 （内网机器）：

# client.toml

[client]

remote_addr = "your-server-ip:2333"


[client.services.my_web]

token = "your-secret-token-here"

local_addr = "127.0.0.1:3000"

启动命令：

# Server 端

./rathole server.toml


# Client 端

./rathole client.toml

这样外部访问 your-server-ip:8080 就能穿透到内网的 127.0.0.1:3000。配置量比 frp 少了至少一半。

适用场景和局限

适合 ：

• 部署在低配云主机上，资源寸土寸金

• 安全要求高，不想手动配 TLS 证书

• 需要频繁修改穿透规则，不想重启服务

不适合 ：

• 需要图形化管理面板（rathole 目前没有 Dashboard）

• 需要 HTTP 层面的高级功能（rathole 只做 TCP/UDP 转发，不像 frp 支持 HTTP 头改写）

• 团队协作场景（frp 的多租户和权限管理更成熟）

说白了，如果你的内网穿透场景对性能和资源消耗敏感（比如部署在 1C1G 的小机器上），rathole 比 frp 更合适。如果你需要完整的管理功能和社区支持，frp 仍然是更稳妥的选择。

---