bore 还是 tunnelto？Rust 内网穿透双雄选型与上手指南
本地跑着 Spring Boot、Vite 或 FastAPI，微信回调打不进来；同事在家，你的 API 还在公司内网；老板突然要看 Demo，你又不想把半成品部署到测试服——这类场景里，内网穿透几乎是开发者的标配能力。
近两年 Rust 生态里冒出两款口碑很好的 CLI：bore（公网实例 bore.pub）和 tunnelto（公网实例 tunnelto.dev）。它们都被拿来和 ngrok、frp、localtunnel 比较，但设计哲学完全不同：一个只管 TCP 转发，一个为 Web 联调做了全套封装。
本文从原理、命令、场景到安全边界，帮你一次性搞懂「综合开发者该怎么选、怎么用」。
一、30 秒看懂：它们各自解决什么问题？
| 维度 | bore | tunnelto |
|---|---|---|
| 一句话 | 极简 TCP 隧道，把本地端口搬到公网 | 面向 Web 的 HTTPS 穿透 + 调试面板 |
| 协议层 | 纯 TCP（SSH、数据库、任意端口） | 主要服务 HTTP/HTTPS 本地 Web |
| 公网形态 | bore.pub:随机端口 |
https://子域名.tunnelto.dev |
| HTTPS | 不处理，需自建反代 | 官方 SaaS 自带 HTTPS |
| 流量面板 | 无 | 本地 http://localhost:9999 |
| Star 量级 | GitHub 约 8k+ | GitHub 约 6k+ |
| 适合谁 | 要穿透非 HTTP、追求极简 | Webhook/支付回调/前后端联调 |
记忆口诀：
- 穿透 MySQL / SSH / 游戏端口 → 想少配置 → bore
- 穿透 本地 8080 Web API，还要 HTTPS 回调地址 → tunnelto
二、底层原理：为什么同是 Rust，体验却差这么多？
2.1 bore：只做「TCP 管道」
bore 的定位在官方 README 里写得很直白："That's all it does: no more, and no less."
工作流程大致是：
1. 客户端 bore local 连到远程 bore server（或公共 bore.pub）
2. 通过控制通道（默认端口 7835）协商「远程监听哪个端口」
3. 公网访问 bore.pub:端口 时，流量被原样转发到你本机 localhost:PORT
它不解析 HTTP，也不终结 TLS。所以你拿到的是「裸 TCP 隧道」——灵活，但 Web 场景要自己处理证书和域名。
2.2 tunnelto：HTTP 反向代理 + 子域名路由
tunnelto 在客户端与 tunnelto_server 之间建立控制连接，把公网 HTTPS 请求按 Host 子域名 路由到本地 http://localhost:端口。
因此它天然适合：
- 支付/微信 notify_url（必须是公网 HTTPS）
- GitHub / 飞书 Webhook（对方只认 URL，不认端口）
- 手机真机访问你电脑上的 dev server（HTTPS 页面混合内容限制更少）
底层同样基于 Tokio 异步 IO，高并发时内存占用低；但产品层多了子域名、Dashboard、API Key 绑定等「Web 开发者友好」能力。
三、上手命令：复制就能跑
3.1 bore：一行映射本地端口
安装（任选其一）
# Rust 生态
cargo install bore-cli
# 或下载 Release 二进制：https://github.com/ekzhang/bore/releases
使用公共服务器 bore.pub
# 把本地 8000 暴露到 bore.pub 的随机远程端口
bore local 8000 --to bore.pub
典型输出（端口每次可能不同）：
listening at bore.pub:51234
访问方式：http://bore.pub:51234（注意是 带端口 的 HTTP，不是子域名路径）。
指定远程端口（需该端口空闲）
bore local 8000 --to bore.pub --port 19999
自建服务端（团队内网 / 合规场景）
# 公网 VPS 上
bore server
# 本机连接自己的服务器
bore local 8000 --to your-vps-ip
可选环境变量 BORE_SECRET 为控制通道增加简单鉴权。
本机实测 bore --help 输出摘要：
Usage: bore <COMMAND>
Commands:
local Starts a local proxy to the remote server
server Runs the remote proxy server
3.2 tunnelto：HTTPS 域名直达本地 Web
安装
brew install agrinman/tap/tunnelto
# 或
cargo install tunnelto
最简启动（本地 8080）
tunnelto --port 8080
输出示例：
https://a1b2c3d4.tunnelto.dev/ -> http://localhost:8080/
固定子域名（推荐联调时绑定）
tunnelto set-auth --key sk-your-api-key-here
tunnelto --port 8080 --subdomain my-api-dev
# => https://my-api-dev.tunnelto.dev/
本地流量审计面板
隧道运行期间打开：
http://localhost:9999
可查看经隧道的 HTTP 请求/响应，调试微信回调时非常省事。
四、五大真实场景：该用谁？
场景 1：微信支付 / 支付宝沙箱回调
推荐：tunnelto
沙箱配置里的 notify_url 通常要求 HTTPS 公网 URL。tunnelto 直接给出 https://xxx.tunnelto.dev/...，填进后台即可在本机断点调试。
bore 只能给你 http://bore.pub:端口，多数支付平台不接受，还要自己在 VPS 上套 Nginx + 证书，得不偿失。
场景 2：穿透本机 PostgreSQL / Redis / SSH
推荐：bore
数据库和 SSH 都是 TCP 协议，tunnelto 的 HTTP 路由模型并不对口。bore 一条命令把 5432 或 22 映射出去即可（务必配合防火墙与强密码，见下文安全章节）。
场景 3：GitHub Actions / 飞书 Webhook 打到本地
推荐：tunnelto
Webhook 提供方按 URL 发 HTTP POST。tunnelto 的 HTTPS 端点 + 本地 Dashboard，能直接看到 payload 与 Header。
场景 4：给老板 / 客户演示本地 H5
两者皆可，优先 tunnelto
tunnelto 链接是标准 HTTPS 域名，手机点开更顺；bore 需要记住 主机:端口，且默认 HTTP，部分浏览器环境会提示不安全。
场景 5：公司有合规要求，不能走第三方 SaaS
推荐：bore 自建 或 frp
- bore：
bore server部署在自有 VPS，客户端--to指向内网可控节点，架构简单。 - tunnelto：可自建
tunnelto_server，但泛域名解析、通配证书、多实例协调成本更高；国内团队长期自建更常选 frp（文档与社区成熟）。
五、和 ngrok / frp / localtunnel 怎么排座次？
把 bore、tunnelto 放进「全家桶」里看，角色更清晰：
| 工具 | 类型 | 优势 | 短板 |
|---|---|---|---|
| ngrok | 商业 SaaS + 客户端 | 生态成熟、功能全 | 国内不稳、免费版限制多 |
| frp | 自建为主 | 国内文档多、稳定可控 | 必须有公网机、要运维 |
| localtunnel | Node 轻量 SaaS | 安装简单 | 稳定性一般、HTTP 为主 |
| bore | 极简 TCP | 二进制小、自建简单 | 无 HTTPS、无 Web UI |
| tunnelto | Rust Web 隧道 | HTTPS + 子域名 + Dashboard | SaaS 流量经第三方 |
综合开发者推荐组合（亲测够用）：
日常 Web 联调 / 回调调试 → tunnelto（随开随关）
TCP 服务 / 数据库临时暴露 → bore（或 bore 自建）
长期稳定、多同事共用 → frp 自建
六、安全红线：便利不等于可以裸奔
[!WARNING] 内网穿透等于在防火墙上临时开一扇窗，以下规则请当作肌肉记忆。
1. 仅用于开发联调：演示结束立刻 Ctrl+C 关隧道，不要把穿透地址写进生产配置。
2. 公共 SaaS 中转风险：bore.pub、tunnelto.dev 上的流量会经过第三方服务器，禁止传输真实用户数据、生产密钥、数据库全量导出。
3. bore 隧道加密有限：控制通道可用 secret，但转发中的 TCP 载荷默认不额外加密；敏感服务应套 TLS 或 VPN。
4. 固定子域名被扫描：tunnelto 绑定固定 subdomain 后，可能被扫描器撞库；本地服务不要有未授权接口、调试后门。
5. 数据库切勿长期暴露：用 bore 临时开 5432 时，务必限制来源 IP、强密码，并Prefer SSH 隧道替代直接暴露。
七、常见问题速查
Q：bore 和 tunnelto 能同时装吗？
能。它们不冲突，按场景切换命令即可。
Q：tunnelto 能穿透 WebSocket 吗？
本地 HTTP 服务升级的 WebSocket，多数情况下可以随 HTTP 一起穿透；纯 TCP 长连接更建议 bore。
Q：国内访问 bore.pub / tunnelto.dev 稳吗？
公共实例无 SLA，偶发超时正常。重要演示前先在目标网络试连；稳定需求请自建。
Q：和之前介绍的 tunnelto 专题文重复吗？
仓库里已有 tunnelto 单品深度文；本篇是 bore + tunnelto 双雄对比 + 综合选型，侧重「该用哪个」。
八、总结：一张表做最终决定
| 你的需求 | 首选 |
|---|---|
| 本地 Web API + HTTPS 公网地址 | tunnelto |
| 看 HTTP 请求明细、调试 Webhook | tunnelto |
| SSH / 数据库 / 任意 TCP 端口 | bore |
| 最小依赖、自建一台 VPS 就够 | bore server |
| 团队长期内网穿透平台 | frp（bore/tunnelto 作个人轻量补充） |
Rust 把这两款工具的性能底子都打磨得很好；真正拉开差距的，是你需要的是「管道」还是「Web 联调套件」。搞清这一点，命令行里那两行配置，基本就不会选错。
项目地址
- bore：https://github.com/ekzhang/bore（公网示例：bore.pub）
- tunnelto：https://github.com/agrinman/tunnelto（公网示例：tunnelto.dev）
长按二维码关注 “边学边练”
