XIU2

@yaotthaha 确实，几个小时前就发现了，虽然比较离奇，但建议再多观察几天。 而且，经历这几次事情，怕是很多人不会再将 `cdn.jsdelivr.net` 用于生产环境（项目）中了。。。

好像没有再复发了，那我就先关了~

@yaotthaha 刚刚发现又被 DNS 污染了。

现在 Cookie 登录比较蛋疼，因为 Cookie 有效期只有 3天了。。。

看了下，只有发现里有一些乱码，搜索、正文什么的都正常，我尝试手动访问发现 URL，也是这样子的。 应该是书源网站本身改动了什么东西，不过这个书源并不是我写的，而是别人推荐给我的，当时 "发现" 还是正常的。。。

@jesee030 没有，我用《阅读》只是为了看普通网文小说，因此我只会写这类书源。

你确定是 九桃小说官方 的新域名吗？ > 如果是新域名的话，那么只需要改改书源里的 域名 即可，因为网页结构什么都没变。而如果网页结构什么的也都变了，那多半不是真的九桃小说。另外，9taoxs.com 这个域名没有被墙，我看了下只是 IP 挂了。 搜索九桃小说，数字 + txs.com 格式的域名有好几个，最后更新时间都是 9 天前。 我也是今天下午才发现九桃小说又挂了，以前也不是没发生过，只不过不知道具体挂了几天了，因为我很久没看过在线小说了（书架里没几个连载小说了，而且前段时间我还将书架里值得收藏的完结小说都下载导出为 TXT 来本地观看）。

命令行方式运行时，加上 ` -n 50 ` 试试，即调低 `测速线程数量`（默认为 200）。 这种情况，是因为你的设备无法承受这个延迟测速的并发，这种情况以前有好几个人反馈过了，所以我才将最初的默认 500 改成 200 了，结果还是有人测速时会出现网卡、断网的情况（虽然相比以前少很多了），但是我这边即使跑到 800 也没感觉。。。而我的也只是个低端路由器，性能也很捉急。 > 当然，这些反馈中，有一些人是在**路由器等微型设备**上跑的，有的是**连 WiFi 网络**跑的，这种情况自然影响更大（特别是后者，WiFi 比有线会占用更多设备资源，并发承受能力更差）。 你最初延迟测速时有 4000+ 个 IP，而再次测速时你给改成了 100+ 个 IP，这点数量自然不会出现网卡、断网的问题了。 另外，这只是 IP 数量，还有个...

@CrazyBoyFeng 不选出来 IP 怎么去下载速度测试。。。直接挨个把所有 IP 下载测速一遍？这效率也太低了吧，而且还严重浪费时间（大量不可用、高丢包的 IP）。 下载测速是单线程的，一次一个，而延迟测速是多线程的，一次 200 个（默认）。 延迟测速就是过滤筛选一遍 IP 段，过滤掉**不可用的、高丢包、高延迟**的 IP，然后再对剩余少量优质 IP 进一步下载测速提纯。 延迟测速是软件核心功能，不可能跳过的，否则就破坏了软件整体功能逻辑。 下载测速反倒是可选的，我平时为了节省时间压根就不下载测速，仅延迟测速就完事了（需要提高 `-t` 测速次数来保证测速结果质量），只要延迟够低、够稳且不丢包，那么速度就差不到那里。

@CrazyBoyFeng 我已经很久没遇到过假墙了，好像今年就没遇到过，至于专用 IP 那都是极少数。 该软件是我为了解决个人需求写的，目前功能已经完全满足我使用了，所以如无必要不会再增加新功能，或大量改动代码了。距离上个版本发布已经过去 8 个月了。 对于这种个性化需求，尽量自给自足吧，我写的这些开源项目就是不喜欢完全指望别人~ 为此专门临时学的 Golang（够用即可）