Xray-core
Xray-core copied to clipboard
XTLS
关于"routeOnly"选项的问题
看过官方文档后没看懂routeOnly的用法，routeOnly可以给一个使用的情形吗？ 比如当我本地使用xray访问谷歌的时候，routeOnly: true 和 routeOnly: False，都可以正常的上网，开不开有什么区别。 再比如 官方文档说 作用是将嗅探得到的域名仅用于路由，代理目标地址仍为 IP。默认值为 false。 那么如果我将本地的hosts文件中写 114.114.114.114 www.google.com ， 按照代理目标地址使用ip的说法，应该是无法访问谷歌才对。
routeOnly: true | false
将嗅探得到的域名仅用于路由，代理目标地址仍为 IP。默认值为 false。
此项需要开启 destOverride 使用。
提示
在能保证 被代理连接能得到正确的 DNS 解析 时，使用 routeOnly 且开启 destOverride 的同时，将路由匹配策略 domainStrategy 设置为 AsIs 即可实现全程无 DNS 解析进行域名及 IP 分流。此时遇到 IP 规则匹配时使用的 IP 为域名原始 IP。
几句话讲不太详细，你大致看下。
我认为最常见到使用的情形
你的路由器刷了openwrt，插件用的是passwall（以1举例），在passwall的高级设置菜单里有这个选项，默认是没勾选。
这时对于你的设备，如台式电脑，手机，连到这个路由器。是透 明代理环境。
DNS流程：设备如浏览器发了一个网址的DNS请求，进路由器，送到passwall，经过设置好的一系列DNS操作，得到网址的IP。
浏览器对这个IP发起连接，又送到passwall，passwall使用xray-core接收这个请求。
-
设passwall默认设置是开了域名嗅探，关了routeOnly。 IP被嗅探出原网址，经过passwall里你设置的xray路由规则一系列匹配，最后是走了代理。VPS端无论你在配置中加不加域名嗅探，因为客户端开了域名嗅探，收到的是网址请求，不是客户端DNS得到的那个IP。
-
设passwall默认设置是开了域名嗅探，开了routeOnly。 IP被嗅探出原网址，经过passwall里你设置的xray路由规则一系列匹配，最后是走了代理。VPS端你在配置中不加域名嗅探，因你在客户端开了routeOnly，收到请求是IP，是客户端DNS得到的那个IP。
VPS端你在配置中加了域名嗅探，因你在客户端开了routeOnly，收到请求被VPS端域名嗅探还原成域名了。客户端DNS得到的那个IP在VPS端没有作用。
建议passwall高级设置里的那些参数，如果你不是要研究，不要动，作者都给你设置到最佳了的。你要研究，要分透明代理，普通 的http/scoks代理2个环境。学的过程是客户，服务器开Debug，观察日志。还要学透明代理下，dns处理流程之类。
一些资料
Edit:今天看了一下代码，发现我之前的理解有误，修改一下：
sniffing（不打开destOverride不打开routeOnly）：不改变该连接的原始目的地ip。只进行嗅探，将得到的fqdn网址和该连接原始目标ip地址交给本地客户端路由模块来分流。
此时，打开destOverride不打开routeOnly：会把本地客户端dns模块解析出的ip地址替换为该连接的目的地ip，并发往远端代理服务器。此时如果远端代理服务器没有开destOverride，或开启了destOverride的同时开启了routeOnly，那么最终目的地ip为本地客户端dns模块解析出的ip地址。
此时，打开destOverride打开routeOnly：不改变该连接的原始目的地ip。只进行嗅探，将得到的fqdn网址交给本地客户端dns模块解析，并将fqdn网址和本地dns模块解析出的新目标ip地址的交给本地客户端路由模块来分流。
你有尝试过Proxy而非VPN模式么？我所做的测试是这样的：在开启adguard的环境下，Android设置里面的Google设置会提示无法联网，play商店和YouTube都会有概率提示没网络。将v2rayNG切换为VPN模式后，无论是添加了routeonly的自定义配置，还是正常手打填入的配置，均可以访问。还没有排查出原因，在另一台手机上没有复现这个问题。 其次，routeonly这个选项对Windows作用不是很大，因为Windows属于HTTP代理，在v2rayN中所见几乎都是域名（如果路由设置写asis，outbound freedom写asis的话），传递到服务端还是域名。而Android可以通过socks代理传递IP，路径为：ADGuard（可选）-V2rayNG（socks代理）-服务端，服务端可见全是IP。所有的解析都是本地完成。 另外还想问一下，您的服务端配置中，routing是asis还是什么呢？sniffing是怎么写的配置呢？
@Extreme-Icer 有群友在问翻到你回的，看了下你的意思，说说我的
会把本地客户端dns模块解析出的ip地址替换为该连接的目的地ip
sniffing 开destOverride 不开routeOnly ，在客户端，是把进来请求（IP地址），嗅探还原成域名，这域名发到你的VPS端
sniffing 开destOverride 开routeOnly ，在客户端，是把进来请求（IP地址），嗅探还原成域名，又进客户端配置的路由模块，匹配你的域名规则，若没中，再匹配IP规则，还没中，一般这请求（IP地址，这IP是透明代理时，请求进来DNS得到的，应该不是在xray路由模块用ip if non match没中，再解析一次的IP）发到VPS端
@Extreme-Icer 有群友在问翻到你回的，看了下你的意思，说说我的
会把本地客户端dns模块解析出的ip地址替换为该连接的目的地ip
sniffing 开destOverride 不开routeOnly ，在客户端，是把进来请求（IP地址），嗅探还原成域名，这域名发到你的VPS端
sniffing 开destOverride 开routeOnly ，在客户端，是把进来请求（IP地址），嗅探还原成域名，又进客户端配置的路由模块，配置你的域名规则，若没中，再配置IP规则，还没中，一般这请求（IP地址）发到VPS端
如果destoverride也不开呢？
@Extreme-Icer 当时用很原始的测试方法，两端开Debug看日志，开和关要测的不懂参数，看两端日志有什么变化
不开destOverride 不开routeOnly 我没测试过了，你有兴趣自己试试
Edit:今天看了一下代码，发现我之前的理解有误，修改一下： ~sniffing（不打开destOverride不打开routeOnly）：嗅探，会把连接中的地址由ip还原成网址sni，并发往远端代理服务器。还原之后，就由远端代理服务器来解析，并连接目的地ip。 如果此时客户端开启了dns模块，并根据dns的解析结果进行路由模块的分流，那么客户端dns模块解析出的地址只用于路由模块分流，而不成为该连接的实际目的地ip----实际目的地ip依然由远端服务器通过解析sni网址获得。~
sniffing（不打开destOverride不打开routeOnly）：不改变该连接的原始目的地ip。只进行嗅探，将得到的sni网址和该连接原始目标ip地址交给本地客户端路由模块来分流。
此时，打开destOverride不打开routeOnly：会把本地客户端dns模块解析出的ip地址替换为该连接的目的地ip，并发往远端代理服务器。此时如果远端代理服务器没有开destOverride，或开启了destOverride的同时开启了routeOnly，那么最终目的地ip为本地客户端dns模块解析出的ip地址。
此时，打开destOverride打开routeOnly：不改变该连接的原始目的地ip。只进行嗅探，将得到的sni网址交给本地客户端dns模块解析，并将sni网址和本地dns模块解析出的新目标ip地址的交给本地客户端路由模块来分流。
那这和文档写的完全相反啊?可以标记一下源码位置吗?
各位表达方式确实一个比一个难懂啊。我用小白一点的语言翻译下，如有错误立刻抽我： 使用xray分流必须开启"嗅探"（sniffing）。
疑惑点主要是下面的"流量嗅探只供路由使用"（即routeOnly）选项，开启与否的实际状况和影响：
不勾选 = 向代理服务器继续发送域名准备访问；（缺点：两次转换，理论上过程慢；优点：VPS的DNS得到的目标IP更准更近） 勾选 = 直接把IP发给代理服务器进行访问。（缺点：有可能这个IP不是最优的，优点：理论上转换过程少更快）
sing-box
各位表达方式确实一个比一个难懂啊。我用小白一点的语言翻译下，如有错误立刻抽我： 使用xray分流必须开启"嗅探"（sniffing）。
疑惑点主要是下面的"流量嗅探只供路由使用"（即routeOnly）选项，开启与否的实际状况和影响：
不勾选 = 向代理服务器继续发送域名准备访问；（缺点：两次转换，理论上过程慢；优点：VPS的DNS得到的目标IP更准更近） 勾选 = 直接把IP发给代理服务器进行访问。（缺点：有可能这个IP不是最优的，优点：理论上转换过程少更快）
您解释的通俗到位，其实就是 传递域名 or 传递IP 的问题， 我玩过sing-box，所以经历过 从sniffing默认的传递域名到 传递IP的转变
传递域名给vps这样做的优点是 ，vps自己本地再解析可以获取最近的cdn IP， 这样vps访问网站的肯定是最优线路， 但是这个也有缺点，缺点是 本地dns分流 也解析了一次dns， 多此一举，而且还多耽误了一次dns解析时间，
因此我玩sing-box默认是喜欢传递IP给vps的，这样其实也可以做到 和 传递域名 一样的 vps解析可以获取最近的cdn IP， 只需要在本地dns解析分流被墙网站的dns设置走这个vps的代理节点即可， 而且节省了 vps端 传递域名导致的 多一次dns解析时间
目前xray,sing-box我都测试可以 传递域名 or 传递IP ， 只是clash.meta我还没有找到参数开启传递IP
在路由器上用passwall2的时候，发现路由器下游的电脑用户用reality连接方式会连接不上，看了下日志也跟这个选项有关。 默认”流量嗅探只供路由使用“是关闭的。对于下游电脑端reality配置里面的sni，xray会嗅探出来，然后去找真实的这个域名的ip，导致客户端发起请求的时候，实际上会连接到这个xray自己另外解析出来的sni域名的真实ip上面。
在路由器上用passwall2的时候，发现路由器下游的电脑用户用reality连接方式会连接不上，看了下日志也跟这个选项有关。 默认”流量嗅探只供路由使用“是关闭的。对于下游电脑端reality配置里面的sni，xray会嗅探出来，然后去找真实的这个域名的ip，导致客户端发起请求的时候，实际上会连接到这个xray自己另外解析出来的sni域名的真实ip上面。
1.dns模块里配置IPIfNonMatch会导致未被域名规则识别的域名由xray解析。 2.如果开了destOverride，解析出来的ip就会覆盖掉原ip。 3.如果再开routeOnly，xray解析出的ip会被用于路由，但实际连接目的地ip还是原ip。（就是说，如果在路由模块里，原始ip应该直连，而xray解析域名出来的ip应该走节点，那么结果就是走节点连原始ip）
在路由器上用passwall2的时候，发现路由器下游的电脑用户用reality连接方式会连接不上，看了下日志也跟这个选项有关。 默认”流量嗅探只供路由使用“是关闭的。对于下游电脑端reality配置里面的sni，xray会嗅探出来，然后去找真实的这个域名的ip，导致客户端发起请求的时候，实际上会连接到这个xray自己另外解析出来的sni域名的真实ip上面。
1.dns模块里配置IPIfNonMatch会导致未被域名规则识别的域名由xray解析。 2.如果开了destOverride，解析出来的ip就会覆盖掉原ip。 3.如果再开routeOnly，xray解析出的ip会被用于路由，但实际连接目的地ip还是原ip。（就是说，如果在路由模块里，原始ip应该直连，而xray解析域名出来的ip应该走节点，那么结果就是走节点连原始ip）
从名称上看确实是你这么解释的。但passwall/passwall2貌似并没有提供destOverride的修改选项，destOverride默认值是true。如果不打开routeOnly(默认是关闭)，日志里看就会把xray客户端 原本请求的vps ip替换成 请求中 sni（servername）域名解析出的真实ip去连接，而启用routeOnly，就不会有这样的情况，路由器下游电脑用reality就能正常使用。
然后在passwall 里(passwall2似乎也遇到这个情况) 测试还发现一个情况：远程vps端的xray路由规则里设置了openai的域名会分流到另外的线路。此时如果开启路由器上的routeonly（routeonly=true, 默认是false），访问chatgpt就会被读取到真实的vps ip，从而被拒绝访问（此vps ip不解锁chatgpt）（推测是openai网站此时使用了quic协议，udp包没法被嗅探出地址导致分流失败）。但如果关闭routeonly（routeOnly=false）后, chatgpt网站就能够正常使用。
passwall/passwall2貌似并没有提供destOverride的修改选项
有，记得在高级里的
passwall默认设置就是屏蔽了udp443的，另外建议你不太懂时将vps端入站使用上域名嗅探。
passwall作者给的默认值都是挺不错的，不瞎折腾通常遇不到莫名问题
上图是8月初编译的passwall版本，高级设置里只看到了有routeOnly的选项，没看到destOverride选项哈。
之前本来是使用passwall2的，但对gfw模式支持不好（如果默认路线是直连，在自动切换设置那边就不方便了），（平时公司有一些常用的网站默认如果走代理体验不好，一个个加例外直连域名不方便），所以就改用passwall了。然后用它的gfw模式，再套xray分流的话，感觉有些别扭，所以就没用入站的域名嗅探。不过用passwall2遇到这个chatgpt问题的时候，测过入站的时候单独分流到能用的vps节点是可行的。
我在passwall2在开启routeOnly遇到这个chaptgpt udp问题的时候，如果是UDP不转发端口设置443，则chatgpt会显示本地宽带的ip 。我看到分流设定里还有个quic协议，把它设置成黑洞，但不管怎么调各种顺序，chatgpt还是会用quic协议。只有把routeOnly关闭，才能够使用，不知道是怎么原因。
"sniffing": { "enabled": true, "destOverride": [ "http", "tls", "quic" ]
不好意思记错了 "destOverride" passwall 网页上是没提供。因为这参数只是里面填http tls quic，填这些时，生不生效是上面一行true false控制的。
另外建议你我记得passwall默认是中国大陆ip以外 这模式，其实你用这模式后，xray分流规则全删了，用也完全ok。
就像ssrp也是默认中国大陆ip以外都走代理，xray作为客户端配置根本不让用户写自己要的规则。有时候，简单就最好。
除非你很懂xray配置在透明代理环境下工作流量，可以研究这些插件才你生成的配置。
另外建议你我记得passwall默认是中国大陆ip以外 这模式，其实你用这模式后，xray分流规则全删了，用也完全ok。
就像ssrp也是默认中国大陆ip以外都走代理，xray作为客户端配置根本不让用户写自己要的规则。有时候，简单就最好。
除非你很懂xray配置在透明代理环境下工作流量，可以研究这些插件才你生成的配置。
在路由器下游因为有时会有海外视讯会议（cisco webex，zoom等），这些连接如果走代理的话，会遇到速度差或是不稳定的问题，所以还是考虑选用gfwlist模式，否则得配置很多直连名单。 而passwall2不能同时支持gfwlist模式和自动切换同时工作（ 如果配置"默认"线路为direct，在自动切换设置没有对应的选项仅将备用节点取代gfwlist的那个分流节点）
几句话讲不太详细，你大致看下。
我认为最常见到使用的情形
你的路由器刷了openwrt，插件用的是passwall（以1举例），在passwall的高级设置菜单里有这个选项，默认是没勾选。
这时对于你的设备，如台式电脑，手机，连到这个路由器。是透 明代理环境。
DNS流程：设备如浏览器发了一个网址的DNS请求，进路由器，送到passwall，经过设置好的一系列DNS操作，得到网址的IP。
浏览器对这个IP发起连接，又送到passwall，passwall使用xray-core接收这个请求。
- 设passwall默认设置是开了域名嗅探，关了routeOnly。 IP被嗅探出原网址，经过passwall里你设置的xray路由规则一系列匹配，最后是走了代理。VPS端无论你在配置中加不加域名嗅探，因为客户端开了域名嗅探，收到的是网址请求，不是客户端DNS得到的那个IP。
- 设passwall默认设置是开了域名嗅探，开了routeOnly。 IP被嗅探出原网址，经过passwall里你设置的xray路由规则一系列匹配，最后是走了代理。VPS端你在配置中不加域名嗅探，因你在客户端开了routeOnly，收到请求是IP，是客户端DNS得到的那个IP。
VPS端你在配置中加了域名嗅探，因你在客户端开了routeOnly，收到请求被VPS端域名嗅探还原成域名了。客户端DNS得到的那个IP在VPS端没有作用。
我想问一下类似passwall这样的透明代理场景下，xray的嗅探tls域名是怎么实现的呢？是通过SNI吗？
我的理解是 routeOnly 选项的作用是将嗅探得到的域名仅用于路由，代理目标地址仍为 IP。默认值为 false，也就是说，如果不设置这个选项，Xray-core 会将嗅探得到的域名用于路由和代理。
比如一下这份Xray日志
2023/12/20 10:40:42 [Info] [4114861100] proxy/http: request to Method [CONNECT] Host [47.246.137.198:443] with URL [//47.246.137.198:443]
2023/12/20 10:40:42 [Info] [4114861100] app/dispatcher: sniffed domain: tls-desktop.dingtalk.com
2023/12/20 10:40:42 [Info] [4114861100] app/dispatcher: taking detour [direct] for [tcp:tls-desktop.dingtalk.com:443]
2023/12/20 10:40:42 127.0.0.1:5957 accepted //47.246.137.198:443 [http -> direct]
2023/12/20 10:40:42 [Debug] app/dns: domain tls-desktop.dingtalk.com matches following rules: [geosite:cn(DNS idx:2) geosite:cn(DNS idx:3)]
2023/12/20 10:40:42 [Debug] app/dns: domain tls-desktop.dingtalk.com will use DNS in order: [UDP:223.5.5.5:53 UDP:114.114.114.114:53 UDP:223.5.5.5:53 UDP:1.1.1.1:53 localhost]
2023/12/20 10:40:42 [Debug] app/dns: UDP:223.5.5.5:53 querying DNS for: tls-desktop.dingtalk.com.
2023/12/20 10:40:42 DNS accepted udp:223.5.5.5:53 [xray.system.be3d9437-db05-4cc7-9f38-f67c4777df39 -> direct]
2023/12/20 10:40:42 [Debug] transport/internet/udp: dispatch request to: udp:223.5.5.5:53
2023/12/20 10:40:42 [Info] transport/internet/udp: establishing new connection for udp:223.5.5.5:53
2023/12/20 10:40:42 [Info] app/dispatcher: taking detour [direct] for [udp:223.5.5.5:53]
2023/12/20 10:40:42 [Debug] transport/internet: dialing to udp:223.5.5.5:53
2023/12/20 10:40:42 [Info] proxy/freedom: connection opened to udp:223.5.5.5:53, local endpoint [::]:60808, remote endpoint 223.5.5.5:53
2023/12/20 10:40:42 [Info] app/dns: UDP:223.5.5.5:53 got answer: tls-desktop.dingtalk.com. TypeA -> [59.82.122.126 59.82.120.201 59.82.122.84 59.82.122.249] 10.5947ms
2023/12/20 10:40:42 [Debug] app/dns: UDP:223.5.5.5:53 updating IP records for domain:tls-desktop.dingtalk.com.
2023/12/20 10:40:42 [Debug] app/dns: domain tls-desktop.dingtalk.com expectIPs [59.82.122.126 59.82.120.201 59.82.122.84 59.82.122.249] matched at server UDP:223.5.5.5:53
2023/12/20 10:40:42 [Info] [4114861100] proxy/freedom: dialing to tcp:59.82.120.201:443
2023/12/20 10:40:42 [Info] [4114861100] transport/internet/tcp: dialing TCP to tcp:59.82.120.201:443
2023/12/20 10:40:42 [Debug] transport/internet: dialing to tcp:59.82.120.201:443
2023/12/20 10:40:42 [Info] [4114861100] proxy/freedom: connection opened to tcp:tls-desktop.dingtalk.com:443, local endpoint 192.168.31.192:5959, remote endpoint 59.82.120.201:443
2023/12/20 10:40:42 [Info] [3287057664] proxy: CopyRawConn readv
首行 Xray-core 收到了一个 HTTP 连接请求，请求方法是 CONNECT，目标主机是 47.246.137.198:443，请求的 URL 是 //47.246.137.198:443，我查询看一下这个ip是阿里云在美国的ip，此时我在入站inbound中开启了sniffing, 并且将routeOnly设置成了false
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls"
],
"routeOnly": `false`
}
就像Xray-core的文档解释的那样：
流量探测主要作用于在透明代理等用途. 比如一个典型流程如下: 如有一个设备上网,去访问 abc.com,首先设备通过 DNS 查询得到 abc.com 的 IP 是 1.2.3.4,然后设备会向 1.2.3.4 去发起连接. 如果不设置嗅探,Xray 收到的连接请求是 1.2.3.4,并不能用于域名规则的路由分流. 当设置了 sniffing 中的 enable 为 true,Xray 处理此连接的流量时,会从流量的数据中,嗅探出域名,即 abc.com Xray 会把 1.2.3.4 重置为 abc.com.路由就可以根据域名去进行路由的域名规则的分流 因为变成了一个向 abc.com 请求的连接, 就可以做更多的事情, 除了路由域名规则分流, 还能重新做 DNS 解析等其他工作. 当设置了 sniffing 中的 enable 为 true, 还能嗅探出 bittorrent 类型的流量, 然后可以在路由中配置"protocol"项来设置规则处理 BT 流量, 比如服务端用来拦截 BT 流量, 或客户端固定转发 BT 流量到某个 VPS 去等.
and
routeOnly: true | false 将嗅探得到的域名仅用于路由，代理目标地址仍为 IP。默认值为 false。
Xray-core 嗅探得到47.246.137.198的对应域名是 tls-desktop.dingtalk.com , 且根据内置的DNS服务器对 tls-desktop.dingtalk.com 重新做 DNS 解析，得到国内的 IP [59.82.122.126 59.82.120.201 59.82.122.84 59.82.122.249]，然后从中选了一个 IP ，此处是 59.82.120.201 作为了新的目标地址。
如果设置为"routeOnly": true,应该只会将嗅探的到的tls-desktop.dingtalk.com拿去做路由规则匹配，但是最后的目标地址仍是国外的 47.246.137.198
我觉得这个routeOnly在设置成false的情况下再搭配 内置dns 一起（比如国内网站用国内dns，国外用国外dns） 应该可以在一定程度上避免 用国内被污染的dns去解析国外网站的问题
不知道理解得对不对，这几天也在细读文档
我的理解是 routeOnly 选项的作用是将嗅探得到的域名仅用于路由，代理目标地址仍为 IP。默认值为 false，也就是说，如果不设置这个选项，Xray-core 会将嗅探得到的域名用于路由和代理。
比如一下这份Xray日志
2023/12/20 10:40:42 [Info] [4114861100] proxy/http: request to Method [CONNECT] Host [47.246.137.198:443] with URL [//47.246.137.198:443] 2023/12/20 10:40:42 [Info] [4114861100] app/dispatcher: sniffed domain: tls-desktop.dingtalk.com 2023/12/20 10:40:42 [Info] [4114861100] app/dispatcher: taking detour [direct] for [tcp:tls-desktop.dingtalk.com:443] 2023/12/20 10:40:42 127.0.0.1:5957 accepted //47.246.137.198:443 [http -> direct] 2023/12/20 10:40:42 [Debug] app/dns: domain tls-desktop.dingtalk.com matches following rules: [geosite:cn(DNS idx:2) geosite:cn(DNS idx:3)] 2023/12/20 10:40:42 [Debug] app/dns: domain tls-desktop.dingtalk.com will use DNS in order: [UDP:223.5.5.5:53 UDP:114.114.114.114:53 UDP:223.5.5.5:53 UDP:1.1.1.1:53 localhost] 2023/12/20 10:40:42 [Debug] app/dns: UDP:223.5.5.5:53 querying DNS for: tls-desktop.dingtalk.com. 2023/12/20 10:40:42 DNS accepted udp:223.5.5.5:53 [xray.system.be3d9437-db05-4cc7-9f38-f67c4777df39 -> direct] 2023/12/20 10:40:42 [Debug] transport/internet/udp: dispatch request to: udp:223.5.5.5:53 2023/12/20 10:40:42 [Info] transport/internet/udp: establishing new connection for udp:223.5.5.5:53 2023/12/20 10:40:42 [Info] app/dispatcher: taking detour [direct] for [udp:223.5.5.5:53] 2023/12/20 10:40:42 [Debug] transport/internet: dialing to udp:223.5.5.5:53 2023/12/20 10:40:42 [Info] proxy/freedom: connection opened to udp:223.5.5.5:53, local endpoint [::]:60808, remote endpoint 223.5.5.5:53 2023/12/20 10:40:42 [Info] app/dns: UDP:223.5.5.5:53 got answer: tls-desktop.dingtalk.com. TypeA -> [59.82.122.126 59.82.120.201 59.82.122.84 59.82.122.249] 10.5947ms 2023/12/20 10:40:42 [Debug] app/dns: UDP:223.5.5.5:53 updating IP records for domain:tls-desktop.dingtalk.com. 2023/12/20 10:40:42 [Debug] app/dns: domain tls-desktop.dingtalk.com expectIPs [59.82.122.126 59.82.120.201 59.82.122.84 59.82.122.249] matched at server UDP:223.5.5.5:53 2023/12/20 10:40:42 [Info] [4114861100] proxy/freedom: dialing to tcp:59.82.120.201:443 2023/12/20 10:40:42 [Info] [4114861100] transport/internet/tcp: dialing TCP to tcp:59.82.120.201:443 2023/12/20 10:40:42 [Debug] transport/internet: dialing to tcp:59.82.120.201:443 2023/12/20 10:40:42 [Info] [4114861100] proxy/freedom: connection opened to tcp:tls-desktop.dingtalk.com:443, local endpoint 192.168.31.192:5959, remote endpoint 59.82.120.201:443 2023/12/20 10:40:42 [Info] [3287057664] proxy: CopyRawConn readv首行 Xray-core 收到了一个 HTTP 连接请求，请求方法是 CONNECT，目标主机是 47.246.137.198:443，请求的 URL 是 //47.246.137.198:443，我查询看一下这个ip是阿里云在美国的ip，此时我在入站inbound中开启了sniffing, 并且将routeOnly设置成了false
"sniffing": { "enabled": true, "destOverride": [ "http", "tls" ], "routeOnly": `false` }就像Xray-core的文档解释的那样：
流量探测主要作用于在透明代理等用途. 比如一个典型流程如下: 如有一个设备上网,去访问 abc.com,首先设备通过 DNS 查询得到 abc.com 的 IP 是 1.2.3.4,然后设备会向 1.2.3.4 去发起连接. 如果不设置嗅探,Xray 收到的连接请求是 1.2.3.4,并不能用于域名规则的路由分流. 当设置了 sniffing 中的 enable 为 true,Xray 处理此连接的流量时,会从流量的数据中,嗅探出域名,即 abc.com Xray 会把 1.2.3.4 重置为 abc.com.路由就可以根据域名去进行路由的域名规则的分流 因为变成了一个向 abc.com 请求的连接, 就可以做更多的事情, 除了路由域名规则分流, 还能重新做 DNS 解析等其他工作. 当设置了 sniffing 中的 enable 为 true, 还能嗅探出 bittorrent 类型的流量, 然后可以在路由中配置"protocol"项来设置规则处理 BT 流量, 比如服务端用来拦截 BT 流量, 或客户端固定转发 BT 流量到某个 VPS 去等.
and
routeOnly: true | false 将嗅探得到的域名仅用于路由，代理目标地址仍为 IP。默认值为 false。
Xray-core 嗅探得到47.246.137.198的对应域名是 tls-desktop.dingtalk.com , 且根据内置的DNS服务器对 tls-desktop.dingtalk.com 重新做 DNS 解析，得到国内的 IP [59.82.122.126 59.82.120.201 59.82.122.84 59.82.122.249]，然后从中选了一个 IP ，此处是 59.82.120.201 作为了新的目标地址。
如果设置为"routeOnly":
true,应该只会将嗅探的到的tls-desktop.dingtalk.com拿去做路由规则匹配，但是最后的目标地址仍是国外的 47.246.137.198我觉得这个routeOnly在设置成false的情况下再搭配 内置dns 一起（比如国内网站用国内dns，国外用国外dns） 应该可以在一定程度上避免 用国内被污染的dns去解析国外网站的问题
不知道理解得对不对，这几天也在细读文档
请帮忙看下log：
在相同的配置下，如果是要被代理的域名，xray发给服务端的是ip还是域名？
如果把destoverride部分删掉，xray发给服务端的是ip还是域名？
请帮忙看下log：
log 在哪
在相同的配置下，如果是要被代理的域名，xray发给服务端的是ip还是域名？
我认为是域名，如果是ip，那么这ip也只是你客户端那边dns解析出的适合你地理位置的域名的ip，但是有些网站可能有多个IP地址，而不同的IP地址可能有不同的内容或速度，如果把你客户端dns解析的ip拿给服务端用，可能就不是服务端地理位置那儿 最佳的ip了，而如果客户端发送的是域名，那么服务端就可以根据自己的DNS设置来解析最适合的IP地址，从而提高访问的效果，我自己也试了一下，最后一行(用XXXX替换了服务器地址)：
2023/12/21 11:36:19 [Warning] core: Xray 1.8.6 started
2023/12/21 11:36:23 [Info] [2522802786] proxy/http: request to Method [CONNECT] Host [dod4r81dg8pmduzedvbd7nyx6t7xepiqktoyy5bb-50.ipleak.net:443] with URL [//dod4r81dg8pmduzedvbd7nyx6t7xepiqktoyy5bb-50.ipleak.net:443]
2023/12/21 11:36:23 [Info] [2522802786] app/dispatcher: sniffed domain: dod4r81dg8pmduzedvbd7nyx6t7xepiqktoyy5bb-50.ipleak.net
2023/12/21 11:36:23 [Info] [2522802786] app/dispatcher: taking detour [proxy] for [tcp:dod4r81dg8pmduzedvbd7nyx6t7xepiqktoyy5bb-50.ipleak.net:443]
2023/12/21 11:36:23 [Info] [2522802786] transport/internet/websocket: creating connection to tcp: XXXXXXXX:443
2023/12/21 11:36:23 [Debug] transport/internet: dialing to tcp:XXXXXXXX.com:443
2023/12/21 11:36:23 127.0.0.1:7900 accepted //dod4r81dg8pmduzedvbd7nyx6t7xepiqktoyy5bb-50.ipleak.net:443 [http -> proxy]
2023/12/21 11:36:24 [Info] [2522802786] proxy/trojan: tunneling request to tcp:dod4r81dg8pmduzedvbd7nyx6t7xepiqktoyy5bb-50.ipleak.net:443 via XXXXXXXX.com:443
如果把destoverride部分删掉，xray发给服务端的是ip还是域名？
我自己试一下验证一下，好像和上面一样？
ps 我感觉文档写得不太详细 ，很多需要靠猜测加实践
请帮忙看下log：
log 在哪
在相同的配置下，如果是要被代理的域名，xray发给服务端的是ip还是域名？
我认为是域名，如果是ip，那么这ip也只是你客户端那边dns解析出的适合你地理位置的域名的ip，但是有些网站可能有多个IP地址，而不同的IP地址可能有不同的内容或速度，如果把你客户端dns解析的ip拿给服务端用，可能就不是服务端地理位置那儿 最佳的ip了，而如果客户端发送的是域名，那么服务端就可以根据自己的DNS设置来解析最适合的IP地址，从而提高访问的效果，我自己也试了一下，最后一行(用XXXX替换了服务器地址)：
2023/12/21 11:36:19 [Warning] core: Xray 1.8.6 started 2023/12/21 11:36:23 [Info] [2522802786] proxy/http: request to Method [CONNECT] Host [dod4r81dg8pmduzedvbd7nyx6t7xepiqktoyy5bb-50.ipleak.net:443] with URL [//dod4r81dg8pmduzedvbd7nyx6t7xepiqktoyy5bb-50.ipleak.net:443] 2023/12/21 11:36:23 [Info] [2522802786] app/dispatcher: sniffed domain: dod4r81dg8pmduzedvbd7nyx6t7xepiqktoyy5bb-50.ipleak.net 2023/12/21 11:36:23 [Info] [2522802786] app/dispatcher: taking detour [proxy] for [tcp:dod4r81dg8pmduzedvbd7nyx6t7xepiqktoyy5bb-50.ipleak.net:443] 2023/12/21 11:36:23 [Info] [2522802786] transport/internet/websocket: creating connection to tcp: XXXXXXXX:443 2023/12/21 11:36:23 [Debug] transport/internet: dialing to tcp:XXXXXXXX.com:443 2023/12/21 11:36:23 127.0.0.1:7900 accepted //dod4r81dg8pmduzedvbd7nyx6t7xepiqktoyy5bb-50.ipleak.net:443 [http -> proxy] 2023/12/21 11:36:24 [Info] [2522802786] proxy/trojan: tunneling request to tcp:dod4r81dg8pmduzedvbd7nyx6t7xepiqktoyy5bb-50.ipleak.net:443 via XXXXXXXX.com:443如果把destoverride部分删掉，xray发给服务端的是ip还是域名？
我自己试一下验证一下，好像和上面一样？
ps 我感觉文档写得不太详细 ，很多需要靠猜测加实践
谢谢。从你这里看，是域名。你这个例子中连接路由的方式，似乎是通过判断该域名是否属于应该被代理。如果是IPIfNoneMatch，并且没有这个域名的路由规则，那么就会本地dns解析。此时我认为会把解析出的ip替换到连接里，发给服务器。
sing-box
各位表达方式确实一个比一个难懂啊。我用小白一点的语言翻译下，如有错误立刻抽我： 使用xray分流必须开启"嗅探"（sniffing）。 疑惑点主要是下面的"流量嗅探只供路由使用"（即routeOnly）选项，开启与否的实际状况和影响： 不勾选 = 向代理服务器继续发送域名准备访问；（缺点：两次转换，理论上过程慢；优点：VPS的DNS得到的目标IP更准更近） 勾选 = 直接把IP发给代理服务器进行访问。（缺点：有可能这个IP不是最优的，优点：理论上转换过程少更快）
您解释的通俗到位，其实就是 传递域名 or 传递IP 的问题， 我玩过sing-box，所以经历过 从sniffing默认的传递域名到 传递IP的转变
传递域名给vps这样做的优点是 ，vps自己本地再解析可以获取最近的cdn IP， 这样vps访问网站的肯定是最优线路， 但是这个也有缺点，缺点是 本地dns分流 也解析了一次dns， 多此一举，而且还多耽误了一次dns解析时间，
因此我玩sing-box默认是喜欢传递IP给vps的，这样其实也可以做到 和 传递域名 一样的 vps解析可以获取最近的cdn IP， 只需要在本地dns解析分流被墙网站的dns设置走这个vps的代理节点即可， 而且节省了 vps端 传递域名导致的 多一次dns解析时间
目前xray,sing-box我都测试可以 传递域名 or 传递IP ， 只是clash.meta我还没有找到参数开启传递IP
请问使用singbox的时候打开routeOnly？ 但是我看到高级设置底部singbox那一块还有一个选项 “覆盖连接目标地址 用探测出的域名覆盖连接目标地址。” 这个又是什么，和routeOnly有冲突吗？ 我用的passwall2。
因此我玩sing-box默认是喜欢传递IP给vps的，这样其实也可以做到 和 传递域名 一样的 vps解析可以获取最近的cdn IP， 只需要在本地dns解析分流被墙网站的dns设置走这个vps的代理节点即可， 而且节省了 vps端 传递域名导致的 多一次dns解析时间
可以分享一下客户端+vps的配置吗？感觉客户端是不是要写两遍分流规则，routing里面一份，dns里面也一份？
各位表达方式确实一个比一个难懂啊。我用小白一点的语言翻译下，如有错误立刻抽我： 使用xray分流必须开启"嗅探"（sniffing）。
疑惑点主要是下面的"流量嗅探只供路由使用"（即routeOnly）选项，开启与否的实际状况和影响：
不勾选 = 向代理服务器继续发送域名准备访问；（缺点：两次转换，理论上过程慢；优点：VPS的DNS得到的目标IP更准更近） 勾选 = 直接把IP发给代理服务器进行访问。（缺点：有可能这个IP不是最优的，优点：理论上转换过程少更快）
我想知道，如果我的DNS访问是走代理的，是否得到的IP地址就已经是“更准更近”的呢？
