不知道你有没有遇到过这种时刻——

本地 localhost:8080 跑得好好的，产品突然说"给我看一眼"，客户说"你发个链接我点一下"，或者你接 Stripe、GitHub 的 webhook，对方死活推不进来，因为你的服务躲在 localhost 后面，公网根本摸不到门。

传统办法要么自己搞 Nginx + 域名 + 证书，折腾半天；要么用 ngrok，好用但免费版限制多，自定义域名还要付费。

前阵子我翻到一个叫 Tunnelto 的小工具，用 Rust 写的，试了一下，基本就是"装好 → 一条命令 → 拿到公网 URL"的体验。下面把我的使用过程和踩到的点都记下来，给有同样需求的人参考。

说明一下：我是普通用户视角，不是项目开发者。下面的描述来自我实际试用 + 翻它的文档和源码，不代表官方立场。

先说清楚：内网穿透到底是个啥

怕有人第一次听这个词，先一句话解释：

内网穿透[把藏在你本机或局域网里的服务，借一个公网中转服务器"探"出去，让外面的人也能访问到你本机的端口]

打个比方。你住在一个小区（局域网），外卖员（外部用户）进不来，也找不到你家门牌。内网穿透就像你在大门口放了一个对外营业的"收发室"（公网服务器），你跟收发室拉了一根内部对讲机（控制连接）。外面的人把包裹送到收发室，收发室通过对讲机喊你，你再从家里把东西递出去。外面的世界始终只跟收发室打交道，根本感知不到你的真实位置。

Tunnelto 干的就是"帮你开这个收发室 + 拉这根对讲机"的活。

装好就能跑：最小使用示例

安装有三种常见方式，挑顺手的：

# macOS 用 Homebrewbrew install agrinman/tap/tunnelto# 如果你装了 Rust 工具链，也可以直接 cargo 装cargo install tunnelto# 其他平台（Windows / Linux）去 GitHub Releases 下载二进制就行

装完，假设你本地有个服务跑在 8000 端口，就这么一行：

tunnelto --port 8000

跑起来后终端大致长这样（具体字符串是随机生成的）：

🚀 Starting tunnelto...🌍 Public URL: https://abc123.tunnelto.dev📊 Dashboard: http://localhost:4040

接下来，任何人访问 https://abc123.tunnelto.dev，实际打到的是你本机 localhost:8000。你改代码、刷新，对方看到的都是实时结果——特别适合联调。

想要一个好记的地址？加个参数：

tunnelto --port 8000 --subdomain myapp

这样就能拿到 https://myapp.tunnelto.dev。子域名[主域名前面的那段，比如 myapp.tunnelto.dev 里的 myapp] 这个能力，在 ngrok 里是要付费的，Tunnelto 免费给。

甚至本地不是 127.0.0.1、或者想指定协议也行：

tunnelto --port 3000 --host 127.0.0.1 --scheme https

它内部是怎么把流量"搬"过来的

我好奇它怎么做到的，翻了下源码和文档，结构其实不复杂，就三个角色：

1. 你本机的客户端（Client）

   ：就是你执行的那个 tunnelto 命令。

2. 云端的服务器（Server）

   ：官方提供的 tunnelto.dev，或者你自己部署的那台。

3. 控制通道（Control WebSocket）

   [一种长连接协议，客户端和服务器之间始终保持一根"热线"，能随时双向发消息]：客户端启动后，先跟服务器用 WebSocket 握个手，说"我要开个隧道"。

之后真实的请求流转是这样的：

• 外部用户访问 https://xxx.tunnelto.dev → 打到服务器；

• 服务器一看这个子域名，知道背后是你，就通过那根控制通道通知你的客户端"有人来访问了"；

• 你本机的客户端再去连你真正的本地服务（比如 localhost:8000）；

• 请求和响应在这两端之间被双向转发。

关键点是：你本机不需要公网 IP，也不需要对外开放任何端口。所有进出流量都先过服务器这一道，再由客户端"拉"回本地。

