遠端雲端 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 臨界值。分享前應將敏感位址與內部網域名稱去識別化，但必須保留時間、命令參數與測試條件。

修復後請依照原本的順序重新執行，不要更換目標，也不要只挑表現最好的一次。驗收可採用以下標準：閒置與負載結果都有紀錄；遠端互動期間沒有持續性的高延遲；網域名稱解析與服務連接埠能連續成功；大型檔案傳輸可以穩定完成；直連與隧道之間的差異已有合理說明。只有這樣得出的結論，才適合寫入工單或團隊操作手冊，也方便下次發生故障時直接與基線比較。

常見問題