小蓝中转站使用文档

Hapi 进阶：优选 IP 配置 ​

当 HAPI 已经能正常工作，但你开始在意远程访问速度、跨地区稳定性或长期在线体验时，再看这一页最合适。

如果你还没把 HAPI 的基本链路跑通，先回到 Hapi 远程控制。

先分清你到底在优化哪一层 ​

很多人会把 HAPI 的远程入口，和底层模型调用的速度混在一起看。实际上它们是两层不同的问题：

  1. HAPI 远程访问层 决定你能不能顺利从手机或浏览器连回会话
  2. 底层模型请求层 决定 Claude Code、Codex、OpenCode 本身连到 小蓝中转站 后快不快

如果手机端页面都很难打开，那大概率先看 HAPI 入口。 如果页面打开很快，但模型回复很慢，那更可能是底层 CLI 当前选择的模型、上下文大小或网络本身的问题。

什么情况下值得继续优化 ​

出现下面这些情况时，再继续折腾入口和线路才有意义：

  • 不同地区访问同一个 HAPI Hub，体验差异明显
  • 本机浏览器访问正常，手机外网访问不稳定
  • Hub 会长期跑在远端开发机或 VPS 上
  • 你准备把它当成日常工作入口，而不是偶尔临时接管一次

如果只是偶尔远程看一眼会话，默认链路通常已经够用。

优化前先确认基础链路没问题 ​

继续优化前，先做三步排除：

  1. 底层 CLI 单独运行时，已经能稳定走 小蓝中转站
  2. hapi hub --relay 本身已经能正常给出访问地址和令牌
  3. 同一网络下至少有一台设备能稳定打开并发送消息

这三步的目的是先证明“系统本身是通的”。只有先排除配置错误、Key 错误和模型错误，后面的 IP 优化才不是盲调。

更稳的思路 ​

让 HAPI 和工作目录待在更稳定的机器上 ​

如果你经常需要远程接管，会比“在笔记本上临时开一个会话再出门”更稳的方式，是把 HAPI Hub 和常用项目放在固定开发机或 VPS 上。

这样做的好处是：

  • 机器不会因为合盖、睡眠或切网而中断
  • 外部访问入口更固定
  • 更适合配合 hapi runner start 长期运行

如果你的机器是笔记本，睡眠和合盖几乎一定会影响远程体验。
HAPI 官方安装文档当前专门提到过这一层：Hub 和 Runner 还在不在，不只取决于命令有没有启动，也取决于这台机器有没有继续保持在线。

在 macOS 上，如果你只是临时想避免会话因为休眠中断，可以先用：

bash
caffeinate -dimsu hapi hub --relay

它解决的不是模型调用速度，而是“这台机器别在你离开后先睡着”。

入口链路越短越好 ​

能直接访问的情况下，不要给 HAPI 叠太多中间层。代理、转发、二次转发越多，排障越麻烦。

先保证最短链路可用，再考虑继续加：

  • 反代
  • 自定义域名
  • 多区域入口

HAPI 官方安装页当前给出的自托管替代路线，主要是这三类：

  • 机器本身有公网 IP：直接访问或挂反代
  • Tailscale：适合私有网络和固定设备之间互联
  • Cloudflare Named Tunnel：适合没有公网 IP、又想稳定给外网访问

如果你只是临时想看一眼，也可以先继续用 hapi hub --relay。
但一旦开始追求更低延迟、更稳定的长连接，自己掌控入口通常比一层层中转更直接。

有一点官方文档写得很明确：Cloudflare Quick Tunnel（TryCloudflare）不适合 HAPI 的实时页面更新。
原因不是 HAPI 挑环境，而是它依赖 SSE 长连接；官方建议在 Cloudflare 路线上直接使用 Named Tunnel。

按场景选入口 ​

只给同局域网设备临时访问 ​

这种场景通常最省事：

bash
export HAPI_LISTEN_HOST=0.0.0.0
hapi hub --no-relay

然后让同一 Wi-Fi 下的设备访问：

