為什麼宣傳數字不能直接信
同一台裝置、同一條線路，換一個時段再測，數字可能差出一倍。測速結果至少受五個變數影響：本地寬頻的實際出口、測試時段是否壅塞、測速伺服器放在哪裡、代理協定與加密帶來的額外開銷，以及用戶端的分流規則有沒有真的把測速流量送進代理。
宣傳頁上的數字通常取自條件最好的一組：就近的測速節點、空閒的時段、多執行緒聚合出來的峰值。它回答的是「這條鏈路在理想條件下能跑多快」，而不是「晚上九點打開影片會不會轉圈」。自己測速的價值，在於把真實的使用條件固定下來，觀察不同時段、不同線路之間的差異。
測速前先清場：暫停系統更新、雲端硬碟同步、其他裝置上的影片與下載。同一網路裡只要有一台裝置在跑大流量，測出來的數字就會偏低，而且偏低多少無法估算。
測速工具怎麼選：三層搭配各管一段
沒有哪個工具能一次回答所有問題。按「先拿基準、再定位問題、最後回到真實場景」的順序排三層，日常判斷基本夠用。
第一層：網頁測速，先拿一個快速基準
Speedtest by Ookla、Fast.com、Cloudflare Speedtest 都屬於這一類，打開就能出下行、上行與延遲。用法上只有一個要點：手動選定測速節點，並且每一輪對照都用同一個節點。自動推薦會隨網路狀況更換伺服器，數字前後就沒有可比性。
第二層：命令列工具，定位問題出在哪一段
ping 與 mtr 負責延遲、抖動和逐跳封包遺失；iperf3 負責裸吞吐與長時間穩定性；curl 的 -w 參數能把 DNS 解析、TCP 連線、TLS 握手、首位元組四個階段的耗時分別印出來——「網頁打開慢」到底慢在哪一步，一測便知。
# 延遲與抖動：連續 20 次 ping，重點看最大值與最小值的差距
ping -c 20 example.com
# 逐跳封包遺失：定位問題出在本地網路、國際出口還是對端
mtr -rwzbc 50 example.com
# 分階段耗時：解析、連線、握手、首位元組各花了多久
curl -o /dev/null -s -w "dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s\n" https://example.com第三層：真實場景測速
從常用的大檔案來源下載一次，或者看一段影片並記錄緩衝次數。這一類沒有漂亮的數字，卻最接近日常體感。判斷影片會不會卡，單執行緒結果比多執行緒聚合值更有參考價值。
多執行緒測速會把多條連線的速度加在一起，顯示的數字通常高於單個應用實際能拿到的頻寬。網頁、影片串流與單個下載任務多數是單執行緒或有限多連線，兩組數字要分開看、分開記。
| 工具 | 主要測什麼 | 適合的情境 | 注意事項 |
|---|---|---|---|
| Speedtest（Ookla） | 下行、上行、延遲 | 快速基準、換線路前後的對照 | 手動鎖定同一個測速節點 |
| Fast.com | 下行頻寬與延遲 | 判斷串流方向的頻寬 | 不測上行，抖動與封包遺失要另外測 |
| Cloudflare Speedtest | 頻寬、延遲、抖動 | 快速看抖動 | 節點由對方網路決定，不能自選 |
| ping / mtr | 延遲、抖動、逐跳封包遺失 | 定位鏈路哪一段出問題 | 需要目標位址，ICMP 可能被限速 |
| iperf3 | 裸吞吐、長時間穩定性 | 自建節點、持續打流 | 需要兩端配合，門檻偏高 |
| curl -w | 解析、連線、握手、首位元組耗時 | 查「打開網頁慢」卡在哪一步 | 命令列輸出，需要理解各階段含義 |
時段怎麼排：離峰與晚間尖峰對照
至少取兩個時段：一個是本地網路的離峰（工作日上午或下午），一個是晚間尖峰（20:00 到 23:00）。同一個節點、同一個工具，每個時段連續測三次，間隔一分鐘以上，取中位數而不是峰值。週末的晚間尖峰通常比平日更壅塞，想看得更準，可以再補一輪週末對照。
跨國存取還要把對方的時區算進去：你這邊是深夜，對端可能正處在業務高峰。線路類型的差異在這個環節最明顯——直連與中轉線路要經過公網國際出口，晚間尖峰的波動更大；IEPL 專線走獨立通道，不擠公網出口，離峰與尖峰的數字通常更接近。這一組對照，比任何單次成績都更能說明線路品質。
測速網站的伺服器大多接在 CDN 邊緣。如果測速網域命中了直連規則，你測到的其實是本地寬頻到 CDN 的速度，和代理線路沒有關係。測速前先確認分流規則，或暫時切到全域模式。
三項指標：延遲、抖動與封包遺失怎麼讀
頻寬數字最顯眼，但決定體感的往往是另外三項。三者要連起來看，單獨一個數字說明不了問題。
延遲（RTT）：看差值，不看絕對值
單位是毫秒。跨國存取的延遲天生高於本地存取，所以比較的重點是兩個差值：與直連基準的差值（代理與線路引入的額外開銷）、晚間尖峰與離峰的差值（鏈路是否壅塞）。如果同一條線路在晚間尖峰延遲明顯放大、抖動同步上升，基本上可以判斷它走的是共享出口。
抖動（jitter）：即時影音的生死線
抖動是相鄰兩次延遲的差值，反映鏈路穩不穩。語音通話、視訊會議、競技類遊戲對它最敏感：平均延遲再低，抖動一大照樣斷續、卡頓。命令列裡連續 ping 二十次，看最大值與最小值的差距，比看平均值有用得多。
封包遺失（loss）：最容易被忽略，影響卻最直接
哪怕只有百分之幾的封包遺失，TCP 也會反覆重傳，體感就是網頁轉圈、進度條不動。基於 QUIC 的協定（Hysteria2、TUIC）在封包遺失鏈路上比基於 TCP 的協定（Shadowsocks、VMess、Trojan、VLESS）更抗損，代價是更吃頻寬，並且要求 UDP 轉發品質過關。
DNS 解析是另一個容易漏掉的環節：如果用戶端的 DNS 請求沒有跟著代理走，可能被本地解析器解析到一條繞遠的入口，表現為連線建立慢、首位元組慢，而頻寬測試完全看不出問題。用 curl 印出各階段耗時，time_namelookup 明顯偏大就是訊號。
| 指標 | 單位 | 怎麼測 | 數值變大代表什麼 |
|---|---|---|---|
| 延遲 RTT | 毫秒 | ping、mtr、測速網站 | 鏈路變長或壅塞，互動變慢 |
| 抖動 jitter | 毫秒 | 連續 ping 的最大值與最小值之差 | 即時影音斷續、卡頓 |
| 封包遺失 loss | 百分比 | mtr 逐跳統計、ping 統計 | 重傳增加，下載與網頁明顯變慢 |
| 下行 / 上行頻寬 | Mbps | Speedtest、iperf3、大檔案下載 | 決定大檔案與影片清晰度的上限 |
| DNS 解析耗時 | 毫秒 | curl -w 的 time_namelookup | 解析繞路，首屏與連線建立變慢 |
一套可重現的測速流程
下面的順序把變數一個個固定住，照著做一遍大約半小時，得到的結果可以直接橫向比較。
- 固定變數。同一台裝置、同一個測速節點、同一條線路、同一個協定。任何一項換了，對照都要重新開始。
- 先清場。關掉背景下載、系統更新、雲端硬碟同步；有條件用網路線代替 Wi-Fi，用 Wi-Fi 就固定在同一位置。
- 測直連基準。關閉代理，記錄下行、上行、延遲、抖動、封包遺失。沒有基準的數字沒有參照物。
- 測線路表現。開啟代理，確認測速網域走代理（全域模式，或把測速網域加入代理規則），連續測三次，間隔一分鐘以上，取中位數。
- 換時段重複。離峰一輪、晚間尖峰一輪，分別記錄，重點看兩輪的差距有多大。
- 換線路對照。同地區的直連、中轉、IEPL 專線各測一輪，只換線路，其他條件全部不動。
- 記錄歸檔。按日期、時段、線路、協定、下行、上行、RTT、抖動、封包遺失九欄記成一張表，一週後再看趨勢。
流程裡最容易省掉的是第三步和第七步：沒有基準，就判斷不出代理與線路引入了多少開銷；不記趨勢，就只能憑一次結果下結論。
結果解讀：常見的幾個誤判
數字測出來之後，怎麼讀同樣關鍵。下面這些判斷方式，不是讓結果失去可比性，就是把不同層面的問題混在一起。
- ❌ 拿單次峰值當穩定值：凌晨測到的高點，不代表晚間尖峰還能維持。
- ❌ 沒確認分流規則就下結論：測速網域走了直連，兩組數字測的根本不是同一條路徑。
- ❌ 只測下行不測上行：視訊會議、雲端硬碟上傳、遠端桌面吃的是上行頻寬。
- ❌ 把測速節點的延遲當成網頁開啟速度：解析、握手、首位元組每一步都會疊加，頻寬再高也救不回來。
- ✅ 固定變數、重複三次取中位數，再看晚間尖峰相對離峰的下降幅度——這是唯一能橫向比較的讀法。
- ✅ 記錄一週的趨勢：線路品質是一個分佈，不是一次成績。
測速解決的不是「哪家最快」，而是「我的網路裡最慢的是哪一段」。固定變數、對照時段、重複測量這三件事做到，宣傳數字值不值得信、這條線路晚間尖峰頂不頂得住，你自己就能給出答案。
如果一輪測下來，瓶頸穩定出現在晚間尖峰的國際出口，而不是本地寬頻或測速節點，那就是線路類型的問題，換一條不擠公網出口的線路，比反覆測同一組數字更有意義。VPNEQ 提供 100+ 國家與 210+ 線路，按地區分組、多線冗餘，Windows、macOS、iOS、Android、Linux 都能用，不限台數同時在線，可以作為你對照表裡的一條參照線路。