Kuma
Kuma
最新版本会间歇性地报证书错误，如： ``` http.Client.Do fail:Get "https://59.111.181.38/api/song/detail?ids=%5B26620638%5D": x509: cannot validate certificate for 59.111.181.38 because it doesn't contain any IP SANs ``` 很奇怪的错误，尝试追踪了一下，错误是出在network/network.go的Request函数里面。在这个函数里面，有对HTTPS IP连接的处理，而且这个错误也不能稳定复现，复现概率大概5%左右。对于大多数同样的请求，根本不报错。经过输出request.Host，确定有进入对tls特殊处理的分支中，而且对于url为IP、Host为域名的请求，绝大部分都能正常完成，不报错。 尝试注释掉`tr.TLSClientConfig.ServerName = request.Host`和`tr.TLSClientConfig.InsecureSkipVerify = true`之中的一个，均无法解决问题。 为什么会通过IP作为Host来发起https请求？有什么特殊用意吗？
1.5.9版本xray-core在使用内置dns进行查询时，极低概率发生无法查询的问题。 具体表现为某个特定的网站（每次不相同）一段时间内dns解析失败，过一段时间（往往是几分钟）之后恢复。重启客户端可以马上恢复。 假设出问题的域名是example.com，出现问题时nslookup example.com结果为SERVFAIL，使用dig @127.0.0.1 -p 15353 example.com查询无返回IP地址（127.0.0.1:15353为xray-core DNS入站监听地址），但是用dig @8.8.8.8 example.com时可正常解析（xray-core dns上游配置的也是8.8.8.8，开了udp透明代理）。尝试在dig后面加上+tcp使用tcp查询127.0.0.1:15353，也是同样无法解析。 客户端和服务端均无法抓取到有价值的日志。 由于此问题发生概率极低（2-3天一次，一次仅针对一个域名，且能在1-3分钟内自动恢复，重启客户端马上恢复），且无法稳定复现，故优先级较低，请开发者有时间时再尝试处理此问题。由于大部分时间可以正常工作，并且重启之后马上恢复，故认为此问题与特定客户端和服务器配置无关，不贴出具体配置。
反馈bug/问题模板，提建议请删除 ## 1.关于你要提交的问题 Q：是否搜索了issue (使用 "x" 选择) * [x] 没有类似的issue 红米AX6000，在开启数据包负载均衡时，进行大带宽吞吐，发生暂时断网问题。 ## 2. 详细叙述 ### (1) 具体问题 开启数据包负载均衡，或只开启eth0的rps时，进行大带宽吞吐，红米AX6000会发生watchdog timeout。然后网卡会暂时下线，几秒钟后重新上线，导致暂时断网。 测试环境为内网xray服务器，通过某插件透明代理。仅在多线程（超过8线程）下载时，CPU负载几乎占满，非常容易发生此现象。使用单线程下载时，几乎不发生此现象。同时，关闭数据包负载均衡，或只关闭eth0的rps，此问题不再复现，但同时速度也不像开启rps时那么快了（开启rps时多线程下载是\~110MB/s，关闭rps时多线程下载是\~90MB/s，单线程下载是\~110MB/s）。 ~~是否考虑为我的这台路由器的个体硬件问题？（之前买过一个RK3399开发板，其内置无线网卡（通过USB2.0转接）也发生过类似问题，速率一快就断联，表现为USB断开连接，最后加焊无线网卡芯片后解决问题。）~~ 更新：朋友的另一台红米AX6000也测试出此问题，个例的概率很小了。 已测试本repo，和x-wrt，均有类似问题。 ### (2) 路由器型号和固件版本 红米AX6000，commit 3929a9889f0ec47c462e81cc846c539b45130772 ### (3)...
关于1.6.6-2也会发生的偶发ssl错误，我这里抓包有新的发现。 **简要概括：xtls转发流量时，漏掉了某些包。** 左边bug.pcapng为本地透明代理后抓到的包，右边orig.pcapng为在服务器上抓到的包。   注意两个图中的142.251.42.174和172.217.31.174不同是因为我在服务端开了sniffing，实际上是同一个连接经过代理。 这个包可以对上，是正常的。   从这里开始，流复制发生了跳跃。本地收到的包也被解析成了Continuation Data，并且没有tls header。  本地收到了错误的包后，应用马上检测到，报错并发送了TCP RST。（那个客户端发的长度为106的Application Data应该是TLS 1.3的Alert？）   注意到发生错误的后一个服务器上的包，其tls header（右图）也被复制到了本地客户端（左图），成为了Continuation Data的一部分。至此可以肯定是发生了流的错误复制。流复制发生了跳过的可能性极高，因为即使在完整的抓包记录中，搜索客户端没收到的那部分包中的data，也找不到任何结果。 经过计算，这个样本中发生跳过的长度为2456-2466。有长度为10的区间是因为不确定在处理的时候有没有算上tls header（长度为5）。 我已上传脱敏后的抓包记录，供开发者分析。 [xtls_bug.zip](https://github.com/XTLS/Xray-core/files/10237808/xtls_bug.zip) 没有抓取服务端的xtls调试信息的原因是，目前这个bug已经很偶发，且不能稳定复现。仅在特定客户端发起的大量https请求中少量复现。所以，服务端抓取有用的日志非常困难。
我在app里貌似没找到官网的Watched筛选，设置的tag是可以高亮显示，但是我没找到怎么仅搜索满足tag权重的内容（官网的Watched功能）。
I use hard links frequently. So, it will be awesome for mergerfs.balance to ignore files with multiple links (e.g., hard links), because moving those files to another partition will leads...
This PR fixed the scale quality of photo-view and fixed some dependency problems so that we can update to the latest flutter SDK version. 1. fix image scale quality: the...