[Bug] error: dns resolve failed
Verify steps
- [X] I have read the documentation and understand the meaning of all configuration items I have written, avoiding a large number of seemingly useful options or default values.
- [ ] I have not reviewed the documentation and resolve this issue.
- [ ] I have not searched the Issue Tracker for the problem I am going to raise.
- [x] I have tested with the latest Alpha branch version, and the issue still persists.
- [X] I have provided server and client configuration files and processes that can reproduce the issue locally, rather than a desensitized complex client configuration file.
- [X] I have provided the simplest configuration that can reproduce the error I reported, rather than relying on remote servers, TUN, graphical client interfaces, or other closed-source software.
- [ ] I have provided complete configuration files and logs, rather than providing only parts that I believe are useful due to confidence in my own intelligence.
Operating System
Windows
System Version
22631.3593
Mihomo Version
Mihomo Meta v1.18.5 windows amd64 with go1.22.3 Sun May 19 08:49:24 UTC 2024 Use tags: with_gvisor
Configuration File
mode: rule
mixed-port: 7899
socks-port: 7898
port: 7897
allow-lan: false
log-level: info
ipv6: true
external-controller: 127.0.0.1:9097
tun:
stack: gvisor
device: Meta
auto-route: true
strict-route: false
auto-detect-interface: true
dns-hijack:
- any:53
mtu: 9000
enable: false
experimental:
ignore-resolve-fail: true
rules:
- DOMAIN-SUFFIX,sinaimg.cn,DIRECT
Description
related: https://github.com/clash-verge-rev/clash-verge-rev/issues/1062
nslookup
> nslookup.exe wx3.sinaimg.cn
服务器: router
Address: 192.168.1.1
非权威应答:
名称: ww1.sinaimg.cn.w.alikunlun.com
Addresses: 240e:ff:d131:100:3::3ea
240e:97d:4:901:3::3f0
240e:ff:9014:100:3::3f1
240e:ff:9014:100:3::3f2
240e:97d:4:901:3::3ef
240e:94c:4000:328:3::3fa
240e:94c:4000:328:3::3f9
240e:ff:d131:100:3::3e9
116.55.234.238
125.73.210.102
183.2.160.226
183.2.160.225
59.36.226.220
14.17.66.225
182.242.154.237
116.55.234.236
113.96.150.217
14.215.55.226
113.96.109.95
119.147.146.214
182.242.154.235
59.36.226.221
125.73.210.97
119.147.146.213
113.96.109.86
125.73.210.96
183.2.160.224
113.96.109.88
59.36.226.219
113.96.109.87
119.147.146.219
14.215.55.207
14.17.66.224
183.2.160.228
14.17.66.220
113.96.150.218
119.147.156.211
125.73.210.101
14.17.66.226
183.2.160.227
116.55.234.239
119.147.146.218
14.17.66.222
59.36.226.223
59.36.226.224
125.73.210.98
182.242.154.238
113.96.109.91
14.215.55.225
119.147.146.217
113.96.150.221
119.147.146.222
182.242.154.234
14.215.55.227
113.96.150.220
113.96.109.89
14.215.55.224
113.96.150.222
119.147.146.220
14.17.66.227
59.36.226.226
59.36.226.222
183.2.160.138
113.96.150.219
14.215.55.209
113.96.150.216
14.17.66.221
182.242.154.233
119.147.146.221
113.96.109.96
116.55.234.240
14.17.66.223
183.2.160.139
14.215.55.206
113.96.150.215
183.2.160.221
Aliases: wx3.sinaimg.cn
weiboimgwx.gslb.sinaedge.com
weiboimgwx.grid.sinaedge.com
Reproduction Steps
browsing weibo.com, some image loading fail
Logs
WARNING
[TCP] dial DIRECT (match DomainSuffix/sinaimg.cn) 127.0.0.1:4485 --> wx3.sinaimg.cn:443 error: dns resolve failed: lookup wx3.sinaimg.cn on 192.168.1.1:53: read udp 192.168.1.50:55305->192.168.1.1:53: wsarecv: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself.
[TCP] dial DIRECT (match DomainSuffix/cn) 127.0.0.1:14714 --> face.t.sinajs.cn:443 error: dns resolve failed: lookup face.t.sinajs.cn on 192.168.1.1:53: read udp 192.168.1.50:52713->192.168.1.1:53: wsarecv: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself.
重启一下clash核心即可
重启一下clash核心即可
没有作用,关闭软件可以正常访问。我没有配置dns,默认fallback是system
重启一下clash核心即可
没有作用,关闭软件可以正常访问。我没有配置dns,默认fallback是system
现在对系统自带dns服务器的识别好像不太靠谱,建议在开启tun情况下也填写一下dns配置,比较稳妥。
以前(没有改名mihomo之前)有些版本,就算不开tun,也得配置dns,不然也会偶尔出现解析超时问题。
我也遇到过 是机场问题,换一个就好了
使用机场的ss节点在重启的几个连接之后,新连接会大量出现dns resolve failed, 自建的v2ray没有这样的问题。 机器是Arch Linux, Tun Stack 为 Mixed. 将Tun Stack 改为system/gvisor,就没有问题了
建议把strict-route打开,这个看上去就是Windows平台特有的DNS泄漏
strict-route
我试了下 我的dns设置是只有: nameserver: - https://223.5.5.5/dns-query#h3=true - https://1.12.12.12/dns-query
我在fake-ip-filter添加了: - 1.12.12.12 - 223.5.5.5
暂时没出现过这个情况了,也不知道是不是碰巧没出现还是真的解决了。
https://wiki.metacubex.one/config/inbound/tun/#dns-hijack
dns-hijack:
- any:53
mtu: 9000
enable: false
- dns 劫持,将匹配到的连接导入内部 dns 模块,不书写协议则为 udp://
- wiki没看到
enable: false这个设置 - 不知道你发的配置的是导入clash-verge-rev前的,还是导入后clash-verge-rev修改过的
- 尝试将53端口改为54
- 添加DNS配置
https://github.com/MetaCubeX/mihomo/issues/1295#issuecomment-2198460626
配置是clash-verge-rev 设置界面导出的,我删除了proxies和proxy-groups片段,rule只保留了出问题的那一条规则
TUN 模式的默认配置没有问题
同样的问题,一开始还以为是clash-verge-rev的问题,我切换回clash-verge后,选择clash内核就不再出现这个问题,若选择clash meta内核一样会出现大量的dns resolve failed
strict-route 严格路线
我试了下 我的dns设置是只有: nameserver: 名称服务器: - 223.5.5.5/dns-query#h3=true - 1.12.12.12/dns-query
我在fake-ip-filter添加了: - 1.12.12.12 - 223.5.5.5
暂时没出现过这个情况了,也不知道是不是碰巧没出现还是真的解决了。
你这个方法成功解决了我的问题,把 dns服务器 加进 fake-ip-filter 就修好了
补充了dig结果,我注意到;; MSG SIZE rcvd: 4493超过了 4096 byte,会不会是DNS服务器回应不规范,加上mihomo没有处理兼容。最近测试没有遇到,应该是weibo简化了DNS
@wwqgtxx 希望能帮忙看看