"My game got worse after turning on the proxy" is common feedback. The reason is not that the proxy is useless, but that game traffic and web traffic want completely different things.
Three characteristics of game traffic
Why TUN is required
A system proxy (HTTP/SOCKS) handles TCP only. A game's real-time data — position updates, ability activations — is almost entirely UDP, and the system proxy is blind to it.
The result: login, the store and updates go through the proxy (TCP), while the actual match traffic stays on the original path. That half-and-half state is sometimes worse than no proxy at all.
To route game traffic for real, you have to enable TUN.
But the node has to support UDP
The udp: true in a config is only a client-side declaration; whether the server actually forwards UDP is up to the provider.
proxies:
- name: "HK-01"
type: trojan
server: hk.example.com
port: 443
password: "pwd"
udp: true # declares support; whether it works depends on the serverWhat NAT type means
The NAT type reported by multiplayer games (open/moderate/strict, or Type 1/2/3) describes whether external hosts can initiate a connection to your device.
A proxy changes your NAT type — potentially in either direction:
- If the node's server has a dedicated public IP with no port restrictions → you may end up Full Cone, better than your home broadband
- If the node is a shared-IP relay, or applies strict port mapping → you become Symmetric, and multiplayer gets harder
That is the usual cause of "I turned on the proxy and now I cannot join lobbies".
Latency is not the only metric — loss matters more
url-test measures latency only; it cannot see loss or jitter. So do not use the automatic group to pick a gaming node.
Measuring packet loss
# Windows: 100 pings, then read the loss rate
ping -n 100 node-ip# macOS / Linux
ping -c 100 node-ip
# a better tool: mtr shows loss at every hop
mtr -r -c 100 node-ipLook at the Loss% on the final line. Above 1% and it is unsuitable for competitive play.
mtr also tells you where loss occurs — if an intermediate hop shows loss but the final hop does not, that router is most likely rate-limiting ICMP rather than actually dropping your traffic.
A gaming-oriented configuration
1. A dedicated gaming policy group
proxy-groups:
- name: "🎮 Gaming"
type: fallback # fallback, not url-test
proxies: ["Dedicated-HK", "Dedicated-JP", "Standard-HK"]
url: "http://www.gstatic.com/generate_204"
interval: 600 # long interval, fewer switchesWhy fallback: switching nodes mid-game means a disconnect and reconnect. fallback only changes when the current node genuinely dies, which is far steadier than url-test.
2. TUN adjustments
tun:
enable: true
stack: gvisor # best UDP compatibility
auto-route: true
auto-detect-interface: true
dns-hijack: [any:53]
mtu: 1400 # slightly lower, reducing fragmentation3. Routing to the gaming group by process or domain
prepend-rules:
# by process
- PROCESS-NAME,steam.exe,🎮 Gaming
- PROCESS-NAME,Battle.net.exe,🎮 Gaming
# by domain
- DOMAIN-SUFFIX,steamserver.net,🎮 Gaming
- DOMAIN-SUFFIX,battle.net,🎮 Gaming
# by port (many games use a fixed range)
- AND,((NETWORK,UDP),(DST-PORT,27000-27100)),🎮 GamingProcess rules need find-process-mode: strict; see process rules explained.
4. Turning off features that may interfere
sniffer:
enable: true
skip-domain:
- "+.steamserver.net" # sniffing can interfere with game protocolsSome games' custom protocols get misread by the sniffer, so add them to skip-domain.
What kind of node suits gaming
Whether a line suits gaming is better judged by measurement than by the spec sheet. Run this on the trial allowance:
When not to play through a proxy
Local games should always go direct. Add a rule that excludes them explicitly:
prepend-rules:
- PROCESS-NAME,local-game.exe,DIRECTAbout anti-cheat
Some games' anti-cheat systems detect virtual adapters and unusual network paths. Using a proxy does not usually breach the rules, but:
- Some games' terms of service prohibit third-party network tools
- A frequently changing IP can trip risk controls (unusual-location detection)
- A small number of anti-cheat systems refuse to start at all with a virtual adapter present
Before and after
In short
- Games use UDP, and only TUN can carry it — the system proxy is useless here
- The node must genuinely support UDP;
udp: trueis only a declaration - Loss and jitter matter more than latency — measure with mtr
- Use fallback rather than url-test for the gaming group, to avoid mid-game switching
- Local games go direct; proxying them only makes things worse
- A dedicated line (IPLC/IEPL) is the real answer for gaming; an ordinary relay rarely meets the bar
Related: TUN internals and process rules explained.
Related docs
How fake-ip actually works, how it differs from redir-host, the division of labour between nameserver and fallback, how to prevent DNS leaks, and why internal hostnames stop resolving.
What TUN mode does, from the packet's point of view: creating a virtual adapter, rewriting the routing table, hijacking port 53, and choosing between the gvisor, system and mixed stacks.
What each column means and how to use it: tracking down the program eating your data, why the connection count explodes, where throughput is bottlenecked, and continuous monitoring through the API.