无法连接
先确认设备状态、访问方式、本地出口网络与系统时间，再区分超时、权限拒绝、指纹变化或图形会话中断。
查看连接检查步骤先复现，再升级处理
问题发生时，先把云端 Mac 的现场记录清楚
这里不按部门分流，而是按无法连接、构建失败、磁盘空间、性能波动、账单与节点状态逐项检查。完成基础诊断后，工单可以直接进入有效排查。
6
类故障入口
99.9%
目标可用率
6
个在售节点
诊断运行单
等待信息
把现象变成可核对的记录
故障范围
单次任务 / 单台设备 / 团队范围
必要时间
发生时间、时区、最近正常时间
环境基线
macOS、Xcode、命令与退出码
安全边界
仅提交脱敏日志，不提交完整密钥
证据完整时，支持团队可以先判断节点、设备、系统访问还是项目环境问题。
按现象进入
先选择最接近当前情况的入口
不要先猜原因。记录直接观察到的现象、影响范围与出现顺序，再进入对应检查路径。同一问题涉及多个现象时，以最早发生的一项为主。
构建失败
保留完整命令、退出码与首个有效错误，核对 Xcode、macOS、依赖锁文件和项目分支是否与成功基线一致。
进入构建排查磁盘空间
检查系统卷剩余容量、派生数据、构建缓存、模型文件和临时产物，避免只看项目目录大小而忽略系统卷压力。
查看存储判断路径性能波动
同时采集 CPU、内存压力、磁盘余量与长时间任务，确认问题是资源达到上限、任务争用还是项目输入发生变化。
进入性能诊断账单问题
准备控制台中的订单标识、计费周期和支付结果。订单统一以 USD 结算，支持 USDT-TRC20 与 Visa / Mastercard / Amex（经 Stripe）。
进入控制台查看账单节点状态
先判断是单台设备、单个节点还是多个地点同时受影响，并记录实际节点与最近一次正常访问时间，不用地理位置替代节点名称。
查看服务状态口径连接前核对
五项基础信息，缺一项都可能误判
连接问题经常由状态、凭据范围、本地网络或时间偏差引起。按顺序检查可以避免反复尝试覆盖原始现场。
-
01
确认控制台中的设备状态
核对订单标识、当前节点和设备状态。不要把浏览器缓存中的旧截图当作当前结果；实际可用状态以控制台实时返回为准。
-
02
确认账号与访问资料属于同一设备
复制主机、用户与端口时逐项核对，避免混用另一台设备或旧会话的资料。工单只需说明使用了哪种资料，不要粘贴完整秘密内容。
-
03
确认访问方式与任务一致
命令行任务优先验证 SSH；需要 Xcode 图形界面时再验证远程桌面。两条路径分别记录结果，不要用一个失败结论替代另一条测试。
-
04
检查本地出口网络
记录当前网络类型、是否经过代理或企业防火墙，并用另一条受控网络进行一次对照。只报告测试结果，不发送内部网络配置全文。
-
05
核对本地与远端系统时间
明显的时间偏差会影响证书、签名与访问验证。记录时区，并确保工单中的发生时间与日志时间可以对应。
构建故障排查
先找首个有效错误，再判断环境还是项目
构建输出末尾的失败摘要通常不是根因。保存完整日志，定位最早出现的明确错误，并将同一输入与最近成功基线对照。
环境采集命令
只读检查
sw_vers
xcodebuild -version
git rev-parse --short HEAD
git status --short
df -h /
xcodebuild -scheme App -configuration Release运行前确认命令不会输出秘密值。若项目使用依赖管理工具，同时记录锁文件摘要与安装命令结果。
无关项目同时失败
最小测试项目与正式项目在相同阶段失败，或系统命令也出现异常时，记录 macOS、Xcode、磁盘余量和完整退出码。
只有特定分支或依赖组合失败
同一设备上的最小项目可以成功，而目标分支在更新锁文件、构建参数或资源后失败，优先回看项目变更。
版本、命令、退出码、日志节选
提交 Xcode 与 macOS 版本、依赖锁文件摘要、完整 xcodebuild 命令、退出码，以及首个有效错误前后的脱敏输出。
1
固定分支与输入
避免排查过程中继续更新依赖或切换配置。
2
保存完整输出
原始日志单独保留，分享前制作脱敏副本。
3
运行最小任务
用最小 scheme 或测试项目验证环境基线。
4
对照最近成功记录
比较版本、参数、缓存状态与任务输入。
性能与存储
把“变慢”拆成 CPU、内存、磁盘与任务持续时间
单次耗时增加不能直接证明设备异常。至少记录同一输入的基线耗时、资源峰值和并发任务，再判断清理、扩容或更换配置。
采样清单
四类指标
活动监视器与命令行交叉核对
CPU
持续占用、进程名称、并发任务数
top -l 1 -o cpu
内存
内存压力、交换使用、峰值阶段
memory_pressure
磁盘
系统卷余量、缓存与产物增长
df -h /
长任务
启动时间、输入规模、运行时长
ps -axo pid,etime,command
HopVM M4 16
M4 · 16GB · 256GB
适合单项目编译、短时测试和低并发自动化。若内存压力长期处于高位，先减少并发，再与 HopVM M4 24 对照。
HopVM M4 24
M4 · 24GB · 512GB
适合同时运行开发工具、模拟器与自动化任务。若大模型或重型构建持续使用交换空间，考虑 HopVM M4 Pro 64。
HopVM M4 Pro 64
M4 Pro · 64GB · 2TB
适合大模型推理、重型构建和高内存工作流。升级前仍应记录输入规模与峰值，避免把网络等待误判为算力不足。
先清理可再生数据
确认派生数据、旧构建产物、无用模拟器数据与下载缓存是否可以重新生成。删除前先核对项目是否依赖本地唯一产物。
容量持续增长时添加存储
项目源文件较小但模型、媒体素材或构建归档长期增长时，可评估既定的 +1TB SSD 或 +2TB SSD 附加项。
高峰与基线分开记录
分别记录空闲、常规任务和峰值并发三个阶段。只有持续资源压力才适合作为升级依据，偶发峰值应先定位触发任务。
服务可用率
99.9%
目标可用率
所有节点按全年 365 天正常运行设计，不设置定期停机时段。近 90 天状态按日记录，以下 30 段用于汇总每三个自然日的运行结果。
近 90 天运行摘要
绿色表示正常运行，黄色仅用于标识已经关闭的事件，不代表当前异常。
正常运行
已关闭事件
统计口径：近 90 天逐日状态记录
工单证据模板
一次写清六项信息，避免往返追问
工单应让未参与现场的人也能按相同步骤复现。请使用控制台中的真实订单标识与节点，不要用设备昵称或团队内部简称替代。
建议正文结构
复制后填写
订单标识：
实际节点：SG / JP / KR / HK / US-E / US-W
问题时间与时区：
最近一次正常时间：
影响范围：
复现步骤：
1.
2.
3.
预期结果：
实际结果：
退出码或错误类型：
脱敏日志节选：六个节点分别为新加坡、日本（东京）、韩国（首尔）、香港、美国东部、美国西部。只保留实际使用的一个节点代码。
订单与节点
订单标识用于关联设备；节点必须从 SG、JP、KR、HK、US-E、US-W 中选择实际值。
时间与时区
写明首次出现时间、最近正常时间和时区，使状态记录与用户日志可以对齐。
复现步骤
从已知正常状态开始，逐步写出命令、输入和操作顺序，不省略失败前的关键动作。
预期与实际
分别描述应该发生什么和实际发生什么，避免只写“无法使用”或“速度很慢”。
错误与退出码
优先提供首个有效错误、退出码和发生阶段，而不是只复制日志最后一行。
脱敏输出
保留调用关系、时间与错误类型，移除密码、完整密钥、令牌、支付凭据和项目秘密。
响应边界
支持团队先确认服务边界，再给出下一步
不同问题需要不同证据。未完成影响范围与环境核对前，不对具体恢复时间作无法验证的承诺。
| 问题类型 | HopVM 可核对范围 | 用户应提供 | 判断结果 |
|---|---|---|---|
| 节点连通性 | 节点状态、网络可达性、影响范围与状态记录 | 实际节点、来源网络、时间与时区、对照测试 | 区分单一出口、单台设备或节点级影响 |
| 设备状态 | 设备运行状态、资源交付记录与控制台关联信息 | 订单标识、最近正常时间、受影响任务数量 | 确认设备状态是否与控制台结果一致 |
| 系统访问 | 访问资料范围、会话入口与系统层连接现象 | 访问方式、错误类型、指纹或权限结果的脱敏信息 | 区分超时、权限、时间偏差与本地网络限制 |
| 开发工具 | 帮助确认设备环境与系统资源是否正常 | Xcode、macOS、依赖版本、完整命令、退出码与最小复现 | 判断是否需要转向项目依赖或第三方工具排查 |
| 账单与订单 | 订单状态、计费周期、支付结果与账务记录 | 订单标识、支付方式类别、发生时间与控制台结果 | 以控制台实时返回的订单与网关状态为准 |
可以直接核对
节点连通性、设备状态、系统访问入口、订单关联与服务侧状态记录。
需要联合复现
性能波动、间歇性连接、特定构建阶段失败和仅在特定输入下出现的问题。
需要项目侧继续处理
第三方依赖缺陷、项目代码错误、构建脚本逻辑和未经验证的工具兼容性问题。
升级处理入口
基础诊断完成后，把运行单交给支持团队
现有订单、连接与设备状态问题请通过控制台提交工单，以便关联实际资源。紧急事件应优先写明影响范围、实际节点、问题时间与最近一次正常时间。
无法进入控制台时，可发送邮件至 support@hopvm.com，正文仍应使用本页证据模板，并删除所有秘密值。