我们捕获了什么——以及没有捕获什么
这些数字已经定稿。官方服务器已关闭，所以无法再捕获新的流量，本页内容也不会再变化。
为了在 Blades 关闭前重建它，我们必须记录游戏如何与服务器通信。我们特意只捕获最少内容——只捕获 Blades 及其竞技场服务器，从不捕获任何人手机上的其他内容。下面公开说明我们具体怎么做。
318 名贡献者报名帮助保存这款游戏。他们通过我们路由的内容，就是留存下来的全部。
我们有意只路由最少内容
VPN本可以把一部手机的全部流量都发给我们。我们刻意没有这么做。我们逆向了游戏自己的匹配协议，以便精确地只把 Blades 使用的服务器列入白名单——其他一切（银行、消息、浏览、所有其他应用）都留在正常连接上，完全不碰。
*.blades.bgs.services——登录、角色、匹配、资源 CDN- 竞技场对局可能运行的14 个区域所对应的 AWS GameLift 地址段
- 设备上的其他一切完全绕过 VPN
- 那些确实路由到这里的非 Blades HTTPS 会被直接透传——我们无法解密它们，只解密
blades.bgs.services
为什么竞技场需要不止一个 IP
竞技场 PvP 运行在 Amazon GameLift 上。对局前，游戏会 ping 14 个 AWS 区域并报告延迟；随后 GameLift 会把对局放到最快且有容量的地区，并给手机一个每场对局都不同的服务器 IP。没有一个固定的竞技场 IP 可以加入白名单。
所以，为了可靠捕获竞技场，我们路由了这 14 个地区的 GameLift 地址段——并且只路由这些。我们用三种相互独立的方式确认了这 14 个地区的准确列表（客户端内置端点表、它的延迟探测目标，以及我们捕获到的实时匹配请求），因此可以确信没有漏掉地区，也没有越界到不需要的地区。
完整 IP 列表以纯文本写入我们发放的每个.conf文件——打开一个，逐行阅读即可。
真实竞技场 ping，由游戏自身测量
大家过去常争论竞技场延迟。现在答案永久留下来了：Blades 对每个地区测得的真实延迟，来自28,100捕获到的匹配请求。测量位置来自我们的贡献者所在地（主要是欧洲和北美），所以最佳代表坐在该地区附近玩家可达到的现实下限；典型是所有样本的中位数。
| 地区 | 最佳 | 典型 |
|---|---|---|
Europe (London) eu-west-2 | 10 ms | 71 ms |
Europe (Frankfurt) eu-central-1 | 12 ms | 67 ms |
US East (Ohio) us-east-2 | 14 ms | 161 ms |
South America (São Paulo) sa-east-1 | 16 ms | 264 ms |
Europe (Ireland) eu-west-1 | 18 ms | 79 ms |
Asia Pacific (Seoul) ap-northeast-2 | 20 ms | 286 ms |
US West (N. California) us-west-1 | 20 ms | 204 ms |
US West (Oregon) us-west-2 | 20 ms | 191 ms |
US East (N. Virginia) us-east-1 | 21 ms | 139 ms |
Canada (Central) ca-central-1 | 21 ms | 143 ms |
Asia Pacific (Mumbai) ap-south-1 | 22 ms | 188 ms |
Asia Pacific (Tokyo) ap-northeast-1 | 22 ms | 283 ms |
Asia Pacific (Sydney) ap-southeast-2 | 23 ms | 312 ms |
Asia Pacific (Singapore) ap-southeast-1 | 23 ms | 223 ms |
竞技场什么时候最热闹？
根据全球前 100 名排行榜在两次观察之间奖杯增长的速度推断——所以它反映的是游戏最后几个月更广泛的玩家群体，而不只是我们。颜色越深 = 对局越多。时间为UTC.我们只能在贡献者打开排行榜时采样，所以覆盖并不完整，也仅限前 100 名玩家——这是真实信号，而不是完整普查。