dns配置中的servers好像不是顺序匹配造成了一些逻辑bug

[lanchengjiu]

一切的起因是 translate.google.cn
这虽然是个谷歌域名，但是却是cn结尾，实际上谷歌翻译可以在中国直连访问。
域名规则文件的包含关系中，geosite:cn和geolocation-!cn出现了交集。
geosite:cn>tld-cn>.cn
geolocation-!cn>tld-!cn>google>.google.cn
到目前为止好像和v2ray没有关系，是域名规则文件的锅，但后边就不是了。

routing配置中，rules的匹配是按照集合顺序匹配的。
如果geosite:cn（直连）在前，translate.google.cn会被路由判定为直连。
但是在outbounds中，如果直连配置了"domainStrategy":"UseIP"，v2ray就会去dns调取服务器并解析IP地址
通过看debug日志，发现dns的servers结果并不按照集合顺序排列。
translate.google.cn同时符合geosite:cn（在前）与geolocation-!cn（在后），结果dns匹配结果列表反而8.8.8.8在前
进而通过8.8.8.8拿到了translate.google.cn的境外IP，最终造成v2ray通过直连路径连接境外IP无法连通。

如果将v2ray的内置dns服务器作为透明代理的dns服务器，也会造成类似问题，而且无法在v2ray中解决
浏览器访问translate.google.cn的DNS请求发送至路由，转发至v2ray的内置dns服务器，得到境外IP
浏览器的HTTP连接中含有域名信息，被v2ray嗅探之后，路由会选择直连路径（还是因为geosite:cn）
此时无论直连配置的domainStrategy如何配置，都会拿到v2ray之前缓存的境外IP，然后凉凉

归根结底是因为routing是顺序匹配，而dns的servers结果乱序，不清楚机理，因而顺序不可靠
日志中，有时候一条geosite条件能出现多个匹配的dns项，可能域名在规则文件中出现了多次
希望能将dns的servers结果也改为顺序匹配

另外也可以考虑将dns的"clientIp"升级一下，做成一个嗅探功能
用一个中国IP作为clientIp发给服务器，如果返回的是境外IP，则代表此网站没有中国节点，不可直连
之后不带clientIp再次发送dns请求，获得正确位置的境外IP（一般是VPS的IP位置附近）

[kslr]

try dns skipFallback

[lanchengjiu]

Thanks for the reply.I don't know about skipFallback, so let's learn it first.

[database64128]

Can’t tell much without seeing your config, but it’s clearly not a bug. You probably put IP rules before domain rules, while using IPOnDemand. And you might not actually want to configure the domain strategy for your freedom outbound.

[lanchengjiu]

Thanks for the reply.The configuration has been attached, and the domain name rule comes before the IP rule.

[lanchengjiu]

所使用的配置示意：

{
......
    "routing":{
        "domainStrategy":"IPOnDemand",
        "domainMatcher":"mph",
        "rules":[
            { // 中国大陆主流网站域名直连
                "type":"field",
                "domain":[
                    "geosite:cn",
                    "ntp.org"
                ],
                "outboundTag":"direct"
            },
            { // 中国大陆 ip 和 保留 ip 直连
                "type":"field",
                "ip":[
                    "geoip:private",
                    "geoip:cn"
                ],
                "outboundTag":"direct"
            }
        ]
    },
    "dns":{
        "servers":[
            { //中国主流网站和中国域名优先使用阿里的 DNS
                "address":"223.5.5.5",
                "port":53,
                "domains":[
                    "geosite:cn",
                    "ntp.org"
                ]
            },
            { //境外主流网站域名优先使用 Google 的 DNS
                "address":"8.8.8.8",
                "port":53,
                "domains":[
                    "geosite:geolocation-!cn"
                ]
            }
        ]
    },
    "outbounds":[
        { // 代理服务器
            "tag":"proxy",
            "protocol":"vless",
......
        },
        { // 本地直连
            "tag":"direct",
            "protocol":"freedom",
            "settings":{
                "domainStrategy":"UseIP"
            }
        }
    ]
}

routing(translate.google.cn)>geosite:cn>outboundTag(direct)
outboundTag(UseIP)>dns>geosite:cn+geosite:geolocation-!cn>DNS(8.8.8.8)>ForeignIP>fail

[Loyalsoldier]

路由规则确实会有少量冲突，介意的话，请自行为那些冲突的规则显式定制路由和 DNS。另外，建议境外 DNS 放在境内 DNS 的上面/前面。

[Loyalsoldier]

在你这个案例中，只要把 routing 中的 domainStrategy 改为 IPIfNoneMatch 即可解决。

[lanchengjiu]

大佬，好像不能解决吧，translate.google.cn同时符合geosite:cn和geolocation-!cn，改成IPIfNoneMatch，在routing第一遍的时候匹配到cn域名，还是会进direct，不会触发匹配DNS解析，循环第二遍了。后边dns的RuleObject也是同时符合geosite:cn和geolocation-!cn，神奇的是8.8.8.8排在前面，难道是堆栈吗，先入后出，哭笑不得。

[Loyalsoldier]

DNS 解析的顺序确实是没问题的，如果都匹配，就是从上到下依次查询。你这个情况，确实应该把 223.5.5.5 放在第一位。

如果还是不行，应该是本地没有 IPv6 网络导致返回了空解析，建议把 DNS 的 queryStrategy 和 Freedom outbound 的 domainStrategy 都设置为 UseIPv4。

[lanchengjiu]

大佬，好像和IPv4没关系，看Debug问题好像出在这步：domain translate.google.cn matches following rules: [geosite:geolocation-!cn(DNS idx:1) geosite:cn(DNS idx:0)]

[lanchengjiu]

附上相应的Debug日志信息

