search

chika0801 / sing-box-examples

sing-box 配置示例
https://github.com/SagerNet/sing-box
1.61k stars 270 forks source link

FAKE IP 配置问题 #94

Closed lin1123 closed 5 months ago

lin1123 commented 5 months ago

请教个问题，sb的fake IP DNS，能不能设置成走代理的将域名发送的服务器解析，不走代理的设置成本地解析之后再分流。现在有一种情况，国内有些小众网站，没有包含在cn的域名规则里面，但是它的IP规则又在cn IP规则里面，fake IP的DNS会导致不会解析IP，结果就走了兜底的路由规则。 客户端入站添加 "domain_strategy": "prefer_ipv4" 会在本地解析，但是又不会传送域名到服务端。 在服务端入站开启 sniff": true, + "sniff_override_destination": true 可以让服务端再解析一次，但嗅探出来的域名又有一些奇奇怪怪的问题，特别是在DNS解锁Netflix的时候。

chika0801 commented 5 months ago

看了你说的，建议你帖具体配置，我才能分析，光看你字相像你的问题理解你的问题，不想动脑了。

chika0801 commented 5 months ago

请教个问题，sb的fake IP DNS，能不能设置成走代理的将域名发送的服务器解析，不走代理的设置成本地解析之后再分流。现在有一种情况，国内有些小众网站，没有包含在cn的域名规则里面，但是它的IP规则又在cn IP规则里面，fake IP的DNS会导致不会解析IP，结果就走了兜底的路由规则。

比如这段，真不想动脑想像，然后你又不是和我相像的一个样。

chika0801 commented 5 months ago

客户端入站添加 "domain_strategy": "prefer_ipv4" 会在本地解析，但是又不会传送域名到服务端。

这个可以回答你，不管你是哪一端，入站，你用了 domain_strategy 后，它将目标地址类型是域名的，查询得到IP，发到出站部分的目标地址，只会是IP。和你入站开不开 sniff": true, + "sniff_override_destination": true 是不冲突的动作（sniff是把别人发过来进sing-box的，目标地址类型是IP的请求做处理）

chika0801 commented 5 months ago

在服务端入站开启 sniff": true, + "sniff_override_destination": true 可以让服务端再解析一次，但嗅探出来的域名又有一些奇奇怪怪的问题，特别是在DNS解锁Netflix的时候。

比如我客户端是SSRP插件，Xrayc-core，发到服务端是目标地址类型是IP。服务端我也是Xray-core，开了sniff，还原目标地址类型成域名，NF域名送到我另外一个VPS，我是从没遇到问题。我认为sing-box当服务端，入站，你开了 sniff": true, + "sniff_override_destination": true 不开 domain_strategy 也应该不会有你说的奇怪问题。你要相信sing-box作者水平。

lin1123 commented 5 months ago 
  "dns": {
    "servers": [
      {
        "tag": "Quad101",
        "address": "https://101.101.101.101/dns-query",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "alidns",
        "address": "https://223.6.6.6/dns-query",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "fakeip",
        "address": "fakeip"
      },
      {
        "tag": "dns_block",
        "address": "rcode://refused"
      }
    ],
    "rules": [
      {
        "rule_set": "category-ads-all",
        "server": "dns_block",
        "disable_cache": true
      },
      {
        "outbound": "any",
        "server": "alidns"
      },
      {
        "query_type": [
          "A",
          "AAAA"
        ],
        "server": "fakeip"
      },
      {
        "domain": [
          "coalcloud.net"
        ],
        "rule_set": [
          "cn",
          "private"
        ],
        "server": "alidns"
      }
    ],
    "fakeip": {
      "enabled": true,
      "inet4_range": "198.18.0.0/15",
      "inet6_range": "fc00::/18"
    },
    "independent_cache": true
  },
  "inbounds": [
    {
      "type": "tun",
      "inet4_address": "172.19.0.1/30",
      "inet6_address": "fdfe:dcba:9876::1/126",
      "auto_route": true,
      "strict_route": true,
      "stack": "system",
      "sniff": true,
      "domain_strategy": "prefer_ipv4"
    }
  ],

贴上DNS部分配置，使用这个配置为客户端，会在本地解析成IP，然后传送到sb服务端，服务端只开启sniff 能正常分流，但这样配置无法在服务端使用DNS解锁流媒体的服务，因为它不会再解析一次。

下方是我的服务端配置

"dns": {
    "servers": [
      {
        "tag": "local",
        "address": "1.1.1.1"
      }
    ],
    "rules": [
      {
        "rule_set": "netflix",
        "server": "local"
      }
    ],
    "strategy": "prefer_ipv4"
  },
  "ntp": {
    "enabled": true,
    "server": "time.cloudflare.com",
    "server_port": 123,
    "interval": "30m0s",
    "detour": "direct"
  },
  "inbounds": [
    {
      "type": "shadowtls",
      "tag": "st-in",
      "listen": "::",
      "listen_port": 10718,
      "detour": "ss-in",
      "sniff": true,
     "sniff_override_destination": true,  //昨晚开了覆盖域名，看Netflix会提示使用代理，关了就好了。
      "version": 3,
      "users": [
        {
          "password": ""
        }
      ],
      "handshake": {
        "server": "www.icloud.com",
        "server_port": 443
      },
      "strict_mode": true
    },
    {
      "type": "shadowsocks",
      "tag": "ss-in",
      "listen": "127.0.0.1",
      "network": "tcp",
      "method": "2022-blake3-aes-128-gcm",
      "password": "",
      "multiplex": {
        "enabled": true
      }
    }
  ],
  "outbounds": [
    {
      "type": "direct",
      "tag": "direct"
    },
    {
      "type": "direct",
      "tag": "warp",
      "detour": "wireguard-out",
      "domain_strategy": "prefer_ipv4"
    },
    {
      "type": "block",
      "tag": "block"
    },
    {
      "type": "dns",
      "tag": "dns-out"
    },
    {
      "type": "wireguard",
      "tag": "wireguard-out",
      "system_interface": true,
      "gso": true,
      "interface_name": "wg0",
      "local_address": [
        "172.16.0.2/32",
        "2606:4700:110:88fd:3924:afeb:66b4:6559/128"
      ],
      "private_key": "",
      "server": "engage.cloudflareclient.com",
      "server_port": 2408,
      "peer_public_key": "",
      "mtu": 1280
    }
  ],
  "route": {
    "rules": [
      {
        "protocol": "dns",
        "outbound": "dns-out"
      },
      {
        "rule_set": "category-ads-all",
        "outbound": "block"
      },
      {
        "rule_set": "google",
        "outbound": "direct"
      },
      {
        "rule_set": [
             "cn",
            "netflix"
        ],
        "outbound": "warp"
      }
    ],
    "rule_set": [
      {
        "type": "remote",
        "tag": "cn",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/sing/geo/mixed/cn.srs",
        "download_detour": "direct"
      },
      {
        "type": "remote",
        "tag": "netflix",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/sing/geo/mixed/netflix.srs",
        "download_detour": "direct"
      },
      {
        "type": "remote",
        "tag": "google",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/sing/geo/mixed/google.srs",
        "download_detour": "direct"
      },
      {
        "type": "remote",
        "tag": "category-ads-all",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/sing/geo/geosite/category-ads-all.srs",
        "download_detour": "direct"
      }
    ],
    "final": "direct",
    "auto_detect_interface": true
  },
  "experimental": {
    "cache_file": {
      "enabled": true
    }
  }
lin1123 commented 5 months ago

客户端入站添加 "domain_strategy": "prefer_ipv4" 会在本地解析，但是又不会传送域名到服务端。

