内网穿透的竞争维度变了：有人在折腾端口转发，有人在让 AI 自己打通隧道

title: "内网穿透的竞争维度变了：有人在折腾端口转发，有人在让 AI 自己打通隧道" description: "从 ngrok 到 Cloudflare Tunnel 再到 Sealtun，内网穿透工具正在经历一次范式转移——不只是把 localhost 暴露出去，而是让 AI Agent 自己完成从本地到公网、从本机到集群的全部打通工作。" tags: ["内网穿透", "Sealtun", "Sealos", "ngrok", "Cloudflare Tunnel", "Kubernetes", "AI编程"]

你见过交响乐团只有一个乐手吗？

现在大部分开发者的内网穿透就是这种状态——你手动敲一条命令，手动复制链接，手动发给同事，手动检查隧道是不是断了，手动重启。每一个环节都是人在做中转。

更讽刺的是，AI 已经能帮你把应用写完、跑起来，终端里优雅地输出 Local: http://localhost:3000，然后呢？然后你还得自己当半个运维：找服务器、配 Nginx、申请证书、开安全组、改防火墙规则。

AI 写完了代码，但最后 100 米的网络打通，还得你自己跑。

这个矛盾正在被一种新工具解决——不是更快的 ngrok，而是把隧道放回 Kubernetes 工作流里的 Sealtun。

从「能不能访问我」到「能不能自己打通」

内网穿透工具的演进，大致经历了三个阶段：

第一阶段：手动打洞。 frp、ngrok 的时代。你能用，但每一步都得自己来——装客户端、写配置、启动服务、复制链接。ngrok 免费版每次重启换域名，生产环境根本不敢用。

第二阶段：平台托管。 Cloudflare Tunnel 的时代。免费、稳定、自带 Zero Trust 安全策略，但你需要把域名托管到 Cloudflare，配置 cloudflared 客户端，写 ingress 规则。它很强，但它是 Cloudflare 生态的工具，不是你开发工作流的一部分。

第三阶段：工作流内嵌。 Sealtun 代表的方向。它不只是一个隧道工具，而是 Sealos Cloud 和 Kubernetes 工作流的一个环节。登录用 Sealos 账号，证书自动签发，Ingress 自动配置，Pod 状态、Service 状态、日志、事件都在同一个上下文里。

这不是功能升级，是范式转移：隧道从「我额外装的一个工具」变成了「我工作流里的一步」。

两条命令，两种方向

Sealtun 的核心能力只有两个，但覆盖了开发者最痛的两个方向：

方向一：把本地服务推到公网。

sealtun login
sealtun expose 3000

一条命令，拿到一个 HTTPS URL。发给同事、填到 Webhook 回调地址、让另一个 AI Agent 继续联调，都行。

它省掉的不是「能不能穿透」这件事——ngrok 也能做。它省掉的是穿透之后那一堆事：不用配 Nginx 反代，不用手动申请证书，不用开安全组，不用让非技术同学理解什么叫 localhost。

方向二：把集群服务拉到本机。

sealtun login
sealtun connect --check
sudo sealtun connect

启动后，你的本机可以直接访问 Kubernetes 集群里的 Service FQDN、ClusterIP 和 Pod IP。MySQL、Redis、curl、浏览器、本地调试工具，都不需要各自配置代理。

以前你想让本机访问集群里的服务，常见做法是 kubectl port-forward，一次只能转发一个端口，断开重连是家常便饭。Sealtun 的 connect 走透明 TCP 模式，临时写入 iptables 和 /etc/hosts，所有工具无感接入。

一个推出去，一个拉回来。 两个方向，一条隧道。

分享链接 ≠ 裸奔链接

临时预览最怕什么？怕链接被转发，怕忘记关，怕谁拿到都能访问。

Sealtun 的安全控制不是事后补丁，而是内建能力：

• Basic Auth：给预览链接加用户名密码
• Bearer Token：API 场景的认证方式
• IP 白名单/黑名单：限制访问来源
• 限流：防止链接被滥用
• 临时分享链接：1 小时后自动失效，支持轮换
• 访问审计：谁在什么时候访问了什么，有记录

这些能力不需要你一上来全学，但当「发给别人看一下」变成真实工作流，访问控制和可回收能力就必须跟上。

一个没有过期机制的分享链接，就是一颗定时炸弹。

代价清醒：Sealtun 不是万能药

任何工具都有边界，Sealtun 也不例外。在决定使用之前，你需要知道这些：

1. 它绑定 Sealos 生态。 Sealtun 的登录、证书、Ingress、诊断全部依赖 Sealos Cloud。如果你不用 Sealos，Sealtun 对你来说就是空气。这不是通用工具，是生态工具。

2. connect 功能仅限 Linux。 透明 TCP 模式需要写 iptables 和 /etc/hosts，macOS 和 Windows 明确暂不支持。如果你是 Mac 开发者，只能用 expose 方向。

3. 项目还很早期。 GitHub 上 61 star、8 fork、0 issue、0 PR，没有设置 License。这意味着社区参与度低，文档和稳定性还需要时间验证。生产环境慎用。

4. 成本来自 Sealos Cloud。 Sealtun 本身不收费，但隧道占用的 CPU、内存、端口、流量都走 Sealos Cloud 计费。不同区域单价不同，长期开着隧道不关，账单会说话。

5. 需要 root 权限。 connect 模式要 sudo，这在容器化开发环境里可能是个障碍。

竞品横评：你到底该用哪个？

选型建议：

• 你只是临时给同事看一眼页面 → ngrok 够用
• 你要长期稳定暴露服务、域名已在 Cloudflare → Cloudflare Tunnel
• 你要完全自控、有服务器资源 → frp
• 你在用 Sealos Cloud 或 Kubernetes、需要集群内外双向打通 → Sealtun

AI Agent 时代的隧道，应该对 Agent 友好

Sealtun 最有意思的设计不是技术本身，而是给 Codex 准备的 Skill。

npx skills add https://github.com/gitlayzer/sealtun

安装后，当你在 Codex 里说「把本地 3000 端口暴露出去」，AI 不需要从零猜命令，也不需要临时翻 README。它知道该用 Sealtun，知道要先检查登录态，知道什么时候只给建议不执行，知道 expose、apply、stop 这类改变状态的命令要更谨慎。

这不是让 AI 记住几个命令，而是让 AI 更懂操作边界。

这个思路值得所有 CLI 工具学习：在 AI 编程时代，命令行工具不能只对人友好，也要对 Agent 友好。你的工具如果 AI 不会用，那 AI 帮用户写完代码之后，用户还是得自己查文档、自己敲命令——AI 编程的效率增益，在最后 100 米被吃掉了。

趋势判断

内网穿透工具的竞争维度正在变化：

过去比的是： 谁更快、谁更稳定、谁免费额度更多。

未来比的是： 谁更懂你的工作流、谁能让 AI 自己完成打通、谁能把隧道从「额外工具」变成「工作流的一步」。

Sealtun 现在还很早期，61 star 的项目离生产级还有距离。但它指出的方向是对的：隧道不应该是一个独立工具，而应该是开发平台的一个原生能力。

就像 iPhone 之前，手机上网需要额外装浏览器、装邮件客户端、装地图 App。iPhone 把这些变成了原生能力。Sealtun 在做的事，类似——把内网穿透从「你额外装的工具」变成「平台原生的一步」。

这个方向，比多支持一个协议、多开一个节点，重要得多。

Sealtun 项目地址： https://github.com/gitlayzer/sealtun

Sealos 国内集群： https://cloud.sealos.run

如果你经常被 localhost 分享、Webhook 回调、本地调集群服务这些问题打断，可以试试。但记住：它绑定 Sealos 生态，connect 只支持 Linux，项目还在早期。选工具之前，先看清代价。