服务器连接诊断
WinMTR（网络诊断工具）
Windows：
下载、解压并运行 WinMTR。
在“Host”文本框中，输入格式为 c[服务器编号].tankionline.com 的服务器名称之一；例如，第五台服务器的名称看起来像 c5.tankionline.com。
按下“Start”按钮，然后让程序自行运行至少 10 分钟，最好是半小时。在此期间，最好尝试进行游戏，以确保你捕捉到了最初的所有统计问题。
要完成统计数据的收集，请点击“Stop”。要将其插入论坛，请点击“Copy text to the clipboard”按钮将结果复制到剪贴板；然后，将数据粘贴到文本消息中（最好使用 [code=auto:0] .. [/ code] 标签将其框起来，以使其呈现表格查看格式）。
Linux：
Linux 用户可以使用 WinMTR，它应该已经存在于计算机系统中。选择服务器名称的建议以及统计数据收集过程与 Windows 操作系统用户相同。
其他网络扫描器（Mac）
Mac OS X 用户无法使用 WinMTR，因此需要在其设备上运行替代程序。
解读： 如果你发布了一个包含此信息的新主题，请确保在“问题与解决方案”论坛中发布，这是放置结果的最佳位置。在项目的参与者中，有能力出众的人愿意在这些问题上提供帮助。如果你想自己分析结果，那么首先查看路由的最后一行（这实际上是游戏服务器）的丢失情况（“Loss%”列）；此阶段的读数不应超过 1.2%，平均往返时间（“Avrg”）不应大于 200 ms，最大值（“Worst”）不应超过 500 毫秒。理想情况：零丢失，平均延迟不超过 100 ms，且最小值（“Best”）和最大值（“Worst”）与平均值的偏差不超过 50%。如果存在异常大的丢失或延迟，请回顾得分更好的测试，并注意你所看到的差异。
命令提示符
测试延迟：
“延迟” - 在计算机网络中，信息包从客户端传输到服务器，再从服务器返回到客户端所需的时间。
延迟是服务器连接最重要的特征。它决定了你接收有关其他玩家位置和行动的当前信息的速度，以及你向服务器发送行动的速度。高且不稳定的延迟通常会导致卡顿——数据传输的长时间延迟。
可以使用标准 Windows 操作系统检查延迟。为此，运行 Windows 控制台（命令行），并使用 ping 命令。你可以通过几种不同的方式运行命令行。其中一种是点击“开始”按钮，从菜单中选择“所有程序”，然后在其中查看“附件”。在标准程序列表中会有“命令提示符”。另一种方式——再次点击“开始”按钮，选择“运行”菜单，在打开的窗口中，在“打开”行中输入“cmd”并点击确定。最后，最简单的方法——使用快捷键 Win + R。在命令提示符下，输入 ping 命令，后跟一个空格和服务器地址。
例如，第五台服务器的延迟测试如下所示：ping c5.tankionline.com。按 Enter 键并监控结果。
解读：
当你对服务器进行延迟测试时，你的结果通常如下所示；
- 传出数据包的大小（字节，默认为 32 字节）；
- 响应时间（毫秒）；
- TTL（生存时间） - 计算机等待服务器响应的时间。
默认情况下，会向服务器发送四个数据包，然后显示测试结果；
- 传输的数据包总数；
- 接收到的数据包数量；
- 丢失的数据包数量；
- 数据丢失百分比（降级）；
- 数据包的最大、最小和平均往返时间。
如果你在发送数据包后没有收到所有数据包，或者文件传输的最大和最小时间之间的差异太大，这可能是网络出现问题的迹象。
有时，自动杀毒软件或防火墙会导致数据包传输（尤其是大型数据包）出现问题，因此在检查所有内容之前，最好在它们的界面控件中禁用 ping。
0 到 100 之间的延迟以及 20% 范围内的文件速度差异（彼此之间）被认为是正常的。
路由追踪：有时需要了解游戏流量从你到服务器所经过的路由。在用户/客户端的某个部分出现大规模问题时，有必要识别该路由上的问题区域。
你可以使用 tracert（Windows）或 traceroute（Linux）工具来执行此操作。tracert 程序与 ping 程序一样，从命令行界面运行。点击“开始”按钮，选择“所有程序”（或早期操作系统版本的“程序”），在其中查看“附件”——在标准程序列表中，点击“命令提示符”。或者点击“开始”按钮，选择“运行”项目，在“打开”窗口中输入 cmd 并点击确定按钮，或按 Enter 键。你也可以使用快捷键 Win + R。在打开的窗口中，输入 cmdlet tracert c5.tankionline.com（它将追踪到第五台服务器）并按 Enter 键。输入地址。
因此，我们建立了到达终点的路由。在命令提示符窗口中，实时追踪输出中会显示中间节点的名称和 IP 地址，响应时间将以毫秒为单位显示。
解读：在路由中响应时间最小的部分，传输进行得最快。这意味着通道没有过载，并且基本上没有任何值得注意的干扰。
然而，在响应时间超过标准数量的地方，我们得到了“请求超时”的结果，这相当于数据包的丢失。
因此，可以确定链条中的问题所在。如果数据包没有到达目的地——那是目的地内部的问题。如果链条在中间断开，则某些中间路由器存在问题。同时，在另一台计算机上，或在不同的路由上（如果存在），可以访问该站点。如果数据包超出了你的 ISP 网络，那么问题就在那里。
请在主题中发布你的统计数据，或联系版主，以便我们能够分析它们并找到最适合你的解决方案。