節點延遲測試逾時怎麼排查

動手之前先記住一件事：這個測試不是 ping。用戶端是透過這個節點向一個測試位址送出一次 HTTP 請求，把回應時間當成延遲。測試流量走的跟你平常上網是同一條路，所以路上任何一環斷掉都會變成逾時——包括那個測試位址你本來就連不上。

接下來只有一個問題要回答：是整欄一起逾時，還是只有零星幾個？這兩種狀況幾乎沒有交集，方向挑錯，就會發生花一個鐘頭換掉一份其實沒問題的訂閱這種事。

全部逾時：先懷疑本機，別懷疑節點

1. 把測試位址換成一個你確定在本地能穩定開啟的，重測一次。
2. 看一眼系統時間。差到一兩分鐘以上就同步一下，再測。
3. 把代理關掉，直接在瀏覽器裡開那個測試位址，確認本機網路和 DNS 是通的。

第一條是裡面最常見的，值得講清楚為什麼。測試請求跟其他請求一樣要過你的規則，很多設定會把這個位址判成直連；而它在你的網路裡不掛代理本來就打不開，於是所有節點整整齊齊一起逾時，看起來像整份訂閱掛了，實際上一個節點都沒事。把測試位址換成一個在你這邊穩定有回應的，數字馬上就出來了。

只有幾個逾時：這才輪到節點

• 節點已經沒了。業者下架機器、換線路是常事，而你用戶端裡躺的還是上週抓的那一份。別對著一個死掉的項目研究，先更新一次訂閱。
• 協定在你目前的網路裡被干擾。以 UDP 為底的傳輸是常見的受害者，電信業者的 QoS 會把它壓下去；特徵是同一家的其他節點都好，就這幾個不行。在同一份訂閱裡找一個走 TCP 的節點對照一下。
• 落地那頭滿了。晚上是尖峰，一個中午測起來正常、十點鐘逾時的節點，基本上都是這個原因，也基本上不是你能修的。

第二條常被誤判成節點壞了。換個網路測同一個節點，用手機熱點就夠。熱點上通了，代表節點是好的，是你這條網路在壓那種傳輸；兩邊都不通，才是節點自己的問題。

有些逾時是測出來的，不是真的

按一下，用戶端同時測幾十上百個節點，這些請求全擠在你一條上行鏈路上排隊，排在後面的直接撞上時限。你看到的逾時比例因此虛高。真在意某幾個節點，就一個一個單獨測，結果跟批次跑出來的完全是兩回事。

另一個因素是時限本身。多數用戶端都有一項可調的測試逾時時間，預設值對尖峰時段的跨洋線路可能偏緊——本來兩秒多能回來的節點直接被判死。把它放寬一點，會有一批「假逾時」活過來。放寬之後還是逾時的，那才值得認真看。

逾時不是判決

測試只打了一個位址、走了一條路徑。你真正要連的網站在不在同一個方向、會不會經過同一段壅塞，是另一回事。所以這兩種狀況都很常見：測出逾時的節點，開網站順得很；測出漂亮的 80ms 的節點，影片卡到沒辦法看。