curl -x socks5://127.0.0.1:1080 translate.google.cn

2021/04/16 18:51:26 [Warning] V2Ray 4.37.3 started
2021/04/16 18:52:13 [Info] [2847325376] proxy/socks: TCP Connect request to tcp:58.254.137.226:80
2021/04/16 18:52:13 tcp:127.0.0.1:12730 accepted tcp:58.254.137.226:80 [direct]
2021/04/16 18:52:13 [Info] [2847325376] app/dispatcher: sniffed domain: translate.google.cn
2021/04/16 18:52:13 [Info] [2847325376] app/dispatcher: taking detour [direct] for [tcp:translate.google.cn:80]
2021/04/16 18:52:13 [Info] [2847325376] proxy/freedom: opening connection to tcp:translate.google.cn:80
2021/04/16 18:52:13 [Debug] app/dns: domain translate.google.cn matches following rules: [geosite:geolocation-!cn(DNS idx:1) geosite:cn(DNS idx:0)]
2021/04/16 18:52:13 [Debug] app/dns: domain translate.google.cn will use DNS in order: [UDP:8.8.8.8:53 UDP:223.5.5.5:53]
2021/04/16 18:52:13 [Debug] app/dns: UDP:8.8.8.8:53 querying DNS for: translate.google.cn.
2021/04/16 18:52:13 [Debug] transport/internet/udp: dispatch request to: udp:8.8.8.8:53
2021/04/16 18:52:13 [Info] transport/internet/udp: establishing new connection for udp:8.8.8.8:53
2021/04/16 18:52:13 [Info] app/dispatcher: default route for udp:8.8.8.8:53
2021/04/16 18:52:13 [Debug] transport/internet/udp: dispatch request to: udp:8.8.8.8:53
2021/04/16 18:52:13 [Info] proxy/freedom: opening connection to udp:8.8.8.8:53
2021/04/16 18:52:13 [Info] app/dns: UDP:8.8.8.8:53 got answer: translate.google.cn. TypeA -> [203.208.43.98] 54.5604ms
2021/04/16 18:52:13 [Debug] app/dns: UDP:8.8.8.8:53 updating IP records for domain:translate.google.cn.
2021/04/16 18:52:13 [Info] app/dns: UDP:8.8.8.8:53 got answer: translate.google.cn. TypeAAAA -> [] 90.2718ms
2021/04/16 18:52:13 [Debug] app/dns: UDP:8.8.8.8:53 updating IP records for domain:translate.google.cn.
2021/04/16 18:52:13 [Info] [2847325376] proxy/freedom: dialing to tcp:203.208.43.98:80
2021/04/16 18:52:13 [Info] [2847325376] transport/internet/tcp: dialing TCP to tcp:203.208.43.98:80

[Loyalsoldier]

找到了，不是 bug，是个 feature，应该是故意为之。

https://github.com/v2fly/v2ray-core/blob/1e222425b6/common/strmatcher/domain_matcher.go#L90-L96

由于 translate.google.cn 在 geosite:geolocation-!cn 中匹配了 google.cn 两段，而在 geosite:cn 中只匹配了 cn 一段。匹配越多，优先级越高。

要解决你这个情况，在 DNS 部分这样配置即可（full 类型的匹配优先级比 domain 类型要高）：

"dns":{
        "servers":[
            { //中国主流网站和中国域名优先使用阿里的 DNS
                "address":"223.5.5.5",
                "port":53,
                "domains":[
                    "geosite:cn",
                    "full:translate.google.cn",
                    "ntp.org"
                ]
            },
            { //境外主流网站域名优先使用 Google 的 DNS
                "address":"8.8.8.8",
                "port":53,
                "domains":[
                    "geosite:geolocation-!cn"
                ]
            }
        ]
    },

[lanchengjiu]

非常感谢，原来有这么个设计在里面，藏得太深了！匹配的域名级数越多，优先级越高。“translate.google.cn”=3段，“google.cn”=2段，“cn”=1段，设计的还是比较有道理的，虽然在这个例子中有些尴尬，看来去维护下geosite:cn是更合理的。

[bhoppi]

关于这一点，我其实一直都想找个机会提一下这个问题。就是domain-list-community的域名组织改变之后，现在正确的匹配国内域名的方式应该是["geosite:cn", "geosite:geolocation-!cn@cn"]这两个一起，但现在官方的文档一直没有提到这一点，仍然用只有"geosite:cn"这一项的方式，这一定程度上是有一定误导性的。
回到楼主这里，在匹配国内域名那里加上"geosite:geolocation-!cn@cn"，就从根本上解决了这一大类问题，而不单单是translate.google.cn这一个域名。

[lanchengjiu]

找到了一个反例，geolocation-!cn>tld-!cn>yahoo>yahoo.cn @cn，IP=74.6.136.150，是一个美国IP，并且无代理无法连接。正好和谷歌翻译的案例相反，这个是cn结尾但是无法访问。看来除了使用DNS的clientIp放个中国IP先行做下嗅探，看能不能拿到中国IP，再凭此做路由匹配，否则没法彻底解决这个问题了，只有靠IP才能相对精确的区分地域。

[Loyalsoldier]

@cn 的标注不一定准确。

[lanchengjiu]

目前来看最好的路由规则，应该是白名单直连，黑名单直接代理，未知域名使用内置DNS解析成IP再做判断。
进一步升级的话，可以使用DNS的clientIp放个中国IP先行做下嗅探，看能不能拿到中国IP，再凭此做路由匹配。
如果拿到中国IP，就直连，如果拿到外国IP，那么不带clientIp配置再做一次远程DNS解析，拿到VPS附近的节点IP代理使用。
虽然这么做会增加DNS解析的时间，但是DNS有缓存，属于一劳永逸，还是可以接受的。