如果觉得TQ的国际互联有点严格，不是全绿，可以看看这个

这是算tcping还是tls握手呢

又加了一个这个？

@Qaaaa #1

不算真正握手延迟，只算syn到首个syn-ack的延迟，严格来说算草稿/beta版本

这个会不会受到dns的影响，dns有可能解析到延迟更高的ip上 ^-^

@coldsword #4

有可能，所以国内测试用的是我统一解析后下发的IP+端口

国际测试用的是系统默认的dns进行解析，如果测出来很高，就是本地dns的问题

国际测试最好走系统的dns，因为如果真的绕路的话，这样可以测出来。

@阿道夫 #2

是的，但目前测试的国际互联多而杂，想着精简一下或者能用更明确简洁的方式呈现

所以发出来看看大家的反馈

@k2think #5 国际互联对比 ×

DNS准度检测 √

个人感觉CDN部署到全球的网站似乎没有必要加入到国际互联的对比上

@coldsword #7

是这样的老哥，目前测试想多而杂，后面得精简一些。

不过确实看到HK和JP的一些线路机互联较差

比如，我手里的绿云JP gen2要比DMIT TYO PRO的互联差

我打算再找找证据，比如互联差的机器是不是多几跳。就目前来说，重传基本上都是0%，很少见非0的。或者修改成从CDN节点上下载上传的速度，而不是现在这样类似握手延迟。

@coldsword #7

老哥说的这个在理，我想要不留一个DNS解析CDN落在哪个地区的展示也行，这样比现在的显示OK

@k2think #8 控制下变量找几个比较代表地方特色的站点，比如云厂的对象存储终结点URL

https://docs.aws.amazon.com/general/latest/gr/s3.html

确实国际互联麻烦的点在于需要控制好通信双方az双端各自接入的链路，可能选取直接是tier1的站点比较具有代表性

@coldsword #10

感觉老哥建议，我会根据老哥的建议优化下国际互联检测的。

aws这个endpoint确实在之前的考虑中，采用类似想法的就是nq大量采用leaseweb各区域机房作为国际互联。优点是测速地区稳定可靠，缺点是用户很少会访问部署在leaseweb机房的服务。但延迟的参考意义还是很大。

@k2think #11 挺好的👍🏻

反馈一个bug？

512MB的小鸡跑这个把我的面板杀掉了（偶发一次），默认命令没有测速

alpine上只跑了3xui

不知道为啥这也杀，swap也够用吧 ^-^

@Qaaaa #14

感谢反馈，我观察一下内存占用

@k2think #15 确实是偶发的bug吧

正常状态

apline系统

@Qaaaa #16

我之前在Debian的alpine上没观察到 我多测几次试试

最近加了一些新功能 搞不好就是这些新功能导致的

非常好的项目 ^-^