遊戲節點延遲不只看距離：封包走的是電信商買到的路

同一個週五晚上，同一個香港節點。台北的玩家打完整場對局，沒抱怨半句；雅加達的玩家卻在群組裡開罵，按了技能要等一下下，角色才動。

伺服器是同一台。雅加達到香港，直線距離是台北到香港的三倍多，體感的差距卻遠不止這個比例。

差別藏在你看不見的地方：封包走的路。台北玩家的封包直接過海進機房；雅加達玩家的封包可能先繞去新加坡、甚至東京，再折回香港。機房地址一樣，線路不一樣，延遲就是兩個數。

這篇想講的就一句話：延遲數字是跟著線路走的，不是跟著機房地址走的。 別人的 ping 表不能抄：你抄來的數字，前提是走了同一條路，而這個前提幾乎不成立。

封包走的路，比地圖上的直線長

你看到的延遲數字，是封包跑完一整段旅程的總和，而這段旅程很少走直線。

封包從玩家的裝置出發，先交給他的電信商，再由電信商轉交給下一家網路，一站一站往前，最後進機房。每換一次手就是一個跳數（hop），白話說就是轉一次車；轉車要等，封包每多轉一站，就多一次排隊等待的時間。地圖上的直線只給了物理下限，實際走的是折線，折線和直線差多遠，取決於你玩家的電信商跟誰接了線。

延遲的構成裡，這篇只拆「路」。距離的因素、ping 為什麼量不準，在台灣玩家連香港還是新加坡？用 3 種玩家分佈決定遊戲節點已經拆過；那篇回答「節點放哪」，這篇回答「數字為什麼對不上」。

所以兩個玩家測同一個節點出現兩個數，第一個該問的問題是：你們的封包，走的是同一條路嗎？

Riot 為什麼自己組了一張全球骨幹網

公網路由靠不住，這件事大到連遊戲公司都自己動手修。這節先講故事，最後給你一把尺：你的遊戲對延遲多敏感，要不要為它花大錢。

英雄聯盟的開發商 Riot Games，從 2014 年開始自建一張私有骨幹網路，官方叫它 Riot Direct：一張專門走 Riot 自己封包的線路與路由器織成的網。自建的原因，官方工程部落格講得很直白：電信商轉發別家流量時，很多情況下預設走「熱馬鈴薯路由」（hot-potato routing），封包像燙手山芋，儘早從最便宜的出口甩給下一家網路。照這個邏輯推下去：便宜的路，常常也是繞遠的路。

Riot 反過來做。它在世界各地設接入點，能直連的地方就跟當地電信商拉專線握手；這種兩家直接拉線、不經第三方交換中心的對等互聯叫 PNI，Riot 明言優先於向外買轉手（transit）。握手之後，玩家的封包一出電信商的網就進 Riot 自己的線，一路走到底，不進公共網路擠。這種「自家線上走越久越好」的走法，業界叫冷馬鈴薯路由（cold-potato routing），跟電信商的預設剛好相反。

砸這麼大的工程換什麼？換體感。按 Riot 自家的說法，英雄聯盟的目標是 15 毫秒以內、約 60 毫秒仍可玩；VALORANT 超過 60 毫秒就很吃力，所以 Riot 為它多放了伺服器點位。同一張網、兩款遊戲，門檻差這麼多，這就是剛才那把尺：競技對局卡不得，延遲的錢花得早；休閒玩法門檻寬得多，同一筆錢可以先花在別處。

數據來源: Riot Games Engineering〈Leveling Up Networking for A Multi-Game Future〉（2026-09-17 擷取）；Riot 亦另有〈Fixing the Internet for Real Time Applications: Part I〉。

兩個團隊測同一節點，數字差一大截，誰錯了？

都沒錯。他們只是從不同的起點、不同的時段，走了不同的路。

同一個節點的讀數，至少被四個變數拉扯：起點電信商、測試時段、起點城市、線路等級。把它們攤開看，就知道為什麼任何一張現成的 ping 表都不敢直接抄。

變數	同一節點的讀數會怎麼變	常見誤判
起點電信商	中華電信、台灣大、遠傳與各家機房的接線各不相同，走線不同、讀數不同	把朋友家或同事家測的數字，當成自己玩家會拿到的
測試時段	尖峰時段對等段塞車，晚間讀數比白天高、且劇烈抖動（讀數忽高忽低）	中午測完一輪就定案
起點城市	距離改變下限，但繞路可能讓「近的反而慢」	只看地圖直線選節點
線路等級	電信商向別家網路買路時拿到的品質不同；機房自己接的上游組合，同樣分好壞	以為同一個城市所有「香港節點」是一回事

