按照教程内网部署，国内分流失败，求教！

[zixiang5288]

环境：内网
科学: passwall

验证递归DNS
nslookup -type=TXT whoami.ds.akahelp.net 10.0.0.8
服务器: UnKnown
Address: 10.0.0.8

非权威应答:
whoami.ds.akahelp.net text =

    "ns"
    "217.146.9.93"

国内走的科学，国内分流失败，求指教

[kkkgo]

你的部署参数是什么？

[kkkgo]

如果你内网有passwall这类环境，你需要把容器IP加入不走代理。如果容器走IP分流的话会干扰递归的判断。

[kkkgo]

另外，镜像本身有提供SOCKS5代理的选项，你passwall可以开一个socks端口给他用的。没有代理也能正常工作，但有代理可以获得更接近你线路的解析结果。

[zixiang5288]

参数是第一个
docker run -d
--name paopaodns
-v /home/mydata:/data
-e CNAUTO=yes
--restart unless-stopped
-p 53:53/udp
sliamb/paopaodns

感谢指导

[kkkgo]

  "ns"
    "217.146.9.93"

这个IP是你线路的IP吗，如果是，你需要考虑让容器“不分流”。
你可以在这里查看你的IP： http://ip.03k.org
或者容器内执行curl ip.03k.org来验证。
另外你的容器参数可以-e SOCKS5=192.168.1.2:7890这样给他加个socks5代理获取更好的境外解析。

[HAOLANYANG]

如果socks5有密码格式是 账号:密码@ip:端口 吗

[kkkgo]

另一种可能是这个IP不是你的线路IP但是你的递归因为网络问题导致无法获取到解析，然后故障转移到dnscrypt上，你可以使用以下命令来测试：

dig whoami.ds.akahelp.net @192.168.1.8 txt -p5301

或者在容器内执行：

dig +trace whoami.ds.akahelp.net  txt

[kkkgo]

还有一种情况是，你的所有请求都被软路由“劫持”了，无论什么请求都被重定向了。比如有的openwrt固件有这个设置：

要检查你的路由器是否存在劫持的规则，可以运行以下命令：

iptables -t nat -S|grep " 53"

[kkkgo]

为了方便调试，最新镜像加入了调试脚本，请拉取最新的镜像：

docker pull sliamb/paopaodns:latest

重新创建容器，并在容器内执行调试脚本：

debug.sh

查看输出结果并反馈。

[zixiang5288]

网络让我干崩了，才上来= =，谢谢！

[zixiang5288]

debug.sh: not found

[kkkgo]

debug.sh: not found

要拉最新的镜像才有，刚刚加进去的

[zixiang5288]

debug.sh: not found

要拉最新的镜像才有，刚刚加进去的

抱歉了，折腾了一大圈子，这回找到原因了，是我的resolv.conf不干净的原因，里边一堆dns
分流非常的准确。谢谢耐心解答！

nslookup -type=TXT whoami.ds.akahelp.net 10.0.0.8
服务器: UnKnown
Address: 10.0.0.8

非权威应答:
whoami.ds.akahelp.net text =

    "ecs"
    "222.xxx.xxx.0/24/24"

whoami.ds.akahelp.net text =

    "ip"
    "222.xxx.xxx.76"

whoami.ds.akahelp.net text =

    "ns"
    "162.158.176.206"

https://nstool.netease.com/
您好，尊敬的网易用户
您的IP地址信息: 222.xxx.xxx.51 xxxxxx电信
您的DNS地址信息: 222.xxx.xxx.51 xxxxxx电信
您的DNS设置正确

另外拉取了最新的镜像 debug.sh: not found

[kkkgo]

那你可以加上dev标签，拉取sliamb/paopaodns:dev试试

[mrzj110]

那你可以加上dev标签，拉取sliamb/paopaodns:dev试试

我这个没问题吧

/data # debug.sh
CNIP URL test:
106.91.69.200
106.91.69.200

NOCN IP URL test:
106.91.69.200
106.91.69.200
106.91.69.200
106.91.69.200
106.91.69.200

IP INFO:
106.91.69.200
CN,Chongqing,Chongqing
ASN4134/China Telecom
HTTP/1.1
curl/7.88.1

The DNS hijacking test, you will see timed out message.
;; communications error to 6.7.8.9#53: timed out
;; communications error to 6.7.8.9#53: timed out
;; communications error to 6.7.8.9#53: timed out
;; no servers could be reached

----------whoami test----------

mosdns whoami dig:
"ns" "106.91.69.200"

local unbound whoami dig:
"ns" "106.91.69.200"

dnscrypt raw whoami dig:
"ns" "2001:de4:0:1::2"

dnscrypt with socks5 whoami dig:
;; communications error to 127.0.0.1#5303: connection refused
;; communications error to 127.0.0.1#5303: connection refused
;; communications error to 127.0.0.1#5303: connection refused
;; no servers could be reached

---

dnscrypt unbound whoami dig:
"ns" "2a0b:89c1:2::e4"

----------CN test----------
mosdns CN dig:
www.taobao.com.danuoyi.tbcache.com.
113.141.190.113
113.141.190.111

local unbound CN dig:
www.taobao.com.danuoyi.tbcache.com.
113.141.190.113
113.141.190.111

dnscrypt raw CN dig:
www.taobao.com.danuoyi.tbcache.com.
192.169.122.232
192.169.122.233

