iPhone 连不上开发电脑：局域网与 Tactic Relay 的完整排查流程

在家里能连接 Mac，走到咖啡店却失败；账号下能看到电脑，打开项目时一直超时；终端能够显示，却没有新的回复。这三种情况看起来都像连接故障，实际需要检查的位置不同。

排查时，先找“最后正常的环节”。如果电脑根本没在运行，就先恢复主机；如果局域网连接失败而已配置的 Relay 能用，就检查本地网络；如果原会话有实时终端输出，就转向智能体状态。这样每一步都有结果可判断，也能保留正在处理的任务。

先留下现场，再动连接设置

记录当前电脑名称、项目和会话、连接方式、错误文字与大致时间。再看最近是否发生了网络切换、电脑睡眠、主机端更新或登录取消。

先不要移除电脑绑定、删除会话或清空所有连接配置。这些操作会改变原来的授权或工作状态，而且无法修复电脑睡眠和访客网络隔离。一次只改变一个与现象有关的条件，再比较结果。

下面的顺序适用于已有连接的定位。首次设置可先按iPhone 入门指南完成配套端与配对流程。

第一步 确认电脑和配套服务仍在运行

电脑需要处于可以工作的状态，配套 App 或 CLI 服务也需要运行。屏幕关闭与整机睡眠不是同一件事；电脑还在账号列表里，也不能代替当前连接验证。先看主机端是否有服务运行状态、是否报错，以及是否真的连到了预期的电脑。

在 Mac 上，可以运行以下只读命令检查默认端口：

lsof -nP -iTCP:8765 -sTCP:LISTEN

默认端口是 8765；如果自己改过端口，使用实际配置。输出中的 COMMAND、PID 和监听地址，有助于判断究竟是哪个进程在提供服务。

这一步不会验证 Tactic 身份，也不会证明手机能访问。Mac App 和独立 CLI 都可能使用同一个默认端口，排查时要明确自己启动的是哪一个。电脑无法亲自查看时，保留“主机状态未确认”这个判断，继续检查手机上能观察到的错误。

第二步 局域网连接检查权限和实际可达性

两台设备显示同一个 Wi-Fi 名称，并不保证可以互相访问。访客网络、企业网络隔离和 VPN 路由都可能影响连接。先在 iPhone 的“设置 → 隐私与安全性 → 本地网络”中检查 Tactic Remote 的访问权限；Apple 的本地网络权限说明介绍了这个入口。

然后核对电脑当前地址与 App 保存的地址。换过路由器、从 Wi-Fi 切到有线网络，或 DHCP 分配了新地址时，原地址可能不再属于这台电脑。以主机配套端当前显示的地址为准，不要默认所有 Mac 的 Wi-Fi 都是 en0。

如果有另一台处在同一可信网络中的 Mac，可以对目标电脑做一次 TCP 连接检查：

# 将示例地址替换为开发电脑的实际局域网地址。
nc -vz -G 3 192.168.1.42 8765

这条命令只尝试建立 TCP 连接，不发送 Tactic 凭据或编程指令。-G 3 是 macOS nc 的连接超时参数；其他系统的参数可能不同。

在开发电脑上测试 127.0.0.1，只能检查它自己。iPhone 浏览器里的 127.0.0.1 则指向手机，不能用来访问 Mac。ping 不通也不足以单独判断服务离线，因为网络可能限制 ICMP。

需要调整防火墙时，针对实际运行的配套应用允许所需访问，保留认证。已有 VPN 的，可以在符合组织网络规定的前提下比较路由变化；不要把关闭全部防火墙、关闭认证或开放路由器端口当作常规修复方法。基础配置见局域网指南。

第三步 Relay 连接检查账号与主机状态

离开家以后，手机无法继续依赖家中电脑的局域网地址。使用 Tactic Relay 时，需要确认两端使用的是预期 Tactic 账号，电脑已绑定，并且电脑端 Relay 正在连接服务。

按以下顺序查看：

1. 电脑是否醒着，配套端和互联网访问是否正常。
2. 手机与电脑是否登录了预期账号，选择的电脑名称是否正确。
3. 电脑端是否显示 Relay 正常连接，还是正在重连或出现具体错误。
4. 是否要求完成账号验证、重新登录，或完成浏览器到 App 的返回流程。
5. 完成提示后，再连接该电脑并打开项目。

Tactic 账号登录用于主机关联和访问授权，Claude Code 等智能体则使用开发电脑上自己的服务商账号。账号下能看到电脑、成功连接工作区、智能体已登录，属于不同状态。

1.11 修复了登录一段时间后绑定电脑可能失败的问题。遇到验证提示，先完成相应验证再尝试绑定。反复移除与重新绑定，会增加需要确认的变化；它不应成为所有超时问题的第一步。

已正确配置的两种连接方式还可以作为对照：同一台电脑上，局域网失败而 Relay 成功时，优先看本地网络；局域网成功而 Relay 失败时，优先看账号验证、电脑端 Relay 与互联网连接。这个对照用于缩小范围，不能证明某一个组件一定没有问题。

使用 Cloudflare Tunnel 时，另外核对隧道地址

如果你使用的是 Cloudflare Tunnel，检查隧道进程、当前地址和实际服务映射。临时隧道重新启动后，地址可能变化；保存的旧地址不一定仍指向当前电脑。

浏览器能打开一个 HTTP 页面，也不能单独证明 App 的 WebSocket 连接和认证都可用。保留完整错误，核对当前地址，再按Cloudflare Tunnel 设置指南检查。不要把隧道访问规则与 Tactic Relay 的账号绑定混在一起修改。

第四步 回到原会话，验证新的输出

连接成功后，选择故障前的电脑、项目和原会话。能列出项目，说明工作区访问已恢复；能看到原会话里的实时终端变化，说明会话输出可以传回手机。旧的历史文字只能证明曾有记录，不能证明当前连接正常。

如果终端停在项目信任、服务商登录或启动提示，转向智能体等待处理指南。这时重复改 Wi-Fi 或重新绑定账号，通常无法回答那个终端提示。

若刚才发送时断线，先找与那条请求对应的新输出。请求可能已到达电脑；恢复网络后不应立即把整段任务重新发送。可以在确认会话空闲后，发送范围小的状态查询：

只读说明当前项目、已完成的工作和正在等待的事项。不要重新执行上一条任务，也不要修改文件。

检查目录和结果是否与原任务一致，再决定后续操作。如果需要新建会话，先记录旧会话的实际状态，明确新会话不会自动接续全部上下文。

仍然失败时，把定位过程交给支持

可以复制下面的模板，把已经知道的事实填进去；没有验证的项目写“未确认”。

手机系统与 Tactic Remote 版本：
电脑系统、配套端类型与版本：
连接方式：局域网 / Tactic Relay / Cloudflare Tunnel
开始失败的时间与时区：
最近的变化：睡眠 / 网络切换 / 更新 / 登录 / 其他
最后正常的环节：登录 / 找到电脑 / 打开项目 / 终端实时输出
完整错误文字：
主机端服务和 Relay 状态：
已经检查的项目及结果：
原会话是否仍可打开：
刚才的请求是否可能已发送：

对外分享前，去掉凭据、配对二维码、登录链接和私有终端内容，按需要遮盖账号、路径与网络地址。向支持提供“局域网端口可达，App 提示验证失败，电脑端版本为……”这样的具体诊断，比只说“连接不上”更容易定位。

恢复连接后，可对照下载页检查两端版本，避免把版本不匹配留到下次远程使用时才发现。关于 1.11 的其他变化，以及手机和电脑端的更新方法，见Tactic Remote 1.11 详解。