𐲓𐳛𐳪𐳂𐳐 𐲀𐳢𐳦𐳫𐳢 𐲥𐳔𐳛𐳪𐳌𐳑𐳖𐳇
𐲓𐳛𐳪𐳂𐳐 𐲀𐳢𐳦𐳫𐳢 𐲥𐳔𐳛𐳪𐳌𐳑𐳖𐳇
> VpnService 需要指定 allowBypass 应用才能绕过 VPN，v2rayNG 并没有这样做，所以恐怕不是这个原因。 按照现在 FCM 的文档来说该当如此，但是目前观察到的现象还是在数据网络下面 FCM 推送直接绕开 VpnService 连接，不知道是 Google 的问题还是什么情况。
后续： 因为手机变砖换了手机，系统是 Android 14 (OxygenOS 14)，现在所有网络下面的 FCM 都没有绕开系统 VPN 服务，全部经过 v2rayNG 进行连接了。 但是 Android 9 下面还是有这样的问题（Android 11 预计亦然），所以现在怀疑是不是 google 那边改动了什么导致的问题。 ~~有种莫名其妙就被整出毛病的感觉~~
It is recommended to use gRPC instead of H2 if you want to pass VLESS through Cloudflare CDN. (Remember to turn on the switch in Cloudflare dashboard) It seems something...
> That is weird, Does repacking corrupt data? No, no data is corrupted, but the mess in behaviors. The repacking can be seems as the "request reordering", because the CDN...
感谢回复，前来补充细节。如有问题还请不吝指教。 以下日志因为隐私原因做了打码及筛选，如果需要完整日志可以私发。 客户端分流及 DNS 查询规则为黑名单（优先 direct），使用加强版 geosite 和 geoip，代理 ```geosite:gfw``` ```geoip:google``` 规则，没有 block。 所有域名（不管直连还是代理）均使用 FakeDNS。 使用的可连通 ts 服务器在国内直连，无法正常连通 ts 服务器在 GCP 上，因为 IP 匹配被代理（如果直连则是没问题的）。 Server Log ``` 2024/01/23 09:32:36 [Info]...
已经找到借用 sing-box 进行 TUN 接管和 DNS 查询的方法。不过这个方法需要进行全局代理，因此最后的日志会很杂。此处放出相关配置。 为了避免 Xray 自己的 FakeDNS 转换对结果发生干扰，此处使用 sing-box 作为 FakeDNS 源，由 sing-box 将域名传送给 Xray。 （不知道为什么 sing-box 也是传输域名而非 IP，歪打正着保留了域名反而方便测试。如果 sing-box 做完全的 TUN 而将 Xray 作为 FakeDNS...
看了下版本变化的记录里面似乎和 #1011 以及 #2356 有关，应该是想实现一个更好的 UDP sniff 处理逻辑但是漏了一些地方没处理。 > * 如果你认为在代理 UDP 时传送域名目标地址到服务器会引起问题，想要总是发送 IP 目标地址到服务器的话，建议实现 outbound 的 ```domainStrategy```。 其实如果客户端的应用程序不太看重 IP 地址是否在指定的目标内而是只要使用时保持地址恒定（FakeDNS 不敏感）的话，传输域名目标地址到服务器处理似乎是更好的做法，这样的话解析策略交由服务端 ~防止出现比如客户端解析了 IPv6 地址交给了单纯的 IPv4 服务器上的服务端的尴尬行为~ 。 ~问题推测：可能是服务端收到来自 inbound...
感谢回复！至少客户端 v1.8.8 (v2rayNG 1.8.17) 下带 FakeDNS **直连**的 QUIC 恢复正常了（之前似乎有问题，无法正常触发）。 不过服务端与客户端同为 v1.8.8 时 ~~**代理** QUIC 似乎无法触发（flow 为 xtls-rprx-vision-upd443，是否实际响应会偏慢的问题？），~~ **（更正：443 端口的 QUIC 正常，线路问题）** 被代理的 Teamspeak 之类的应用似乎也有问题（响应似乎很缓慢）。 另外因为才想到可以用虚拟机来做客户端，然后将模拟的服务端放置在宿主机或者另一个虚拟机中，这样就可以在保证没有隐私问题的同时获得详细记录（不过 UDP 回包依然不会被 log...） 然后似乎的确还有点问题（比如 Teamspeak...
感谢回复，这个方法的确有效果 > ```sb_tunin-sb_socksoutray_socksin-ray_directout```, ```sb_tunin-sb_socksoutsb_socksin-sb_directout``` 这两种情况本地测试抓包看下 Loopback 网卡的 SOCKS5 （以及出口网卡的流量）有什么区别 如果是 ```sb_tunin-sb_socksoutray_socksin-ray_directout``` 的情况，发出的 SOCKS5 UDP 为域名，返回的 SOCKS5 UDP 为 FakeIP 范围内的 IP 地址（应该是 Xray-core 的 DNS 查询被 sing-box 一同劫持了），TUN 上的抓包是 FakeIP...
切换成两个端点不同机器的话 如果是 sb_tunin-sb_socksoutray_socksin-ray_directout 的情况，发出的 SOCKS5 UDP 为域名，返回的 SOCKS5 UDP 为实际地址，TUN 上的抓包是真实地址返回，连接失败。 如果是 sb_tunin-sb_socksoutsb_socksin-sb_directout 的情况，SOCKS5 中的 UDP 均为域名，TUN 上的抓包是 FakeIP 返回，连接成功。