是的

是因为大家的他的内网穿透感兴趣的人变多了，虽然只是原因之一。

这里看看我们建立的新的隧道。

https://dash.cloudflare.com/554ec620453d03ce122797778b8ebd92/one/networks/connectors

使用自有域名托管需要先登录cloudefared

并且，必须使用一级域名的拓展，例如 fun.devs.top（这里的顶级域名 就是devs.top）

如下的就不行 fun.net.devs.top

这是详细的记录呢

这次把手机远程连接 claude-remote 的过程，最后证明了一个很现实的问题：能通 HTTP，不代表 WebSocket 也能通；能通 Tailscale，也不代表手机 App 真能把 ws:// 请求发出去。最开始我以为是本机服务没起来、端口没开或者 token 配错，于是先做排除法。先在 Windows 上确认 claude-remote 确实监听在 0.0.0.0:3100，再确认 Tailscale 电脑和手机彼此在线，本机访问 100.x.x.x:3100 也能通。之后又单独写了一个带日志的 HTTP 小服务，通过手机访问 /ping 和 /calc.html，最终在服务端日志里明确看到手机的 Tailscale IP，这一步证明了“手机 -> Tailscale -> PC”的 HTTP 链路没有问题。

但接着问题变得更绕：HTTP 能到，claude-remote 却始终收不到来自手机 App 的 WebSocket 握手。为此又专门写了一个最简 WebSocket 探针服务，监听 31003，专门记录有没有 WS 握手到达。结果反复测试后发现，手机 App 对 ws://100.x.x.x:31003 的尝试根本没有落到服务端。后来去读 App 仓库源码，发现它保存服务器后会自动发起 WebSocket probe，说明不是“我没点连接”，而是 App 端对明文 ws:// 很可能被 Android/WebView 的 cleartext 策略卡住了。这个时候方向才真正收敛：问题不是 Tailscale 本身，而是手机 App 对 ws:// 这条链路不稳定。

于是改走 Cloudflare Tunnel。先用 trycloudflare.com 的临时域名测试，把本地服务通过 wss:// 暴露出去。这里也踩了几次坑：一开始 cloudflared 回源写的是 http://localhost:31003，在 Windows 上被解析到 IPv6 ::1，而本地服务只监听 IPv4，结果不断报 connectex actively refused。改成 http://127.0.0.1:31003 后，这条问题才消失。进一步测试发现，手机 App 通过 wss://...trycloudflare.com 已经能真实发起 WebSocket，请求能到 Cloudflare Edge，说明 wss 方向是对的。再把同样的方法套到 claude-remote 的 3100 上后，服务端日志终于出现了完整链路：WS connected、WS hello、Auth OK、replay_done，这才算真正确认手机 App 可以通过 Cloudflare 稳定连到本机 claude-remote。

最后为了摆脱临时 trycloudflare.com 每次都会变的麻烦，又继续走了命名隧道。先执行了 cloudflared tunnel login、cloudflared tunnel create claude-r、cloudflared tunnel route dns ...，然后自己写 config.yml，把固定域名映射到本机 127.0.0.1:3100。这里又遇到一个很容易忽略的坑：最开始绑定的是 claude-r.net.de---.top，这是二级子域名，结果浏览器直接报 ERR_SSL_VERSION_OR_CIPHER_MISMATCH。后来才意识到 Cloudflare 免费证书通常只稳妥覆盖根域和一级子域，于是把域名改成单层的 claude-r.d---.top。这时配置才真正走上正轨。

这一整套折腾下来，最有价值的经验不是某条命令，而是排查顺序。第一，先把 HTTP 和 WS 分开验证，不要因为浏览器能打开页面就以为 WebSocket 也能通。第二，不要只盯着客户端报错，要让服务端一定能留下“有没有收到请求”的证据。第三，Windows 下 localhost 和 127.0.0.1 在隧道回源场景里不能想当然混用。第四，如果手机 App 对 ws:// 路子始终诡异，优先怀疑平台策略，尽快切到 wss://。最后的结论也很明确：对这种手机远程控制 claude-remote 的私用场景，最终保留 Cloudflare Tunnel + 固定域名 + wss，比继续死磕 Tailscale + 明文 WebSocket 更省事，也更稳定。

国内其他进展

用户只需输入“帮我部署 OpenClaw”，**KiKi 就会自动完成资源购买、环境初始化到部署配置的全过程**，并在关键节点提示确认，其余步骤全部自动执行。
KiKi 还可以实现在官网、控制台、购买页等多个页面之间的自动跳转，理解当前上下文，自主拆解任务并选择最优路径执行，把原本割裂的多页面操作，变成一次连续完成的任务。

在执行能力之外，KiKi 也保留了对流程的控制权。**所有操作步骤均可视、可追溯**，用户可以随时介入或中断；在涉及关键或敏感操作时，系统会主动暂停并请求确认，确保操作边界清晰可控。当任务执行受阻时，KiKi 还能自动调整策略、重新规划路径。

其实类似的，spaceship域名管理网站在0205年我用的时候就有了。