最後一列值得多說一句。香港一個城市，就有 13 條海纜系統登陸（通訊事務管理局 2026 年中口徑，此前業界統計 12 條），分屬 10 個登陸站；同一個城市裡，不同機房對外的海纜組合都不見得一樣。「香港節點」四個字，背後是一堆不同的線路組合，選的時候要問到具體是哪一座機房、走哪些登陸站。問的時候不用怕對方接不住：講不清自己走哪些登陸站的供應商，本身就是一個信號。

數據來源: 香港通訊事務管理局辦公室（OFCA）海纜登陸頁（2026 年中口徑 13 條、10 個登陸站）與 SubmarineNetworks 香港頁（2025 年 10 月口徑 12 條），2026-09-18 查核更新。

這四個變數，動任何一個，讀數就不同。同一張表有人覺得準、有人覺得離譜，原因都在這。

擁塞多半不在機房裡

一到晚上就卡，先看卡在哪一段：多數尖峰擁塞，發生在機房外面那段路上。

晚高峰的機制不複雜。大家同時回家上網，最先塞的往往不是機房自己的頻寬，而是玩家側的最後一哩、電信商的對外出口、還有電信商之間握手的對等互聯點。自租小節點要多看一項：你那台機器的埠頻寬，和託管商對外的上聯有沒有超售。這一項卡住，白天晚上都會卡，跟電信商那條路無關。

消費者網路社群裡「ping 每天晚上固定變差」是長年常見的診斷題，答案多半指向電信商擁塞。不過別拿社群答案定案，用下面的兩時段對照驗證完再下結論。

怎麼定位塞在哪？同一個節點、同一台裝置，白天和晚上各測一輪：白天順、晚上卡，八成在路上；白天晚上都卡，才輪到節點與路由被懷疑。再借一台手機網路的裝置交叉驗證，嫌疑範圍能縮得更小。

定體感門檻時，雅加達、馬尼拉這類尖峰落差明顯的市場，晚上那一輪的數據比白天那一輪值錢得多。

五步排一份能對外說話的實測

實測要有效，關鍵在起點和時段；工具不用高級。排一份能對外說話的測試計畫，至少做滿這五步：

從玩家所在地測。 在台北辦公室測雅加達節點，測到的是你們公司那條企業線的讀數。
覆蓋主要電信商。 中華電信、台灣大、遠傳各找一台裝置；東南亞市場至少加一家當地電信商，再配一條手機網路。
兩個時段起步。 離峰一輪，晚高峰（玩家當地時間，例如晚上八點到十一點）一輪，兩輪對照才有意義。
記三個指標，用對的工具。 平均延遲之外，記抖動（jitter，讀數忽高忽低的幅度）與丟包（packet loss，封包在半路掉了）。工具用 mtr（Windows 用 WinMTR）或 ping 長跑統計，遊戲內建的網路面板也算數；tracert 量不了這兩樣。遊戲體感常常死在抖動和丟包上，平均數看不出來。
看一眼走線，會讀再下結論。 Windows 跑 tracert、Mac 跑 traceroute，測前先關掉加速器與 VPN，不然量到的是加速器那條路。多數跳點會帶電信商命名的城市字樣，從頭掃一遍；中間跳點出現星號是常態，最後一兩跳不回應也不少見（很多遊戲伺服器不回應探測）。連香港的線中途冒出東京這種明顯大迂迴，才是繞路；認不出來的跳點，把整段結果交給懂行的人解讀。

這五步做完，你手上就有自己的數字了。跳點列表看不出所以然，把結果交給節點延遲評估解讀，比對著表格猜快得多。

測出繞路，錢怎麼花才不冤

確認是線路的問題之後，錢有三個花法，而且有先後：先花時間的，再花小錢的，最後才是花大錢的。先看圖：

遊戲節點延遲路徑對比圖：同一節點兩條線路，直連與繞道的封包旅程對照，標示對等互聯點、擁塞段與三條處理路徑

圖的解讀：同樣從雅加達出發到香港，下路直連、一路順；上路先繞經新加坡、東京，再折返香港，多出來的每一站都在加時間。三個花法，對應的是確認之後「改哪一段」：

第一個花法，花的是時間：換節點重測。換的目標是「電信商×機房」這對組合，地圖距離是次要的；同一城市換一座機房，海纜登陸站與對等互聯的組合可能整個換一輪，讀數常常跟著換一個樣。代價是重來一輪實測的時間；邊界是，新節點同樣要按上面的五步測過，看了別人的表就搬家，等於把上一次的虧再吃一遍。

第二個花法是買線路等級，前提先講清楚。Google Cloud 把對外連線分成 Premium 與 Standard 兩檔：Premium 在靠近用戶的地方就把流量收進 Google 自己的骨幹，Standard 走公共網路；AWS 的 Global Accelerator 做的事情類似，把流量放上 AWS 全球骨幹、送到離玩家最近的區域端點，前提是那個區域有你部署的端點。這類產品只對開在對應雲上的資源生效，節點是別家機房的裸金屬或 VPS，就買不到；它救的也只是雲邊緣之後那一段，擁塞若發生在玩家電信商自己的網段裡，它管不到。所以掏錢的條件很窄：確認了繞路或擁塞、受影響玩家集中在少數幾家電信商、節點又剛好開在對應雲上，三個條件同時成立才值得；公測期小流量，先把錢花在多測幾輪。

