gscan_quic 扫描 IPv6，扫出的IP放入goproxy中，绝大部分IP为 bad_addrs

[panpeach]

config.json参数里面的"QUIC"下的验证等级"Level"，无论是1.2.3.4，扫描IPV6后的，直接放入gae.user.json中，只有约10%为googd_addrs，其余90%为bad_addrs。 若把扫出的IPV6_IP，导入到XX-net,并检查全部IP，检查好后的IPV6_IP再放入goproxy中，那么90%以上IP为googd_addrs。 请问gscan_quic扫描IPv6验证是不是有问题？能不能改进？ 谢谢。 goproxy中启用IPv6，比xx-net和goagent中启用IPv6速度快多了。 附上速度测试截图

[jasonliul]

主任已经被丰乳肥臀俘获, 不用指望了~

[qwertccc]

恭喜主任喜提丰乳肥臀

[NAVrasZ]

~~记得有说因为取消域名前置所以扫不了了？~~ (

[Kisesy]

说是要改进，我也对此不太了解啊，ipv6 跟 ipv4 底层也都差不多，而且你把 quic 的IP给xx-net来验证，验出来的也都是 tls ip，也算是个双保险了，也许也该改进一下验证方式，支持同时验证多个类型，验完quic再验tls

[jasonliul]

@Kisesy 你能不能不要每次都从天而降? :)

[Kisesy]

@jasonliul 这里没啥事，我就潜水喽 没办法，只能强制自己少来，不然没法专注啊，以前在goagent和xx-net那里，每天都得点开看看近百次，在上面的时间太多了，必须得转移 现在转到了刷题上，潜水这段时间刷了近两百道题吧。。。 :trollface:

[SeaHOH]

v6 的域前置好像还在

[jasonliul]

@Kisesy 今年明显旱情, 感觉民众都像瘟鸡一般慵懒~~~

[panpeach]

@Kisesy
我是用 quic扫描IPv6段的IP，扫完的IP直接使用90%以上不能用（比如扫出3000个，只有300个能用） 若把这3000个IP导入xx-net检验，验证完也是300个左右可用，我想xx-net的验证机制比较靠谱。 用quic扫描IPv4段IP，输出的IP直接使用，几乎100%为googd_addrs，验证机制很正确。 PS：大约二个月前用quic扫描IPv6段的IP（延时1500以下），输出的几乎全部能用，现在不知道GFW 升级了什么玩意，也许是我选择延时太低，扫出延时1000以下的大部分IP被GFW屏蔽了，而不能用

[Kisesy]

@panpeach IP 保存时是按照延迟从低到高的顺序排序的，你可以看一下你测的可用的IP是在哪个位置，如果真的是延迟低的有问题，可以把 ScanMinRTT 调高。 又或者把ScanCountPerIP调一下，多测几次。

[panpeach]

@Kisesy 好的谢谢，我试试看，还是用1500延时，扫出后从后面取300个再测试， 这有可能遗漏掉前面低延时高质量的IP，若几千个IP一个一个测试太费时间了。

[panpeach]

"QUIC"里"ScanCountPerIP": 2，"ScanMaxRTT": 1500，其余默认，用gscan_quic扫描xx里面最新IPv6库， 约扫出3500个，取出前500个放入xx检测，检测出约5个可用。清空导入xx的IP，再取出后500个放入 xx检测，检测出约150个可用，然后再清空导入xx的IP，把gscan_quic扫出的3500个全部导入到xx检测， 检测出580多个可用，再把xx检测出可用的IP放入gscan_quic扫描，扫出后放入goproxy中大多都能用， 且可用IP延时都很低。不玩了太费时间，只要能用就行。

[jyuan15]

@panpeach 问下，你用的哪个版本xx测试的？

[panpeach]

@jyuan15 发帖时用3.8.7版本测试的，现阶段IPV6速度，IP可用数量明显下降，但一直能用，youtube速度1万左右 近阶段没再测试换过IP，在折腾绑定免费域名，不用再找IP很方便，youtube速度也能达1万左右。