traceroute 怎麼看：星號、中間跳丟包和延遲突增分別說明什麼
traceroute 怎麼看，可以先記住一條：先看最後一跳，再看問題是不是從某一跳開始一直持續到最後。中間某一跳出現星號、丟包或者延遲偏高，只要後面的跳恢復正常，大多數情況下只是那臺路由器不願意回應探測包，不代表你的流量在那裡出了問題。
traceroute 是怎麼得到每一跳的？
traceroute 發出一串 TTL（IPv6 裡叫 hop limit）依次為 1、2、3……的探測包。每經過一臺路由器，TTL 減 1，減到 0 時這臺路由器丟掉包，並回一個 ICMP “超時”訊息。traceroute 收到這個回覆，就知道了第 N 跳的地址和往返時間。
這個原理直接決定了怎麼讀結果：
- 中間跳的延遲，是“路由器生成 ICMP 回覆”的耗時，不是轉發你業務流量的耗時。路由器轉發資料走硬體，生成 ICMP 回覆往往由控制平面的 CPU 處理，並且普遍有限速。
- 去程和回程可能走不同的路徑。你看到的是去程上的每一跳，但每一跳的延遲裡包含了它的回程。
- 只有最後一跳是目標本身在回應，它的延遲和丟包最接近真實業務的體驗。
一份 traceroute 輸出逐行怎麼讀？
下面是一份示例輸出（地址取自私有、運營商共享和文件保留網段，數字為說明用途，不是實測）：
$ traceroute -n api.example.com
traceroute to api.example.com (203.0.113.10), 30 hops max, 60 byte packets
1 192.168.1.1 1.2 ms 1.1 ms 1.0 ms ← 家裡路由器
2 100.64.0.1 4.8 ms 5.1 ms 4.9 ms ← 運營商接入（CGNAT 網段）
3 * * * ← 不回應 ICMP，常見
4 198.51.100.5 9.7 ms 9.9 ms 10.2 ms
5 198.51.100.33 85.4 ms 12.1 ms 11.8 ms ← 單次偏高，後續正常
6 198.51.100.70 168.2 ms 167.9 ms 168.5 ms ← 跨境/跨洋段，延遲臺階
7 * * *
8 203.0.113.10 170.3 ms 169.8 ms 170.6 ms ← 末跳：目標本身
逐行解讀：
- 第 1–2 跳是你自己的網路和運營商接入。第 1 跳就有幾十毫秒或丟包，優先查 Wi-Fi 和本地裝置。
- 第 3、7 跳全是星號，但第 4、8 跳正常回應，說明流量透過了這兩跳，只是它們不回 ICMP。
- 第 5 跳三次裡一次 85 ms，其餘正常，後面也不受影響，屬於路由器回覆限速或 CPU 繁忙。
- 第 6 跳出現一個 150 ms 左右的“臺階”，並且之後每一跳都保持在這個水平。這是物理距離或跨境鏈路帶來的，是真實延遲的主要來源。
- 第 8 跳是目標，170 ms 左右，三次穩定，這才是要記錄的結論。
mtr 報告裡 Loss%、Avg、StDev 各看什麼？
traceroute 每跳只發 3 個包，偶發情況很容易誤判。mtr 會對每一跳持續發包並統計，適合下結論。推薦用報告模式：
mtr -r -c 100 -n api.example.com
下面是一份示例報告（同樣不是實測）：
HOST: laptop Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 1.1 1.3 0.9 4.2 0.4
2.|-- 100.64.0.1 0.0% 100 5.0 5.2 4.6 9.8 0.7
3.|-- ??? 100.0% 100 0.0 0.0 0.0 0.0 0.0
4.|-- 198.51.100.5 60.0% 100 10.1 10.4 9.6 14.0 0.8
5.|-- 198.51.100.33 0.0% 100 11.9 23.6 11.2 140.3 28.1
6.|-- 198.51.100.70 0.0% 100 168.1 168.6 167.5 175.2 1.2
7.|-- 203.0.113.10 0.0% 100 170.2 170.5 169.4 178.9 1.4
| 列 | 含義 | 怎麼用 |
|---|---|---|
| Loss% | 這一跳沒有回應的比例 | 只有“從這一跳開始，後面所有跳包括末跳都丟”才有意義 |
| Snt | 已傳送的探測數 | 少於 100 時結論不穩，寧可多跑一會兒 |
| Last / Avg | 最近一次 / 平均往返 | 看 Avg 在哪一跳出現臺階，並且之後保持 |
| Best / Wrst | 最小 / 最大往返 | Best 接近物理下限；Wrst 遠大於 Avg 說明有抖動 |
| StDev | 標準差 | 末跳 StDev 大，說明業務會感到忽快忽慢 |
示例裡第 4 跳 60% 丟包，但第 5–7 跳都是 0%，所以第 4 跳的丟包是“不愛回應”，可以忽略。第 5 跳 Avg 23.6、StDev 28.1，波動大，但第 6 跳又回到穩定，同樣只是那臺裝置回覆慢。真正需要記錄的是末跳：170.5 ms，0% 丟包，StDev 1.4，這條路徑是健康的。
星號、中間跳丟包、延遲突增：怎麼判斷？
對照自己的結果時可以用這張表：
| 你看到的現象 | 後續跳的情況 | 結論 | 下一步 |
|---|---|---|---|
某跳全是 * * * | 後面的跳和末跳正常 | 該路由器不回 ICMP 或限速，忽略 | 無需處理 |
末尾連續多跳 * * *，到不了目標 | — | 目標或其前面的防火牆丟棄了 ICMP/UDP 探測 | 換成 TCP 443 探測再看（見下文） |
| 中間某跳 Loss% 高 | 後續跳 Loss% 回到 0 | 控制平面限速，忽略 | 無需處理 |
| 從第 N 跳開始丟包 | 後續所有跳包括末跳都在丟，比例相近 | 第 N 跳附近鏈路真實丟包 | 記錄第 N 跳的地址和時間段，換時段複測 |
| 某跳 Avg 突增 | 後續跳回到之前的水平 | 該裝置回覆慢，忽略 | 無需處理 |
| 某跳 Avg 出現臺階 | 後續跳都保持在高位 | 物理距離或跨境段，屬正常延遲 | 若臺階異常大，對比不同時段 |
| 末跳 StDev 很大 | — | 路徑擁塞或排隊，業務會抖動 | 高峰、低峰各跑一次對比 |
| 末跳少量丟包（如 1–2%） | — | 可能是目標限速，也可能是真實丟包 | 用 TCP 探測複核，再結合應用層測速 |
判斷規則：丟包和延遲只有在持續到末跳時才算數。
各系統用什麼命令？
Windows
tracert -d api.example.com # -d 不做反向 DNS，速度快很多
pathping -n api.example.com # 系統自帶，帶逐跳丟包統計，但耗時較長
tracert 的星號顯示為“請求超時”。需要類似 mtr 的連續統計，可以用開源的 WinMTR 圖形工具，或者在 WSL 裡裝 mtr。
macOS
traceroute -n api.example.com
brew install mtr
sudo mtr -r -c 100 -n api.example.com # macOS 上 mtr 通常需要 sudo
Linux
sudo apt install mtr-tiny traceroute # Debian/Ubuntu
traceroute -n api.example.com
mtr -r -c 100 -n api.example.com
mtr -r -c 100 -n -6 api.example.com # 單獨測 IPv6 路徑
如果機器同時有 IPv4 和 IPv6，兩條路徑可能完全不同，結論要分開記。這部分的排查思路可以參考IPv6 代理不生效：雙棧網路下 IPv4 與 IPv6 出口不一致的原因與排查。
為什麼要用 TCP 443 探測？
預設情況下，Linux/macOS 的 traceroute 發 UDP，Windows 的 tracert 發 ICMP。不少雲服務和 API 入口會在邊界上丟棄這兩種探測，於是末尾出現一串星號，看起來像“不通”，但瀏覽器訪問一切正常。
AI API 和網頁走的是 TCP 443，用同樣的協議和埠探測，結果更接近真實業務：
sudo traceroute -T -p 443 -n api.example.com # Linux，需 root
sudo mtr -T -P 443 -r -c 100 -n api.example.com # 注意 mtr 用大寫 -P 指定埠
sudo tcptraceroute api.example.com 443 # 部分發行版可用
如果 ICMP 探測末尾全是星號、TCP 443 探測能到達末跳且丟包為 0，說明只是目標不回應 ICMP，路徑本身沒問題。反過來，TCP 443 也在某一跳之後持續丟包，才值得懷疑鏈路。
另外要注意：開著代理或 VPN 時，traceroute 看到的通常是你到代理伺服器的路徑，或者被本地虛擬網絡卡改寫過的結果，並不是業務流量到 API 的真實路徑。做路由追蹤前先確認流量走的是哪個出口，可以先到 IP 與環境檢測 看一下當前的出口 IP 和分流狀態。
路由追蹤的結論怎麼和應用層耗時對上？
traceroute 和 mtr 只回答“網路層這條路徑的延遲和丟包”。使用者實際感受到的是 DNS、TCP、TLS 握手加上請求往返的總時間。兩邊對一下，才能確認問題在哪一層。
第一步：在 cdnping 首頁測應用層時間
開啟 cdnping 線上測速，它在瀏覽器裡分別測出每個 API 的“首次連線”（包含 DNS 與 TLS 握手）和“往返”（連線複用後 3 次請求的中位數）。“往返”最接近一次純粹的網路來回，可以直接和 mtr 末跳的 Avg 比較。
第二步：按下表對照
| mtr 末跳 | 首頁“往返” | 首頁“首次連線” | 結論 |
|---|---|---|---|
| 延遲正常、0% 丟包 | 與末跳 Avg 接近 | 約為往返的數倍 | 網路正常，握手開銷屬預期 |
| 延遲正常、0% 丟包 | 明顯高於末跳 Avg | — | 慢在服務端或中間的閘道器/代理，不在路由 |
| 延遲正常 | 正常 | 遠高於往返的數倍 | 重點查 DNS 解析或 TLS 握手 |
| 末跳持續丟包 | 波動大或時有失敗 | 偶發超時 | 鏈路問題，記錄出問題的跳和時段 |
“首次連線”比“往返”高出幾倍是正常的，因為 TCP 和 TLS 握手本身就要多走幾個來回。三段時間各自怎麼拆、怎麼用 curl -w 單獨量，可以看AI API 延遲拆解：連線建立、閘道器往返與首 token 時間（TTFT）。
第三步：拿邊緣側資料做基線
如果自己的結果偏高，可以和 API 狀態頁 對比，區分“服務端這會兒就慢”和“只是我這條路慢”。/status 從 Cloudflare 邊緣每 5 分鐘探測各官方 API 入口。以 cdnping 2026-10-17 的資料快照為例（探測點為丹佛 DEN 節點；cdnping 當天才開始採集，這份快照的視窗約 85 分鐘、242 次探測，只能當作當時的參考，不是長期統計）：
| API 入口 | p50（ms） | p95（ms） |
|---|---|---|
| api.anthropic.com | 73 | 84 |
| api.openai.com | 96 | 194 |
| api.deepseek.com | 353 | 414 |
| api.moonshot.cn | 375 | 1125 |
這組數字是邊緣節點到 API 入口的耗時，不是你家到 API 的耗時，不能直接相減。它的用處是看趨勢：如果邊緣側的 p50 和平時一致，而你那邊明顯變慢，問題多半在你的接入、出口或跨境段，回去看 mtr 裡臺階和丟包出現在哪一跳；如果邊緣側也同時變慢或出現失敗，那更可能是服務端的問題，路由追蹤查不出什麼，先看官方狀態頁，讀法見怎麼看 OpenAI 狀態頁和 Claude 狀態頁。採集方式和口徑寫在資料方法裡。
排查時的檢查清單
- 先確認出口：是否開著代理、VPN，IPv4 和 IPv6 是否走同一出口。
- 用
mtr -r -c 100 -n跑一次，至少 100 個包。 - 只看末跳的 Loss%、Avg、StDev；中間跳的星號和孤立丟包先忽略。
- 末尾全是星號時，換成
-T -P 443再跑一次。 - 找出 Avg 的“臺階”在哪一跳，判斷是本地、運營商、跨境段還是目標側。
- 開啟 cdnping 首頁測“首次連線”和“往返”，用上面的表對照。
- 對比 /status 的邊緣側資料，區分服務端問題和自己的路徑問題。
- 需要找運營商或服務方時，附上 mtr 報告原文、測試時間和出口 IP 段。
如果你排查的是某個具體工具連不上，可以接著看Claude Code 連線超時和報錯怎麼排查：四層網路檢查清單和ChatGPT 掛了嗎？三步判斷是服務故障還是自己的網路問題；想把出口 IP、DNS、測速一起過一遍，可以按開發者網路自檢清單（2026 版）走一遍。
