作为开发者，我们经常会遇到这样的痛点：需要把本地跑在 localhost:3000 的服务发给产品经理预览，或者需要一个公网域名来接收第三方接口的 Webhook 调试。
大家以前习惯用 ngrok，但免费版动辄限制连接数、域名随机变动；用 frp 虽然强大，但配置文件的复杂度让人望而却步；cloudflared 则是纯纯的企业级重型武器。
今天向大家推荐一个极简、高性能的新选择：基于 Rust 构建的开源项目 Tunelo。
💡 核心原理：中继模式与 QUIC 协议
Tunelo 并不是依靠复杂的 P2P 打洞技术，而是采用了极其稳定的中继服务器（Relay）模式。
Browser (公网) ──HTTPS──► Relay 服务器 ──QUIC stream──► 我们的电脑 (Client) ──► localhost:3000
为什么它不需要我们在路由器上配置公网 IP 映射？
这是因为采用了类似 Cloudflare Tunnel 的 Outbound-only（仅出站）连接模型。我们的本地客户端会主动向 Relay 发起基于 UDP 的 QUIC 连接。因为绝大多数防火墙默认放行主动出站的流量，一旦连接建立，Relay 就可以随时通过这条双向通道把公网请求“塞”回我们本地。
🚀 为什么推荐 Tunelo？（技术亮点）
-
极致轻量，零拷贝转发
得益于 Rust 和
tokio::io::copy_bidirectional带来的数据平面零拷贝技术，Tunelo 的性能损耗极低。二进制文件仅约 4 MB，运行时的 Relay 端内存占用低至 8 MB RSS，隧道开销相比直连仅增加 ~14%。 -
底层拥抱 QUIC 协议
相比于传统的 TCP 隧道工具（如 bore），Tunelo 使用了
quinn + rustls构建 QUIC 通道。自带多路复用，无队头阻塞问题，且隧道全程强加密，延迟更低。 -
极简的使用体验
没有
ini或yaml，一行命令直接起飞
🔒 安全性：我们能放心在工作中使用吗？
内网穿透最让人担心的就是“引狼入室”。Tunelo 在这方面提供了非常清晰的信任模型。
在默认情况下，Relay 服务器充当了“受信任的第三方”。如果使用官方免费节点，意味着我们需要信任作者。但 Tunelo 最大的优势在于支持一键自建 Relay，并且自带极其易用的密码保护机制。
| 场景需求 | CLI 命令 | 安全性表现 |
|---|---|---|
| 临时测试公开接口 | tunelo port 3000 |
隧道完全公开，任何人拿到域名即可访问。 |
| 分享给同事预览 | tunelo port 3000 --password |
系统自动生成 4 位随机密码（如 reef3847），未授权请求在 Relay 层就会被拦截，根本不会打到你本地。 |
| 自定义密码分享 | tunelo port 3000 --password mysecret |
使用自定义密码，分享链接只需加上 ?pwd=mysecret。 |
对于我们团队的最佳实践（生产级安全）：
我们的最优解是：自建 Relay 服务器 + 本地服务开启 HTTPS + 强制使用 --password。
哪怕退一万步讲，自建的 Relay 服务器被黑客攻破，只要我们本地服务是 HTTPS，Relay 截获的也只是密文，无法解密我们的业务数据。
⚖️ 横向对比选型
| 工具名称 | 核心特点与局限 | Tunelo 的优势 |
|---|---|---|
| ngrok (免费版) | 闭源商业化，功能多但限制极其严格。 | 完全开源，无并发/时间限制。 |
| frp | 老牌王者，功能大而全（~50k+ 行代码）。 | 代码极简（仅 1100+ 行 Rust），无需编写配置文件。 |
| bore | 同样由 Rust 编写的极简工具。 | bore 使用 TCP 易受网络波动影响，Tunelo 使用 QUIC 更稳且内置密码。 |
| cloudflared | Cloudflare 官方工具，企业级但偏重健。 | Tunelo 更轻量，适合开发者日常快速拉起。 |
总结
Tunelo 完美击中了小团队“需要快速暴露本地端口，但又不想折腾复杂配置”的痛点。极简的几千行 Rust 代码背后，是对现代网络协议（QUIC）的巧妙运用。
