Ping、Traceroute、MTR 有何不同？網路故障排查該用哪個

排查網路故障最忌諱盲目抓封包。Ping、Traceroute 和 MTR 這三個工具雖然大家天天都在用，但不少人在遇到存取異常時，依然分不清到底該用哪一個來定位問題。本質上，它們並不是替代關係，而是層層遞進。Ping 幫你確認服務死活，Traceroute 幫你拆解資料封包走的路線，而 MTR 則用來捕捉那些忽好忽壞的間歇性抖動。

如果你經常處理伺服器掉封包、線路繞路、跨境網路不穩定或者晚高峰卡頓等問題，這篇文章就是為你寫的。接下來，我會深入拆解這三個工具在實際排查中的定位與限制，並透過幾個最常見的網路故障情境，告訴你遇到不同問題時該怎麼選工具，以及如何按最省時間的順序快速鎖定故障節點。

一、為什麼排查網路故障不能只看 Ping？

遇到網站打不開或者存取慢，大多數人的第一反應都是打開終端機 Ping 一下目標 IP 或網域名稱。

Reply from 203.0.113.10: time=31ms
Reply from 203.0.113.10: time=33ms
Reply from 203.0.113.10: time=30ms
Reply from 203.0.113.10: time=32ms

如果看到這種結果，很多人會覺得網路「沒問題」。但實際上，使用者從發起請求到收到回應，中間跨越了非常複雜的網路層級：

使用者本機電腦 → 家用路由器 → 本地電信商接入網路 → 國家骨幹網路 → 跨境海纜/線路 → 目標機房入口 → 伺服器/CDN 節點

Ping 給你的，只是起點到終點拼湊出來的最終結果。

如果延遲飆到 200ms，Ping 只能告訴你「現在很慢」，卻無法回答：到底是本地 Wi-Fi 訊號不好、本地電信商壅塞、國際出口海纜故障，還是對方機房防火牆卡頓？

所以，Ping 適合做初步的「快速篩查」，但不適合單獨用來定位具體的故障位置。

二、Ping 的正確用法與限制

Ping 適合在排障第一步使用，重點關注三個指標：

• 基礎連通性：目標機器是否在線、回應。

• RTT（來回時間）：延遲是否在合理區間。

• 連續掉封包與抖動：如果在測試過程中頻繁出現Request timed out或延遲忽高忽低（比如上一秒 20ms，下一秒 300ms），說明網路存在嚴重不穩定。

排障中的兩個常見誤區：

1. Ping 不通 ≠ 服務當機：很多公有雲伺服器、機房防火牆或 CDN 節點出於安全考量，會直接停用 ICMP 協定（即拒絕回應 Ping），但 HTTP/HTTPS 或 SSH 服務依然可以正常存取。

2. Ping 很快 ≠ 網頁載入快：網頁打得慢，可能是 DNS 解析延遲、TCP 握手慢、TLS 憑證協商耗時過長，或者後端資料庫查詢慢，這些 Ping 都無法反映。

當你發現 Ping 的結果確實存在高延遲或掉封包時，就需要引入第二個工具：路由追蹤。

三、Traceroute：把資料封包的傳輸路線拆開看

如果說 Ping 是用來確認「對方在不在家」，那 Traceroute（路由追蹤）的作用就是幫你把從本地到目標伺服器之間經過的每一個路由器節點（Hop）全部扒出來。

跑一次 Traceroute，終端機裡通常會印出類似這樣的結果：

1   192.168.1.1       2 ms
2   10.10.0.1         8 ms
3   203.0.113.1      15 ms
4   198.51.100.5     68 ms
5   198.51.100.20   145 ms
6   203.0.113.50    152 ms

這份結果能直接告訴你不少關鍵細節：

• 資料封包一共跳了多少個節點

• 每一個節點的 IP 位址

• 延遲是在哪個節點開始陡增的

• 路由有沒有被繞遠路

• 哪個節點掉封包逾時了

拿上面的資料來說，前四跳的延遲都在 60ms 以內，但到了第 5 跳突然飆到了 145ms。這時候你心裡就有底了——排查重點直接鎖定在第 4 跳到第 5 跳之間的這段網路。

這也正是 Traceroute 相比 Ping 最接地氣的地方：Ping 只能告訴你「終點現在變慢了」，而 Traceroute 能直接指給你看「具體是從哪一段開始拉胯的」。

