한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

配對與區域分配錯誤 Wrong region assignment (matchmaking / GeoDNS)

原因 ID in-region-match · 主要負責 遊戲開發團隊（伺服器開發） · 協同遊戲開發團隊（用戶端開發）, 基礎設施團隊（網路基礎設施）, 外部（外部）

沒被分到近的區域、卻被分到遠方區域的伺服器時，即使線路正常，也只有那位玩家的 ping 一直偏高。

為什麼 GeoIP 資料錯誤、VPN、以隊友平均 ping 分配整個隊伍、人數不足時擴大到遠方區域的規則、依 DNS 解析器（resolver）位置分配 → 於是明明有近的區域，卻連到海外區域的伺服器 → 畫面上 在多個區域設有伺服器的遊戲中，只有我（或只有我們隊伍）ping 一直偏高，出現輸入延遲、拉回、技能被吃

症狀: 輸入延遲, 拉回, 吃指令／回檔
因素: 延遲
誰會遇到: 只有我, 特定地區／電信業者
何時: 一直都有, 剛登入／維護剛結束
負責單位: 主要負責 遊戲開發團隊（伺服器開發） · 協同遊戲開發團隊（用戶端開發）, 基礎設施團隊（網路基礎設施）, 外部（外部）
遊戲開發團隊要做的事: 伺服器：以用戶端實測的各區域 ping 取代 GeoIP 來分配，擴大到遠方區域的規則要設 ping 上限，隊伍除了平均值也要看最高的隊友 ping，把分配的區域與當時的 ping 記錄到 log。用戶端：用 UDP 測量各區域 ping 並隨配對請求一起送出，在畫面上顯示連線的區域與 ping，提供自行選擇區域的選項。
基礎設施團隊要做的事: 若用 DNS 選擇區域，確認權威 DNS 是否支援 EDNS Client Subnet（玩家使用的解析器不傳送時，會依解析器位置分配），定期更新 GeoIP 資料庫，在各區域伺服器的連線 log 加上 GeoIP 國家與 ASN，找出被導向遠方區域的國家與電信業者。
外部要做的事: 請玩家關掉 VPN、遊戲加速器後重新連線看看，請使用公司或海外 DNS 的玩家改用電信業者的 DNS 試試，向 GeoIP 業者申請更正錯誤的位置。
數值參考: 首爾玩家沒被分到東京、而被分到美國西部區域時，ping 會從約 30ms 增加到約 130ms。GeoIP 以國家為單位約 99.8% 正確，但以城市為單位，即使在美國，落在 50km 內的比例也只有約 66%；使用 VPN 時，查到的會是 VPN 伺服器的位置。
圖表上: 只有部分偏高 · 各玩家的 RTT（ping）、分配到的區域分布
查看位置: 在各區域伺服器的連線紀錄（負載平衡器存取 log、VPC Flow Logs）中的用戶端 IP 加上 GeoIP 國家與 ASN，依國家、電信業者統計連到哪個區域。若是單一玩家，比較該玩家實際連線的區域，以及到近的區域實測的 ping（由玩家測量，或從該區域伺服器對玩家 IP 執行 mtr）
符合的跡象: RTT 高的玩家或國家沒連到近的區域、而是連到遠方區域，對近的區域實測的 ping 很低
不符合的跡象: 已正確分配到近的區域但 ping 仍高時，是繞遠路的路由或該玩家的線路、Wi-Fi 問題
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）
深入了解: 用 DNS 選擇區域的方式（依地理位置、延遲的 DNS），推測位置時看的是玩家所用 DNS 解析器的位址。解析器若不支援傳遞部分玩家位址的 EDNS Client Subnet，使用公司 DNS 或遠方 DNS 的玩家就會以解析器所在地為準來分配。配對系統也可能以隊友 ping 的平均值判斷整個隊伍，或在等待太久時放寬 ping 標準，分配到遠方區域。AWS GameLift Servers 對隊伍 ping 的預設基準也是平均值，並舉了把 ping 上限從 50ms 放寬到 100ms、200ms 的設定為例。開啟 VPN 的玩家可能同時遇到經過中繼伺服器而增加的延遲（「經由 VPN／遊戲加速器」）與被分配到遠方區域，可以看關掉 VPN 重新連線後分配到的區域是否改變來區分。附近根本沒有區域、只能連到遠方區域的情況，在「傳播延遲（物理距離）」說明。

出處

RFC 7871: Client Subnet in DNS Queries IETF
依位置給出不同回答的 DNS 會以送出查詢的解析器位址推測位置，使用離玩家很遠的集中式解析器時會得到不適當的回答。以 EDNS Client Subnet（選用功能）傳遞部分玩家位址
How Amazon Route 53 uses EDNS0 to estimate the location of a user AWS
解析器不支援 edns-client-subnet 時，會以解析器的位址推測玩家位置，依解析器位置回答（地理位置路由與延遲路由皆同）
Geolocation accuracy MaxMind
國家層級約 99.8%、美國城市層級（50km 內）約 66%；使用 VPN 時得到的是 VPN 伺服器位置；行動網路 IP 在大範圍地區共用，無法得知精細位置；資料庫需要持續更新；可申請更正
FlexMatch rule types AWS
延遲規則（maxLatency）看各位置的玩家延遲，隊伍預設使用隊友平均值（partyAggregation avg），佇列也可能把玩家放到不符延遲規則的區域
Create a player latency policy AWS
放到所有玩家平均延遲最低的位置，但延遲極端的玩家也會被放入；把 ping 上限從 50ms 放寬到 100ms、200ms 的政策範例
Amazon GameLift Servers UDP ping beacons AWS
遊戲用戶端對各託管位置的 UDP 端點測量延遲，用於放置與配對，比 ICMP ping 更接近實際遊戲流量
Azure network round-trip latency statistics Microsoft Azure
以首爾（Korea Central）為起點的實測往返中位數：東京（Japan East）29ms、美國西部 124～136ms
Flow log records AWS
VPC Flow Logs 紀錄的 srcaddr：傳入流量時為送出端的 IP 位址

配對與區域分配錯誤 Wrong region assignment (matchmaking / GeoDNS)

出處

相關原因

同一層：L13 伺服器架構與維運

同一症狀（輸入延遲）在其他層的原因