香港、新加坡、日本節點對遊戲延遲差多少？實測前先看這份表
三份節點報價放到桌上：香港、新加坡、東京。單價差不到兩成，延遲那一欄三張都空著，供應商只留一句「建議先測試」。
報價單不敢填的空欄，不是銷售偷懶。遊戲節點延遲在你們自己的實測之前，本來就沒有一個四海皆準的準數。但開區的決策等不了實測排期，總得先有東西可看。
現在就能拿到的是兩種數字：下限和量級。下限算得出來，量級查得到，兩種都有來源、有口徑，可以逐項複核；落點要等你自己的實測。這篇把香港、新加坡、東京三個節點之間的這兩種數字擺好：香港到新加坡骨幹實測 36 毫秒、新加坡到東京 72 毫秒。再告訴你表答到哪裡為止。
實測之前，你手上能先鎖定兩種延遲數字
先給表。三行數字，兩個來源，正是它經得起轉寄的原因。
| 節點對 | 直線距離 | 物理下限（往返） | Azure 骨幹實測（往返） |
|---|---|---|---|
| 香港到新加坡 | 2,587 km | 約 26 ms | 36 ms |
| 香港到東京 | 2,882 km | 約 29 ms | 49 ms |
| 新加坡到東京 | 5,318 km | 約 53 ms | 72 ms |
兩欄的讀法不一樣。物理下限是算出來的：假設封包走直線、全程光纖，往返一趟最少要這麼久，這是光纖介質給出的下限，跟選哪家雲無關。骨幹實測欄出自微軟官方頁面：Azure 在自家骨幹網兩個區域之間持續探測，每分鐘採樣一次、取中位數，本文數字擷取自 2026-09-19。探測協議官方頁沒有標明，這欄當量級錨用就好，別拿去做個位數的精算。區域對應城市也核過微軟的區域清單頁：East Asia 對香港、Southeast Asia 對新加坡、Japan East 對東京、Japan West 對大阪。
數據來源: Azure network round-trip latencies（官方區域間往返延遲，骨幹內部探測、1 分鐘間隔採樣），2026-09-19 擷取。區域與城市對應出自 Azure regions list，2026-09-19 逐項核對。Azure 頁為滾動統計值，讀者複核時個別數字可能出現 ±1–2 毫秒漂移。
這張表回答的問題很窄：三對節點之間，最快能到什麼量級。它回答不了「你的玩家會測出多少」，原因後面兩節拆開講。可玩與否的尺也先錨好：Riot 的電競工程口徑，最高競技級上限 40 毫秒（±5），日常玩法在 60 毫秒上下仍可接受。兩者都是端到端的數，和本文的骨幹值不是一段帳，量級對照見文末 FAQ。
數據來源: Riot Games Tech Blog〈Artificial Latency for Remote Competitors〉（競技級上限 40ms±5 原文，2026-09-19 親自核對）；Riot Games Engineering〈Leveling Up Networking for A Multi-Game Future〉（英雄聯盟平均 60ms 上下仍可玩原文，2026-09-19 親自核對）。
看圖更直接：每對節點兩根柱子，青色是物理下限，黃色是骨幹實測。三對的實測值都壓在下限之上，高出約三成半到七成。高出來的部分是誰的賬，往下分兩段算。
下限是算出來的：距離乘固定速度
光在光纖裡比在真空裡跑得慢。單模光纖的折射率約 1.47，換算成工程口徑，就是光每公里走 5 微秒左右。網路規劃通行的就是這個數（ITU-T G.114 規劃值，原文明列光纖系統每公里 5 微秒）。往返跑兩趟，算式一行寫完：
往返下限（µs）≈ 直線距離（km）× 10 µs/km，除以 1000 換成毫秒
代入三對距離：香港到新加坡 2,587 公里，約 26 毫秒。香港到東京 2,882 公里，約 29 毫秒。新加坡到東京 5,318 公里，約 53 毫秒。距離取自城市對直線距離計算（DistanceFYI，三對均開頁核對；直線距離是確定性數學，用城市坐標也可以自行重算）。
數據來源: 光纖傳播速度換算見 M2 Optics: Calculating Optical Fiber Latency；規劃值見 ITU-T G.114；距離見 DistanceFYI（另兩對為 香港到新加坡 與 台北到東京），2026-09 核對。
直線距離跟海纜實際長度有差。海纜要繞開海底地形、避開漁錨區，登陸點也不是城中心，實際路徑只會更長。所以這個下限在現實裡不會被「擊穿」：哪天你測出比下限還小的數字，先別高興，查自己的測法，多半是測到了近端快取或設備回應，不是封包真的跑完了全程。
下限到玩家實測的差距，分兩段算
香港到新加坡，下限 26、骨幹 36，高出約四成。這四成怎麼來的，要從下限一路算到玩家的實測值。中間的差距分兩段看：下限到骨幹一段，骨幹到玩家另一段。
先看下限到骨幹這一段，賬在路徑與設備。海纜沿海底地形鋪，陸纜沿管廊走，封包實際走的折線比直線長，這是路徑的賬。有一篇彙整全球實測延遲的研究，把各大洲的實測延遲對直線距離做回歸：北美城市的平均延遲約為理論下限的 1.5 倍，歐洲約 2 倍，非洲個別線路對高到 3 倍。拿上表三對來算，Azure 骨幹是下限的 1.4 到 1.7 倍，跟北美同一檔，而北美在這份研究裡已是最貼近理論下限的地區之一。距離越短的對，固定的設備開銷佔比越大，倍數也抬得越高。
設備的賬在轉發與收發。封包過路由器要轉發，光纖兩端有收發設備，每一步都加一點，量級固定；排隊那一部分隨擁塞起伏，那筆賬歸時段測試管。
骨幹到玩家的另一段，是量測範圍的差。骨幹探測在雲廠商自己的網路內部、兩個區域之間跑；你的玩家封包先在電信商網裡走一段，經過的轉手與排隊都比骨幹探測多。所以玩家的實測值幾乎必然高於骨幹值，高出的那段賬記在電信商與路由頭上，不記在機房頭上。
數據來源: 各大洲實測延遲對直線距離的回歸見 RTT Delay in the Internet（北美斜率 0.015 ms/km 即下限 1.5 倍、歐洲 0.02 ms/km 即 2 倍、Tunis–Lagos 約 3 倍，理論下限基線 0.01 ms/km），2026-09-19 開頁核對。「1.4 到 1.7 倍」為拿上表三對自行推算（36/26、49/29、72/53）。
也因為這段範圍差，這張表敢給你的只有量級。三地兩兩之間的相對關係是穩的：香港到新加坡最近、新加坡到東京最遠、香港到東京在中間。起點就在這三城或緊鄰的城市時，這個排序跟你實測出來的大體一致；起點在別處，先別套——同樣的兩對城市，換一個起點看，近遠次序可能整個反過來。嚴重繞路把排序翻掉的情況另算，那是線路的問題，遊戲節點延遲不只看距離專門拆過。
三地的家底：海纜與交換點
量級之外，三地的家底結構不同。這決定的是出事時的恢復選項和長期擴容空間，跟「快不快」是兩件事。
海纜指鋪在海底、把不同岸站連起來的光纖，是跨境流量的物理通道。香港 13 條海纜系統、10 個登陸站的現行口徑（OFCA 2026 年中）在線路篇逐字核過來源，這裡直接引用。新加坡現役登陸的系統 28 條，承載全國 99% 以上的國際流量（CSIS 2025-09 口徑），登陸站集中在樟宜、大士與丹那美拉一帶。日本登陸的系統數量比港新都多，業界簡報口徑約 40 條；東京有 JPNAP、JPIX 兩個大型網路交換點（多家電信商把線路接在一起、就近互轉流量的設施），PeeringDB 登記口徑分別接了 246 與 271 個網路。
數據來源: OFCA 海纜基建頁（2026 口徑，2026-09-18 核對）；新加坡系統數見 techdirectory.sg（轉述 CSIS 2025-09 案例），2026-09-19 核對；日本海纜口徑見 JPIX 於 TWNOG 的技術簡報；IXP 網路數見 PeeringDB（JPIX 271，JPNAP 246），2026-09-19 查詢。
三地還被同一條纜串著：2025 年 7 月投役的 SJC2，登陸安排把新加坡、香港、日本、韓國連在一條系統上（RFS 2025-07-16）。三地之間的物理連接不缺，缺的從來不是纜，是你玩家那一段的線路品質。
數據來源: SJC2 投役資訊見 SubmarineNetworks，2026-09-19 核對。
海纜條數是會變的數，引用時帶口徑日期。條數多寡也不直接等於快，它影響的是斷纜時的恢復選項與容量上限，這筆賬在選型時記在「備援」欄，不記在「延遲」欄。
把你的玩家放進這張三角裡
表講的是三對城市之間的關係，你的玩家站在三角之外。你的玩家站在哪，就先看哪一行：
| 你的玩家主力 | 第一輪先測 | 參考量級 |
|---|---|---|
| 台灣、香港、澳門 | 香港 | 台北到香港 810 km，下限約 8 ms，三地裡最近 |
| 印尼、馬來西亞 | 新加坡 | 骨幹探測：雅加達到新加坡 17 ms，吉隆坡到新加坡 9 ms |
| 日本、韓國 | 東京 | 骨幹探測：首爾到東京 30 ms，東京是日韓互聯樞紐 |
| 台灣與東南亞兩塊都不小 | 香港與新加坡一起測 | 港到新骨幹 36 ms，各自就近服務自己那側玩家，互為故障備援 |
上面三行骨幹數字同樣出自微軟的探測頁：Korea Central 對首爾、Indonesia Central 對雅加達、Malaysia West 對吉隆坡，城市對應逐項核過微軟的區域清單頁。台北到香港 810 公里、台北到東京 2,100 公里兩個直線距離，來源掛在前面算式的註腳裡。台灣玩家的完整判斷（含玩家分佈三檔怎麼切），台灣篇整篇在講。
反面也說一句。我不建議在日韓玩家占比低時，為了「多測穩妥」把東京排進第一輪：它是三角裡的第三個方向，測試窗口有限，先測跟主力玩家相關的那一兩個組合。與其把三對各測一輪，不如把最相關的那一對，白天與晚間各測齊一輪。玩家已經上線、後台有登入地區資料的，直接看後台 30 天的登入分佈，這張表就完成任務了——它的用處主要在開區前。
把骨幹值當零點
照無口徑的對照表定了錯方向的節點，開區後才發現玩家在另一頭，搬家停服遷存檔——這類返工的帳，台灣篇算過一整篇。對照表害人不在數字錯，在它沒有口徑，你不知道那個數字是誰、從哪、什麼時候測的。
正確用法是把骨幹值當零點，同一家的表配同一家的節點最準；你買的是別家或自租，這欄只當城市對的量級錨。舉個數：從吉隆坡辦公室測新加坡節點，測出 90 ms，骨幹上吉隆坡到新加坡只有 9 ms，多出來的八十幾毫秒在骨幹之外。這一刀只告訴你差距不在骨幹裡，切到哪一段要靠 mtr 或多點同時測：先查起點段與走線，再輪到線路與節點。掛在雲大廠骨幹上的區域節點，這刀基本成立；自租的小節點，擁塞可能就出在機房自己的埠上，先按同時段對比排除。另外接入方式有正常水位——手機網路玩家比辦公室寬頻多一截是常態，先知道水位再談超沒超。怎麼一步一步查，五步實測清單列了順序，這裡不重複。
網上對照表也不是全無用處，想知道量級時它給了個錨。但無來源、無口徑、無法複核的數字，作為採購證據不合格。該停在這張有來源的表上，把剩下的空白留給實測。
怎麼把組合和時段排出來，遊戲伺服器節點選型服務有自查清單，這一步免費。
FAQ
延遲多少算正常？多少能玩？
分兩檔看。競技級：Riot 的電競工程口徑，最高級別可玩上限 40 毫秒、容差 ±5 毫秒。日常玩法：Riot 工程部落格以英雄聯盟為例，平均延遲 60 毫秒上下仍然好玩。這兩檔都是端到端的數，本文表格的骨幹值只是其中一段；拿你玩家實測出來的數字對檔位，才是有效的比法。
為什麼我實測出來的數字比表上高？
表上骨幹值是雲廠商在自家骨幹網內部測的，你的玩家封包先在電信商網裡走一段，經過的設備與轉手都比骨幹探測多。實測值減骨幹值，多出來的部分在骨幹之外；具體出在起點段、線路還是節點，要靠 mtr 或多點同時測來切。
台灣玩家該連香港還是東京？
台北到香港直線約 810 公里，往返物理下限約 8 毫秒；到東京 2,100 公里，下限約 21 毫秒。台灣玩家物理上離香港最近，第一輪先測香港；東京只在日韓玩家占有一席時才排進第一輪。
日本東部跟西部節點有差嗎？
Azure 骨幹實測，香港到日本東部（東京）49 毫秒、到日本西部（大阪）48 毫秒，差距對玩家無感。結構上的差別在東京：網路交換點更密，日韓互聯的選擇更多，選東京的理由通常在這裡，不在那 1 毫秒。
這張表的數字是實測嗎？口徑是什麼？
兩欄口徑不同。物理下限是算式值：直線距離乘光在光纖中的速度，哪家廠商都一樣；骨幹實測欄出自微軟官方的區域間往返延遲頁，Azure 骨幹網內部探測、每分鐘採樣取中位數，本文擷取日期 2026-09-19。區域與城市的對應（East Asia 對香港、Japan East 對東京等）逐項核對過微軟的區域清單頁。
東南亞玩家對這三個節點呢？
骨幹探測顯示雅加達到新加坡 17 毫秒、吉隆坡到新加坡 9 毫秒，東南亞玩家的就近節點是新加坡，不是東京。玩家分散在印尼、泰國、越南時，第一輪該測的是新加坡，香港做台港澳側的就近備援。
關於新星雲
這篇的每個數字背後都掛著來源與日期，算式給到能自己複算的程度。把一張表做到經得起逐項複查，是新星雲接案子時的做事方式，選節點如此，核帳單也如此。我是一人獨立營運的顧問與代客採購，不簽任何一家的代理；跟原廠往來的英文工單，也能替你開、替你追。想自己跑，材料都在正文裡。要人一起對數字，在 Telegram 開個話頭就行。
下限和量級都在上面的表裡，剩下的數字要從你玩家的裝置上跑出來。節點延遲評估承接排測試與讀數字。
相關閱讀
- 遊戲節點延遲不只看距離：封包走的是電信商買到的路：實測值為什麼對不上、五步實測怎麼排，這篇的下一步在這裡。
- 台灣玩家連香港還是新加坡？用 3 種玩家分佈決定遊戲節點：兩個節點之間的二元判斷，玩家分佈三檔怎麼切。
- 香港遊戲伺服器節點怎麼選？延遲、頻寬、防護與備援實測：把延遲放回整張評估表裡看，頻寬與防護一起算。
- 遊戲伺服器卡頓，不一定是規格買小了：節點選對之後，同一台機器上買到的核心是不是你的，這是另一半答案。
- 回到部落格總覽，看節點選型與成本拆解系列的其他文章。