dnscrypt with socks5 CN dig:
;; communications error to 127.0.0.1#5303: connection refused
;; communications error to 127.0.0.1#5303: connection refused
;; communications error to 127.0.0.1#5303: connection refused
;; no servers could be reached

---

dnscrypt unbound CN dig:
www.taobao.com.danuoyi.tbcache.com.
79.133.176.232
79.133.176.233

----------NOCN test----------
mosdns NOCN dig:
youtube-ui.l.google.com.
216.58.214.14
142.250.179.142
142.251.36.46
142.250.179.174
142.250.179.206
142.251.36.14
142.251.39.110
172.217.168.206
216.58.208.110

local unbound NOCN dig:
148.163.48.215

dnscrypt raw NOCN dig:
youtube-ui.l.google.com.
142.251.42.238
172.217.160.78
172.217.163.46
142.251.43.14

dnscrypt with socks5 NOCN dig:
;; communications error to 127.0.0.1#5303: connection refused
;; communications error to 127.0.0.1#5303: connection refused
;; communications error to 127.0.0.1#5303: connection refused
;; no servers could be reached

---

dnscrypt unbound NOCN dig:
youtube-ui.l.google.com.
142.251.40.46
172.217.14.78
142.250.68.14
142.250.188.238
142.250.68.46
142.250.72.238
142.250.176.14
142.250.68.110
142.250.217.142
142.250.189.14
142.250.68.78
142.250.72.142
142.250.72.174

----------IPV6 test----------
dual CN domain IPV6:
dual NOCN domain IPV6:
IPV6 only domain :

[kkkgo]

@mrzj110 没啥问题，如果你有你线路的socks代理的话可以考虑加上。

[kkkgo]

你adguard home配置的上游是唯一的吗？192.168.0.127是你的adguard home套了一层的IP？还是192.168.0.127就是直接连的docker的端口

[mrzj110]

你adguard home配置的上游是唯一的吗？192.168.0.127是你的adguard home套了一层的IP？还是192.168.0.127就是直接连的docker的端口

adgurad作为可视化，他上游就是docker 192.168.0.4:53，127是客户端我电脑的ip

[mrzj110]

你adguard home配置的上游是唯一的吗？192.168.0.127是你的adguard home套了一层的IP？还是192.168.0.127就是直接连的docker的端口
可能是我的网络有问题吧，过段时间再看看

[kkkgo]

你adguard home配置的上游是唯一的吗？192.168.0.127是你的adguard home套了一层的IP？还是192.168.0.127就是直接连的docker的端口
可能是我的网络有问题吧，过段时间再看看

你可以尝试直接用手机连docker的ip，跳过adh，或者你在电脑版看看adh的详细查询日志，是什么记录类型的查询耗时。

[kkkgo]

@mrzj110 你是否有IPV6环境？如果你给手机分配了IPV6地址但没IPv6解析有可能会导致这种异常。因为这个超时值太凑巧了，我修改过的mosdns源码里面最大的超时值刚好是3000ms和总超时值4000ms，你这个显示的超时可能是指IPV6的超时值，还是建议用电脑版看看查询记录的类型是什么比较好判断。

[mrzj110]

@mrzj110 你是否有IPV6环境？如果你给手机分配了IPV6地址但没IPv6解析有可能会导致这种异常。因为这个超时值太凑巧了，我修改过的mosdns源码里面最大的超时值刚好是3000ms和总超时值4000ms，你这个显示的超时可能是指IPV6的超时值，还是建议用电脑版看看查询记录的类型是什么比较好判断。

并没有开启ipv6，我又在家里的联通宽带公网下nas搭建了一套，使用非常流畅并没有上面的情况，上面的情况是公司的nas 用的是电信宽带没有公网，而且是两条宽带合并的，我估计是因为网络的原因导致的

[zixiang5288]

公网部署速度很快，内网经常国内解析走科学，一阵一阵的没得规律

[kkkgo]

公网部署速度很快，内网经常国内解析走科学，一阵一阵的没得规律

你这个公网内网是指的什么

[zixiang5288]

是一级路由和二级路由，不是运营商的公网和内网

[kkkgo]

是一级路由和二级路由，不是运营商的公网和内网

你的意思是，服务部署在一级路由器下正常，部署在二级路由下会有这种情况是吗

[zixiang5288]

对的，之前单独用的mosdns，没准mesh组网下部署能行，二级路由不在同网段

[zixiang5288]

主路由弄完了开网页确实比其他的反应快

[kkkgo]

对的，之前单独用的mosdns，没准mesh组网下部署能行，二级路由不在同网段

是这样的，国内解析会走加密查询只有一种情况，就是本地递归查询超时失败，故障转移到加密查询上，而本地递归查询超时的情况可能是上级网络的限制比如Qos、丢包等，因为递归查询会并发一定的UDP查询，网络质量太差的话会可能造成超时。
针对这个情况我后面再更新一下镜像，兼容网络质量较差时对查询fallback的处理，提供额外选项，兼顾网络质量和解析质量的平衡。

[zixiang5288]

折腾网络容易崩，所以基本在二级路由折腾的，感谢不断优化！

[kkkgo]

@zixiang5288 @mrzj110 新增CNFALL=yes环境变量，默认开启，兼容网络质量较差时对查询fallback的处理。可以拉取最新镜像试试。