访问视频号、企业微信的云盘文件出现 ERR_CONNECTION_RESET
Opened this issue · 8 comments
多谢大佬分享配置。不过，我目前使用 sing-box_1.11.json 这个配置时，访问视频号 或者 企业微信的云盘文件出现。不知道该问题是否普遍？
印象中，我之前使用其他配置文件也出现过该问题，后来设置 "sniff_override_destination": true 就能解决问题了。但 1.11不支持该参数了。
我自己一直用的sing-box的最新版本，目前也是 sing-box_1.11.json 这个配置开TUN，对接的XRAY。
我自己日常开网站没有遇到你的现象。
要么你发下你的sing-box配置，看描述一下情况了。
感谢大佬回复。我的配置文件与你提供的基本相同，奇怪的是，我昨天测试时，访问视频号、企业微信的云盘文件遭遇 ERR_CONNECTION_RESET ，今天再测试时就没有遇到这问题了，今天正常了。
另外，fakeip 好像导致 ping 失效。大佬能不能改一个 realip 的配置出来？
我今天测试的配置内容如下（主要是增加了 AI 的过滤；btw，我之前都没想到让 sing-box 搭配本地的xray 使用，这下开阔思路了 ）。
{
"log": {
"level": "warn",
"timestamp": true
},
"dns": {
"servers": [
{
"tag": "dns_proxy",
"address": "https://cloudflare-dns.com/dns-query",
"address_resolver": "dns_resolver",
"address_strategy": "ipv4_only",
"strategy": "ipv4_only",
"detour": "node-selected"
},
{
"tag": "dns_direct",
"address": "h3://dns.alidns.com/dns-query",
"address_resolver": "dns_resolver",
"address_strategy": "ipv4_only",
"strategy": "prefer_ipv4",
"detour": "direct"
},
{
"tag": "dns_resolver",
"address": "223.5.5.5",
"detour": "direct"
},
{
"tag": "dns_success",
"address": "rcode://success"
},
{
"tag": "dns_refused",
"address": "rcode://refused"
},
{
"tag": "dns_fakeip",
"address": "fakeip"
}
],
"rules": [
{
"outbound": "any",
"server": "dns_resolver"
},
{
"rule_set": "geosite-geolocation-!cn",
"query_type": [
"A",
"AAAA"
],
"server": "dns_fakeip"
},
{
"rule_set": "geosite-geolocation-!cn",
"query_type": [
"CNAME"
],
"server": "dns_proxy"
},
{
"query_type": [
"A",
"AAAA",
"CNAME"
],
"invert": true,
"server": "dns_refused",
"action": "route-options",
"disable_cache": true
}
],
"final": "dns_direct",
"independent_cache": true,
"fakeip": {
"enabled": true,
"inet4_range": "198.18.0.0/15",
"inet6_range": "fc00::/18"
}
},
"route": {
"rule_set": [
{
"type": "remote",
"tag": "geosite-geolocation-!cn",
"format": "binary",
"url": "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/refs/heads/sing/geo/geosite/geolocation-!cn.srs",
"download_detour": "node-selected",
"update_interval": "2d"
},
{
"type": "remote",
"tag": "geoip-cn",
"format": "binary",
"url": "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/refs/heads/sing/geo/geoip/cn.srs",
"download_detour": "node-selected",
"update_interval": "2d"
},
{
"tag": "geosite-openai",
"type": "remote",
"format": "binary",
"url": "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/refs/heads/sing/geo/geosite/openai.srs",
"download_detour": "node-selected",
"update_interval": "2d"
},
{
"tag": "geosite-gemini",
"type": "remote",
"format": "binary",
"url": "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/refs/heads/sing/geo/geosite/google-gemini.srs",
"download_detour": "node-selected",
"update_interval": "2d"
}
],
"rules": [
{
"inbound": "tun-in",
"action": "sniff"
},
{
"protocol": "dns",
"action": "hijack-dns"
},
{
"process_name": [
"xray.exe",
"hysteria.exe"
],
"outbound": "direct"
},
{
"port": 853,
"network": "tcp",
"action": "reject"
},
{
"port": 443,
"network": "udp",
"action": "reject"
},
{
"rule_set": [
"geosite-openai",
"geosite-gemini"
],
"outbound": "node-AI"
},
{
"rule_set": "geosite-geolocation-!cn",
"outbound": "node-selected"
},
{
"rule_set": "geoip-cn",
"outbound": "direct"
},
{
"ip_is_private": true,
"outbound": "direct"
}
],
"final": "node-selected",
"auto_detect_interface": true
},
"inbounds": [
{
"type": "tun",
"tag": "tun-in",
"address": [
"172.16.0.1/30",
"fd00::1/126"
],
"mtu": 1492,
"auto_route": true,
"strict_route": true,
"stack": "system"
}
],
"outbounds": [
{
"type": "direct",
"tag": "direct"
},
{
"type": "urltest",
"tag": "node-auto",
"outbounds": [
"hk-xtls",
"sg-xtls"
],
"url": "https://www.gstatic.com/generate_204",
"interval": "240m",
"idle_timeout": "360m",
"interrupt_exist_connections": true,
"tolerance": 50
},
{
"type": "selector",
"tag": "node-selected",
"outbounds": [
"direct",
"node-auto",
"hk-xtls",
"sg-xtls"
],
"default": "hk-xtls",
"interrupt_exist_connections": true
},
{
"type": "selector",
"tag": "node-AI",
"outbounds": [
"sg-xtls"
],
"default": "sg-xtls",
"interrupt_exist_connections": true
},
{
"type": "vless",
"tag": "hk-xtls",
"server": "隐藏",
"server_port": 443,
"uuid": "隐藏",
"flow": "xtls-rprx-vision",
"packet_encoding": "xudp",
"tls": {
"enabled": true,
"utls": {
"enabled": true,
"fingerprint": "chrome"
}
}
},
{
"type": "vless",
"tag": "sg-xtls",
"server": "隐藏",
"server_port": 443,
"uuid": "隐藏",
"flow": "xtls-rprx-vision",
"packet_encoding": "xudp",
"tls": {
"enabled": true,
"utls": {
"enabled": true,
"fingerprint": "chrome"
}
}
}
],
"experimental": {
"cache_file": {
"enabled": true,
"path": "cache.db",
"store_fakeip": true,
"store_rdrc": true
},
"clash_api": {
"external_controller": "127.0.0.1:9090",
"external_ui": "ui",
"external_ui_download_url": "https://github.com/MetaCubeX/Yacd-meta/archive/gh-pages.zip",
"external_ui_download_detour": "node-selected",
"default_mode": "rule"
}
}
}
我之前都没想到让 sing-box 搭配本地的xray 使用
我一直是拿sing-box开tun，接管win下所有的流量。DNS查询处理由sing-box来负责。出站（连服务端）是sing-box到本机的一个socks端口，xray入站部分监听接这端口，再出站连服务端。
然后在sing-box的配置中把xray.exe设置一个规则走直连，这样实现的，我用了挺久没什么异常现象。
看了下配置中
逻辑是从上到下，域名DNS请求进来，从上到下如果是在geosite-geolocation-!cn类别中， 查询类型是 A或AAAA 返回Fakeip。如果类型是CNAME用 DNSproxy查。下面一个规则意思是非 A AAAA CNAME的查询类型给屏蔽了。那没一个DNS请求从上到下最后结果就是排除了 geosite-geolocation-!cn 类别 。其它网址的 A AAAA CNAME DNS请求用你设置的 "final": "dns_direct", 这个DNS来查。我也是一直这样用的。这里面有自己的习惯逻辑考虑。建议你不要被网上什么DNS泄露迷惑了。根据你自己想的实现的来即可。
"rules": [
{
"outbound": "any",
"server": "dns_resolver"
},
{
"rule_set": "geosite-geolocation-!cn",
"query_type": [
"A",
"AAAA"
],
"server": "dns_fakeip"
},
{
"rule_set": "geosite-geolocation-!cn",
"query_type": [
"CNAME"
],
"server": "dns_proxy"
},
{
"query_type": [
"A",
"AAAA",
"CNAME"
],
"invert": true,
"server": "dns_refused",
"action": "route-options",
"disable_cache": true
}
],
"final": "dns_direct",
"independent_cache": true,
"fakeip": {
"enabled": true,
"inet4_range": "198.18.0.0/15",
"inet6_range": "fc00::/18"
}
},
看了下你把AI的网站，在路由规则 走你指定的VPS。
我的做法是，不在客户端处理。AI的走到我服务端。我服务端用的Xray我用xray的配置，把AI的网址，发到对应出站，到我能解锁的VPS。
在客户端做还是在服务端做，也是看个人习惯和需求。比如你的VPS给N个朋友用，你不可能教他们每个人客户端配置文件，这种情况你在服务端配置文件中分，就是好的方法。我是这个想法。
fakeip 好像导致 ping 失效。大佬能不能改一个 realip 的配置出来？
我刚在cmd试了一下sing-box开tun时，ping没反应，我也没注意到这现象，我就不去研究这事了。没空。
fakeip 好像导致 ping 失效。大佬能不能改一个 realip 的配置出来？
我刚在cmd试了一下sing-box开tun时，ping没反应，我也没注意到这现象，我就不去研究这事了。没空。
我无意中试了一下， 1.10.x 版本开启tun也能 ping 的；但是 1.11.x 版本就不行了。玄学比较多，我也懒得折腾了。
建议你不要花时间问WHY。那边作者不喜欢这类问题的梗了。