-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FAQ] forward 报错 context deadline exceeded #98
Comments
如果单纯是阿里的DNS时常这样何解?我这里(包括其他DNS相关软件)测试有且仅有阿里的DNS会这样。 |
我的日志info级别是经常出现 |
如果很多,是要换 tcp。 |
用的fast_forward,大量warn都是PTR查询
|
这个大量的 context deadline exceeded 正常吗? ` ` |
还发现一个问题,经常出现context deadline exceeded之后,所有域名都解析成10.0.0.1,造成上不了网,以前的版本没有这个问题,查看日志也没有什么有用的信息,重启服务后正常。 |
我也是有一堆
|
我也是, 而且都是这个域名出现问题 bundled_upstream/bundled_upstream.go:93 2022-07-11T13:50:36.999+0800 debug transport/transport.go:213 retrying pipeline connection {"previous_err": "read udp 172.31.74.103:50958->119.29.29.29:53: i/o timeout", "attempt": 1} |
2022-07-11T14:04:18.338+0800 debug executable_seq/if_node.go:164 matcher result {"query": "autodiscover.sme.sh.cn. IN A 60335 2 127.0.0.1", "tag": "query_is_ad_domain", "result": false} |
解决了,clash 的
|
为什么我出现的 context deadline exceeded 都是
貌似都是苹果相关的域名 |
大佬怎么改的。没看懂 |
大量出现这种错误,但针对出现这种错误的每个域名,自己用 nslookup 试又能正常返回 dns 记录,就很奇怪,比如:
但我自己用 nslookup 执行都是ok的:
都是ok的 @IrineSistiana 是哪里出了问题吗,不应该啊 出现这种错误好像都是 clash 那边发起的 dns 请求,不清楚是哪一边的问题 |
上游不支持qtype 65查询,把qtype65 match出来,发给能处理的上游 |
defult-nameserver可以添加127.0.0.1:5335吗?作用是啥? |
我用passwall + mosdns 也是出现大量这个错误,过一段时间可能几个小时就会科学网络不通,重启服务就又好了,查了好几天,目前把mosdns关了在用。 |
兄弟,我也是一样。请问解决了吗? |
我也是出现了这种错误,也是passwall2配合mosdns这样,等一个大佬救命。 |
我都放弃了 还是smartdns吧 稳定 没有这些问题,还找不到解决方法。 |
把机场节点的地址加入MosDNS的白名单试试,我的就这样解决了。 |
哎,暂时放弃这个方案了,smartdns可能会慢一点,但是好在设置简单并且可以之前也设置好了去广告了,就不折腾了,谢谢兄弟给的方案,留给其他朋友做个参考哈哈! |
我也用smartdns了,感觉速度并不慢,和mosdns差不多吧。一般人用mosdns更简单,自定义又可以很强,但一般人玩不转。我照着官网设置了去广告,都感觉不到效果,电视盒子有广告,浏览器因为有插件没广告,比DNS过滤强大很多,所以不知道smartdns去广告起效了没有。 |
最近开始用SSRP+也是大量出现这样的错误,过一段时间可能几个小时就会科学网络不通(科学插件显示一切正常),然后导致所有网站都不能访问,就连ping网站和本地运营商的DNS的IP地址都不通,但是SSH连上路由器,路由器本身内外网都能访问,也能ping通,重启服务就又好了,看来不是我的设置问题。 |
同样的问题,解决不了 |
这个问题还没解决啊,困扰了好几年了 |
mosdns的上游都改成非udp的,比如tls://223.5.5.5,基本上就不会有了,作者其实在上面提过了,包括如果使用clash或者sing-box之类的fakedns作上游,也写成tcp://192.168.1.100:7874这种,再不行log level 改error吧。 |
同样是这个问题啊 |
.jiedian.stream.", "qclass": 1, "qtype": 1, "upstream": "tls://8.8.8.8", "error": "dial tcp 8.8.8.8:853: i/o timeout"} |
2024-10-11 13:48:41 WARN forward_remote upstream error {"uqid": 1, "qname": "private-user-images.githubusercontent.com.", "qclass": 1, "qtype": 1, "upstream": "tls://1.1.1.1", "error": "dial tcp 1.1.1.1:853: i/o timeout"} |
不用管,开error就行了,没事谁天天看日志。 |
实测可行,只要把日志中出现超时的上游dns服务器从配置中删除掉,全部换成非udp的,就不会出现这个提示了。 |
这连接数不用说肯定是配置错误了。 |
forward 报
context deadline exceeded
是因为 某个请求发出去了,但过了很长时间(大约5秒)也没收到上游的任何应答。收不到应答的主要原因:
网络波动 (丢包/长连接被切断等)。
出现零星的警告是正常现象,网络波动不可避免,但日常使用不会有任何感觉,因为客户端/系统都有重试/容错机制。如果希望眼不见心不烦可以将 log level 设为 error。大量警告/日常使用有感觉,说明网络太差,建议使用更可靠的上游。
次要原因:
如果报错都是相同请求类型,可能是上游问题,不能正确处理这类请求。
如果报错都是相同域名,可能是这个域名的托管服务器有问题。
如果确信是 mosdns 的 bug 请开新 issue。
The text was updated successfully, but these errors were encountered: