Closed zakuwaki closed 1 year ago
when change client dns config to
"dns": {
"servers": [
{
"address": "tcp://119.29.29.29"
}
]
}
server and client log:
在服务端配置
入站加
"sniff": true,
"sniff_override_destination": true,
"domain_strategy": "ipv4_only",
或者
才会使用到你设置的DNS
@chika0801 谢谢你。这其实是一个简单的demo,是具体使用场景下的抽象,为了方便作者排查问题。实际的使用场景是将远端的dns server通过隧道透传到本地
5ce3ddee9be640c309a23341951434861dc4c2e0 此配置场景能够在reality中传输dns数据
请查看您issue中服务器日志的部分。
使用 cd5c2a7999b157e3ca25b35a958a050efee9456c 版本的日志,注意将服务端users下的flow字段删除。可以正常使用并查询到dns信息
"users": [
{
"uuid": "bf000d23-0752-40b4-affe-68f7707a9661"
}
]
实际上客户端均开启了xtls-rprx-vision
当客户端在 27aba99e6c6c1d03dff3912bd5345cddeeaae26b 下,去除dns模块的配置时,一切就是正常的,不再出现flow mismatch: expected xtls-rprx-vision, but got none
的问题。所以这里highlight是dns传输的问题。
{
"inbounds": [
{
"type": "socks",
"listen": "0.0.0.0",
"listen_port": 11080,
"sniff": true,
"sniff_override_destination": true,
"domain_strategy": "ipv4_only"
}
],
"outbounds": [
{
"type": "vless",
"server": "127.0.0.1",
"server_port": 443,
"uuid": "bf000d23-0752-40b4-affe-68f7707a9661",
"flow": "xtls-rprx-vision",
"packet_encoding": "xudp",
"tls": {
"enabled": true,
"server_name": "goproxy.cn",
"utls": {
"enabled": true,
"fingerprint": "chrome"
},
"reality": {
"enabled": true,
"public_key": "D4sZ_w2mzS2ITDoDYT5vDYjH2CUpJXgV0qYyBTSJrmI",
"short_id": "141294801e782f67"
}
}
}
]
}
描述不清,请将 reality 与 vision 分开检查。
实锤了,是xtls-rprx-vision的问题
minimal config
server
{
"inbounds": [
{
"type": "vless",
"listen": "0.0.0.0",
"listen_port": 443,
"users": [
{
"uuid": "bf000d23-0752-40b4-affe-68f7707a9661",
"flow": "xtls-rprx-vision"
}
]
}
]
}
client
{
"dns": {
"servers": [
{
"address": "119.29.29.29"
}
]
},
"inbounds": [
{
"type": "socks",
"listen": "0.0.0.0",
"listen_port": 11080,
"sniff": true,
"sniff_override_destination": true,
"domain_strategy": "ipv4_only"
}
],
"outbounds": [
{
"type": "vless",
"server": "127.0.0.1",
"server_port": 443,
"uuid": "bf000d23-0752-40b4-affe-68f7707a9661",
"flow": "xtls-rprx-vision",
"packet_encoding": "xudp"
}
]
}
试了,应该是 sing-box 或者 vision 的协议实现有问题,暂时不要用吧。
可能是服务端查了 flow?客户端 UDP 和 MUX 指令不应带 flow,服务端也不应检查(因为 flow 没有生效,但是以后可能会定义)
7ecb9fc738be799d66bb18d2b18267b3460d4f7e
看起来是同时支持了普通 TLS 代理,根据反馈它会导致 Vision 被一起封端口
按这个逻辑 mux 也应该开 vision
(下面一行)
服务端 Vision 还要禁掉非 XUDP 的 MUX
客户端一定会把 XUDP 粘在 VLESS 头后面一起发,MUX ID 为 1+,而 XUDP ID 为 0,服务端简单判断一下即可: https://github.com/XTLS/Xray-core/blob/a4790133d23547f219628f445f576171b3921ab6/proxy/vless/inbound/inbound.go#L158
逻辑:默认拒绝 MUX,除非能确认首包就包含 XUDP。
7ecb9fc
开启"flow": "xtls-rprx-vision",确定在udp下修复。换了一个支持tcp的dns问题依然存在(关闭后正常)
server
INFO[0000] inbound/vless[0]: tcp server started at 0.0.0.0:443
INFO[0000] sing-box started (0.00s)
INFO[0028] [1120430546] inbound/vless[0]: inbound connection from 127.0.0.1:46930
DEBUG[0028] [1120430546] dns: lookup domain goproxy.cn
DEBUG[0028] [1120430546] dns: lookup succeed for goproxy.cn: 122.205.109.41
INFO[0028] [1646825650] inbound/vless[0]: [0] inbound connection to 127.0.0.1:53
INFO[0028] [1646825650] outbound/direct: outbound connection to 127.0.0.1:53
TRACE[0028] inbound/vless[0]: Xtls Unpadding new block 21 26 padding 32 0
TRACE[0028] inbound/vless[0]: XtlsPadding 42 21 0
DEBUG[0038] [1120430546] inbound/vless[0]: connection closed: process connection from 127.0.0.1:46930: upload: EOF | download: EOF
INFO[0000] inbound/socks[0]: tcp server started at 0.0.0.0:11080
INFO[0000] sing-box started (0.00s)
INFO[0015] [2323261235] inbound/socks[0]: inbound connection from 127.0.0.1:41592
INFO[0015] [2323261235] inbound/socks[0]: inbound connection to 183.3.226.35:80
DEBUG[0015] [2323261235] router: sniffed protocol: http, domain: qq.com
DEBUG[0015] [2323261235] dns: lookup domain qq.com
INFO[0015] outbound/vless[0]: outbound connection to 127.0.0.1:53
TRACE[0015] outbound/vless[0]: XtlsPadding 26 32 0
ERROR[0025] [2323261235] dns: lookup failed for qq.com: context deadline exceeded
DEBUG[0025] [2323261235] inbound/socks[0]: connection closed: process connection from 127.0.0.1:41592: context deadline exceeded
应该是我的 vision 实现有问题,这几天身体非常差,所以先咕着
感谢世界!问题已被修复🎉🎉🎉
Welcome
Description of the problem
DNS cannot get though reality. udp:// and tcp:// both failed
Version of sing-box
Server and client configuration file
Server and client log file