它最適合搞定哪些情境？

只要涉及到「路徑」和「中間節點」的問題，用 Traceroute 排查效率最高：

• 單一電信商異常：同一個網站，行動存取很流暢，電信或者聯通存取卻卡得要死。

• 跨境/海外服務延遲飆升：存取海外伺服器時延遲爆表，懷疑流量被繞到了第三方國家。

• CDN 切節點後反變慢：接入 CDN 後以為會變快，結果排程錯節點導致延遲反而升了。

• 特定地區連不上：只有某些省份或城市的使用者報修說打不開伺服器。

特別是做跨境業務或者用海外伺服器時，只看 Ping 很容易被矇蔽。比如同樣是連線一台美國伺服器，兩條線路 Ping 出來的延遲可能都是 180ms。但用 Traceroute 一查，第一條是真正的跨太平洋海纜直連；第二條則是先從中國香港繞去歐洲，再跨大西洋切回美國。雖然平時 Ping 出來的數字差不多，可一旦到了晚高峰，第二條繞路線路的穩定性會瞬間崩掉。

看到* * *就是掉封包了嗎？

真不一定。 這是絕大多數新手最容易誤判的地方。

比如經常能看到這種輸出：

1   2 ms
2   8 ms
3   * * *
4   35 ms
5   42 ms

第 3 跳全部顯示逾時的星號* * *，但第 4 跳和第 5 跳卻能秒回，而且延遲完全正常。

這種情況大可不必驚慌。中間那個路由器很可能只是開了安全策略，停用了對 ICMP / TTL Exceeded 報文的回應，或者對探測請求做了極嚴的限速。只要資料封包能順暢穿過它傳給第 4 跳，就說明真實的業務流量在這裡根本沒掉。

真正需要關注的故障特徵只有一種：從某一跳開始出現逾時或高延遲，並且這種異常一路順延、砸到了後續的所有節點和最終目標。

四、MTR：捕捉動態抖動與持續掉封包

如果說 Traceroute 算是一次性的路線抓拍，那 MTR（My TraceRoute）玩的其實是持續監控。

單跑一次 Traceroute，你只能看到當前那一秒資料封包踩過了哪幾個路由器。可現實裡搞網路維運，最怕的從來不是徹底斷網，而是那些抽風式的隱蔽故障：

• 白天順暢得很，一到晚上八九點網頁就卡死

• 隔個三五分鐘掉幾個封包，WebSocket 直接斷開

• 玩遊戲或者語音通話，時不時跳一下高延遲

• 介面平時回應挺快，偶爾就逾時一次

碰到這種抓不著規律的毛病，單跑一次 Traceroute 極容易剛好踩在網路正常的那一秒，啥異常也抓不到。

MTR 解決的就是這個問題。它相當於把 Ping 的連續發送封包和 Traceroute 的逐跳路由合在了一起，一邊跑路由，一邊盯著每一跳持續發送封包，最後拉出一份統計表。

拿到 MTR 的結果，盯著這幾個核心指標看就行：

1. Loss%（掉封包率）：別被單跳的高數字騙了

Loss% 看的是資料封包掉了多少。跟 Traceroute 一個道理，中間某個節點掉封包率高，不代表那裡真出了故障。

假設第 4 跳顯示掉封包 50%，但後面的第 5 跳和最終目標掉封包率全是 0%，這大概率是第 4 跳那個路由器限制了 ICMP 探測報文，業務流量過它的時候根本不受影響。

真正有問題的掉封包，是從某一跳開始出現掉封包（比如 10%），而且這個掉封包率一路順延到了後面的每一跳和終點。

2. Avg（平均延遲）：看真實傳輸水準

比起測一次兩次的隨機延遲，Avg（平均延遲）更能體現這條線路在幾分鐘內的真實拉胯程度。

3. Best 和 Wrst（最好/最差延遲）：專門抓網路抖動

搞即時業務，這兩個指標比平均延遲重要得多：

• 如果 Best 30ms、Avg 35ms、Wrst 42ms，說明線路穩得很。

• 如果 Best 30ms、Avg 80ms，但 Wrst 飆到了 450ms，這就是典型的網路抖動。

像遊戲、語音、WebSocket 或者即時 API 這類業務，對時延波動極其敏感。這種忽高忽低的劇烈抖動，往往比單純的「延遲高」更折磨人。

