TryHackMe OpenVPN 配置优化指北
TryHackMe OpenVPN 配置优化指北
前言
TryHackMe 是一个好平台，我已经在上面玩了有三个月的时间了，Free Path 走完之后就开了个会员，跟着把红队路线做完了，同时还完成了个 Offensive Pentesting。现在没开会员了，在刷免费的房间，刷完就转战 HTB 咯~
在我刚开始学习 Free Path 的时候，每天都是用的 Attack Box 1 小时的免费时长，把每个前置任务点做完之后才敢开机器开打（1h 一天是真的不够玩）。免费路线刷完了，就开了个会员开始付费路线的学习。在学习的过程中愈发觉得 Attack Box 不够用，于是就转战本地的攻击机，选的 Kali，当然你用别的比如 Parrot 也行。
THM 为了安全考虑，是不会开放他们的机器到公网的，因为那些靶机丢到公网分分钟都会被橄榄，但是用本地的攻击机的话，是需要连接到 THM 的内网的，THM 提供了 OpenVPN 这种方式接入他们的内网。
通过 OpenVPN 接入 THM
THM 提供了一个房间来讲述配置如何配置 OpenVPN，但是对于我们国内用户来说是不适用的。
由于众所周知的原因，OpenVPN 的流量特征已经被精准识别了，如果直接使用下载下来的配置文件，通常在使用一段时间后你会发现连接被掐了，或者根本连不上，报错 TLS handshake failed，如下图。
2025-09-20 00:38:23 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2025-09-20 00:38:23 TLS Error: TLS handshake failed
所以你需要给 OpenVPN 再嵌套一层代理，让你去往 THM 服务器的流量经过你的代理节点，这就是我们要做的。
我的使用方案
首先分享一下我的使用方案吧，我的主力环境是 Windows，Kali 攻击机是跑在 Windows 里面的。
Windows 的 OpenVPN 用 EU-VIP-2，连接跑在 Windows 上的 Clash。
Kali 里面的 OpenVPN 用 EU-VIP-1，连接跑在 Windows 上的 Clash。
这样的话，主机和攻击机都能作为单独的 IP 连进 THM 的内网，如果仅仅只是主机上单独跑一个 OpenVPN 的话，攻击机用主机 NAT 之后的网络，有些地方会挺受限的（需要单独配置端口转发），所以最好是每个端都单独跑一个 OpenVPN。
Windows 配置
我使用的代理软件是 Clash Verge，如果你和我是一样的，且你没有改动配置文件，你可以照抄我的配置。
首先需要找到你的代理软件的设置，打开局域网连接（或者是 Allow LAN 之类的设置），这是让你局域网的其他机器能连接到你的 Windows 机器的必要条件，然后在找到你的端口设置，记住他（默认是 7897），下图已圈出需要注意的地方。
其他代理软件也是类似的设置，如下是 V2rayN 的配置，记住监听的端口号就行。
配置好了之后，就是配置 OpenVPN 本体了，首先右键他的图标 -> 选项 -> 代理，选择手动设置，地址填写你电脑的 IP（本机填写 127.0.0.1），端口就是你上面记住的监听端口，我的设置如下。
点击确定即可，至此，Windows 端的 OpenVPN 配置已经结束，右键托盘图标，选择导入的配置文件连接即可。
若连接成功，会弹窗提示连接成功，以及你分配到的 THM 内网 IP，托盘图标的显示器背景变绿。
可以打开 http://10.10.10.10 测试是否连接成功，如果成功连接，会看到你的内网 IP 和一个 flag，如下图所示：
同时你也可以 ping 10.10.10.10，查看你电脑到 THM 服务器的延迟，通常 200ms 以内就算比较好了。如果你的延迟高于 300ms，后面会告诉你怎么解决。
Linux(Kali) 配置
我的环境是 VMware + Kali，如果你的和我一样，可以照抄。
VMware 下载地址：423down - VMware Workstation PRO_v17.6.4_正式版
我假定你已经导入好虚拟机，并且已经成功开机了，如果你没有完成到这一步，请自行解决。
获取通信网卡 IP
在 VMware 的主界面，点击编辑 -> 虚拟网络编辑器
打开之后选择 NAT 类型的网卡，找到子网 IP 这一项，记住他。
在默认设置下，你的电脑的给 VMware NAT 网卡的 IP 是 192.168.x.1，比如说我这里显示的是 192.168.244.0，我默认的 NAT 网卡的 IP 就是 192.168.244.1，你也可以通过多种方式去查看他，比如说去控制面板，或是用 ipconfig 等。
如果你是桥接模式，就是你桥接的那张网卡在你电脑上获取的 IP。我们的最终目的是找到虚拟机能和你电脑通信的网卡的 IP，从而能连接到我们宿主机上的代理软件。
配置 Kali 上的 OpenVPN
我们目前掌握的信息：宿主机和虚拟机通信模式是 NAT，NAT 网卡的 IP 是 192.168.244.1，代理软件的监听端口是 7897。
启动虚拟机，首先你需要把你的从 THM 获取到的配置文件复制到你 Kali 的随便一个目录下，如果复制不了，一般是 vmware-tools 有问题，如果你是直接用官方提供的 Kali VMware 镜像是不会出现这个问题的。
打开你刚刚复制进去配置文件，增加下面这一行，这是连接到你主机上代理软件上的 socks 监听端口的命令。
1
socks-proxy YOUR_IP_ADDRES 7897
或者你可以用这段命令，直接写入到你的配置文件中，这一行在哪无所谓，只要在配置文件中，就能成功被应用。
1
echo 'socks-proxy YOUR_IP_ADDRESS 7897' >> ./YOUR_CONF.ovpn最后用这行命令启动在 Kali 上的 OpenVPN。
1
sudo openvpn ./YOUR_CONF.ovpn成功连接会看到如下提示：
可以看到 OpenVPN 自动帮你加了去往靶机 IP 段的路由表，这时你就可以 ping 10.10.10.10 测试一下看通不通。
可能碰到的问题
到这里，如果你碰到了如下两个问题，可以参照着解决：
- OpenVPN 连不上，提示
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)- 你用的节点不支持 UDP，需要更换支持 UDP 的节点
- 检查代理软件的监听端口
- 检查你的代理软件的规则，是否开了仅常用端口走代理。THM 用的端口是 1194，需要自行修改规则，后文会附解决办法
- Windows 能连上，但是 Linux 连接不上
- 检查你的虚拟机是否能正常上网，
ping baidu.com - 检查代理软件是否打开了 Allow LAN（允许局域网连接）之类的选项
- 检查你本机和虚拟机通信的网卡，确定网卡 IP 正确
- 检查代理软件设置的监听端口
- 检查你的虚拟机是否能正常上网，
代理规则设置
一般来说，大多数的配置文件都会加入一个 🐟 漏网之鱼 类似这样的规则组去兜底访问非标端口需要代理的场景，请你检查这个代理组是否设置走代理。如果你通过切换解决了，那恭喜你，不用跟着下面操作了。
编辑你的配置文件，找到 rules: 开头，加上这一行。
1
- DST-PORT,1194,🚀 节点选择
最后面的 🚀 节点选择 是你的代理组的名字，如果你的配置文件和我不一样，需要对应着修改，不然会报错。
还有要注意的是，你修改过的 Clash 配置文件可能过一会就被替换掉了，这是自动更新订阅的原因，可以改成不自动更新订阅。也可以使用订阅聚合配置文件进行使用，这是我的一个模板。网上教程很多，请自行查阅修改。
关于其他软件的设置，请自行查阅解决，在此不赘述。
网络优化
首先想要拥有良好的打靶体验，你需要低 + 稳定的 RTT（round-trip time）。通过本节的学习，你会得到 200ms 以内的 RTT，如果你的延迟是这个数，或者你觉得你现在的体验完全足够你使用，可以不用往下看了。
IP 路由原理
在深入探讨如何优化网络之前，我们首先需要理解一个核心概念：路由。
很多人误以为，网络连接是简单的“点对点”直连。然而，真实的互联网世界要复杂得多。你的网络数据包从你的电脑出发，抵达 TryHackMe 的服务器，通常需要穿越多个国家，甚至跨越多个大洲。这个过程就像是一封信件在国际间旅行，它不会直接从你家飞到目的地，而是会经过多个邮政中转站。在网络中，这些“中转站”就是路由器（Router），而路由器之间如何选择路径，则是由路由协议决定的。
其中最重要、最复杂的协议就是 BGP（Border Gateway Protocol）。简单来说，BGP 就像是全球各大网络运营商（例如中国电信、中国移动、AT&T 等）之间达成的一套“交通规则”，它决定了数据包如何跨越不同的网络，选择最佳的路径。运营商之间通过 Peer（对等互联） 的方式交换网络路由信息，共同构成了整个互联网的骨干。
但问题就出在这里：运营商出于商业考量，Peer 线路的质量和优先级并不一致。你的数据包很可能因为运营商之间的利益关系或网络配置，被安排了一条“绕远路”。例如，你身在中国，想要访问欧洲的 TryHackMe 服务器，理想情况下应该走一条最近的路径。但实际情况可能是，你的数据包先绕到了日本，再去了美国，最后才抵达欧洲，走了很多不必要的跳数（Hop），导致延迟居高不下。
CN2、CMI
- CN2（ChinaNet Next Generation）： 这是中国电信旗下的高端骨干网络。与传统的中国电信 163 骨干网相比，CN2 的路由节点更少，网络拥塞更低。
- CMI（China Mobile International）： 这是中国移动的国际出口网络。近年来，CMI 线路的质量有了显著提升，尤其是在连接香港、日本、新加坡等地的国际方向上，表现非常出色。
我们的最终目的是：用最优的路由，把去靶机的路拉直。
接入区域选择
美东靶机
THM 在 2025 年 8 月的时候悄悄上架了 N. Virginia（弗吉尼亚州） 的靶机，也就是 AWS 的 us-east-1 ，你可以在你的账户设置里面设置靶机区域。
从大陆到美西最快是 110ms 左右，而美西到美东需要 60ms（参考 AWS Latency Monitoring），加起来就是 170ms 打底了，这还是在理论情况下。在我实战中，打这个区域的靶机 RTT 最快是 220ms。
所以这个新上架的区域就不考虑了，我们能选的只有欧洲区域的靶机，经过合理的优化达到 180ms 左右是不难的。
THM 接入节点
THM 的 OpenVPN 提供了以下地区的接入节点：
| 名称 | 区域 | AWS region |
|---|---|---|
| EU | 欧洲 - 爱尔兰 | eu-west-1 |
| US-West | 美国 - 弗吉尼亚州 | us-east-1 |
| AU | 澳洲 - 悉尼 | ap-southeast-2 |
| IN | 印度 - 孟买 | ap-south-1 |
偷偷提一嘴，THM 的 OpenVPN 支持多个配置文件同时连接，但是不支持单个配置文件多个客户端连接。每个配置文件分配的 IP 都是不同的，可以试一下那几个配置文件有没有分到好记的 IP，就用那个配置文件作为主力使用（EU 有 6 个配置文件）。
测试 RTT
你可以通过 AWS Speed Test 测试你本地到 AWS 的每个区域的延迟。
测试到 eu-west-1 的延时 - 10ms 左右就是你最终到靶机的延迟，我也不知道为什么这个网站测试出来的 RTT 偏大，反正最终你连上之后 ping 10.10.10.10 就是了。
线路优化原理
在开头讲述了路由这个概念，我们现在的目标就是通过对线路的分析，挑选出一条最适合我们的路。
线路分析
欧洲的靶机是在 eu-west-1，也就是爱尔兰，而我们国内到欧洲比较好的线路方案有两种：
京德专线/优化线路 120ms 左右
这是北京联通 -> Misaka 德国法兰克福的优化线路，联通移动最快 120ms，电信慢一些 160ms。
使用 https://www.itdog.cn/ 测试
专线和优化线路的还有一个区别就是，专线不需要考虑出去的是哪条线路，只需要考虑国内 -> 入口机器的延迟即可。而优化线路看是哪家运营商，走哪家运营商的优化线路，差异比较大，不过也可以套一个前置解决。
粤港入口 -> 香港 RETN -> 欧洲，150ms
算上入口物理延迟 160ms 左右，通过 RETN 的 Looking Glass 测试出来香港到爱尔兰是 173ms。
根据这两条基础线路，针对不同区域的人群就有了不同的推荐。
区域推荐
华北区域
如果你在北方，不管是从物理链路还是实际线路，就只能选择京德方案了。我们的最终目的都是想把线路拉直，也就是到我们目的地走最短的线路。
理论极限：北京 -> 德国 120ms + 德国 -> 爱尔兰 25ms = 145ms
华中华东区域
推荐京德，因为离北京近。
理论值：华中 -> 北京 10 - 20ms + 北京 -> 德国 120ms + 德国 -> 爱尔兰 25ms = 155 - 165ms
华西区域
据说有乌鲁木齐的出口，但是我没见到过，这一片还是推荐京德。
理论值：华西 -> 北京 20 - 40ms + 北京 -> 德国 120ms + 德国 -> 爱尔兰 25ms = 155 - 175ms
广东/华南
但是你在广东的话，情况就不一样了，因为 广东 -> 北京 30ms + 京德 120ms + 德国 -> 爱尔兰 25ms = 175ms
下图是优化线路的京德，可以看到广州 -> 北京的 RTT 是 35ms，到德国 175ms 左右，再从德国到爱尔兰的靶机接近 200ms 了（我实测 180 - 200ms 左右，看时段）。
而走香港 RETN 的话，可能是 本地 -> 粤港入口 10 - 5ms + 香港 -> 爱尔兰走 RETN 173ms = 178ms，两者的 RTT 差不多，所以不如走有优化的 RETN 了（更有性价比+更快）。
湖南广西这类地区的话，就看你自己的选择了，其实位置挺尴尬的，选京德和香港 RETN 都可以。
并不是优化线路就一定好
当你获得了一条看似完美的优化线路，你可能会发现延迟（RTT）很低，但连接依旧不够稳定，时常感到卡顿。这背后一个常常被忽视的因素，就是 Jitter（网络抖动）。
尽管大多数线路会尽量优化这项指标，但是由于各家的预算不一，可能会碰到入口/线路拥塞，导致卡顿。所以仅仅追求低延迟是不够的，你还需要确保这条线路能够提供稳定、低抖动的传输质量。
机场/线路选择
有了前文的铺垫，相信师傅们对如何优化到靶机的网络线路已经有了一定的了解了。
对于师傅们我更建议是选择一个好的机场，可以参考沪日&中欧 天梯表去选择机场，当然单独买线路或者 VPS 搭也是可以的。对我来说我比较适合机场，因为折腾这些需要大量的时间还有钱。（摊手
如何选购
因为前面打靶机卡死我了，我硬是怼着美东 230ms 的延迟打了半个月。最近查了大量的资料，也找了很多家的测评，总结了下面的选购经验：
看测速图德国、荷兰、伦敦的节点，如果有爱尔兰的更好，靶机就在家门口。
同时注意测速后端地区，如果和你的地区和运营商一致，那么恭喜你，这就是你的真实体验。如果地区不一样但是你和他的物理距离不远，并且是同一运营商。比如说测速机是东莞电信，而你用的是阳江电信，这也能作为你的参考。因为这些线路的好坏受运营商影响非常大，所以必须要特别注意。
找到和你类似地区/运营商的测速图了之后，主要是看里面的 RTT 参数，这就是决定你的体验的关键，比如说下图的 RTT 是 124，Jitter 是 4.9，很优秀了。
| 地区 | RTT 下限 |
|---|---|
| 华北地区 -> 德国、荷兰、伦敦 | 160 |
| 华东地区 -> 德国、荷兰、伦敦 | 180 |
| 华南地区 -> 德国、荷兰、伦敦 | 200 |
有些测速图是没有 RTT 标准差这一项的，下面的图是连通性测试，大多你能看到的测速图都是测速+解锁流媒体测试。
还有要注意的就是测速的时间了，一般晚上 18 - 24 这个时间段是高峰期，测速时间在这个时间段更能看出来实力。
最后一点，线路是有时效性，可能用着用着线路就因为不可抗力的原因切了也有可能，建议在购买的时候不要买长期的，建议月/季付，确定稳定再长期购买。
个人体验
下面是我体验过的，还算 OK 的机场。
FlowerCloud #专线
🌷有京德专线，国内通过北京华为云接入。延迟很好看，但是 UDP 的线路有问题，延迟很高还丢包。TCP 没问题，THM AD 域的网络的配置文件是走的 TCP 1194 过去的，可以低延迟愉快玩耍 AD 域，实际体验 < 180ms + 稳。
还有就是有半个 RETN 优化过的香港，爱尔兰 -> RETN -> HKIX 165ms，实际体验 < 195ms + 稳。
注册链接：flowercloud
ctc02 #直连优化
ctc02 就是我前面放的 MTR 图的那家，德国节点用的 Misaka 优化过的线路，走京德，如果你在北京的话应该很爽了，150ms 打靶不是梦。实际体验 180 - 200ms + 稳 / 高峰期没法用。
而他的其他线路就比较没用了，他全是直连优化线路，线路质量挺好的。不过我主力是花云，所以我基本用不上。
这家挺便宜的，42块钱能买一年。我是买来测试德国节点用的，最主要的问题是高峰期 RTT 会爆炸💥，当个备用用还是 OK 的。
注册链接：ctc02 优惠码：20%OFF
顶流线路
我在前面提到的天梯图的群里潜伏，从他们3月13日的讨论中找到了如下信息：
这张图可以看出来这几家都挺厉害的，都是一线机场，都是买不起的（
注意测速点是在北京，而里面的节点是走的中转，实际的 RTT 要减去 北京 - 对应地区的 RTT。
其价格分别是：Nex 55/月，Dler 999/年，TAG 160/季，AIFUN 18.8/月，MESL 155/年。
这之中 TAG 和 MESL 的节点覆盖是最全的，有爱尔兰节点。
鹿语云 北京测速
看到一个非常牛逼的机场，但是听说挺贵的。
在他们讨论完的两天后就被清退了hhhh，3月13讨论的，3月15亖的。
花云 北京测速
花云 深圳电信 - 荷兰
绿叶 深圳电信 - 荷兰
总结
如果你是懒狗，又不太在意预算的话，无脑看天梯图，挑一家买就完事。极致优化线路/专线的价格不是一般机场能承受的起的，而对这种线路有需求的人又是少数，基本上小机场不会上这种线路，只有大机场才有，所以相应套餐的价格也是偏高的（一分钱一分货）。
鹿语云已经下架了，那个 $d 不知道是什么玩意，找了一下也没有有价值的信息
上榜的价格如下：
- VikingLinks 35/月
- xipcloud 400/年
- tag 160/季
- 花云 128/年
上面这四家我都会买一遍体验一下，如果花云能解决 UDP TCP RTT 不一致的问题就好了（我已经发了工单），我猜是 UDP 过去走了不同的线路，或者没走专线。
2025-09-20 回复：没法解决
参考资料
测试工具
测速站
番外
在写完本文一天后，我突发奇想，THM 用的是 AWS，而 AWS 是全球最大的云服务器提供商，非常多的游戏都是用的他家的服务器，那是否我们可以利用网游加速器，来实现加速我们的 THM 呢？
利用网游加速器
网游加速器相信师傅们都用过吧，这些加速器厂商为了游戏玩家都会把线路优化到极致，所以我们就可以利用他的加速，把我们到 THM 服务器的连接加速上，达到最优的打靶体验。
本文以 UU 加速器为例，寻找利用他的方法。
网游加速器介绍
大多数网游加速器都是通过国内服务器做中转来给国内用户接入，国内服务器到国外的落地机之间这条线路做好优化，体验就挺好了。
而有些加速器甚至连国内的运营商都考虑到了，做了多线接入，这就保证了用户这边不论用的是哪家运营商，都是享受着最佳的路线过去的。国内 + 国外的线路都考虑到了，用户体验才会优秀嘛。
这里以 UU 加速器加速 APEX 的欧服节点为例，可以看到下面显示的游戏延迟为 154ms，这是到德国的延迟。
使用 System Informer 抓出来加速节点的 IP，UU 加速器一般连接着的节点会有两个 TCP 连接，端口号一个1k+，另一个2k+，很好分辨。其他加速器厂商就不清楚了。
使用 OpenTrace 进行路由追踪到中转服务器的链路，我本地 - 北京的中转服务器大约是 42ms，而加速器加速界面显示的延迟为 154ms，即中德之间的延迟为 112ms，和前面分析的差不多。
如果能利用这条线路去访问爱尔兰的话，延迟应该是 178ms（后文会做验证）。
加速模式
常见的网游加速器给游戏加速有两种手段，一种是劫持进程，即进程模式，还有一种则是虚拟一块网卡，全局代理三层流量，即路由模式。
这里不会详细介绍他们的实现原理，两种方法都有利用他们的办法。
利用进程模式，我们可以对他们要加速的游戏进行注入，把我们的代理程序注入到游戏进程里，再连接那个代理端口，游戏加速器会帮我们“加速“我们注入进去的那个程序，实现加速我们访问服务器的链路。
而路由模式就很简单了，因为他直接开了一块网卡，相当于三层隧道了。所以我们只需要一点小小的改动，就能利用上，本节会以此来叙述。
观察加速行为
这里还是以 UU 加速器为例，在 “区服、节点选择” 的节点选项卡中，过滤路由模式的节点，点击立即加速。
在控制面板 - 网络连接里面可以看到，UU 加速器新建了一块 UU Wintun Tunnel 的网卡。
而 UU 加速器是怎么样让我们游戏的流量经过这块网卡呢？想必聪明的你们已经想到了，路由表。
UU 加速器并不会加一条 0.0.0.0 的路由，相反，他很聪明。他把游戏的所有服务器的 IP 段都抓出来了，加进我们电脑的路由表中。
你可以使用 route PRINT 查看：
1
2
3
4
5
6
7
8
9
10
11
12
IPv4 路由表
===========================================================================
活动路由:
网络目标 网络掩码 网关 接口 跃点数
0.0.0.0 0.0.0.0 10.2.2.1 10.2.2.106 30
0.0.0.0 0.0.0.0 172.19.84.1 172.19.84.237 130
2.16.168.9 255.255.255.255 172.19.84.1 172.19.84.237 5
2.16.168.12 255.255.255.255 172.19.84.1 172.19.84.237 5
3.0.0.0 255.254.0.0 172.19.84.1 172.19.84.237 100
3.1.250.122 255.255.255.255 172.19.84.1 172.19.84.237 100
3.12.0.0 255.255.0.0 172.19.84.1 172.19.84.237 100
...这里只截取了一小部分，完整的路由表有 2000 多条。
很可惜，我翻了一下，路由分得很细，并没有大段大段的块，我把 THM 的 6 个欧洲的节点都看了，都不在里面。刚开始还想直接起飞呢。下图是离得比较近的一个。
修改路由表
既然没有我们的路由，那我们就加一个嘛，Windows 系统加路由表的语法如下
1
route ADD 157.0.0.0 MASK 255.0.0.0 157.55.80.1 METRIC 3 IF 2我们就构造一个出来
1
2
route ADD 18.202.129.195 MASK 255.255.255.255 172.19.84.1
操作完成!直接开 ping！
1
2
3
4
5
6
7
C:\Users\Recopec>ping 18.202.129.195
正在 Ping 18.202.129.195 具有 32 字节的数据:
请求超时。
请求超时。
请求超时。
请求超时。哦嚯，不通，抓包看看。
网卡里面可以看到我们发出的 ICMP Echo 数据包，但没有 Echo Reply/Destination Unreachable 之类的回包，就代表根本没通！
我猜测是他们加速器的服务端做了限制，不仅依赖客户端这边的路由表，服务端那边还有一份白名单路由。
我把 THM 的美国和欧洲的所有节点都试了一遍，没法加速。
1
2
3
4
5
6
route ADD 3.254.253.220 MASK 255.255.255.255 172.19.84.1
route ADD 18.202.129.195 MASK 255.255.255.255 172.19.84.1
route ADD 34.253.19.14 MASK 255.255.255.255 172.19.84.1
route ADD 52.16.156.56 MASK 255.255.255.255 172.19.84.1
route ADD 54.76.30.11 MASK 255.255.255.255 172.19.84.1
route ADD 63.35.110.70 MASK 255.255.255.255 172.19.84.1但是在我切换游戏的时候，发现了不一样的行为，每个不同游戏添加的路由表都是不一样的。
观察不同游戏的路由表
我会从 18.200.0.0 这里开始截取 5 个路由，以供进行对比。
这是加速 APEX 的
1
2
3
4
5
6
18.204.0.0 255.252.0.0 172.19.84.1 172.19.84.237 100
18.207.13.253 255.255.255.255 172.19.84.1 172.19.84.237 5
18.208.49.79 255.255.255.255 172.19.84.1 172.19.84.237 5
18.208.99.156 255.255.255.255 172.19.84.1 172.19.84.237 5
18.208.109.74 255.255.255.255 172.19.84.1 172.19.84.237 100
18.209.202.220 255.255.255.255 172.19.84.1 172.19.84.237 5瓦洛兰特
1
2
3
4
5
18.201.0.0 255.255.0.0 172.19.83.1 172.19.83.237 100
18.204.0.0 255.252.0.0 172.19.83.1 172.19.83.237 100
18.205.205.190 255.255.255.255 172.19.83.1 172.19.83.237 35
18.208.112.174 255.255.255.255 172.19.83.1 172.19.83.237 35
18.210.130.43 255.255.255.255 172.19.83.1 172.19.83.237 35PUBG
1
2
3
4
5
18.204.0.0 255.252.0.0 172.19.84.1 172.19.84.237 100
18.204.57.43 255.255.255.255 172.19.84.1 172.19.84.237 5
18.208.0.0 255.248.0.0 172.19.84.1 172.19.84.237 100
18.216.0.0 255.252.0.0 172.19.84.1 172.19.84.237 100
18.220.0.0 255.252.0.0 172.19.84.1 172.19.84.237 100有没有发现，他们添加的路由表是不一样的，但是有重叠的部分。
验证猜想
为了验证上面的猜想，即是否依赖服务端的白名单路由，我将会找出未添加到该游戏的 IP 段，而在另一个游戏里面有添加的 IP 段进行测试。
这里我挑选的是在瓦洛兰特里面出现的 18.201.0.0/16 进行测试，刚好这是和 THM 同一个服务区的 IP 段。
首先扫描这里面能 ping 通的主机，为了节省时间，我只扫一个 C 段。
1
2
3
4
5
6
7
8
9
10
11
# -sn 不扫描端口 -PE ICMP扫描 -n 不进行 DNS 解析 --min-rate 最低速度
nmap -sn -PE -n 18.201.0.0/24 --min-rate=1000
Starting Nmap 7.95 ( https://nmap.org ) at 2025-09-21 14:33 HKT
Nmap scan report for 18.201.0.14
Host is up (0.23s latency).
Nmap scan report for 18.201.0.83
Host is up (0.23s latency).
Nmap scan report for 18.201.0.201
Host is up (0.23s latency).
Nmap done: 256 IP addresses (3 hosts up) scanned in 1.85 seconds18.201.0.14 就你了，首先测试本机直连的 ping 延迟。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
PS D:\tools> ping 18.201.0.14 -n 10
正在 Ping 18.201.0.14 具有 32 字节的数据:
来自 18.201.0.14 的回复: 字节=32 时间=229ms TTL=107
来自 18.201.0.14 的回复: 字节=32 时间=228ms TTL=107
来自 18.201.0.14 的回复: 字节=32 时间=229ms TTL=107
来自 18.201.0.14 的回复: 字节=32 时间=229ms TTL=107
来自 18.201.0.14 的回复: 字节=32 时间=229ms TTL=107
来自 18.201.0.14 的回复: 字节=32 时间=228ms TTL=107
来自 18.201.0.14 的回复: 字节=32 时间=229ms TTL=107
来自 18.201.0.14 的回复: 字节=32 时间=228ms TTL=107
来自 18.201.0.14 的回复: 字节=32 时间=228ms TTL=107
来自 18.201.0.14 的回复: 字节=32 时间=228ms TTL=107
18.201.0.14 的 Ping 统计信息:
数据包: 已发送 = 10，已接收 = 10，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 228ms，最长 = 229ms，平均 = 228ms手动添加路由表
1
route ADD 18.201.0.14 MASK 255.255.255.255 172.19.84.1再次 ping 测试
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
PS D:\tools> ping 18.201.0.14 -n 10
正在 Ping 18.201.0.14 具有 32 字节的数据:
来自 18.201.0.14 的回复: 字节=32 时间=176ms TTL=64
来自 18.201.0.14 的回复: 字节=32 时间=174ms TTL=64
来自 18.201.0.14 的回复: 字节=32 时间=180ms TTL=64
来自 18.201.0.14 的回复: 字节=32 时间=177ms TTL=64
来自 18.201.0.14 的回复: 字节=32 时间=176ms TTL=64
来自 18.201.0.14 的回复: 字节=32 时间=175ms TTL=64
来自 18.201.0.14 的回复: 字节=32 时间=180ms TTL=64
来自 18.201.0.14 的回复: 字节=32 时间=176ms TTL=64
来自 18.201.0.14 的回复: 字节=32 时间=173ms TTL=64
来自 18.201.0.14 的回复: 字节=32 时间=174ms TTL=64
18.201.0.14 的 Ping 统计信息:
数据包: 已发送 = 10，已接收 = 10，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 173ms，最长 = 180ms，平均 = 176ms有效果！说明 UU 加速器依赖的是在服务端的那一份大的白名单路由表。而我们测试的 THM 的 IP 段没加进路由，没法用。
其实我很好奇，难道 AWS 给游戏厂商服务器的段是专用的？不会和现有的重叠吗？我还心存侥幸的以为会有漏网之鱼呢，没想到一个都没有。
从这份结果就可以验证，从我现在所在区域到 THM 服务器，目前能达到的最快延迟是 173ms，和之前猜想 178ms 差不多。
后记
发现了 UU 加速器的一个漏洞，交给网易 SRC 不认。
看完我觉得你们应该猜得出来应该怎么利用了，但是我不能说，因为我同意网易 SRC 的用户协议了，怕喜提银手镯。
如果有其他问题可以联系我讨论，请参考关于博主。