Ping測試結果怎麼看：抖動、0 ms與HTTP延遲測試解讀
看懂瀏覽器延遲與抖動結果，了解0 ms與重複使用連線的意義，以及HTTP/3為何使用QUIC而非TCP。免費測試，限制清楚說明。
把中位數、範圍與抖動放在一起看
延遲工具在一次暖機請求之後，依序記錄八個HTTP回應時間。中位數是排序後測量值的中間值；範圍顯示最小值與最大值。這裡的抖動是相鄰樣本之間變化量的平均絕對值，而不是封包層級的測量。
以一個八樣本的範例來計算：20、30、10、40、20、30、10、40 ms。排序後中間的一對是20與30，因此中位數為25 ms。七個相鄰變化量合計140 ms，除以七得到20 ms的變動。範圍為10–40 ms。這些只是用來說明計算的範例輸入，並非某位訪客連線的實測值。
0 ms或計時缺漏代表什麼
回應時間樣本與連線建立各階段的耗時是兩項獨立的測量。重複使用的連線可以直接承載新的請求，不必再次進行DNS查詢或交握。
| 畫面文字 | 意義 | 下一步 |
|---|---|---|
| 已快取或連線已重複使用 | 這次請求沒有測到新的DNS階段 | 不要把它當成DNS解析器的查詢速度 |
| 無新建連線（連線已重複使用） | 資源計時（Resource Timing）項目中沒有新的連線建立區間 | 比較各請求的回應時間，不要把連線建立耗時當成往返延遲 |
| 未使用TCP（HTTP/3 · QUIC） | 這次請求使用HTTP/3，其傳輸層為QUIC | 如果邊緣節點回報了QUIC RTT，請查看該數值 |
| 未回報 | 所需的計時資料缺漏或無法使用 | 維持為未知；這不是測得的零值 |
| 回報為0 ms（精確度不明） | 邊緣節點回傳了零，但精確度不足以進一步解讀 | 不要據此推斷實際延遲為零或連線已重複使用 |
公平比較Wi-Fi、行動數據或VPN
做小規模比較時，請使用同一台裝置和同一個瀏覽器。結果只是排除問題時的觀測，而不是對整條網際網路連線的校準基準測試。
- 暫停下載、串流與其他大流量活動，然後執行延遲工具，記下中位數、範圍與變動。
- 只變更你想比較的網路或VPN設定，等它穩定後再重複測試。
- 記錄多次執行的結果與測試時間。如果觀測到的邊緣節點或路由改變，請將結果視為完整路徑之間的比較。
- 使用「TLS檢測」查看HTTP通訊協定與邊緣節點回報的RTT。這些中繼資料來自它自己的檢查請求，因此不一定與延遲樣本相同。
保留能解釋變化的比較紀錄
每次執行都記下時間、網路名稱、VPN設定、中位數、範圍與變動。如果要比較VPN，請保持Wi-Fi與裝置不變；如果要比較Wi-Fi與行動數據，請保持VPN設定不變。同時改變兩項之後中位數變大，並無法看出是哪一項造成的。
把上面的範例與八個剛好都是25 ms的樣本相比：兩者的中位數都是25 ms，但固定數列的範圍是25–25 ms，相鄰變動為0 ms。中位數相同，穩定程度卻可能截然不同。這些合成範例只是為了單獨說明計算方式；實際瀏覽器的排程會帶來雜訊。請重複測量出乎意料的結果，並在紀錄中保留設定標籤。不要把邊緣節點RTT加到瀏覽器的總請求時間上：這些數值可能互相重疊，而且來自不同的請求。
為什麼瀏覽器測得的Ping與遊戲Ping不同
一次HTTP請求除了網路傳輸時間，還包含瀏覽器與伺服器的處理時間。遊戲則是與另一個端點通訊，而且可能使用其他通訊協定。鄰近Cloudflare節點的結果無法預測你連到某台遊戲伺服器的延遲；本工具也不測量ICMP ping、封包遺失或下載速度。
如果目的是自己架設遊戲伺服器，請使用「遊戲IP」頁面準備位址，並查看路由器WAN端的線索。如果是遊戲過程中延遲卡頓，也請查看遊戲本身的網路統計，並在問題發生時重複測試。CGNAT線索與高延遲是兩項獨立的觀測，其中一項並不能證明另一項。
常見問題
為什麼使用HTTP/3時TCP RTT顯示「未使用」？
HTTP/3使用的是QUIC而不是TCP，因此TCP欄位不適用於該請求。當邊緣節點回報QUIC RTT時，IPNixa會另外顯示。
0 ms是否代表我的連線沒有延遲？
不是。在重複使用的連線上可能會略過建立連線的階段，或者伺服器回報的0精確度不足以解讀。這些情況會與缺少的數值分開標示。
瀏覽器延遲和ICMP Ping測試結果一樣嗎？
不一樣。這些樣本測量的是傳送到IPNixa的小型HTTP請求所花的時間，其中包含瀏覽器與端點的處理時間。ICMP、遊戲與其他目的地使用的是不同的測量方式。
這項測試能找出封包遺失或緩衝膨脹（bufferbloat）嗎？
不能。八個小型HTTP請求無法測量封包遺失，也無法測量受控上傳或下載負載下的延遲。請使用專為這些測量設計的工具。