txt
http://你的电脑局域网 IP:3006

这一套没有额外中转，排障也最简单。
如果这一层都不稳定，先不要急着上公网入口，先看本机防火墙、路由器隔离和机器睡眠。

机器本身有公网 IP ​

如果 HAPI 跑在有固定公网 IP 的开发机或 VPS 上，最直接的做法通常是：

  1. 先让 Hub 在本机稳定跑起来
  2. 再用反向代理或 Web 服务器把入口收敛到固定域名
  3. 给外部入口补 HTTPS

这样做的好处，是你完全知道入口在哪一层、证书在哪一层、日志又在哪一层。
比起多套一层临时隧道，长期维护时更省心。

没有公网 IP，但设备基本固定 ​

这种情况下，官方当前更推荐 Tailscale 这一类私有网络互联方式。
它的优势不是“更神奇”，而是设备关系固定、连通性清楚，比较适合你自己的电脑、手机和开发机之间长期互通。

没有公网 IP，但需要浏览器远端访问 ​

这种场景再看 Cloudflare Named Tunnel 更合适。
重点不是“Cloudflare 一定更快”，而是它比 Quick Tunnel 更适合 HAPI 依赖的实时连接方式。

把“远程访问入口”和“模型调用问题”分开排障 ​

最常见的误区是：页面慢，就去换模型；模型慢，就去换入口。

更稳的判断顺序是：

  • 页面都打不开：先看 HAPI 入口、Hub、Relay、令牌
  • 页面能打开但消息发不出去：先看会话状态和 Runner
  • 页面和消息都正常，只有回答慢：回到底层 CLI 和当前模型

Relay 连得上但很不稳 ​

HAPI 官方 FAQ 还给出过一条很实用的思路：如果你怀疑当前 Relay 路径不稳定，可以先强制改走 TCP 再试一次。

bash
export HAPI_RELAY_FORCE_TCP=true
hapi hub --relay

这一步的作用不是“永久最佳实践”，而是帮助你快速判断：问题到底是临时网络路径，还是更基础的 Hub / Runner / CLI 层。

什么时候不建议继续折腾优选 IP ​

下面几种情况，继续做 IP 优化大多收益不高：

  • 你只是偶尔远程查看一次会话
  • 你的主要问题其实是模型名写错、Key 无效或底层 CLI 没配好
  • HAPI 本机访问本来就不稳定
  • 当前瓶颈其实是大上下文任务本身，而不是入口线路

先把基础稳定性做好，再谈“更快”更划算。

一个实用的排查顺序 ​

当你怀疑远程体验差时，按这个顺序看：

  1. 本机验证底层 CLI
    • Claude Code / Codex / OpenCode 单独能不能正常回复
  2. 本机验证 HAPI
    • 本机浏览器能不能稳定访问 Hub 页面
  3. 同局域网验证
    • 同一网络下的另一台设备能不能接管
  4. 外网验证
    • 手机流量或异地网络能不能接管
  5. 最后才看 IP、反代和线路优化

这样做的原因很简单：越靠前的问题越基础，也越容易被误认为“线路问题”。

长期运行时的建议 ​

  • 远端环境单独使用一把 Key
  • 定期检查 ~/.hapi/settings.json 的保存位置和访问权限
  • 给需要长期在线的机器准备固定工作目录
  • 不要把 HAPI 访问令牌和项目代码一起同步到公开仓库
  • 如果你改成了自托管公网入口，优先给它配 HTTPS，再对外分享
  • 用 Runner 长期在线时，顺手保留 ~/.hapi/logs/，排障会轻松很多

如果你已经进入长期运行阶段，再顺手把这几个状态看起来：

bash
hapi runner status
ls ~/.hapi/logs

很多“昨晚明明还好好的，今天怎么不行了”，最后都不是模型配置变了，而是 Runner 中断、机器睡眠，或者入口层自己换了状态。

长期用得越多，越应该把会话入口、模型凭证和项目目录分开管理。

小蓝中转站使用文档

© 2026 小蓝中转站