Date: 2026-06-20
Public version note: this post keeps the config shape, debugging path, and main decisions. Real internal addresses, client IPs, Xray outbound tags, proxy node addresses, and concrete client ports observed during downloads have been replaced with example values.
This post follows the earlier Raspberry Pi Wi-Fi hotspot and Xray transparent proxy setup. After the hotspot, tproxy, and dnsmasq were working, two smaller problems showed up:
```text
Client DNS appeared to enter the Raspberry Pi, but the Raspberry Pi itself could still leak some lookups to the upstream router
Game platforms, stores, and account pages should use the proxy, but game download CDNs should not
```
Neither problem can be solved by a broad "domestic direct, foreign proxy" rule. DNS, Xray routing, transparent proxy sniffing, game platform domains, and download CDN domains have to be handled separately.
The final shape was:
```text
Client DNS always goes to dnsmasq on the Raspberry Pi
dnsmasq does not query public DNS directly, and forwards everything to the Xray DNS inbound
Xray DNS sends Chinese domains and game download CDN domains to the local upstream DNS
Xray DNS sends other domains to Cloudflare DoH through the proxy outbound
Xray routing sends game platform domains through the proxy
Xray routing sends game download CDN domains direct
Xray routing.domainStrategy is set to AsIs to avoid local secondary DNS resolution
The proxy node address is pinned as an IP to avoid resolving the node domain during startup and reconnects
```
The important part is not "Steam direct" or "Steam proxy". Split it into two groups:
```text
Steam store, community, login, and platform APIs: proxy
Steam game content download CDNs: direct
```
PlayStation, Xbox, Nintendo Switch, and Epic Games follow the same idea.
## Related posts
- [Raspberry Pi Wi-Fi hotspot through Xray: DNS protection and transparent proxying](https://aside0.me/en/raspberry-pi-wifi-hotspot-xray-dns-2026-06-19-en/)
- [Raspberry Pi Tailscale exit node and Xray transparent proxy setup](https://aside0.me/en/raspberry-pi-tailscale-xray-2026-06-15-en/)
- [Route Cloudflare Tunnel through Xray: cloudflared, nftables, and sniffing](https://aside0.me/en/cloudflared-tunnel-xray-sniff-nft-2026-06-17-en/)
## Final topology
The DNS path looks like this:
```mermaid
flowchart LR
client["Client<br/>Phone / PC / game console"]
dnsmasq["dnsmasq<br/>192.168.10.20:53<br/>10.42.0.1:53"]
xray_dns["Xray DNS inbound<br/>127.0.0.1:5354"]
local_dns["Local upstream DNS<br/>192.168.10.1:53"]
doh["Cloudflare DoH<br/>cloudflare-dns.com"]
proxy["Xray default proxy outbound"]
client --> dnsmasq
dnsmasq --> xray_dns
xray_dns -->|"geosite:cn / download CDN"| local_dns
xray_dns -->|"Other domains"| proxy
proxy --> doh
```
The normal connection path looks like this:
```mermaid
flowchart LR
client["Client traffic"]
nft["nftables TProxy"]
xray["Xray routing"]
direct["direct<br/>local exit"]
proxy["default proxy<br/>proxy exit"]
client --> nft
nft --> xray
xray -->|"Game download CDN / geoip:cn"| direct
xray -->|"Game platforms / Google / YouTube / default"| proxy
```
Keep these two decisions separate:
```text
Where DNS goes: controls resolution results and CDN steering
Where connections go: controls whether the real access or download traffic uses the proxy
```
When game downloads are slow, the connection layer is not always the problem. If DNS uses remote DoH, the client may receive CDN nodes closer to the proxy exit, not closer to the home broadband. Resolving download CDN domains with local DNS can matter more than simply marking the connection as direct.
## How the DNS leak showed up
The first packet capture on the client side looked clean. Clients were sending DNS to the Raspberry Pi:
```text
Client -> 192.168.10.20:53
Client -> 10.42.0.1:53
```
So the clients were not bypassing dnsmasq.
But when I captured on `eth0` on the Raspberry Pi, I still saw the Raspberry Pi itself querying the router:
```text
192.168.10.20 -> 192.168.10.1:53 A? cloudflare-dns.com
192.168.10.20 -> 192.168.10.1:53 A? proxy-node.example.com
```
This was not a client side leak. It was a Raspberry Pi side leak. Two common causes are:
```text
Xray uses IPIfNonMatch, so it resolves domains into IPs before trying geoip rules
The Xray outbound node address is a domain, so startup or reconnects have to resolve that node name first
```
This leak is easy to miss. Client packet capture looks clean, and the Xray access log may still show that the final connection to `cloudflare-dns.com:443` uses the proxy. Before that connection happens, though, the name `cloudflare-dns.com` may already have been resolved by the local router.
The useful check is:
```bash
sudo tcpdump -ni eth0 'src host 192.168.10.20 and (udp port 53 or tcp port 53 or port 853)'
```
If the Raspberry Pi is querying `192.168.10.1:53` for the proxy node, DoH hostnames, or foreign sites, there is still a local DNS leak.
## Why I changed domainStrategy to AsIs
Xray has several common values for `routing.domainStrategy`. The risky one here is `IPIfNonMatch`.
`IPIfNonMatch` works like this:
```text
First try domain rules
If nothing matches, resolve the domain into an IP
Then try IP rules such as geoip:cn
```
That is useful when a domain request should still fall into an IP based rule such as `geoip:cn`. The tradeoff is that it can trigger local DNS resolution. If the system resolver still points to the router or the ISP, that creates a DNS leak.
The final setting was:
```json
{
"routing": {
"domainStrategy": "AsIs"
}
}
```
`AsIs` means Xray does not actively resolve a domain just to run IP rules. It uses the original domain, or the SNI / Host recovered by sniffing, for domain rules.
There is a cost:
```text
A domain passed into a local SOCKS inbound will not be resolved into an IP for geoip:cn if it does not match geosite
```
For this Raspberry Pi transparent proxy setup, that cost is acceptable:
```text
Most tproxy connections are already client-resolved IP connections
Xray can still match geoip:cn for those IP targets
When HTTP/TLS/QUIC sniffing recovers a domain, geosite rules still work
The default rule is still proxy, so AsIs does not turn unknown traffic into a leak
```
More importantly, `AsIs` stops Xray from quietly asking local DNS just to make a routing decision.
## The node domain also needs attention
Even after switching `domainStrategy` to `AsIs`, Xray still has to resolve the outbound node if the node address is a domain.
The public config should not contain a real node. The shape is roughly:
```json
{
"outbounds": [
{
"tag": "default-proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "203.0.113.10",
"port": 443,
"users": [
{
"id": "00000000-0000-0000-0000-000000000000",
"encryption": "none"
}
]
}
]
}
}
]
}
```
The address is an IP instead of a hostname so Xray does not have to resolve the proxy node through the local upstream DNS at startup.
If the node IP changes often, pinning the IP may not work for you. In that case, accept that bootstrapping the node domain is hard to avoid completely. Another option is a trusted bootstrap DNS or a hosts entry for the node name, but you must make sure it does not create proxy outbound recursion.
## dnsmasq only acts as the entry point
Keep dnsmasq simple. Its job is only to:
```text
Listen for LAN / hotspot DNS
Hand out DHCP to hotspot clients
Filter HTTPS/SVCB records
Forward all DNS to the Xray DNS inbound
```
Example config:
```ini
interface=wlan0
bind-interfaces
listen-address=10.42.0.1
listen-address=192.168.10.20
listen-address=127.0.0.1
dhcp-range=10.42.0.10,10.42.0.254,255.255.255.0,1h
dhcp-option=3,10.42.0.1
dhcp-option=6,10.42.0.1
no-dhcp-interface=eth0
no-resolv
server=127.0.0.1#5354
filter-rr=65
log-dhcp
```
I would not put a large set of rules like this into dnsmasq:
```ini
server=/steamcontent.com/192.168.10.1
server=/youtube.com/127.0.0.1#5354
```
dnsmasq can only do suffix based splitting. It cannot reuse `geosite:cn`, `geosite:steam`, or `geosite:category-games@cn` cleanly. Putting the split inside Xray DNS keeps DNS routing closer to the connection routing rules.
## Xray DNS split
Xray DNS handles the real DNS split:
```text
Chinese domains -> local upstream DNS
Game download CDNs -> local upstream DNS
Other domains -> Cloudflare DoH through the proxy
```
Example config:
```json
{
"dns": {
"servers": [
{
"address": "192.168.10.1",
"port": 53,
"domains": [
"geosite:cn",
"domain:cn",
"geosite:category-games@cn",
"domain:steamcontent.com",
"domain:steamserver.net",
"full:steamcdn-a.akamaihd.net",
"full:steampipe.akamaized.net",
"domain:epicgamescdn.com",
"full:download.epicgames.com",
"full:download2.epicgames.com",
"full:download3.epicgames.com",
"full:download4.epicgames.com",
"full:egdownload.fastly-edge.com",
"full:epicgames-download1.akamaized.net",
"full:assets1.xboxlive.com",
"full:assets2.xboxlive.com",
"full:d1.xboxlive.com",
"full:dlassets-ssl.xboxlive.com",
"domain:dl.delivery.mp.microsoft.com",
"domain:delivery.mp.microsoft.com",
"domain:dl.playstation.net",
"domain:gs2.ww.prod.dl.playstation.net",
"full:psnobj.prod.dl.playstation.net",
"full:theia.dl.playstation.net",
"domain:hac.lp1.d4c.nintendo.net",
"domain:hac.lp1.eshop.nintendo.net",
"domain:wup.eshop.nintendo.net",
"domain:wup.shop.nintendo.net",
"domain:cdn.nintendo.net"
],
"skipFallback": true
},
{
"address": "https://cloudflare-dns.com/dns-query"
}
],
"queryStrategy": "UseIPv4",
"useSystemHosts": true,
"tag": "dns-local"
}
}
```
`skipFallback: true` matters. When a domain matches the local upstream DNS server, and the local DNS returns NXDOMAIN or another clear result, Xray should not ask Cloudflare DoH again. Otherwise the same Chinese or download CDN domain may be queried on both sides.
Then make sure Xray DNS itself uses the proxy when it reaches DoH:
```json
{
"routing": {
"rules": [
{
"type": "field",
"inboundTag": ["dns-local"],
"domain": [
"domain:cloudflare-dns.com",
"domain:dns.google"
],
"outboundTag": "default-proxy"
},
{
"type": "field",
"inboundTag": ["dns-local"],
"outboundTag": "direct"
}
]
}
}
```
Those two rules mean:
```text
Xray built-in DNS -> Cloudflare DoH: proxy
Xray built-in DNS -> local upstream 192.168.10.1:53: direct
```
## Separate game platforms from download CDNs
The tempting first version is:
```json
{
"type": "field",
"domain": [
"geosite:steam",
"geosite:epicgames",
"geosite:xbox",
"geosite:playstation",
"geosite:nintendo"
],
"outboundTag": "direct"
}
```
That is not what this setup needs.
`geosite:steam` includes more than download CDNs:
```text
store.steampowered.com
steamcommunity.com
steampowered.com
steamstatic.com
steamcontent.com
steamcdn-a.akamaihd.net
```
If the whole set goes direct, the store, community, login, and APIs go direct too. The more common goal is:
```text
Platform, store, community, account, friends, inventory: proxy
Game download content CDNs: direct
```
So the routing order should be:
```text
Match download CDNs first -> direct
Then match game platform geosite groups -> proxy
Then match geoip:cn -> direct
Default -> proxy
```
The order matters. If `geosite:steam -> proxy` comes first, a later `steamcontent.com -> direct` rule may never get a chance to match.
## Direct rules for download CDNs
This is a practical skeleton for direct download CDN rules. The public version keeps only the domain shape and contains no private data.
```json
{
"type": "field",
"domain": [
"geosite:category-games@cn",
"domain:steamcontent.com",
"domain:steamserver.net",
"full:steamcdn-a.akamaihd.net",
"full:steampipe.akamaized.net",
"full:steampipe-kr.akamaized.net",
"full:steampipe-partner.akamaized.net",
"full:alibaba.cdn.steampipe.steamcontent.com",
"full:dl.steam.clngaa.com",
"full:st.dl.bscstorage.net",
"full:st.dl.eccdnx.com",
"full:st.dl.pinyuncloud.com",
"domain:epicgamescdn.com",
"full:download.epicgames.com",
"full:download2.epicgames.com",
"full:download3.epicgames.com",
"full:download4.epicgames.com",
"full:fastly-download.epicgames.com",
"full:egdownload.fastly-edge.com",
"full:epicgames-download1.akamaized.net",
"regexp:^epicgames-download[0-9]+\\.akamaized\\.net$",
"regexp:^cdn[0-9]+-epicgames-[0-9]+\\.file\\.myqcloud\\.com$",
"regexp:^epicgames-download[0-9]+-[0-9]+\\.file\\.myqcloud\\.com$",
"full:assets1.xboxlive.com",
"full:assets1.xboxlive.com.nsatc.net",
"full:assets2.xboxlive.com",
"full:d1.xboxlive.com",
"full:xbox-mbr.xboxlive.com",
"full:xvcf1.xboxlive.com",
"full:xvcf2.xboxlive.com",
"full:dlassets-ssl.xboxlive.com",
"domain:dl.delivery.mp.microsoft.com",
"domain:delivery.mp.microsoft.com",
"domain:prod.do.dsp.mp.microsoft.com",
"domain:dl.playstation.net",
"domain:gs2.ww.prod.dl.playstation.net",
"domain:gs2.ww.prod.dl.playstation.net.edgesuite.net",
"domain:gs2-ww-prod.psn.akadns.net",
"full:gs-sec.ww.np.dl.playstation.net",
"full:gst.prod.dl.playstation.net",
"full:psnobj.prod.dl.playstation.net",
"full:theia.dl.playstation.net",
"full:tmdb.np.dl.playstation.net",
"full:uef.np.dl.playstation.net",
"full:vulcan.dl.playstation.net",
"domain:hac.lp1.d4c.nintendo.net",
"domain:hac.lp1.eshop.nintendo.net",
"domain:wup.eshop.nintendo.net",
"domain:wup.shop.nintendo.net",
"domain:cdn.nintendo.net",
"full:ccs.cdn.wup.shop.nintendo.net.edgesuite.net",
"full:ecs-lp1.hac.shop.nintendo.net",
"full:geisha-wup.cdn.nintendo.net",
"full:idbe-wup.cdn.nintendo.net",
"full:receive-lp1.dg.srv.nintendo.net"
],
"outboundTag": "direct"
}
```
This list is based on two public sources:
```text
v2fly/domain-list-community: useful for game platform and geosite rules
uklans/cache-domains: useful for game download content cache and CDN domains
```
Do not send the whole `geosite:microsoft` group direct. It is too broad and includes GitHub, Office, Copilot, Visual Studio, Windows Update, and many cases unrelated to Xbox downloads. For Xbox / Microsoft Store downloads, pick the smaller delivery set such as `assets1.xboxlive.com`, `dl.delivery.mp.microsoft.com`, and `dlassets-ssl.xboxlive.com`.
Do not send the whole `geosite:sony` group direct either. It covers more than PlayStation downloads. Use PlayStation download CDN domains such as `dl.playstation.net` and `gs2.ww.prod.dl.playstation.net`.
## Proxy rules for platform domains
After the download CDN direct rule, route the game platform groups through the proxy:
```json
{
"type": "field",
"domain": [
"geosite:steam",
"geosite:epicgames",
"geosite:xbox",
"geosite:playstation",
"geosite:nintendo"
],
"outboundTag": "default-proxy"
}
```
This rule must sit after the download CDN direct rule.
The result should look like this:
```text
store.steampowered.com -> proxy
steamcommunity.com -> proxy
www.epicgames.com -> proxy
www.xbox.com -> proxy
www.playstation.com -> proxy
www.nintendo.com -> proxy
steamcdn-a.akamaihd.net -> direct
steamcontent.com -> direct
download.epicgames.com -> direct
assets1.xboxlive.com -> direct
gs2.ww.prod.dl.playstation.net -> direct
hac.lp1.d4c.nintendo.net -> direct
```
## Other routing rule order
The final order can be understood like this:
```text
dns-in -> dns-out
DNS port -> dns-out
UDP/443 -> blackhole or fast nft reject
dns-local to DoH -> proxy
dns-local to local DNS -> direct
Game download CDN -> direct
Game platform main domains -> proxy
Ad domains -> blackhole or proxy as needed
geoip:private -> direct
Google / YouTube -> proxy
geoip:google -> proxy
geoip:cn -> direct
geosite:cn -> direct
NTP -> direct
Default -> proxy
```
For UDP/443, I prefer an nftables fast reject before Xray blackhole. Silent drops make clients wait for timeout. A fast reject lets browsers and apps fall back to TCP/443 sooner.
## Verify DNS split
First capture whether the Raspberry Pi sends queries to the local upstream DNS:
```bash
sudo tcpdump -ni eth0 'host 192.168.10.1 and port 53'
```
Then query these domains from the client entry point:
```text
store.steampowered.com
www.epicgames.com
www.xbox.com
www.playstation.com
www.nintendo.com
steamcontent.com
download.epicgames.com
assets2.xboxlive.com
gs2.ww.prod.dl.playstation.net
hac.lp1.d4c.nintendo.net
```
Expected result:
```text
Platform main domains: should not appear in the 192.168.10.1:53 capture
Download CDN domains: should appear in the 192.168.10.1:53 capture
```
One actual verification looked like this:
```text
store.steampowered.com did not hit local DNS
www.epicgames.com did not hit local DNS
www.xbox.com did not hit local DNS
www.playstation.com did not hit local DNS
www.nintendo.com did not hit local DNS
steamcontent.com -> 192.168.10.1:53
epicgamescdn.com -> 192.168.10.1:53
assets2.xboxlive.com -> 192.168.10.1:53
gs2.ww.prod.dl.playstation.net -> 192.168.10.1:53
hac.lp1.d4c.nintendo.net -> 192.168.10.1:53
```
That means:
```text
Platform access uses proxy-side DNS
Download CDNs use local DNS to get nearby nodes
```
## Verify connection routing
The Xray access log is the clearest evidence. Use the local SOCKS inbound to test a few domains:
```bash
curl --socks5-hostname 127.0.0.1:10808 -I https://store.steampowered.com/
curl --socks5-hostname 127.0.0.1:10808 -I https://www.epicgames.com/
curl --socks5-hostname 127.0.0.1:10808 -I https://www.xbox.com/
curl --socks5-hostname 127.0.0.1:10808 -I https://www.playstation.com/
curl --socks5-hostname 127.0.0.1:10808 -I https://www.nintendo.com/
curl --socks5-hostname 127.0.0.1:10808 -I https://steamcdn-a.akamaihd.net/
curl --socks5-hostname 127.0.0.1:10808 -I https://download.epicgames.com/
curl --socks5-hostname 127.0.0.1:10808 -I https://assets1.xboxlive.com/
curl --socks5-hostname 127.0.0.1:10808 -I https://gs2.ww.prod.dl.playstation.net/
curl --socks5-hostname 127.0.0.1:10808 -I https://atum.hac.lp1.d4c.nintendo.net/
```
Expected Xray log:
```text
store.steampowered.com [socks-in -> default-proxy]
www.epicgames.com [socks-in -> default-proxy]
www.xbox.com [socks-in -> default-proxy]
www.playstation.com [socks-in -> default-proxy]
www.nintendo.com [socks-in -> default-proxy]
steamcdn-a.akamaihd.net [socks-in -> direct]
download.epicgames.com [socks-in -> direct]
assets1.xboxlive.com [socks-in -> direct]
gs2.ww.prod.dl.playstation.net [socks-in -> direct]
atum.hac.lp1.d4c.nintendo.net [socks-in -> direct]
```
For transparent proxy clients, watch the access log in the same way:
```bash
sudo tail -f /var/log/xray/access.log
```
During a Steam game download, you may see many connections like:
```text
from 192.168.10.50 accepted tcp:183.238.66.68:8090 [tproxy-in -> direct]
from 192.168.10.50 accepted tcp:183.238.66.69:8090 [tproxy-in -> direct]
from 192.168.10.50 accepted tcp:183.238.66.100:8090 [tproxy-in -> direct]
from 192.168.10.50 accepted tcp:183.238.66.103:8090 [tproxy-in -> direct]
```
It is normal that `steamcontent.com` does not appear there. The client has already resolved the domain into CDN IPs, so Xray tproxy sees IP targets. The evidence is:
```text
The targets cluster around local CDN IPs
The ports match download behavior, such as 80 / 443 / 8090
The Xray outbound is direct
At the same time, platform pages or foreign background requests can still use default-proxy
```
## Verify that DNS no longer leaks
Finally, confirm that the Raspberry Pi itself is not sending unwanted DNS out:
```bash
sudo tcpdump -ni eth0 'src host 192.168.10.20 and (udp port 53 or tcp port 53 or port 853)'
```
Allowed examples:
```text
192.168.10.20 -> 192.168.10.1:53 Chinese domains
192.168.10.20 -> 192.168.10.1:53 game download CDN domains
```
Unexpected examples:
```text
192.168.10.20 -> 192.168.10.1:53 google.com
192.168.10.20 -> 192.168.10.1:53 youtube.com
192.168.10.20 -> 192.168.10.1:53 cloudflare-dns.com
192.168.10.20 -> 192.168.10.1:53 proxy node domain
```
If `cloudflare-dns.com` still appears, Xray DNS may not be routing DoH through the proxy, or another local DoH forwarder may be resolving the DoH hostname itself.
If the proxy node domain still appears, the Xray outbound probably still uses a hostname, or another proxy process on the system is resolving its node.
## Backup and rollback
Back up the Xray config before editing:
```bash
sudo cp /etc/xray/config.json /etc/xray/config.json.bak-$(date +%Y%m%d-%H%M%S)
```
Test the new config first:
```bash
sudo /usr/local/bin/xray run -test -config /tmp/new-xray-config.json
```
After it passes, replace the config:
```bash
sudo install -m 0644 /tmp/new-xray-config.json /etc/xray/config.json
sudo systemctl restart xray
sudo systemctl is-active xray
```
Rollback:
```bash
sudo install -m 0644 /etc/xray/config.json.bak-YYYYMMDD-HHMMSS /etc/xray/config.json
sudo systemctl restart xray
```
Back up dnsmasq too:
```bash
sudo cp /tmp/raspi-hotspot-dnsmasq.conf /tmp/raspi-hotspot-dnsmasq.conf.bak-$(date +%Y%m%d-%H%M%S)
dnsmasq --test --conf-file=/tmp/raspi-hotspot-dnsmasq.conf
```
## Common mistakes
First mistake: only checking whether clients send external DNS.
Client DNS entering the Raspberry Pi does not prove that the Raspberry Pi itself is clean. Capture `src host Raspberry-Pi-address and port 53` on `eth0`.
Second mistake: sending the whole `geosite:steam` group direct.
That also sends the Steam store, community, and account traffic direct. Downloads may improve, but platform access can become unstable again. A better split is download CDN direct, platform geosite proxy.
Third mistake: sending `geosite:microsoft` direct.
That affects much more than Xbox. Xbox downloads only need a small group of `xboxlive` and Microsoft Store delivery domains.
Fourth mistake: changing only the connection layer for game download CDNs.
If DNS still uses remote DoH, the CDN result may be close to the proxy exit instead of the home broadband. Download CDNs should have both:
```text
local DNS resolution
direct connection routing
```
Fifth mistake: enabling `IPIfNonMatch` for finer geoip routing and forgetting that it can trigger local DNS.
In transparent proxy setups, many connections are already IP connections. With sniffing and explicit geosite rules, `AsIs` is usually cleaner.
## References
The game platform and download CDN split in this post mainly comes from these public sources:
- Xray routing documentation, including the behavior of `AsIs`, `IPIfNonMatch`, and `IPOnDemand`.
https://xtls.github.io/en/config/routing.html
- Xray DNS documentation, including built-in DNS, DNS server objects, and routing-stage resolution.
https://xtls.github.io/en/config/dns.html
- v2fly/domain-list-community, the source for `geosite:steam`, `geosite:epicgames`, `geosite:xbox`, `geosite:playstation`, and `geosite:nintendo`.
https://github.com/v2fly/domain-list-community
- uklans/cache-domains, game download CDN domain lists for LAN content caches.
https://github.com/uklans/cache-domains
- Epic official allowlist for Epic Games Store and download related domains.
https://www.epicgames.com/help/c-202300000001619/c-202300000001672/which-domains-need-to-be-whitelisted-to-reach-the-epic-servers-a202300000012358
- Microsoft Windows / Xbox endpoint documentation for Xbox Live and Microsoft Store delivery endpoints.
https://learn.microsoft.com/en-us/windows/privacy/windows-11-endpoints-non-enterprise-editions
## Summary
The core idea is layering:
```text
DNS layer:
Chinese domains and game download CDNs use local DNS
Other domains use proxy-side DoH
Connection layer:
Game download CDNs direct
Game platforms and foreign sites proxy
Chinese IPs direct
Default proxy
Leak prevention:
routing.domainStrategy uses AsIs
The proxy node address does not depend on local DNS
tcpdump verifies the Raspberry Pi's own DNS egress
```
The end result is that Steam, Epic, Xbox, PlayStation, and Nintendo platform pages still use the proxy for reachability. When the client downloads game content, DNS uses the local upstream to get a nearby CDN, and the connection goes direct without consuming proxy bandwidth.
Raspberry Pi Xray DNS leak control and game download split routing
This person is a lazy dog and has left nothing
Comments