kgggggb

There is another problem. The order of groups is not the same every time. I guess it may be related to group activities.

> Did you mean the dotted box ? > > I thinks it's only mean you've clicked or selected this line or item. When you clicked outside, it should disappear....

> 新版本应该解决这个问题了 ``` root@Ubuntu:/home/Ubuntu/189# ./cloudpan189-go 提示: 方向键上下可切换历史命令. 提示: Ctrl + A / E 跳转命令 首 / 尾. 提示: 输入 help 获取帮助. cloudpan189-go > login 请输入用户名(手机号/邮箱/别名), 回车键提交 > *** 请输入密码(输入的密码无回显, 确认输入完成,...

> 发log才知道发生了什么，还有对应出问题的域名。 以下 log 对应了 `电脑浏览器闪现这个错误然后会立马重载正常访问` ``` [2024-03-01 16:05:58,605][DEBUG][ dns_server.c:7114] recv query packet from 内网电脑, len = 39, type = 0 [2024-03-01 16:05:58,605][DEBUG][ dns_server.c:7130] request qdcount = 1, ancount =...

> 检查你的上游吧 ，上游服务器返回的结果被truncate了，这个结果透传到客户端，客户端认为无效的结果。 > > 你可以尝试注释一些上游看看时哪个上游有问题。 上游是没有问题的，因为每次它显示被 truncate 的上游都会不一样，我对着所有上游使用 dig 和 curl 连续查询一个小时一个出错的都没有，但是为了避免真的是上游有问题我仍然尝试把所有私有上游都删了就留一个 Cloudflare 的也会时不时的出现 `ERR_NAME_NOT_RESOLVED`，其它同类软件从来都没有出现过类似错误，不过既然有可能是上游的问题的话，有没有办法不 passthrough 这个有问题的结果给客户端而是让 SmartDNS 等待其它上游回应没有问题的结果再返回给客户端？按理来说多上游的作用就是防止单一故障点，还是说 SmartDNS 有多线程并行查询但是没有类似防故障的功能？

> 1.1.1.1不应该出现truncate，log里面有什么？还是一样？ 一样。。。

> 日志里面也有truncate？ 如果留 tcp/udp 1.1.1.1 会有 truncate ，如果留 HTTTPS 不会有，但是仍然会 `ERR_NAME_NOT_RESOLVED` ，只是日志没有 truncate 。 > 有点像传输层问题，MRU小于MTU？或是中间经过了某些点对点或桥接网？ 检查过了 都是对称的 1500 如果真的是网络问题那其它同类软件应该也会有相同的问题 而且 `我对着所有上游使用 dig 和 curl 连续查询一个小时一个出错的都没有` 我看到其它贴子说 SmartDNS 超时默认是 1s...

> 超时时间是2s，dig如果truncate的话，会使用tcp重试查询的。 > > 你配置国内DNS看看吧。 国内 DNS 有污染，用 SmartDNS 就是为了国内外分流无污染 dig 没有问题，只有 SmartDNS 会有问题。