远程云端 Mac 网络基线：用 networkQuality 定位吞吐、响应与 MTU

远程会话开始掉帧、拉取依赖忽快忽慢时，先不要重装工具链，也不要只跑一次测速就下结论。云端 Mac 的体验同时受吞吐、负载延迟、DNS、路由和路径 MTU 影响。正确做法是固定测试条件，采集一组可重复的基线，再用对照实验判断问题发生在使用端网络、传输路径还是远端任务竞争。

先固定测试条件再采样

网络结果只有在条件一致时才可比较。记录 macOS 版本、接口、是否经过 VPN、测试时间段和当时运行的任务。远端机器正在下载依赖、同步大文件或执行高并发构建时，测到的是“业务负载下的网络”，不能与空闲结果混在一起。

先建立一次空闲基线，再在真实任务运行期间重复。每组至少执行三次，保留中位结果，不用单次峰值。SoarMac 节点选择应以控制台当前可选配置为准；跨地区比较时，也要确保使用端网络和测试目标不变。

mkdir -p "$HOME/network-baseline"
cd "$HOME/network-baseline"

date -u
sw_vers
scutil --nwi
route -n get default
networkQuality -v | tee "networkquality-$(date +%Y%m%d-%H%M%S).log"

scutil --nwi 用于确认实际承载流量的接口，route 显示默认出口。若系统同时存在有线、无线和隧道接口，仅看菜单栏连接状态很容易判断错路径。

基线的目标不是证明网络“快”，而是得到一组能在故障前后、空闲与负载、直连与隧道之间比较的数据。

同时看吞吐与负载响应

networkQuality 会给出下行、上行和响应能力。大文件同步更依赖持续吞吐，远程桌面、SSH 输入和调试操作则更依赖负载下的往返响应。带宽数值很高，并不代表交互一定流畅。

用并行采样识别排队

打开两个终端。第一个运行 networkQuality -v，第二个持续对同一目标执行 ping：

export TARGET_HOST="your-controlled-endpoint"
ping -c 40 "$TARGET_HOST" | tee ping-under-load.log

先在空闲状态执行一次，再在上传大文件时执行。重点比较平均延迟、最大延迟和波动范围。如果空闲延迟稳定，而上传期间明显升高，常见原因是使用端上行被占满，封包在出口排队。此时限制同步任务并发或带宽，通常比更换远端开发工具有效。

把 DNS 与路由单独拆开

依赖下载失败不一定是带宽问题。先检查系统实际使用的解析器，而不是只查看网络设置界面：

scutil --dns | tee dns-state.log
dscacheutil -q host -a name "$TARGET_HOST"
route -n get "$TARGET_HOST" | tee target-route.log

scutil --dns 可能显示多组解析器及匹配域。若命令行能访问 IP，却无法稳定解析主机名，应先处理 DNS；若解析正常但流量走入意外的隧道接口，则检查路由优先级。修改配置前保存输出，改动后使用相同命令复测，避免一次调整多个变量。

验证端口而非只看 ping

部分目标不会回应 ICMP，ping 失败不能直接等同于服务不可达。对自己控制的目标，可验证实际业务端口：

nc -vz -G 5 "$TARGET_HOST" 443

端口连接成功而 ping 无响应，说明至少 TCP 建连路径可用。端口超时则继续检查路由、防火墙策略和隧道出口；不要仅凭浏览器一次成功就排除间歇性故障。

用递增载荷检查路径 MTU

VPN 或额外封装会减少可承载的有效载荷。典型表现是小请求正常，大文件传输停顿，或者连接建立后长时间没有进度。macOS 的 ping 可设置不分片标记并调整载荷：

export TARGET_IPV4="192.0.2.10"

for size in 1200 1300 1400 1450 1472; do
  echo "payload=$size"
  ping -D -c 3 -s "$size" "$TARGET_IPV4"
done

示例地址必须替换为自己控制的 IPv4 目标。若较小载荷稳定成功、较大载荷持续失败，记录临界值，并分别在直连和隧道状态下复测。不要立即把远端接口 MTU 改小；先确认限制来自哪段路径，否则可能掩盖真正问题，还会影响其他连接。

建立可复查的验收记录

一次完整记录应包含系统版本、接口、默认路由、DNS 状态、空闲与负载下的 networkQuality、同目标 ping，以及 MTU 临界值。敏感地址和内部域名在共享前应脱敏，但时间、命令参数和测试条件要保留。

修复后按原顺序重跑，不要换目标或只挑表现最好的一次。验收可以采用以下标准：空闲与负载结果均有记录；远程交互期间没有持续性高延迟；域名解析与业务端口连续成功；大文件传输能够稳定完成；直连与隧道差异已有解释。这样得到的结论才能进入工单或团队运行手册，也便于下一次故障直接与基线比较。

常见问题