为什么用 Rust + Tokio[Rust 的异步运行时，可以理解成一个高效调度大量"等待中任务"的发动机]？说白了就是为了省资源、扛并发。异步 IO 的好处是：单线程就能同时照看成千上万个连接，不用为每个连接开一个线程（那样内存和切换开销会爆炸）。对一个"中转站"来说，这点很关键。

和 ngrok、localtunnel 比，怎么选

我用过的几个同类工具，横向摆一摆（评价偏主观，按需取用）：

我的看法：如果你只是偶尔演示一下，三个都能用；但如果你在意数据走谁家的服务器、想要免费自定义域名、或者想自己部署一套，那 Tunnelto 的性价比就出来了。ngrok 胜在生态成熟、文档稳，localtunnel 胜在零门槛（Node 环境里一行就能起）。

不想数据过别人家服务器？可以自托管

这点我觉得是对隐私敏感的同学最该看的。Tunnelto 开源了服务端代码，你可以自己搭。

官方给了两条路：

• 单实例

  ：编译成 musl 静态二进制（就是把依赖全部打进一个文件里，拷到服务器就能跑），或者用 Docker 起一个容器。Docker[把应用和它所依赖的环境打包成一个可移植"盒子"，到哪都能原样运行] 方式对新手最友好。

• 分布式

  ：官方自己是用 Fly.io 的私有网络 + Gossip 协议做服务发现的，多实例负载均衡。这个属于进阶玩法，一般个人用不太到。

几个关键的环境变量（配在服务器端）：

• ALLOWED_HOSTS

  ：允许哪些主机名进来，防域名被乱绑；

• CTRL_HOST

   / CTRL_PORT：控制通道监听的地址和端口；

• CTRL_TLS_OFF

  ：本地测试时可以关掉 TLS 加密，省事。

哪些场景，它真的能救命

挑几个我身边最常见的：

• 给客户/产品演示

  ：不用先部署到测试环境，本地改两笔直接发链接，对方点开就是最新效果。

• 接第三方 webhook

  [别人系统主动给你的地址"推消息"，比如支付成功通知、CI 构建结果，而不是你去反复查]：Stripe、GitHub Actions 这类，必须给一个公网可达的回调地址。localhost 收不到，Tunnelto 一接就通。

• OAuth 回调

  [用微信/Google 登录时，授权完成后对方要跳回你指定的地址]：本地调试第三方登录几乎是刚需。

• 移动端真机测试

  ：手机连外网访问你电脑上的页面，测响应式、测真机兼容性，比开模拟器真实。

• 前端联调

  ：前端同事连你本机的 API，不用你先推到远程。

安全这块别忽略

工具再方便，把本机暴露出去总得留个心眼。Tunnelto 提供几层保障：

• API Key 认证

  ：可以设一个密钥，没有密钥的人连不上你的隧道，防止被路人扫到乱用。

• 默认 HTTPS

  ：公网那一段是加密的（TLS），数据在传输途中不会被明文截获。

• 主机名白名单

  ：服务端能配置 ALLOWED_HOSTS，避免别人把你的子域名绑到别处去。

我的习惯：演示完、联调完，顺手把隧道关掉。别让它一直开着。

一点使用感受

优点很直接：安装简单、命令短、免费送自定义子域名、还能自托管，对隐私党友好。Rust 写的中转站资源占用确实低，我开着它基本感觉不到存在。

要说不足：项目最近更新不算特别活跃（最新稳定版是 0.1.18），生态和文档丰富度比不上 ngrok；另外官方公共服务器是别人提供的，介意数据路径的请务必走自托管。

总归，它适合想一条命令把本地服务甩到公网、又不想被收费项卡脖子的开发者。如果你正好被 webhook / 演示 / 联调这类事烦着，可以拉下来试五分钟，不行再卸也不亏。

项目地址：

• GitHub：https://github.com/agrinman/tunnelto

• 官网：https://tunnelto.dev

阅读原文：原文链接