從你家出發，Yandex Cloud各區域到底有多快？

大部分“雲節點測速”網站，以及廠商自己的 Looking Glass，測試都是從他們的伺服器發起的。這些伺服器放在機房裡，接的是優質線路，測出來的只是“機房到機房”有多快。而你真正感受到的那一段，家裡寬頻或手機網路、運營商骨幹、國際出口，還有今晚堵不堵，它們統統測不到。

Me2Cloud 的每個請求都從你的瀏覽器發出，所以結果把這些全算進去了：Wi‑Fi、路由器、運營商、運營商選的路由，還有晚高峰。

1. 先發一次預熱請求，把 DNS、TCP、TLS 都建好。這次的時間會顯示出來，但不計入結果。
2. 然後在同一條連線上，對同一個主機再發 5、10 或 20 次請求。每次只花一個往返，再加上廠商伺服器的處理時間。
3. 每家廠商都用我們實測過、能保持連線的請求方式：AWS、Azure、Google Cloud、華為雲、DigitalOcean、Scaleway 用 GET；Oracle、IBM Cloud、阿里雲、騰訊雲、火山引擎、百度智慧雲、Naver Cloud、Linode、Vultr、OVHcloud、IONOS Cloud、Aruba Cloud、Leaseweb、Gcore、Yandex Cloud 用 HEAD（它們的 GET 會斷開連線，測出來會翻 3 倍）；只有 Hetzner 用 <img>。
4. 結果給出中位數（最典型的值）、平均值、P90（10 次裡有 9 次不超過它）、抖動（相鄰兩次的平均變化）和丟包（超時沒響應的次數）。
5. 等級按中位數劃分：T0 夯 ≤ 30 ms、T1 頂級 ≤ 80 ms、T2 人上人 ≤ 150 ms、T3 NPC ≤ 250 ms，再往上就是 T4 拉完了。推薦用的綜合分是“中位數 + 2 × 抖動 + 丟包懲罰”，所以穩定的 60 ms 會排在忽高忽低的 45 ms 前面。

• 跟你的流量走同一條路。網頁、API、走 443 的隧道、遊戲登入、下載，用的都是 TCP。不少運營商對 ICMP 單獨排隊、限速，甚至單獨選路，所以經常 ping 看著挺好、網頁卻卡得要死，反過來也有。
• 不會被限速吞掉。路由器和雲廠商經常限制甚至直接丟棄 ICMP，而訪問公共 HTTPS 端點總會有響應。
• 算上你的真實環境。DNS、IPv4/IPv6 的選擇、代理、加速器，對瀏覽器流量都會生效，測出來的就是你實際能拿到的效果。
• 代價是：每次取樣還包含一點很穩定的伺服器處理時間。我們實測 AWS 是 0–5 ms，阿里雲約 8 ms，華為雲 OBS 約 20 ms。延遲上百毫秒的節點完全可以忽略；離你特別近的區域，數字會比 ping 略高一點。

• 家庭寬頻在晚上 20:00–23:00 最堵，出國線路更明顯。中午還是 T1 頂級的區域，到了晚上可能直接掉到 NPC。
• 建議白天測一次、晚高峰再測一次。儲存的結果會打上“晚高峰”標籤，在測試結果裡可以來回切換對比。
• 測試時先暫停大檔案下載、影片和網盤同步。有線比 Wi‑Fi 準；只能用 Wi‑Fi 的話，儘量離路由器近一點。
• 用手機流量測，結果會跟著訊號走。最好在你真正要用的地方測。

• 買伺服器、遊戲服、CDN 回源之前，先把候選區域篩一遍。
• 比較同一家廠商的不同區域，或者同一個城市不同廠商的表現。
• 看穩定性（抖動、丟包）夠不夠打遊戲、開視訊會議、遠端桌面和 SSH。
• 驗證你的代理、加速器或者新辦的寬頻到底行不行：開著測一次，關掉再測一次。
• 用自定義節點，把你自己的伺服器或 CDN 跟大廠放在一起比。

• 只代表一個位置。測的是你的線路，不是你使用者的。可以讓幾個使用者也測一下，匯出來對比。
• 測的是端點，不是你以後的雲主機。我們測的是廠商在該區域的公共 API 或儲存端點。同區域的伺服器一般共用網路，但精品線路（比如 CN2、BGP 和單線、Lightsail 和 EC2）可能不一樣。
• 不測頻寬、不測 UDP、不做路由追蹤。只測往返時間，不測下載速度、UDP 遊戲流量，也看不到中間經過哪些節點。
• 瀏覽器本身的影響。外掛、代理、VPN、很忙的標籤頁都會帶來噪聲。測試時關掉佔資源的標籤頁，讓本頁保持在前臺。
• Hetzner 在瀏覽器裡沒法保持連線，所以它的數字每次都包含握手時間。個別端點在某些國家和地區可能訪問不到。

• 本頁是放在 Cloudflare 上的純靜態檔案。沒有後端、不用註冊、沒有統計程式碼，結果也從不上傳。
• 所有測試請求都由你的瀏覽器直接發給廠商。開啟上面的請求記錄，或者瀏覽器開發者工具的 Network 面板，每一條都看得到。
• 網路資訊來自 Cloudflare（speed.cloudflare.com/meta 和 /cdn-cgi/trace）。可選的 WebRTC 檢測會向 stun.cloudflare.com 詢問你的 UDP 出口地址，不想用可以在設定裡關掉。
• IPv4/IPv6 檢測會同時詢問 Cloudflare 以外的 ipify.org 和 ident.me，某一家被網路阻斷時，不會被誤判成沒有 IPv6。
• 設定、自定義節點和最近幾次結果只存在這個瀏覽器的本地儲存裡，“清空全部資料”會把它們全刪掉。

對公共端點請求太猛，可能觸發廠商的限流或 WAF，結果也就不準了。所以測試節奏刻意壓得很低：

• 每個主機同一時間只有一個請求，兩次取樣之間停 250–370 ms（每個主機每秒最多 2–3 個請求）。
• 每家廠商最多同時測 2 個主機，總共最多 8 個（預設 4 個）。
• 每次測試每個主機最多 21 個請求（預熱 + 20 次），沒有持續轟炸的模式。
• 連續失敗 3 次就放棄這個主機，不會反覆重試。
• 全部是匿名、不帶 Cookie、不帶 Referer 的“簡單請求”：沒有預檢，響應只有幾百位元組，能用 HEAD 就用 HEAD，不會下載大檔案。

整個過程的流量比開啟一個普通網頁還少。每個端點都驗證過能正常響應匿名請求（返回 200、403、404 都不影響計時）。

流量走代理的話，瀏覽器測到的是“你到代理”加上“代理到廠商”，而不是你自己的線路。網路面板會檢查幾個常見跡象：出口網路屬於機房、時區和出口國家對不上、開了 WARP、WebRTC 出口和 HTTPS 出口不一致。

點獲取直連規則，只把測試域名設成直連（支援 Clash / Mihomo、Surge、Shadowrocket、Quantumult X、Loon、sing-box、Xray、SwitchyOmega 和純域名列表），然後重新檢測。如果你想測的正是代理本身，那就開著測，得到的就是代理的真實表現。

• 每一行的條形圖都用同一把尺子（對數刻度，2 ms 到 3 s）。圓點是每次取樣，陰影框是中間一半取樣所在的範圍，豎線是中位數。
• 框越窄越穩；框很寬或者點很散，就是抖得厲害。紅色 × 是丟包的次數。
• 點開一行，能看到每次取樣的先後變化、全部統計資料和用到的端點。✓ 表示符合你的需求。