游戏玩家对网络的抱怨很少是带宽不够，更多是动一下就顿。顿来自延迟和抖动，不是来自端口还有多少兆没用完。日本服务器、东京服务器和香港服务器之所以经常出现在游戏采购单上，是因为东亚玩家到这几个城市的海缆和陆地距离比较短。城市名本身不会降低延迟。真正起作用的是玩家从哪一家运营商进来，以及机器用哪一条线路把流量送回去。
把游戏服务器放在东京，适合玩家主要在日本、韩国，或需要一条相对稳定的亚太互访路径时。东京机房到日本本土运营商通常更直接，大陆玩家则要再经过一段跨境。把机器放在香港，适合玩家集中在华南和东南亚，大陆玩家的路径也往往更短。两边都有玩家时，不要指望一台服务器用一条线路同时讨好两个方向。常见的做法是：对战和房间状态放在玩家更多的那一侧，另一侧只放登录或匹配，必要时再加一个节点，而不是把带宽从 20M 升到 200M。
对局进程和线路要一起看
云服务器适合匹配、大厅和可以快速重建的无状态进程。独立服务器或物理服务器适合承载持续对局，因为对局进程不喜欢被邻居的处理器和磁盘突然拖慢。网络质量再好，机器自己在抖，玩家仍会觉得是线路不行。所以低延迟方案要同时看线路和机器隔离。物理服务器的价值在这里不是更贵，而是对局进程少受干扰。裸金属服务器如果仍然接在一条晚高峰会绕路的国际带宽上，隔离做得再好，返回路径照样抖动。
BGP 多线在游戏里的意义，是不同运营商的玩家可以走各自比较合适的入口。它不能把东京到华南的物理距离取消。晚高峰国际出口拥塞时，延迟会先升高，丢包随后出现，带宽图却可能仍然很空。这时加带宽没有用。换一条更可控的路径，或者把节点挪到玩家一侧，才对得上症状。只比较日本服务器和香港服务器哪一个标题更常被搜索，不看玩家分布，买到的是搜索词，不是时延。
用玩家的晚高峰做样本
验收要用玩家的网络，而不是在机房里两台机器互 ping。选工作日晚高峰，从日本、香港和大陆主要运营商分别进入同一局，记录延迟、抖动和丢包。语音和操作对抖动比对平均延迟更敏感。平均延迟 40 毫秒、抖动经常跳到 200 毫秒，比稳定的 70 毫秒更难打。样本要留下运营商和时间，避免下次扩容时只记得上次选了东京。美国服务器可以服务北美玩家，但不要把它的跨洋延迟拿来和东京到日本本土的延迟比高低，那是两组用户，不是同一条线路的优劣。
如果暂时只能买一个节点，就放在付费玩家更多的城市，把另一个方向的匹配放到轻量的云服务器上，并明确写清跨机房同步的是房间结果还是每一帧操作。每一帧都跨城同步，延迟会被架构自己加上去，线路再好也补不回来。等主节点的晚高峰数据稳定之后，再为第二组玩家加日本服务器或香港服务器。同时铺开两个半成品，出了卡顿很难知道该查哪一条线路。
房间人数上来之后，带宽才会重新变成约束。几十人的实时同步，加上语音，仍然常常吃不完一条很大的端口，但会吃不消共享带宽里的突发排队。独享带宽在这里买的是对局期间速率不被邻居占用，不是为了把测速跑到端口上限。共享池在别的租户传大文件时，游戏的小包会先感到抖动。这个症状和地理距离造成的稳定延迟不一样：距离是每局都在，共享排队是一阵一阵的。
版本更新和登录排队会在开服当晚把流量堆到匹配机器上，对局服务器未必同时变忙。匹配可以放在云服务器上横向加开，对局仍留在原来的物理服务器和原来的线路上，避免为了下载补丁去更换玩家已经测过的入口。补丁文件放到单独的下载地址，用国际带宽或对象存储发出，不占用对局的独享端口。这样日本服务器或香港服务器上的延迟样本，不会被开服下载冲掉。
游戏采购单上建议分开写四行：节点城市、玩家所在运营商、独享还是共享、晚高峰延迟样本。带宽数字只保留对局流量真正需要的那一档。多数对局吃不完很大的端口，却吃不消一条抖动的返回路径。城市可以写香港或东京，线路方向和样本时间必须写在城市旁边。没有样本的低延迟，只是标题。