阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/Star-133k-neiwangchuantougongju-Rust-yuyanbianxie-frpngrok-tidai/ 「芋道源码」欢迎转载，保留摘要，谢谢！

• rathole 是什么
• 四大核心优势
• rathole vs frp vs ngrok：怎么选
• 快速上手
• 适用场景和局限

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

内网穿透工具选型，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 的原理相同，区别在实现层面。

四大核心优势

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

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

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

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

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

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

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

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

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 仍然是更稳妥的选择。