本地服务分享 & 本地 webhook 接收回调

把本地服务,安全送到公网。

把本地或 VPC 内服务映射为稳定公网入口,叠加鉴权与访问控制,联调、演示与临时协作即刻可用。

FinderFileEditViewGoWindowHelp
Mon Jul 206:25 PM
https://app-7f3a.orbitproxy.io
内网localhost服务
主页博客联系我其他
$npm run dev
Listening on http://localhost:5173...
Local: http://localhost:5173/
$orbitproxy http 5173
Endpoint https://app-7f3a.orbitproxy.io
-------------
[15:21:59] GET / 200
[15:21:58] GET /api 200
$

localhost / 内网程序的一些不便之处

联调、演示、协作经常卡在「对面访问不到你的本机」

本地 localhost 或 VPC 里的服务默认出不了网。前端同学要临时开站点给产品预览,后端同学要临时开接口给前端调,都先卡在「对面访问不到你的本机」。给同事看一眼页面、给客户走一遍流程、让第三方回调打进来,也都先卡在「你那台机器别人进不去」。

自己搭隧道还要养证书、进程和域名

自己维护 frp、nginx、证书和域名,理解和运维成本都不低。对 AI 时代的小团队来说,这些进程本身就是负担,分享一次服务不该变成一次运维事故

敏感环境MCP服务不敢直接暴露给AI Agent调用

MCP非常强大,AI可以利用MCP对你的服务做任何事情,可以查日志,可以操作数据库,可以重启服务甚至可以读取改写你生产环境的配置文件和环境数据,但同样MCP也很危险,同时伴随一个致命缺陷,很多服务在 linux 云端,而 mysql 这种只提供 exec 模式的MCP交互根本出不了公网给AI Agent调用。

服务一旦裸奔公网,没有鉴权就等于开门揖盗

临时分享常常先图快,鉴权后补。公网入口一旦暴露,扫描、爆破、刷接口会立刻找上门,演示环境同样会被打穿。

换网络、换咖啡店,公网地址就变了

家庭宽带、公司网络和咖啡馆的出口都不一样。没有稳定 Endpoint,移动端联调、第三方回调配置、分享出去的链接都会反复失效。

webhook 和移动端调试,需要一条稳定入口

微信支付、OAuth、开放平台回调打不到 localhost;手机 App 也连不上你电脑上的后端。没有稳定公网入口,这类联调只能靠猜,或者把服务先发到测试环境。

为本地服务分享带来哪些能力

提供穿透域名和 TLS 证书,Endpoint 不会因为你换了网络就失效。把同一个地址交给联调方、移动端或第三方回调配置,在家、公司和咖啡馆都能打到同一台本机服务。

本机先跑起服务,再把端口交给 。 几步操作就能拿到公网入口,把 localhost 或 VPC 内服务映射出去,联调、演示和临时协作不必先发一版测试环境。

在穿透方面的优势

极度注重安全

得益于 团队多年在 k8s 云原生及网关的经验和耕耘, 深知作为一个网关需要在安全模型方面积累多少底蕴才能做到让用户可以放心地把流量交给我们。内网客户端和云网关采用自签 CA TLS 私有信道,用户数据始终本地私钥加密传输,可随时吊销;云网关启用实时巡检扫描恶意流量并拦截,用户内网零感知。

极度注重性能和稳定

数据面启用 TCPMux 多路复用:内网客户端与云网关只维持一条 TLS 会话,业务流量在同一条连接上按需打开 yamux work stream,不必为每个请求重建隧道。存活探测由 yamux keepalive 承担,短暂卡顿不会拆掉整条会话。HTTP 入口复用空闲连接,work 配额接近上限时回收空闲流,避免把隧道打满。控制面不可达时,数据面继续从本地 SQLite 转发,隧道不跟着控制中心一起停。

MCP AI领域领先

对 AI 提供第一梯队支持,自研 MCP Composer 引擎提供对内网 MCP 服务的聚合解决方案,行业领先。多个内网 MCP Tool,一条 Composer 隧道,意味着你可以将内网 MCP 服务根据不同环境、不同机器交给 AI 批量管理和维护。同时 积极适配主流 AI Agent,提供更安全稳定的 AI 解决方案。

更强大的可观测性

提供了一套完善的云端点观测机制,让你可以随时知道自身云端点的所有访问情况及 AI 调用情况。了解内网服务全链路观测

准备把现有服务接进来

控制台已经具备云端点、网关与策略配置能力。把本地、VPC 与边缘入口接上同一条可控链路,马上开始构建。

进入控制台