我对 ngrok 感到沮丧，于是自己构建了一个自托管的隧道工具

Source: Dev.to

我已经运行副项目和本地开发环境多年。每次需要公开本地服务——测试 webhook、与团队成员共享进行中的工作、向客户演示某些功能——我都会选择 ngrok。而每一次，我都会遇到同样的障碍。

免费套餐提供 1 GB 带宽、一个活跃的隧道，以及每次会话都会更换的随机子域名。想要一个稳定的 URL？要花 10 美元/月。想要多个隧道？需要付更多钱。想使用自己的域名？只能选企业套餐。对于本质上只是把 TCP 包转发到我的机器的需求来说，这感觉像是为一个我自己可以解决的问题租用了别人的基础设施。

替代方案也并不理想

frp 在 GitHub 上拥有超过 10 万星标，所以我先尝试了它。技术上很扎实，但 TOML 配置真的让人头疼。我花了比实际建立隧道更多的时间来调试配置文件。它能工作——但它不尊重你的时间。

Cloudflare Tunnel 免费且功能强大，但你被锁定在 Cloudflare 生态系统中。他们的服务条款限制了你可以路由的流量，而且在 2025 年 6 月那次 2.5 小时的宕机中，很多人（包括我）意识到，依赖单一提供商来访问自己的服务是一个真实的风险。

bore 和 chisel 干净简约，但功能基础——没有自定义域名、没有多隧道管理、没有仪表盘。

Pangolin（YC 2025）起初很有前景，却逐渐演变成一个完整的零信任网络访问平台——包括 WireGuard、OIDC、RBAC、多站点管理。如果你是构建企业基础设施的系统管理员，这很棒。但如果你只是想在自己的域名上暴露 3000 端口，那就显得大材小用。

我想要的很简单：运行一条命令，在我的域名上获得一个隧道，完成。

我构建了 Proxly

Proxly 是一款自托管的隧道工具，能够让你通过自己的 VPS 上的子域名公开本地服务。使用 npm 安装后，交互式向导会一步步引导你完成所有设置：

npm install -g @a1tem/proxly
proxly

首次运行时，Proxly 会提示你输入用户名、转发主机和密钥令牌——随后让你设置第一个项目和隧道。为项目取个名字，指向一个端口（或完整的 URL），即可在 yourname‑myapp.yourdomain.com 上实时访问。

以后需要管理项目吗？CLI 操作非常简洁：

proxly add      # 创建新项目
proxly delete   # 删除项目
proxyl reset    # 重置所有

再次运行 proxly 时，如果只有一个项目会自动启动；如果有多个项目则会弹出选择器让你挑选。

Source:

架构：保持极简

请求流程非常直接：

Browser → Nginx (TLS on your VPS) → Relay server → WebSocket → Proxly CLI on your machine → your local dev server

该线协议使用 JSON 消息通过 WebSocket 传输，支持 HTTP 请求、WebSocket 连接以及二进制数据。

服务器端需要三件事：

1. 一台拥有公网 IP 的 VPS。
2. 一个指向该 VPS 的通配符 DNS（*.yourdomain.com）。
3. Node.js 18+（以及用于 TLS 终止的 Nginx）。

在本地机器上只需要 Node.js 和 Proxly CLI。

每个隧道将子域名映射到本地端口或目标 URL。你的配置保存在本机——只需设置一次，proxly 每次运行时都会自动生效。如果你在团队中工作，每个人都有自己的用户名命名空间，这样多个开发者就可以在不相互冲突的情况下为同一项目创建隧道。

什么让它与众不同

Proxly 并不想成为一个平台；它是一个专注于开发者体验的隧道工具。

接下来

Proxly 是开源的，自托管版本将永远免费。我正在开发一个托管版，供想要隧道服务但不想自己管理 VPS 的用户使用——如果你感兴趣，请加入等候名单。

当前的重点是打磨开发者体验：一键安装，第一条隧道在一分钟内上线，文档能够在你提问之前就解答疑惑。

如果你厌倦了 ngrok 的限制、frp 的配置文件，或依赖他人基础设施来访问自己的服务——请尝试 Proxly 并告诉我哪些地方出问题。

GitHub: