Your Split Tunnel Excludes the Launcher, Not the Game
A launcher starts another executable for the match, and that process owns its own sockets. Find the real process, match the right identifier, then test.
You add the launcher to the exclusion list, the download jumps from slow to fast, and the match still lands on a distant server. Nothing is broken. The launcher and the game are two processes with two sets of sockets, and excluding one says nothing about the other. The download got faster because the download was the launcher's traffic; the match is somebody else's connection, opened by an executable your rule has never seen.
One installer, many processes
Modern game software is a small constellation. There is a client that signs you in, an updater that pulls content, a launcher that starts the game, and a game executable that may itself spawn a second process for anti-cheat or for the matchmaking overlay. Each of those can hold its own connections to its own destinations.
An exclusion rule usually names one of them. Which one it names depends entirely on the identifier the VPN client supports, and that is the part users rarely check. Some clients match an executable path, some match a bundle or package identifier, and some match a process name that two unrelated binaries can share. Read the rule before you read the process list, because the rule constrains what you can even express.
The symptom is therefore not "split tunnelling is broken". It is "the rule covers a process that is not the one carrying the traffic I care about", which is a much narrower and much more fixable statement. Once you say it that way, the next step stops being guesswork.
Find the process that owns the match connection
Start the game, get into a match, and look at who owns the sockets rather than at what is on screen. On Windows the process list plus a per-process socket query answers it in two commands:
Get-Process | Where-Object { $_.ProcessName -match 'launcher|game|client' } | Select-Object Id,ProcessName,Path
Get-NetTCPConnection -State Established | Select-Object OwningProcess,RemoteAddress,RemotePort | Sort-Object OwningProcessThe second command prints a process id, not a name, so join the two outputs by id. The row you are looking for is the one whose remote address belongs to the game service, and its owning process is the executable your rule has to name.
On Linux the same question takes one command per socket type, and it is worth checking both, because a match connection may be UDP while everything else is TCP:
ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'If the game runs in a container or a compatibility layer, the process you find may be a shim rather than the binary you installed. In that case the identifier that matters is the one the client sees, which may be the shim's path, and no amount of editing the original file will affect it.
Match the identifier your client supports
Read the client's documentation for the exclusion rule before adding anything. The three common models behave differently, and one of them is a trap.
| Identifier | How it behaves | Failure mode |
|---|---|---|
| Executable path | Matches exactly the file at that path | Breaks when an update moves the binary |
| Process name | Matches any binary with that name | Too broad; catches unrelated software |
| Package or bundle id | Matches a signed application group | May include services you did not intend |
Path rules are the most precise and the most brittle. A launcher update that relocates the executable leaves the rule pointing at a file that no longer runs, and the symptom returns without anything obviously changing. Package rules survive that, and they can also quietly cover helper processes you never thought about, which is either convenient or alarming depending on the helper.
Whatever the client supports, do not add entries for every executable you can find. A list assembled by trial and error until one session worked is unreviewable, and it will silently accumulate exceptions for unrelated software. Name the process you found, and write down what it was for.
Test on the match, not on a download
The launcher's download speed is the worst possible test, because it exercises exactly the process that was already excluded. Use the thing that was failing, and check the path rather than the game's own performance display:
ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015The first command needs the address the match server resolved to, which the game's connection log or your client can give you. If the route names the physical interface, the rule is working. The second shows whether a session exists at all, which separates "excluded but the server is down" from "not excluded".
Keep the region and the access network fixed while you test. A match that lands on a different datacentre each attempt produces different addresses, and you will end up chasing a moving target instead of validating a rule. Two runs with the same address are worth more than ten with different ones.
Recheck after the next update
Any path-based rule has a shelf life measured in patch cycles. When the game stops respecting the exclusion a month later, the first thing to check is whether the executable moved, and the second is whether a new helper process appeared alongside it.
The application exclusion model documented by one client is a reasonable reference for how these rules are described, though the details differ between products. Read yours, record the identifier you used, and note the date. That record is what turns a mystery into a five-minute fix the next time the launcher ships an update.
If the client simply cannot express the boundary you need, an approved broader policy is better than a pile of undocumented exceptions. Broad and understood beats narrow and wrong, especially when the narrow version is what everyone believes is in place.