​

五、三大工具功能比較

為了在日常工作中快速選對工具，可以參考這份彙總比較：

六、遇到不同網路故障，應該怎麼選？

實戰裡大家很少為了測試而測試，基本上都是業務報了異常，再倒推該掏哪個工具。面對不同的故障現象，挑選工具的思路其實大不相同：

情境一：網站徹底打不開

第一時間還是先敲個 Ping。如果能 Ping 通，說明底層的網路鏈路大體沒斷，可以直接去排查 80/443 連接埠服務、Nginx 設定或者應用層是不是卡死了。如果連 Ping 都逾時，再接著跑 Traceroute，看看請求到底是在哪一段徹底丟掉的。

不過這裡有個小細節：千萬別一看到 Ping 不通就斷定是伺服器當機，很多機房或雲廠商預設會封鎖 ICMP 報文，但網頁業務依然能正常跑。

情境二：網站能開，但載入明顯變慢

這種情況先用 Ping 確認整體的來回延遲（RTT）。比如離峰期只有 35ms，突然飆到了 180ms，這就很適合接著用 Traceroute 來查了。

重點盯著延遲是從哪一跳開始出現劇烈跳升的，同時留意路由節點有沒有變多。如果同一個 IP 昨天走的是 8 跳直連，今天突然變成了 15 跳還繞去了海外，那大概率是電信商路由調整或者海纜出問題導致繞路了。

情境三：白天順暢，一到晚高峰就頻繁卡頓

處理這種「時段性」的隱蔽故障，MTR 是唯一的選擇。因為單次的 Traceroute 只能截取某一個瞬間，很容易剛好測在網路沒卡的那一秒。

你需要的是在高峰期掛著 MTR 跑上幾分鐘，重點看 Loss%（掉封包率）、Avg（平均延遲）和 Wrst（最差延遲）。如果某一個骨幹網路節點從晚上 8 點開始持續掉封包、延遲飆升，到了半夜又自動恢復，這就是非常典型的骨幹網路頻寬壅塞。

情境四：只有部分特定地區的使用者回報打不開

如果你身在北京，收到廣東或者新加坡使用者的報修，直接在自己電腦上敲命令沒有任何意義，你的測試結果只能代表你本地到伺服器的路徑。

這種情境得靠chahu這種分散式的多節點撥測工具，直接從新加坡、德國、日本等不同地區的節點去發起 Ping 和 Traceroute。對比不同節點的路由圖，要是發現北方節點一切正常，但新加坡節點被錯誤排程到了美國西海岸，那故障點就很清晰了，完全沒必要把時間浪費在查伺服器 CPU 或資料庫上。

情境五：接入 CDN 後速度反而變慢了

這種情況相當常見。先 Ping 一下 CDN 節點回傳的 IP，看看基礎延遲是否符合預期。接著用 Traceroute 瞅一眼路由，很多時候是因為 CDN 節點的解析排程出了偏差，比如本該分配給香港使用者的節點，卻被排程到了更遠的區域。如果存取只是偶爾卡一下，就再掛個 MTR 觀察節點連線的穩定性。

七、最實用的網路故障排查順序

日常排查網路問題，最忌諱上手就亂抓封包或者瞎折騰設定。如果不確定從哪入手，記住這套順手又省時間的排查流程：

Ping → Traceroute → MTR

1. 第一步用 Ping 敲門：先看目標能不能連通，算算基礎延遲和掉封包率，快速確認「到底是整體有問題，還是根本沒通」。

2. 第二步用 Traceroute 扒路徑：如果發現延遲飆升或者連線不上，用它把資料封包經過的每一跳拆開看，鎖定是從哪個節點開始出異常的。

3. 第三步用 MTR 盯穩定性：遇到那種忽好忽壞、晚高峰卡頓或者偶爾斷線的問題，直接掛上 MTR 跑幾分鐘，盯著 Loss%、Avg 和 Wrst 看看波動規律。

為了方便查閱，不同故障對應的選型可以參考這個速查表：

這三個工具看著都是在測網路，其實分工非常明確：Ping 負責看終點通不通，Traceroute 負責看路線怎麼走，MTR 負責看這條路穩不穩。按這個順序一層層往下排，先定性（有沒有問題），再定位（問題在哪），最後定抓手（是不是持續抖動），比一開始就死磕某一個工具要高效得多。