第三個花法是大錢：上多區，就近接入。玩家分佈太散、單一節點怎麼測都有地區吃虧，就該往多區走，按玩家分佈三檔判斷主節點與第二節點的分工（方法在台灣篇）。代價是資源與資料同步都變成兩份帳；還有個前提要先確認，你的遊戲得能分區開服，全球同服、權威伺服器只有一套的架構，多區救不了它。

也有不用花的錢。下載、更新包這類不吃即時性的流量，交給 CDN 就夠，別為它買骨幹加速；單一電信商玩家占了絕大多數、白天晚間都測得穩的節點，用不著為了以防萬一先租專線。專線（IPLC）是兩點之間租一條不經公網的線，護的只有兩點之間那一段，玩家到接入點的最後一段它管不到；要用的話，留給核心對局伺服器那種「斷了就出事」的流量。

數據來源: Google Cloud〈Network Service Tiers overview〉（Premium／Standard 兩檔的官方定義），2026-09-17 擷取。

數據來源: AWS Global Accelerator 開發者指南（官方原文：Global Accelerator directs traffic over the AWS global network to endpoints in the nearest Region to the client），2026-09-17 擷取。

選節點，選的其實是一張路網。數字是線路給的；先把線路看懂，再談距離，帳單和玩家群組都會安靜很多。

你的玩家最常從哪個城市、哪家電信商連進來，決定了該走上面哪一條路。這兩個分佈要是還沒著落，可以從登入日誌的 IP 反查，或看後台的玩家位置報表；整理好之後，到 Telegram 講玩家分佈聊一聊，先判斷該補哪一輪測試、還是該動哪條線。

FAQ

同一個節點，為什麼兩個團隊測出來差很多？

起點電信商、測試時段、起點城市、線路等級，四個變數不同。兩家公司測同一節點，等於在跑兩條不同的路，數字本來就可能對不上。要比，先確認起點電信商和時段一致，否則對上的只是各自的線路。

玩家一到晚上就卡，是節點選錯了嗎？

多數時候不是。尖峰擁塞常發生在電信商出口與對等互聯段；自租的小節點，還要先排除機器本身的埠頻寬與託管商上聯超售。同一節點白天、晚間各測一輪：白天順、晚間卡，先往電信商與線路方向查；兩個時段都卡，才把節點與路由列入嫌疑。

怎麼確認玩家的流量有沒有繞路？

讓玩家或對應電信商的測試點跑 tracert 或 traceroute，測前先關掉加速器與 VPN。多數跳點會帶電信商命名的城市字樣，從頭掃一遍；中間跳點出現星號是常態，最後一兩跳不回應也不少見。連香港的線中途冒出東京這類明顯大迂迴，才是繞路。看不懂跳點列表，把原始結果交給懂行的人解讀。

平均延遲不高，為什麼玩家還是喊卡？

平均值看不見抖動與丟包。用 mtr 或 ping 長跑把三個指標一起記：平均延遲、抖動（讀數忽高忽低的幅度）、丟包（封包在半路掉了）。三個指標一起看，光記一個平均數，會漏掉真正的兇手。

骨幹加速類產品什麼情況值得買？

三個條件同時成立：實測確認了繞路或擁塞、受影響的玩家集中在少數幾家電信商、節點開在對應雲上。這時 Google Cloud 的 Premium 線路等級、AWS Global Accelerator 這類把流量提前收進雲廠商骨幹的產品才花得有道理；玩家電信商自己網段內的擁塞，它們救不了。公測期小流量階段，先把錢花在多測幾輪。

海纜斷了，節點是不是就廢了？

短期體感劣化跑不掉。2006 年恆春地震後多條海纜同時受損、修復以週計；2023 年台馬海纜先後雙斷，馬祖靠微波備援頂了相當時間，線路故障從來不是理論風險。能提前準備的是多區部署與備援路由，但兩者都救不了故障當下；規劃預算時，把偶發的劣化期算進成本預期，別假設線路永遠滿血。

關於新星雲

寫這篇之前，我把 Riot 自組骨幹網的工程記錄，和兩家雲的線路分檔文檔重讀了一遍。把工程文檔讀成採購判斷，就是新星雲幫團隊選節點、核帳單時每天在做的事。新星雲是我一個人的顧問服務，站上每一家雲的優劣都照實寫，因為我不靠任何一家廠商吃飯，也沒有授權牌要護；需要跟原廠用英文往來時，我可以直接替你開工單、追進度。你自己採購、只借個方向走，也完全可以，那就先把玩家的城市與電信商分佈整理好，它比任何報價單都值錢。