极度注重安全
得益于 orbitproxy 团队多年在 k8s 云原生及网关的经验和耕耘,orbitproxy 深知作为一个网关需要在安全模型方面积累多少底蕴才能做到让用户可以放心地把流量交给我们。内网客户端和云网关采用自签 CA TLS 私有信道,用户数据始终本地私钥加密传输,可随时吊销;云网关启用实时巡检扫描恶意流量并拦截,用户内网零感知。
本地 localhost 或 VPC 里的服务默认出不了网。前端同学要临时开站点给产品预览,后端同学要临时开接口给前端调,都先卡在「对面访问不到你的本机」。给同事看一眼页面、给客户走一遍流程、让第三方回调打进来,也都先卡在「你那台机器别人进不去」。
自己维护 frp、nginx、证书和域名,理解和运维成本都不低。对 AI 时代的小团队来说,这些进程本身就是负担,分享一次服务不该变成一次运维事故。
MCP非常强大,AI可以利用MCP对你的服务做任何事情,可以查日志,可以操作数据库,可以重启服务甚至可以读取改写你生产环境的配置文件和环境数据,但同样MCP也很危险,同时伴随一个致命缺陷,很多服务在 linux 云端,而 mysql 这种只提供 exec 模式的MCP交互根本出不了公网给AI Agent调用。
临时分享常常先图快,鉴权后补。公网入口一旦暴露,扫描、爆破、刷接口会立刻找上门,演示环境同样会被打穿。
家庭宽带、公司网络和咖啡馆的出口都不一样。没有稳定 Endpoint,移动端联调、第三方回调配置、分享出去的链接都会反复失效。
微信支付、OAuth、开放平台回调打不到 localhost;手机 App 也连不上你电脑上的后端。没有稳定公网入口,这类联调只能靠猜,或者把服务先发到测试环境。
orbitproxy 提供穿透域名和 TLS 证书,Endpoint 不会因为你换了网络就失效。把同一个地址交给联调方、移动端或第三方回调配置,在家、公司和咖啡馆都能打到同一台本机服务。
本机先跑起服务,再把端口交给 orbitproxy。 几步操作就能拿到公网入口,把 localhost 或 VPC 内服务映射出去,联调、演示和临时协作不必先发一版测试环境。
HTTPS / TCP 域名由 orbitproxy 签发,内网和 localhost 服务不用自己暴露公网入口。
访问控制、鉴权和私有信道在网关完成。内网地址不对外,设备级私钥隔离。
经过 orbitproxy API 网关的每一次请求都会留痕。来源、路径和结果都可以回看。
限流、熔断、改写按路径挂载,热更新生效。不用改业务代码也能收紧入口。
得益于 orbitproxy 团队多年在 k8s 云原生及网关的经验和耕耘,orbitproxy 深知作为一个网关需要在安全模型方面积累多少底蕴才能做到让用户可以放心地把流量交给我们。内网客户端和云网关采用自签 CA TLS 私有信道,用户数据始终本地私钥加密传输,可随时吊销;云网关启用实时巡检扫描恶意流量并拦截,用户内网零感知。
数据面启用 TCPMux 多路复用:内网客户端与云网关只维持一条 TLS 会话,业务流量在同一条连接上按需打开 yamux work stream,不必为每个请求重建隧道。存活探测由 yamux keepalive 承担,短暂卡顿不会拆掉整条会话。HTTP 入口复用空闲连接,work 配额接近上限时回收空闲流,避免把隧道打满。控制面不可达时,数据面继续从本地 SQLite 转发,隧道不跟着控制中心一起停。
orbitproxy 对 AI 提供第一梯队支持,自研 MCP Composer 引擎提供对内网 MCP 服务的聚合解决方案,行业领先。多个内网 MCP Tool,一条 Composer 隧道,意味着你可以将内网 MCP 服务根据不同环境、不同机器交给 AI 批量管理和维护。同时 orbitproxy 积极适配主流 AI Agent,提供更安全稳定的 AI 解决方案。