这个可以回答你，不管你是哪一端，入站，你用了 domain_strategy 后，它将目标地址类型是域名的，查询得到IP，发到出站部分的目标地址，只会是IP。和你入站开不开 sniff": true, + "sniff_override_destination": true 是不冲突的动作（sniff是把别人发过来进sing-box的，目标地址类型是IP的请求做处理）

在sb服务端开启 sniff": true, + "sniff_override_destination": true 的目的是想让SB通过本机的DNS再解析一遍，这样DNS流媒体解锁才能劫持的到Netflix的请求。不开"sniff_override_destination": true` 是不会再解析的，会直接路由出站。

chika0801 commented 5 months ago

在sb服务端开启 sniff": true, + "sniff_override_destination": true 的目的是想让SB通过本机的DNS再解析一遍，这样DNS流媒体解锁才能劫持的到Netflix的请求。

从你描述来看，推测你是用的SNI 反代 NF 的所谓DNS解释，那么你肯定要用 sniff": true, + "sniff_override_destination": true 加你DNS部分对应的规则

不开"sniff_override_destination": true `

你看日志也看得到，不开它，送到出站的目标地址IP，是接收到的那个IP。

chika0801 commented 5 months ago

国内有些小众网站，没有包含在cn的域名规则里面，但是它的IP规则又在cn IP规则里面，fake IP的DNS会导致不会解析IP，结果就走了兜底的路由规则。

  "dns": {
    "servers": [
      {
        "tag": "Quad101",
        "address": "https://101.101.101.101/dns-query",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "alidns",
        "address": "https://223.6.6.6/dns-query",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "fakeip",
        "address": "fakeip"
      },
      {
        "tag": "dns_block",
        "address": "rcode://refused"
      }
    ],
    "rules": [
      {
        "rule_set": "category-ads-all",
        "server": "dns_block",
        "disable_cache": true
      },
      {
        "outbound": "any",
        "server": "alidns"
      },
      {
        "domain": [
          "coalcloud.net"
        ],
        "rule_set": [
          "cn",
          "private"
        ],
        "server": "alidns" // 你之前把这段放在 fakeip 后面了，这个规则自然不能命中了，我引用你那段话我测试是这原因引起的。你把fakeip放它前面时，所有的A AAAA记录全返回的fakeip，这规则自然不能有效。除非CN域名是cname。这种细节要到你sing-box配置熟悉，网络知识基础有，才能分析到。你参考我给的示例，分析我那么做的逻辑，都是这样学别人的自己想，慢慢学懂的。
      },
      {
        "query_type": [
          "A",
          "AAAA"
        ],
        "server": "fakeip"
      }
    ],
    "fakeip": {
      "enabled": true,
      "inet4_range": "198.18.0.0/15",
      "inet6_range": "fc00::/18"
    },
    "independent_cache": true
  },
lin1123 commented 5 months ago

国内有些小众网站，没有包含在cn的域名规则里面，但是它的IP规则又在cn IP规则里面，fake IP的DNS会导致不会解析IP，结果就走了兜底的路由规则。

  "dns": {
    "servers": [
      {
        "tag": "Quad101",
        "address": "https://101.101.101.101/dns-query",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "alidns",
        "address": "https://223.6.6.6/dns-query",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "fakeip",
        "address": "fakeip"
      },
      {
        "tag": "dns_block",
        "address": "rcode://refused"
      }
    ],
    "rules": [
      {
        "rule_set": "category-ads-all",
        "server": "dns_block",
        "disable_cache": true
      },
      {
        "outbound": "any",
        "server": "alidns"
      },
      {
        "domain": [
          "coalcloud.net"
        ],
        "rule_set": [
          "cn",
          "private"
        ],
        "server": "alidns" // 你之前把这段放在 fakeip 后面了，这个规则自然不能命中了，我引用你那段话我测试是这原因引起的。
      },
      {
        "query_type": [
          "A",
          "AAAA"
        ],
        "server": "fakeip"
      }
    ],
    "fakeip": {
      "enabled": true,
      "inet4_range": "198.18.0.0/15",
      "inet6_range": "fc00::/18"
    },
    "independent_cache": true
  },

放在fake IP前面的话，如果tun入站开启了IPV6，他会优先解析IPV6地址并发起出站连接，在本地网络没有V6地址的情况下，会出现国内网站无法打开的情况，所有我才放在fake ip的后面。

  "inbounds": [
    {
      "type": "tun",
      "inet4_address": "172.19.0.1/30",
      "inet6_address": "fdfe:dcba:9876::1/126",
      "auto_route": true,
      "strict_route": true,
      "stack": "system",
      "sniff": true,
      "domain_strategy": "prefer_ipv4"  //入站设置了这一行，出站只会传递IP到服务器，之前在文档看见过
    }
  ],
chika0801 commented 5 months ago

https://github.com/chika0801/sing-box-examples/blob/main/Tun/config_client_android_experimental.json#L19

所以你能掌握自己客户端环境时，知道什么时候用v几就填。

要么就老实v4 only，想v6优先，你要考虑查询DNS后得到的v4 v6，发到服务端最终是IP时，服务端还不还原成域名，这种连锁的细节问题。

chika0801 commented 5 months ago 

  "inbounds": [
    {
      "type": "tun",
      "inet4_address": "172.19.0.1/30",
      "inet6_address": "fdfe:dcba:9876::1/126",
      "auto_route": true,
      "strict_route": true,
      "stack": "system",
      "sniff": true, 
      "domain_strategy": "prefer_ipv4" // 这参数你又用了Fakeip时，除非你非常懂sing-box流程，自己看debug日志认真分析过日志是你的目的，不然，我建议你不要使用它。你看我的配置示例我就不会用它。
    }
lin1123 commented 5 months ago 
  "inbounds": [
    {
      "type": "tun",
      "inet4_address": "172.19.0.1/30",
      "inet6_address": "fdfe:dcba:9876::1/126",
      "auto_route": true,
      "strict_route": true,
      "stack": "system",
      "sniff": true, 
      "domain_strategy": "prefer_ipv4" // 这参数你又用了Fakeip时，除非你非常懂sing-box流程，自己看debug日志认真分析过日志是你的目的，不然，我建议你不要使用它。你看我的配置示例我就不会用它。
    }

不要这一条就会出现开头描述的那个问题。

国内有些小众网站，没有包含在cn的域名规则里面，但是它的IP规则又在cn IP规则里面，fake IP的DNS会导致不会解析IP，结果就走了兜底的路由规则。 例如这个网站 > www.coalcloud.net

chika0801 commented 5 months ago 
  "inbounds": [
    {
      "type": "tun",
      "inet4_address": "172.19.0.1/30",
      "inet6_address": "fdfe:dcba:9876::1/126",
      "auto_route": true,
      "strict_route": true,
      "stack": "system",
      "sniff": true,
      "domain_strategy": "prefer_ipv4"  //入站设置了这一行，出站只会传递IP到服务器，之前在文档看见过
    }
  ],

你不放这个参数，一样发到服务端会是IP

https://github.com/chika0801/sing-box-examples/blob/main/Tun/config_client_android_experimental.json

以我这个为例，简单给你说下，假设域名没命中任何DNS的规则 ，最后我是用阿里查DNS得到IP。此IP请求进sing-box还原成域名，没开 "sniff_override_destination": false 。此时IP和域名同时是条件进路由规则，我设这IP不是CN的，最终没命中任何路由规则，走了默认的代理。

此时发到服务端的目标地址类型，就是在客户端，用阿里查到的IP地址。

chika0801 commented 5 months ago

回你这楼问题

https://github.com/chika0801/sing-box-examples/issues/94#issuecomment-1890347229

你这样试下了来，我都是看了你配置，在相像，理论上给你建议解决方法了，你自己先试。

"domain_strategy": "prefer_ipv4" // 这参数你又用了Fakeip时，除非你非常懂sing-box流程，自己看debug日志认真分析过日志是你的目的，不然，我建议你不要使用它。你看我的配置示例我就不会用它。

"server": "alidns" // 你之前把这段放在 fakeip 后面了，这个规则自然不能命中了，我引用你那段话我测试是这原因引起的。你把fakeip放它前面时，所有的A AAAA记录全返回的fakeip，这规则自然不能有效。除非CN域名是cname。这种细节要到你sing-box配置熟悉，网络知识基础有，才能分析到。你参考我给的示例，分析我那么做的逻辑，都是这样学别人的自己想，慢慢学懂的。

把修改后的配置发上来，日志开debug，截一段，自己看看了来。

我看你配置想像得到的问题点，就上面说的那些

chika0801 commented 5 months ago

看了你的服务端配置，你不是用的NS SNI解锁，你是把NF送到WARP去了。

你现在服务端配置流程是这样的，你入站开了

      "sniff": true,
     "sniff_override_destination": true,

接收到的目标地址类型全都还原成域名，

这些请求进路由，命中下面的

      {
        "rule_set": [
             "cn",
            "netflix"
        ],
        "outbound": "warp"
      }

域名送到 "outbound": "warp" 的出站即Wireguard。Wireguard一看是域名，不能直接发进warp，域名会进DNS域名

匹配命中了

    "rules": [
      {
        "rule_set": "netflix",
        "server": "local"
      }
    ],

总规则你是用的 "strategy": "prefer_ipv4" ，得到NF的V4，v4IP进wireguard

chika0801 commented 5 months ago

https://github.com/chika0801/sing-box-examples/blob/main/wireguard.md#%E5%8F%A6%E4%B8%80%E7%A7%8D%E6%96%B9%E5%BC%8F-1

上面的思路用法，在这也有写

lin1123 commented 5 months ago 
+0800 2024-01-13 14:53:56 INFO [3744908844 0ms] outbound/direct[🎯 全球直连]: outbound connection to 202.89.233.100:443
+0800 2024-01-13 14:53:56 DEBUG dns: exchange qq.com. IN AAAA
+0800 2024-01-13 14:53:56 DEBUG dns: exchange qq.com. IN A
+0800 2024-01-13 14:53:56 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 14:53:56 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 14:53:56 DEBUG dns: exchanged qq.com NOERROR 599
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com A qq.com. 599 IN A 123.150.76.218
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com A qq.com. 599 IN A 203.205.254.157
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com A qq.com. 599 IN A 113.108.81.189
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com OPT OPT PSEUDOSECTION: EDNS: version 0 flags: MBZ: 0x0257, udp: 4096
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com. A qq.com. 599 IN A 123.150.76.218
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com. A qq.com. 599 IN A 203.205.254.157
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com. A qq.com. 599 IN A 113.108.81.189
+0800 2024-01-13 14:53:56 DEBUG dns: exchanged qq.com NOERROR 302
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com SOA qq.com. 302 IN SOA ns1.qq.com. webmaster.qq.com. 1330914143 3600 300 86400 300
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com OPT OPT PSEUDOSECTION: EDNS: version 0 flags: MBZ: 0x012e, udp: 4096
+0800 2024-01-13 14:53:56 INFO [498709855 0ms] inbound/tun[0]: inbound connection from 172.19.0.1:2995
+0800 2024-01-13 14:53:56 INFO [498709855 0ms] inbound/tun[0]: inbound connection to 123.150.76.218:443
+0800 2024-01-13 14:53:56 DEBUG [498709855 0ms] router: sniffed protocol: tls, domain: qq.com
+0800 2024-01-13 14:53:56 DEBUG [498709855 0ms] router: match[20] rule_set=cn => 🎯 全球直连
+0800 2024-01-13 14:53:56 INFO [498709855 0ms] outbound/direct[🎯 全球直连]: outbound connection to 123.150.76.218:443
+0800 2024-01-13 14:53:56 DEBUG dns: exchange www.qq.com. IN A
+0800 2024-01-13 14:53:56 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 14:53:56 DEBUG dns: exchange www.qq.com. IN AAAA
+0800 2024-01-13 14:53:56 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 14:53:57 DEBUG dns: exchanged www.qq.com NOERROR 31
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com CNAME www.qq.com. 31 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com A ins-r23tsuuf.ias.tencent-cloud.net. 31 IN A 58.246.163.58
+0800 2024-01-13 14:53:57 DEBUG dns: exchanged www.qq.com NOERROR 9
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com CNAME www.qq.com. 9 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com AAAA ins-r23tsuuf.ias.tencent-cloud.net. 9 IN AAAA 2408:80f1:21:c120::c
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com AAAA ins-r23tsuuf.ias.tencent-cloud.net. 9 IN AAAA 2408:80f1:21:c120::e
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com OPT OPT PSEUDOSECTION: EDNS: version 0 flags: MBZ: 0x0009, udp: 4096
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. CNAME www.qq.com. 9 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. AAAA ins-r23tsuuf.ias.tencent-cloud.net. 9 IN AAAA 2408:80f1:21:c120::c
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. AAAA ins-r23tsuuf.ias.tencent-cloud.net. 9 IN AAAA 2408:80f1:21:c120::e
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com A ins-r23tsuuf.ias.tencent-cloud.net. 31 IN A 116.128.170.212
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com OPT OPT PSEUDOSECTION: EDNS: version 0 flags: MBZ: 0x001f, udp: 4096
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. CNAME www.qq.com. 31 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. A ins-r23tsuuf.ias.tencent-cloud.net. 31 IN A 58.246.163.58
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. A ins-r23tsuuf.ias.tencent-cloud.net. 31 IN A 116.128.170.212
+0800 2024-01-13 14:53:57 INFO [452703663 0ms] inbound/tun[0]: inbound connection from [fdfe:dcba:9876::1]:2997
+0800 2024-01-13 14:53:57 INFO [452703663 0ms] inbound/tun[0]: inbound connection to [2408:80f1:21:c120::c]:443
+0800 2024-01-13 14:53:57 DEBUG [452703663 0ms] router: sniffed protocol: tls, domain: www.qq.com
+0800 2024-01-13 14:53:57 DEBUG [452703663 0ms] router: match[20] rule_set=cn => 🎯 全球直连
+0800 2024-01-13 14:53:57 INFO [452703663 0ms] outbound/direct[🎯 全球直连]: outbound connection to [2408:80f1:21:c120::c]:443
+0800 2024-01-13 14:53:57 ERROR [452703663 0ms] inbound/tun[0]: dial tcp [2408:80f1:21:c120::c]:443: An invalid argument was supplied.
+0800 2024-01-13 14:53:57 INFO [3066516418 0ms] inbound/tun[0]: inbound connection from [fdfe:dcba:9876::1]:2998
+0800 2024-01-13 14:53:57 INFO [3066516418 0ms] inbound/tun[0]: inbound connection to [2408:80f1:21:c120::c]:443
+0800 2024-01-13 14:53:57 DEBUG [3066516418 0ms] router: sniffed protocol: tls, domain: www.qq.com
+0800 2024-01-13 14:53:57 DEBUG [3066516418 0ms] router: match[20] rule_set=cn => 🎯 全球直连
+0800 2024-01-13 14:53:57 INFO [3066516418 0ms] outbound/direct[🎯 全球直连]: outbound connection to [2408:80f1:21:c120::c]:443
+0800 2024-01-13 14:53:57 ERROR [3066516418 0ms] inbound/tun[0]: dial tcp [2408:80f1:21:c120::c]:443: An invalid argument was supplied.

日志

  "dns": {
    "servers": [
      {
        "tag": "Quad101",
        "address": "https://101.101.101.101/dns-query",
        "strategy": "prefer_ipv4",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "alidns",
        "address": "https://223.6.6.6/dns-query",
        "strategy": "prefer_ipv4",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "fakeip",
        "address": "fakeip"
      },
      {
        "tag": "dns_block",
        "address": "rcode://refused"
      }
    ],
    "rules": [
      {
        "rule_set": "category-ads-all",
        "server": "dns_block",
        "disable_cache": true
      },
      {
        "outbound": "any",
        "server": "alidns"
      },
      {
        "domain": [
          "coalcloud.net"
        ],
        "rule_set": [
          "cn",
          "private"
        ],
        "server": "alidns"
      },
      {
        "query_type": [
          "A",
          "AAAA"
        ],
        "server": "fakeip"
      }
    ],
    "fakeip": {
      "enabled": true,
      "inet4_range": "198.18.0.0/15",
      "inet6_range": "fc00::/18"
    },
    "independent_cache": true
  },
  "inbounds": [
    {
      "type": "tun",
      "inet4_address": "172.19.0.1/30",
      "inet6_address": "fdfe:dcba:9876::1/126",
      "auto_route": true,
      "strict_route": true,
      "stack": "system",
      "sniff": true
//      "domain_strategy": "prefer_ipv4"
    }
  ],

DNS 规则

chika0801 commented 5 months ago

补充一个和问题无关的，解锁NF，你买台落地机，入站你开嗅探还原域名，路由规则 把NF域名转到对应出站发给那台解锁机，我一般是用SS协议，你用WARP解锁节约这点钱，还不稳定。

chika0801 commented 5 months ago 
+0800 2024-01-13 14:53:56 INFO [3744908844 0ms] outbound/direct[🎯 全球直连]: outbound connection to 202.89.233.100:443
+0800 2024-01-13 14:53:56 DEBUG dns: exchange qq.com. IN AAAA
+0800 2024-01-13 14:53:56 DEBUG dns: exchange qq.com. IN A
+0800 2024-01-13 14:53:56 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 14:53:56 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 14:53:56 DEBUG dns: exchanged qq.com NOERROR 599
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com A qq.com. 599 IN A 123.150.76.218
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com A qq.com. 599 IN A 203.205.254.157
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com A qq.com. 599 IN A 113.108.81.189
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com OPT OPT PSEUDOSECTION: EDNS: version 0 flags: MBZ: 0x0257, udp: 4096
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com. A qq.com. 599 IN A 123.150.76.218
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com. A qq.com. 599 IN A 203.205.254.157
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com. A qq.com. 599 IN A 113.108.81.189
+0800 2024-01-13 14:53:56 DEBUG dns: exchanged qq.com NOERROR 302
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com SOA qq.com. 302 IN SOA ns1.qq.com. webmaster.qq.com. 1330914143 3600 300 86400 300
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com OPT OPT PSEUDOSECTION: EDNS: version 0 flags: MBZ: 0x012e, udp: 4096
+0800 2024-01-13 14:53:56 INFO [498709855 0ms] inbound/tun[0]: inbound connection from 172.19.0.1:2995
+0800 2024-01-13 14:53:56 INFO [498709855 0ms] inbound/tun[0]: inbound connection to 123.150.76.218:443
+0800 2024-01-13 14:53:56 DEBUG [498709855 0ms] router: sniffed protocol: tls, domain: qq.com
+0800 2024-01-13 14:53:56 DEBUG [498709855 0ms] router: match[20] rule_set=cn => 🎯 全球直连
+0800 2024-01-13 14:53:56 INFO [498709855 0ms] outbound/direct[🎯 全球直连]: outbound connection to 123.150.76.218:443
+0800 2024-01-13 14:53:56 DEBUG dns: exchange www.qq.com. IN A
+0800 2024-01-13 14:53:56 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 14:53:56 DEBUG dns: exchange www.qq.com. IN AAAA
+0800 2024-01-13 14:53:56 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 14:53:57 DEBUG dns: exchanged www.qq.com NOERROR 31
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com CNAME www.qq.com. 31 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com A ins-r23tsuuf.ias.tencent-cloud.net. 31 IN A 58.246.163.58
+0800 2024-01-13 14:53:57 DEBUG dns: exchanged www.qq.com NOERROR 9
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com CNAME www.qq.com. 9 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com AAAA ins-r23tsuuf.ias.tencent-cloud.net. 9 IN AAAA 2408:80f1:21:c120::c
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com AAAA ins-r23tsuuf.ias.tencent-cloud.net. 9 IN AAAA 2408:80f1:21:c120::e
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com OPT OPT PSEUDOSECTION: EDNS: version 0 flags: MBZ: 0x0009, udp: 4096
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. CNAME www.qq.com. 9 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. AAAA ins-r23tsuuf.ias.tencent-cloud.net. 9 IN AAAA 2408:80f1:21:c120::c
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. AAAA ins-r23tsuuf.ias.tencent-cloud.net. 9 IN AAAA 2408:80f1:21:c120::e
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com A ins-r23tsuuf.ias.tencent-cloud.net. 31 IN A 116.128.170.212
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com OPT OPT PSEUDOSECTION: EDNS: version 0 flags: MBZ: 0x001f, udp: 4096
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. CNAME www.qq.com. 31 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. A ins-r23tsuuf.ias.tencent-cloud.net. 31 IN A 58.246.163.58
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. A ins-r23tsuuf.ias.tencent-cloud.net. 31 IN A 116.128.170.212
+0800 2024-01-13 14:53:57 INFO [452703663 0ms] inbound/tun[0]: inbound connection from [fdfe:dcba:9876::1]:2997
+0800 2024-01-13 14:53:57 INFO [452703663 0ms] inbound/tun[0]: inbound connection to [2408:80f1:21:c120::c]:443
+0800 2024-01-13 14:53:57 DEBUG [452703663 0ms] router: sniffed protocol: tls, domain: www.qq.com
+0800 2024-01-13 14:53:57 DEBUG [452703663 0ms] router: match[20] rule_set=cn => 🎯 全球直连
+0800 2024-01-13 14:53:57 INFO [452703663 0ms] outbound/direct[🎯 全球直连]: outbound connection to [2408:80f1:21:c120::c]:443
+0800 2024-01-13 14:53:57 ERROR [452703663 0ms] inbound/tun[0]: dial tcp [2408:80f1:21:c120::c]:443: An invalid argument was supplied.
+0800 2024-01-13 14:53:57 INFO [3066516418 0ms] inbound/tun[0]: inbound connection from [fdfe:dcba:9876::1]:2998
+0800 2024-01-13 14:53:57 INFO [3066516418 0ms] inbound/tun[0]: inbound connection to [2408:80f1:21:c120::c]:443
+0800 2024-01-13 14:53:57 DEBUG [3066516418 0ms] router: sniffed protocol: tls, domain: www.qq.com
+0800 2024-01-13 14:53:57 DEBUG [3066516418 0ms] router: match[20] rule_set=cn => 🎯 全球直连
+0800 2024-01-13 14:53:57 INFO [3066516418 0ms] outbound/direct[🎯 全球直连]: outbound connection to [2408:80f1:21:c120::c]:443
+0800 2024-01-13 14:53:57 ERROR [3066516418 0ms] inbound/tun[0]: dial tcp [2408:80f1:21:c120::c]:443: An invalid argument was supplied.

看了这日志中qq.com的过程，不是正常了嘛

qq.com得到的IP，走了 你本地的直连出站outbound/direct ，你DNS设置的perferv4，看日志它使用了qq的v6我也不清楚原因了。

lin1123 commented 5 months ago

看了你的服务端配置，你不是用的NS SNI解锁，你是把NF送到WARP去了。

你现在服务端配置流程是这样的，你入站开了

      "sniff": true,
     "sniff_override_destination": true,

接收到的目标地址类型全都还原成域名，

这些请求进路由，命中下面的

      {
        "rule_set": [
             "cn",
            "netflix"
        ],
        "outbound": "warp"
      }

域名送到 "outbound": "warp" 的出站即Wireguard。Wireguard一看是域名，不能直接发进warp，域名会进DNS域名

匹配命中了

    "rules": [
      {
        "rule_set": "netflix",
        "server": "local"
      }
    ],

总规则你是用的 "strategy": "prefer_ipv4" ，得到NF的V4，v4IP进wireguard

补充一个和问题无关的，解锁NF，你买台落地机，入站你开嗅探还原域名，路由规则 把NF域名转到对应出站发给那台解锁机，我一般是用SS协议，你用WARP解锁节约这点钱，还不稳定。

我是在SG的落地机上用的免费的DNS解锁

lin1123 commented 5 months ago 
+0800 2024-01-13 14:53:56 INFO [3744908844 0ms] outbound/direct[🎯 全球直连]: outbound connection to 202.89.233.100:443
+0800 2024-01-13 14:53:56 DEBUG dns: exchange qq.com. IN AAAA
+0800 2024-01-13 14:53:56 DEBUG dns: exchange qq.com. IN A
+0800 2024-01-13 14:53:56 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 14:53:56 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 14:53:56 DEBUG dns: exchanged qq.com NOERROR 599
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com A qq.com. 599 IN A 123.150.76.218
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com A qq.com. 599 IN A 203.205.254.157
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com A qq.com. 599 IN A 113.108.81.189
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com OPT OPT PSEUDOSECTION: EDNS: version 0 flags: MBZ: 0x0257, udp: 4096
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com. A qq.com. 599 IN A 123.150.76.218
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com. A qq.com. 599 IN A 203.205.254.157
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com. A qq.com. 599 IN A 113.108.81.189
+0800 2024-01-13 14:53:56 DEBUG dns: exchanged qq.com NOERROR 302
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com SOA qq.com. 302 IN SOA ns1.qq.com. webmaster.qq.com. 1330914143 3600 300 86400 300
+0800 2024-01-13 14:53:56 INFO dns: exchanged qq.com OPT OPT PSEUDOSECTION: EDNS: version 0 flags: MBZ: 0x012e, udp: 4096
+0800 2024-01-13 14:53:56 INFO [498709855 0ms] inbound/tun[0]: inbound connection from 172.19.0.1:2995
+0800 2024-01-13 14:53:56 INFO [498709855 0ms] inbound/tun[0]: inbound connection to 123.150.76.218:443
+0800 2024-01-13 14:53:56 DEBUG [498709855 0ms] router: sniffed protocol: tls, domain: qq.com
+0800 2024-01-13 14:53:56 DEBUG [498709855 0ms] router: match[20] rule_set=cn => 🎯 全球直连
+0800 2024-01-13 14:53:56 INFO [498709855 0ms] outbound/direct[🎯 全球直连]: outbound connection to 123.150.76.218:443
+0800 2024-01-13 14:53:56 DEBUG dns: exchange www.qq.com. IN A
+0800 2024-01-13 14:53:56 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 14:53:56 DEBUG dns: exchange www.qq.com. IN AAAA
+0800 2024-01-13 14:53:56 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 14:53:57 DEBUG dns: exchanged www.qq.com NOERROR 31
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com CNAME www.qq.com. 31 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com A ins-r23tsuuf.ias.tencent-cloud.net. 31 IN A 58.246.163.58
+0800 2024-01-13 14:53:57 DEBUG dns: exchanged www.qq.com NOERROR 9
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com CNAME www.qq.com. 9 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com AAAA ins-r23tsuuf.ias.tencent-cloud.net. 9 IN AAAA 2408:80f1:21:c120::c
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com AAAA ins-r23tsuuf.ias.tencent-cloud.net. 9 IN AAAA 2408:80f1:21:c120::e
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com OPT OPT PSEUDOSECTION: EDNS: version 0 flags: MBZ: 0x0009, udp: 4096
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. CNAME www.qq.com. 9 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. AAAA ins-r23tsuuf.ias.tencent-cloud.net. 9 IN AAAA 2408:80f1:21:c120::c
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. AAAA ins-r23tsuuf.ias.tencent-cloud.net. 9 IN AAAA 2408:80f1:21:c120::e
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com A ins-r23tsuuf.ias.tencent-cloud.net. 31 IN A 116.128.170.212
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com OPT OPT PSEUDOSECTION: EDNS: version 0 flags: MBZ: 0x001f, udp: 4096
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. CNAME www.qq.com. 31 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. A ins-r23tsuuf.ias.tencent-cloud.net. 31 IN A 58.246.163.58
+0800 2024-01-13 14:53:57 INFO dns: exchanged www.qq.com. A ins-r23tsuuf.ias.tencent-cloud.net. 31 IN A 116.128.170.212
+0800 2024-01-13 14:53:57 INFO [452703663 0ms] inbound/tun[0]: inbound connection from [fdfe:dcba:9876::1]:2997
+0800 2024-01-13 14:53:57 INFO [452703663 0ms] inbound/tun[0]: inbound connection to [2408:80f1:21:c120::c]:443
+0800 2024-01-13 14:53:57 DEBUG [452703663 0ms] router: sniffed protocol: tls, domain: www.qq.com
+0800 2024-01-13 14:53:57 DEBUG [452703663 0ms] router: match[20] rule_set=cn => 🎯 全球直连
+0800 2024-01-13 14:53:57 INFO [452703663 0ms] outbound/direct[🎯 全球直连]: outbound connection to [2408:80f1:21:c120::c]:443
+0800 2024-01-13 14:53:57 ERROR [452703663 0ms] inbound/tun[0]: dial tcp [2408:80f1:21:c120::c]:443: An invalid argument was supplied.
+0800 2024-01-13 14:53:57 INFO [3066516418 0ms] inbound/tun[0]: inbound connection from [fdfe:dcba:9876::1]:2998
+0800 2024-01-13 14:53:57 INFO [3066516418 0ms] inbound/tun[0]: inbound connection to [2408:80f1:21:c120::c]:443
+0800 2024-01-13 14:53:57 DEBUG [3066516418 0ms] router: sniffed protocol: tls, domain: www.qq.com
+0800 2024-01-13 14:53:57 DEBUG [3066516418 0ms] router: match[20] rule_set=cn => 🎯 全球直连
+0800 2024-01-13 14:53:57 INFO [3066516418 0ms] outbound/direct[🎯 全球直连]: outbound connection to [2408:80f1:21:c120::c]:443
+0800 2024-01-13 14:53:57 ERROR [3066516418 0ms] inbound/tun[0]: dial tcp [2408:80f1:21:c120::c]:443: An invalid argument was supplied.

看了这日志中qq.com的过程，不是正常了嘛

本地网络如果没有V6，就无法访问。之前在sb那边看见过这个iss，开发者的意见是全局fake ip

lin1123 commented 5 months ago

+0800 2024-01-13 14:53:57 ERROR [3066516418 0ms] inbound/tun[0]: dial tcp [2408:80f1:21:c120::c]:443: An invalid argument was supplied. 这里报错

chika0801 commented 5 months ago

本地网络如果没有V6，就无法访问。之前在sb那边看见过这个iss，开发者的意见是全局fake ip

      {
        "tag": "alidns",
        "address": "https://223.6.6.6/dns-query",
        "strategy": "prefer_ipv4", // 这改V4 only你再看日志了
        "detour": "🎯 全球直连"
      },

你把出站也可以帖下 tag proxy 可省略。不过应该没什么特别的吧。

chika0801 commented 5 months ago

~另外再建议一点，因为没看到客户端完整配置（你没发出站部分)~

~我特意试了我这个配置 https://github.com/chika0801/sing-box-examples/blob/main/Tun/config_client_android_experimental.json#L19~

~把这里改成 perferv6 v6优先，我手机上用，然后手机接的WIFI是只有v4，SFA在我手机上我是用的全局接管，没分应用，打开QQ网站检查IP网站都只有V4没遇到问题。~

重新说下结果：

只改这个参数

我特意试了我这个配置 https://github.com/chika0801/sing-box-examples/blob/main/Tun/config_client_android_experimental.json#L19

测试方法 我手机上用，然后手机接的WIFI是只有v4，SFA在我手机上只代理chrome，打开Qq.com测试

perferv6 perferv4 观察日志最终都访问成qq.com的v6，本地没v6，打不开

和你遇到的一样的现象

只有改 ipv4_only 就打开了

chika0801 commented 5 months ago

建议你，不要发ISS问sing-box作者why，可能作者就是这样设计的，自己知道解决方法，老实用ipv4 only完事

要不然自己要研究得会代码看作者 perferv6 perferv4 逻辑关系，我也不会，我也不会发ISS说这是BUG。

关于本地遇到这现象这问题，你不问，我平时一直手机上是有v4v6环境，用过preferv6 v4 only，所以我一直没遇到你这现象。谢谢你提这个问题，让我们sing-box又学到东西。

lin1123 commented 5 months ago 
+0800 2024-01-13 15:19:37 DEBUG dns: exchange www.google.com. IN A
+0800 2024-01-13 15:19:37 DEBUG [1864602847 0ms] router: sniffed packet protocol: dns
+0800 2024-01-13 15:19:37 DEBUG [1864602847 0ms] router: match[0] protocol=dns => dns-out
+0800 2024-01-13 15:19:37 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 15:19:37 DEBUG dns: exchange www.google.com. IN AAAA
+0800 2024-01-13 15:19:37 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 15:19:37 DEBUG dns: strategy rejected
+0800 2024-01-13 15:19:37 INFO [3908191581 0ms] inbound/tun[0]: inbound packet connection from 172.19.0.1:63716
+0800 2024-01-13 15:19:37 INFO [3908191581 0ms] inbound/tun[0]: inbound packet connection to 172.19.0.2:53
+0800 2024-01-13 15:19:37 DEBUG [3908191581 0ms] router: sniffed packet protocol: dns
+0800 2024-01-13 15:19:37 DEBUG [3908191581 0ms] router: match[0] protocol=dns => dns-out
+0800 2024-01-13 15:19:37 DEBUG dns: exchange www.google.com. IN AAAA
+0800 2024-01-13 15:19:37 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 15:19:37 DEBUG dns: strategy rejected
+0800 2024-01-13 15:19:37 INFO [1389507582 0ms] inbound/tun[0]: inbound packet connection from [fdfe:dcba:9876::1]:56549
+0800 2024-01-13 15:19:37 INFO [1389507582 0ms] inbound/tun[0]: inbound packet connection to [fdfe:dcba:9876::2]:53
+0800 2024-01-13 15:19:37 DEBUG [1389507582 0ms] router: sniffed packet protocol: dns
+0800 2024-01-13 15:19:37 DEBUG [1389507582 0ms] router: match[0] protocol=dns => dns-out
+0800 2024-01-13 15:19:37 DEBUG dns: exchange www.gstatic.com. IN A
+0800 2024-01-13 15:19:37 INFO [2847734135 0ms] inbound/tun[0]: inbound packet connection from [fdfe:dcba:9876::1]:60037
+0800 2024-01-13 15:19:37 INFO [2847734135 0ms] inbound/tun[0]: inbound packet connection to [fdfe:dcba:9876::2]:53
+0800 2024-01-13 15:19:37 DEBUG [2847734135 0ms] router: sniffed packet protocol: dns
+0800 2024-01-13 15:19:37 DEBUG [2847734135 0ms] router: match[0] protocol=dns => dns-out
+0800 2024-01-13 15:19:37 DEBUG dns: exchange www.gstatic.com. IN AAAA
+0800 2024-01-13 15:19:37 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 15:19:37 DEBUG dns: strategy rejected
+0800 2024-01-13 15:19:37 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 15:19:37 INFO [412804913 0ms] inbound/tun[0]: inbound packet connection from 172.19.0.1:60037
+0800 2024-01-13 15:19:37 INFO [412804913 0ms] inbound/tun[0]: inbound packet connection to 172.19.0.2:53
+0800 2024-01-13 15:19:37 DEBUG [412804913 0ms] router: sniffed packet protocol: dns
+0800 2024-01-13 15:19:37 DEBUG [412804913 0ms] router: match[0] protocol=dns => dns-out
+0800 2024-01-13 15:19:37 DEBUG dns: exchange www.gstatic.com. IN AAAA
+0800 2024-01-13 15:19:37 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 15:19:37 DEBUG dns: strategy rejected
+0800 2024-01-13 15:19:37 INFO [1779909635 0ms] inbound/tun[0]: inbound packet connection from 172.19.0.1:62465
+0800 2024-01-13 15:19:37 INFO [2952350166 0ms] inbound/tun[0]: inbound packet connection from 172.19.0.1:56549
+0800 2024-01-13 15:19:37 INFO [2952350166 0ms] inbound/tun[0]: inbound packet connection to 172.19.0.2:53
+0800 2024-01-13 15:19:37 INFO [1779909635 0ms] inbound/tun[0]: inbound packet connection to 172.19.0.2:53
+0800 2024-01-13 15:19:37 DEBUG [2952350166 0ms] router: sniffed packet protocol: dns
+0800 2024-01-13 15:19:37 DEBUG [2952350166 0ms] router: match[0] protocol=dns => dns-out
+0800 2024-01-13 15:19:37 DEBUG [1779909635 0ms] router: sniffed packet protocol: dns
+0800 2024-01-13 15:19:37 DEBUG [1779909635 0ms] router: match[0] protocol=dns => dns-out
+0800 2024-01-13 15:19:37 DEBUG dns: exchange www.gstatic.com. IN A
+0800 2024-01-13 15:19:37 DEBUG dns: exchange www.google.com. IN A
+0800 2024-01-13 15:19:37 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 15:19:37 DEBUG dns: match[2] domain=coalcloud.net rule_set=[cn private] => alidns
+0800 2024-01-13 15:19:37 DEBUG dns: exchanged www.google.com NOERROR 2
+0800 2024-01-13 15:19:37 INFO dns: exchanged www.google.com A www.google.com. 2 IN A 199.59.149.237
+0800 2024-01-13 15:19:37 INFO dns: exchanged www.google.com OPT OPT PSEUDOSECTION: EDNS: version 0 flags: MBZ: 0x0002, udp: 4096
+0800 2024-01-13 15:19:37 INFO dns: exchanged www.google.com. A www.google.com. 2 IN A 199.59.149.237
+0800 2024-01-13 15:19:37 INFO [4145636744 0ms] inbound/tun[0]: inbound connection from 172.19.0.1:11887
+0800 2024-01-13 15:19:37 INFO [4145636744 0ms] inbound/tun[0]: inbound connection to 199.59.149.237:443
+0800 2024-01-13 15:19:37 DEBUG [4145636744 0ms] router: sniffed protocol: tls, domain: www.google.com
+0800 2024-01-13 15:19:37 DEBUG [4145636744 0ms] router: match[15] rule_set=google => 🚀 节点选择
+0800 2024-01-13 15:19:37 INFO [4145636744 0ms] outbound/vless[🇭🇰 广港→Vm]: outbound multiplex connection to 199.59.149.237:443

日志

  "dns": {
    "servers": [
      {
        "tag": "Quad101",
        "address": "https://101.101.101.101/dns-query",
        "strategy": "prefer_ipv4",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "alidns",
        "address": "https://223.6.6.6/dns-query",
        "strategy": "ipv4_only",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "fakeip",
        "address": "fakeip"
      },
      {
        "tag": "dns_block",
        "address": "rcode://refused"
      }
    ],
    "rules": [
      {
        "rule_set": "category-ads-all",
        "server": "dns_block",
        "disable_cache": true
      },
      {
        "outbound": "any",
        "server": "alidns"
      },
      {
        "domain": [
          "coalcloud.net"
        ],
        "rule_set": [
          "cn",
          "private"
        ],
        "server": "alidns"
      },
      {
        "query_type": [
          "A",
          "AAAA"
        ],
        "server": "fakeip"
      }
    ],
    "fakeip": {
      "enabled": true,
      "inet4_range": "198.18.0.0/15",
      "inet6_range": "fc00::/18"
    },
    "independent_cache": true
  },
  "inbounds": [
    {
      "type": "tun",
      "inet4_address": "172.19.0.1/30",
      "inet6_address": "fdfe:dcba:9876::1/126",
      "auto_route": true,
      "strict_route": true,
      "stack": "system",
      "sniff": true
//      "domain_strategy": "prefer_ipv4"
    }
  ],

这样设置DNS，居然走的是阿里的解析，传递到服务器的好像是污染的ip，结果访问不了

lin1123 commented 5 months ago

建议你，不要发ISS问sing-box作者why，可能作者就是这样设计的，自己知道解决方法，老实用ipv4 only完事

要不然自己要研究得会代码看作者 perferv6 perferv4 逻辑关系，我也不会，我也不会发ISS说这是BUG。

关于本地遇到这现象这问题，你不问，我平时一直手机上是有v4v6环境，用过preferv6 v4 only，所以我一直没遇到你这现象。谢谢你提这个问题，让我们sing-box又学到东西。

因为我的网络环境一直在变化，配置就一套支持双栈的，本地网络有时候有V6，有时候又没有，偶然发现这个问题的，我自己的alist 服务器解析了双栈，死活打不开。后面看日志，看连接才发现走的V6访问，结果本地没有V6网络访问能力。

chika0801 commented 5 months ago

测试了一下，可这样

客户端入站

"sniff_override_destination": true,

不写 "domain_strategy": "prefer_ipv4"

比如qq.com的连接请求进入站，还原成域名，过你路由规则，直连出站。

sing-box的直连出站接收到的目标地址是域名时，会用内置dns，此时dns规则你写的是prefer v4，当你在只有v4wifi时，就会v4。

如果是命中fakeip的请求还原成域名，在你路由规则中命中走代理。

我在手机上初测了下可以的。

具体研究方法还是你找测试域名，看日志研究它的流程。

chika0801 commented 5 months ago

反正你客户端遇到的这现象，我想了下就这解决方法。服务端的问题，你再花时间自己研究下了。

chika0801 commented 5 months ago

我想了下原理

设wifi是只有v4， 手机用sfa，接wifi，入站tun设置参数中启用了v4 v6地址。

测试用qq.com，域名解析出是有v4v6，入站开sniff，不开override。

由于sfa的tun环境网卡模拟是有v4 v6的，dns配置中也是正确解析出qq.com的v4 v6，这里暂不管preferv4 或 v6区别。

dns得到ip后，被sniff还原成域名，不开override，域名和ip进路由命中cnip直连。

进入出站部分的目标地址是qq.com的v4 v6，此时谁优先，假设在tun虚拟网卡这层不讨论，这组qq.com送回上一层网卡，这里指手机接wifi，只有v4地址这一层，此时安卓系统设是v6优先，这层的卡网只有v4，访问qq.com失败，没人管（即不会回落再尝试访问qq的v4）

所以我们看到浏览器表现就是网址打不开。

我还拿v2rayng，xray配置，类似道理的流程来复现，一样能复现故障。

我认为这不是哪个core应该管的，反正没人管，懂的用户就懂。

lin1123 commented 5 months ago

我想了下原理

设wifi是只有v4， 手机用sfa，接wifi，入站tun设置参数中启用了v4 v6地址。

测试用qq.com，域名解析出是有v4v6，入站开sniff，不开override。

由于sfa的tun环境网卡模拟是有v4 v6的，dns配置中也是正确解析出qq.com的v4 v6，这里暂不管preferv4 或 v6区别。

dns得到ip后，被sniff还原成域名，不开override，域名和ip进路由命中cnip直连。

进入出站部分的目标地址是qq.com的v4 v6，此时谁优先，假设在tun虚拟网卡这层不讨论，这组qq.com送回上一层网卡，这里指手机接wifi，只有v4地址这一层，此时安卓系统设是v6优先，这层的卡网只有v4，访问qq.com失败，没人管（即不会回落再尝试访问qq的v4）

所以我们看到浏览器表现就是网址打不开。

我还拿v2rayng，xray配置，类似道理的流程来复现，一样能复现故障。

我认为这不是哪个core应该管的，反正没人管，懂的用户就懂。

大佬厉害，确实是这个原因，只要tun开启了v6，就会v6优先连接，所以才导致这个问题。主要还是没有GUI不方便随时开关。

lin1123 commented 5 months ago 
  "dns": {
    "servers": [
      {
        "tag": "Quad101",
        "address": "https://101.101.101.101/dns-query",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "alidns",
        "address": "https://223.6.6.6/dns-query",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "fakeip",
        "address": "fakeip"
      },
      {
        "tag": "dns_block",
        "address": "rcode://refused"
      }
    ],
    "rules": [
      {
        "rule_set": "category-ads-all",
        "server": "dns_block",
        "disable_cache": true
      },
      {
        "outbound": "any",
        "server": "alidns"
      },
      {
        "domain": [
          "coalcloud.net"
        ],
        "rule_set": [
          "cn",
          "private"
        ],
        "server": "alidns" // 你之前把这段放在 fakeip 后面了，这个规则自然不能命中了，我引用你那段话我测试是这原因引起的。
      },
      {
        "query_type": [
          "A",
          "AAAA"
        ],
        "server": "fakeip"
      }
    ],
    "fakeip": {
      "enabled": true,
      "inet4_range": "198.18.0.0/15",
      "inet6_range": "fc00::/18"
    },
    "independent_cache": true
  },

这样设置dns，访问被墙的会走阿里dns解析，并没有走fake ip传递域。 我想实现CN合集下的直接解析，没有在CN合集里面的域名规则，全部走fake ip。该怎么设置DNS？

chika0801 commented 5 months ago

访问被墙的会走阿里dns解析

看了你发的规则 ，逻辑上来说不会发生你说的

不知道你用什么域名测的

你读下规则 ，比如google.com从上到下，先不会命中

      {
        "domain": [
          "coalcloud.net"
        ],
        "rule_set": [
          "cn",
          "private"
        ],
        "server": "alidns" // 你之前把这段放在 fakeip 后面了，这个规则自然不能命中了，我引用你那段话我测试是这原因引起的。
      },

然后 它的 的A AAAA命中fakeip，它的非A AAAA 命中你默认的第1个DNS即 "tag": "Quad101",

chika0801 commented 5 months ago

https://github.com/chika0801/sing-box-examples/blob/main/Tun/config_client_android_experimental.json

逻辑道理你参考这个里面

lin1123 commented 5 months ago

访问被墙的会走阿里dns解析

看了你发的规则 ，逻辑上来说不会发生你说的

不知道你用什么域名测的

你读下规则 ，比如google.com从上到下，先不会命中

      {
        "domain": [
          "coalcloud.net"
        ],
        "rule_set": [
          "cn",
          "private"
        ],
        "server": "alidns" // 你之前把这段放在 fakeip 后面了，这个规则自然不能命中了，我引用你那段话我测试是这原因引起的。
      },

然后 它的 的A AAAA命中fakeip，它的非A AAAA 命中你默认的第1个DNS即 "tag": "Quad101",

用google,跟youtube测试的，所有的域名解析都走了阿里，没有通过fake ip，我也搞不明白啥原因。

lin1123 commented 5 months ago 
{
  "log": {
    "level": "debug",
    "output": "box.log",
    "timestamp": true
  },
  "dns": {
    "servers": [
      {
        "tag": "Quad101",
        "address": "https://101.101.101.101/dns-query",
        "strategy": "ipv4_only",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "alidns",
        "address": "https://223.6.6.6/dns-query",
        "strategy": "ipv4_only",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "fakeip",
        "address": "fakeip"
      },
      {
        "tag": "dns_block",
        "address": "rcode://refused"
      }
    ],
    "rules": [
      {
        "rule_set": "category-ads-all",
        "server": "dns_block",
        "disable_cache": true
      },
      {
        "outbound": "any",
        "server": "alidns"
      },
      {
        "rule_set": [
          "cn",
          "lan"
        ],
        "query_type": [
          "A",
          "AAAA"
        ],
        "invert": true,
        "server": "fakeip"
      },
      {
        "rule_set": [
          "cn",
          "lan"
        ],
        "server": "alidns"
      }
    ],
    "fakeip": {
      "enabled": true,
      "inet4_range": "198.18.0.0/15",
      "inet6_range": "fc00::/18"
    },
    "independent_cache": true
  },
  "inbounds": [
    {
      "type": "tun",
      "inet4_address": "172.19.0.1/30",
      "inet6_address": "fdfe:dcba:9876::1/126",
      "auto_route": true,
      "strict_route": true,
      "stack": "system",
      "sniff": true
    }
  ],

我这样配置想实现CN规则在客户端进行dns解析，其他的全部走fake ip传递，走代理的传递到远端解析，不走代理的本地解析。结果还是走的阿里dns。不知道是rule_set反选不起作用，还是其他原因导致的。

lin1123 commented 5 months ago 
+0800 2024-01-14 20:40:59 DEBUG dns: exchange www.google.com. IN AAAA
+0800 2024-01-14 20:40:59 DEBUG dns: match[3] rule_set=[cn lan] => alidns
+0800 2024-01-14 20:40:59 DEBUG dns: strategy rejected
+0800 2024-01-14 20:40:59 INFO [2070463995 0ms] inbound/tun[0]: inbound packet connection from 172.19.0.1:51312
+0800 2024-01-14 20:40:59 INFO [2070463995 0ms] inbound/tun[0]: inbound packet connection to 172.19.0.2:53
+0800 2024-01-14 20:40:59 DEBUG [2070463995 0ms] router: sniffed packet protocol: dns
+0800 2024-01-14 20:40:59 INFO [2070463995 0ms] router: found process path: \Device\HarddiskVolume2\Windows\System32\svchost.exe
+0800 2024-01-14 20:40:59 DEBUG [2070463995 0ms] router: match[0] protocol=dns => dns-out
+0800 2024-01-14 20:40:59 DEBUG dns: exchange www.google.com. IN AAAA
+0800 2024-01-14 20:40:59 DEBUG dns: match[3] rule_set=[cn lan] => alidns
+0800 2024-01-14 20:40:59 DEBUG dns: strategy rejected

日志这样的

lin1123 commented 5 months ago 
{
  "log": {
    "level": "debug",
    "output": "box.log",
    "timestamp": true
  },
  "dns": {
    "servers": [
      {
        "tag": "Quad101",
        "address": "https://101.101.101.101/dns-query",
        "strategy": "ipv4_only",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "alidns",
        "address": "https://223.6.6.6/dns-query",
        "strategy": "ipv4_only",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "fakeip",
        "address": "fakeip"
      },
      {
        "tag": "dns_block",
        "address": "rcode://refused"
      }
    ],
    "rules": [
      {
        "rule_set": "category-ads-all",
        "server": "dns_block",
        "disable_cache": true
      },
      {
        "outbound": "any",
        "server": "alidns"
      },
      {
        "rule_set": [
          "cn",
          "lan"
        ],
        "server": "alidns"
      },
      {
        "query_type": [
          "A",
          "AAAA"
        ],
        "invert": true,
        "server": "fakeip"
      }
    ],
    "fakeip": {
      "enabled": true,
      "inet4_range": "198.18.0.0/15",
      "inet6_range": "fc00::/18"
    },
    "independent_cache": true
  },
  "inbounds": [
    {
      "type": "tun",
      "inet4_address": "172.19.0.1/30",
      "inet6_address": "fdfe:dcba:9876::1/126",
      "auto_route": true,
      "strict_route": true,
      "stack": "system",
      "sniff": true
    }
  ],

FAKE IP放在最后，结果还是走的阿里dns。

lin1123 commented 5 months ago 
{
  "log": {
    "level": "debug",
    "output": "box.log",
    "timestamp": true
  },
  "dns": {
    "servers": [
      {
        "tag": "Quad101",
        "address": "https://101.101.101.101/dns-query",
        "strategy": "ipv4_only",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "alidns",
        "address": "https://223.6.6.6/dns-query",
        "strategy": "ipv4_only",
        "detour": "🎯 全球直连"
      },
      {
        "tag": "fakeip",
        "address": "fakeip"
      },
      {
        "tag": "dns_block",
        "address": "rcode://refused"
      }
    ],
    "rules": [
      {
        "rule_set": "category-ads-all",
        "server": "dns_block",
        "disable_cache": true
      },
      {
        "outbound": "any",
        "server": "alidns"
      },
      {
        "rule_set": "cn",
        "query_type": [
          "A",
          "AAAA"
        ],
        "invert": true,
        "server": "fakeip"
      },
      {
        "rule_set": [
          "cn",
          "lan"
        ],
        "server": "alidns"
      }
    ],
    "fakeip": {
      "enabled": true,
      "inet4_range": "198.18.0.0/15",
      "inet6_range": "fc00::/18"
    },
    "independent_cache": true
  },
  "inbounds": [
    {
      "type": "tun",
      "inet4_address": "172.19.0.1/30",
      "inet6_address": "fdfe:dcba:9876::1/126",
      "auto_route": true,
      "strict_route": true,
      "stack": "system",
      "sniff": true
    }
  ],

这样配置能实现了，CN规则集本地解析出IP匹配出站，其他的走fake ip

chika0801 commented 5 months ago 
      {
        "rule_set": [
          "cn",
          "lan"
        ],
        "server": "alidns"
      }
      {
        "rule_set": [
          "cn",
          "lan" //  google.com命中的是这条 问题出在这 lan rule set上，我没用过它，不清楚它是干什么的。
        ],
        "server": "alidns"
      }
chika0801 commented 5 months ago 
+0800 2024-01-14 20:40:59 DEBUG dns: exchange www.google.com. IN AAAA
+0800 2024-01-14 20:40:59 DEBUG dns: match[3] rule_set=[cn lan] => alidns

我也没用 lan 这个rule 所以你看日志，自己也能分析，就是这么自查的。