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

匹配/区域分配错误 Wrong region assignment (matchmaking / GeoDNS)

原因 ID in-region-match · 主责 研发团队·服务器开发 · 配合研发团队·客户端开发, 运维团队·网络运维, 外部·外部

没有分到近的区域（region），被分到远区域的服务器，即使线路正常，也只有这个玩家 ping 一直偏高。

起因 GeoIP 数据错误，VPN，按队友平均 ping 给整个队伍分配，人数不够时扩大到远区域的规则，按 DNS 解析器位置分配 → 结果明明有近的区域，却连到了海对面区域的服务器 → 画面表现 在多个区域部署服务器的游戏中，只有我（或只有我们队伍）ping 一直偏高，出现操作延迟、拉回、吞技能

症状: 操作延迟, 拉回, 吞操作/回档
因素: 延迟
谁会遇到: 只有我, 特定地区/运营商
何时出现: 一直, 刚登录/维护结束后
负责方: 主责 研发团队·服务器开发 · 配合研发团队·客户端开发, 运维团队·网络运维, 外部·外部
研发团队要做的事: 服务器：用客户端测得的各区域 ping 来分配，不依赖 GeoIP；扩大到远区域的规则要设 ping 上限；队伍除了看平均值，也要看 ping 最高的队友；把分配的区域和当时的 ping 记入日志。客户端：用 UDP 测各区域 ping，随匹配请求一起发送；在界面上显示所连区域和 ping；提供手动选择区域的选项。
运维团队要做的事: 如果用 DNS 选区域，确认权威 DNS 支持 EDNS Client Subnet（玩家使用的解析器不发送时，会按解析器位置分配）；定期更新 GeoIP 数据库；给各区域服务器的接入日志标上 GeoIP 国家和 ASN，找出连到远区域的国家和运营商。
外部要做的事: 引导玩家关掉 VPN、游戏加速器后重新连接；引导使用公司 DNS、海外 DNS 的玩家改用运营商 DNS 试试；请 GeoIP 服务商更正错误位置。
数值参考: 首尔玩家没分到东京而分到美国西部区域时，ping 从约 30 ms 升到约 130 ms。GeoIP 在国家级别准确率约 99.8%，城市级别即使在美国，落在 50 km 以内的比例也只有约 66%；使用 VPN 时，查到的会是 VPN 服务器的位置。
监控图上: 仅部分偏高 · 各玩家的 RTT（ping），分配区域的分布
查看位置: 给各区域服务器接入记录（负载均衡器访问日志、VPC 流日志）中的客户端 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 上限从 50 ms 放宽到 100 ms、200 ms 的配置例子。开着 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%，美国城市级别（50 km 以内）约 66%；使用 VPN 时得到的是 VPN 服务器的位置，看不到最终用户的位置；移动网络 IP 在大范围内使用，无法得知精确位置；数据库需要持续更新；可以申请更正
FlexMatch rule types AWS
延迟规则（maxLatency）看各位置的玩家延迟，队伍默认用队友平均值（partyAggregation avg）；队列也可能把玩家放到不符合延迟规则的区域
Create a player latency policy AWS
放到所有玩家平均延迟最低的位置，但延迟极端的玩家也会被放进去；举了把 ping 上限从 50 ms 放宽到 100 ms、200 ms 的策略例子
Amazon GameLift Servers UDP ping beacons AWS
游戏客户端用每个托管位置的 UDP 端点测延迟，用于放置和匹配，比 ICMP ping 更接近真实游戏流量
Azure network round-trip latency statistics Microsoft Azure
以首尔（Korea Central）为起点的实测往返中位数：东京（Japan East）29 ms，美国西部 124~136 ms
Flow log records AWS
VPC 流日志记录中的 srcaddr：入站流量时为发送方 IP 地址

匹配/区域分配错误 Wrong region assignment (matchmaking / GeoDNS)

出处

相关原因

同一层：L13 服务器架构与运维

其他层中同样导致“操作延迟”的原因