先说结论：
这次 iPhone 端连不上，不是一个“入口填错了”的问题，而是连接、配对、语音三层问题叠在一起。
公开表达里我把 OpenClaw 这类本地 AI 助手网关简称为“小龙虾”。这不是绕规则，而是减少工具品牌词被误判；真正的合规点是不放真实地址、授权码、设备 ID 和导流元素。
第一层：连接
Mac 上能访问本地服务，不代表 iPhone 也能访问。
127.0.0.1 在每台设备上都指向自己。Mac 能打开本地网关，只能证明 Mac 自己能访问它；手机要访问 Mac 上的网关，需要处在同一条可达链路里。
实际排查时，先确认这几件事：
- 手机和 Mac 是否在同一个局域网里。
- 如果走 Tailscale，手机是否也打开了 Tailscale。
- 入口是否是手机能访问的 HTTPS 网关，而不是手机自己的 loopback。
- Mac 端网关是否仍然保持本地 loopback，不要为了手机访问直接乱改服务暴露方式。
只有这一层通了，后面的配对和语音才有意义。
第二层：配对
Safari 能打开网关页面，只能说明网络可达，不代表 App 已经获得授权。
移动端还要完成 setup code 或配对码流程，并在网关侧确认对应设备处于 connected 和 approved 状态。
这里最容易误判：
- 页面能打开，不等于 App 已经配对。
- 旧配对残留，可能让状态一会儿 online、一会儿 offline。
- setup code 过期后，需要重新生成，不要拿旧码继续试。
- 设备没有 approved，就算网络通了，也可能不能稳定工作。
我现在会把配对单独当成一层，而不是把它混在“网络不通”里。
第三层：语音
连接和配对成功以后，Talk 报错又是另一件事。
Google、MiniMax、OpenAI 不是一个概念：实时语音、语音合成和大模型 API 要分开看。ChatGPT 套餐也不等于 OpenAI API Key，更不等于 realtime API 可用额度。
iOS 端尤其要看 transport：
- 当前 provider 支持 websocket，还是 WebRTC。
- App 实际走的是哪种传输方式。
- 语音识别、TTS、实时语音是不是同一个供应商。
- 失败时是否回退到了 iOS 系统语音方案。
如果 provider 和 App 的 transport 不匹配，就算网络和配对都没问题，语音层也会单独失败。
公开发布怎么写更稳
短平台首屏可以叫“小龙虾”，长文里解释它指本地 AI 助手网关。
但这不是用谐音、错字、符号去规避审核。真正要控制的是内容里不要出现真实地址、授权码、设备 ID、二维码、链接、下载和私信类提示。
这类内容最好写成经验复盘，而不是工具下载或配置导流：
- 不展示 tailnet、token、setup code、设备 ID。
- 不在图片里放二维码、网址、下载、私信、扫码等词。
- 短平台用昵称降低误杀，长文平台补一句解释。
- 重点讲排查顺序和判断框架，而不是让读者照抄某个配置。
可复用路径
我最后沉淀下来的稳定路径是：
- 先确认手机和 Mac 在同一条可达链路里。
- 再确认手机访问的是可达 HTTPS 网关，不是手机自己的 loopback。
- 清掉旧配对，重新生成 setup code。
- 在网关侧确认设备 connected 和 approved。
- 最后检查语音 provider 和 transport 是否匹配。
这套经验真正能复用的，不是某条命令，而是把移动端 Agent 的本地服务、远端访问、设备授权和语音通道分开验证。
对正在搭个人 AI 工作台、内容工作流和产品验证环境的人来说，这就是移动端 Agent 的基础 SOP。