Dein Split-Tunnel schließt den Launcher aus, nicht das Spiel

Du nimmst den Launcher in die Ausschlussliste auf, der Download springt von langsam auf schnell, und das Match landet trotzdem auf einem weit entfernten Server. Nichts ist kaputt. Launcher und Spiel sind zwei Prozesse mit zwei Sätzen von Sockets, und den einen auszuschließen sagt nichts über den anderen. Der Download wurde schneller, weil der Download der Verkehr des Launchers war; das Match ist die Verbindung von jemand anderem, geöffnet von einer ausführbaren Datei, die deine Regel nie gesehen hat.

Ein Installer, viele Prozesse

Moderne Spielsoftware ist ein kleines Sternbild. Es gibt einen Client, der dich anmeldet, einen Updater, der Inhalte lädt, einen Launcher, der das Spiel startet, und eine Spieldatei, die selbst einen zweiten Prozess für Anti-Cheat oder für das Matchmaking-Overlay starten kann. Jeder davon kann eigene Verbindungen zu eigenen Zielen halten.

Eine Ausschlussregel benennt normalerweise einen davon. Welchen sie benennt, hängt vollständig von der Kennung ab, die der VPN-Client unterstützt, und genau das prüfen Nutzer selten. Manche Clients gleichen einen Pfad zu einer ausführbaren Datei ab, manche eine Paket- oder Bundle-Kennung, und manche einen Prozessnamen, den zwei unabhängige Binärdateien teilen können. Lies die Regel, bevor du die Prozessliste liest, denn die Regel begrenzt, was du überhaupt ausdrücken kannst.

Das Symptom ist also nicht „der Split-Tunnel ist kaputt“. Es ist „die Regel deckt einen Prozess ab, der nicht derjenige ist, der den Verkehr trägt, der mich interessiert“, und das ist eine viel engere und viel leichter reparierbare Aussage. Sobald du es so sagst, hört der nächste Schritt auf, Rätselraten zu sein.

Finde den Prozess, dem die Match-Verbindung gehört

Starte das Spiel, gehe in ein Match und schau, wem die Sockets gehören, statt was auf dem Bildschirm steht. Unter Windows beantwortet die Prozessliste plus eine Socket-Abfrage pro Prozess das mit zwei Befehlen:

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 OwningProcess

Der zweite Befehl gibt eine Prozess-ID aus, keinen Namen, also verknüpfe die beiden Ausgaben über die ID. Die Zeile, die du suchst, ist die, deren Remote-Adresse zum Spieldienst gehört, und ihr besitzender Prozess ist die ausführbare Datei, die deine Regel benennen muss.

Unter Linux braucht dieselbe Frage einen Befehl pro Socket-Typ, und es lohnt sich, beide zu prüfen, weil eine Match-Verbindung UDP sein kann, während alles andere TCP ist:

ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'

Läuft das Spiel in einem Container oder einer Kompatibilitätsschicht, kann der gefundene Prozess ein Shim sein statt der Binärdatei, die du installiert hast. In diesem Fall ist die Kennung wichtig, die der Client sieht, und das kann der Pfad des Shims sein; kein Bearbeiten der Originaldatei wird daran etwas ändern.

Ordne die Kennung zu, die dein Client unterstützt

Lies die Dokumentation des Clients zur Ausschlussregel, bevor du etwas hinzufügst. Die drei üblichen Modelle verhalten sich unterschiedlich, und eines davon ist eine Falle.

Pfadregeln sind die genauesten und die brüchigsten. Ein Launcher-Update, das die ausführbare Datei verschiebt, lässt die Regel auf eine Datei zeigen, die nicht mehr läuft, und das Symptom kehrt zurück, ohne dass sich offensichtlich etwas ändert. Paketregeln überstehen das, und sie können auch still Hilfsprozesse abdecken, an die du nie gedacht hast, was je nach Helfer praktisch oder alarmierend ist.

Was auch immer der Client unterstützt, füge keine Einträge für jede ausführbare Datei hinzu, die du findest. Eine Liste, die durch Ausprobieren zusammengestellt wurde, bis eine Sitzung funktionierte, ist nicht überprüfbar, und sie wird still Ausnahmen für unbezogene Software ansammeln. Benenne den Prozess, den du gefunden hast, und notiere, wofür er war.

Teste am Match, nicht an einem Download

Die Download-Geschwindigkeit des Launchers ist der denkbar schlechteste Test, weil sie genau den Prozess beansprucht, der bereits ausgeschlossen war. Nimm das, was fehlschlug, und prüfe den Pfad statt die eigene Leistungsanzeige des Spiels:

ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015

Der erste Befehl braucht die Adresse, zu der der Match-Server aufgelöst hat, die dir das Verbindungsprotokoll des Spiels oder dein Client geben kann. Wenn die Route die physische Schnittstelle nennt, funktioniert die Regel. Der zweite zeigt, ob überhaupt eine Sitzung existiert, was „ausgeschlossen, aber der Server ist down“ von „nicht ausgeschlossen“ trennt.

Halte Region und Zugangsnetz während des Tests fest. Ein Match, das bei jedem Versuch in einem anderen Rechenzentrum landet, erzeugt unterschiedliche Adressen, und du jagst am Ende ein bewegliches Ziel, statt eine Regel zu validieren. Zwei Läufe mit derselben Adresse sind mehr wert als zehn mit verschiedenen.

Prüfe nach dem nächsten Update erneut

Jede pfadbasierte Regel hat eine Haltbarkeit, gemessen in Patch-Zyklen. Wenn das Spiel einen Monat später den Ausschluss nicht mehr respektiert, prüfst du zuerst, ob die ausführbare Datei verschoben wurde, und zweitens, ob daneben ein neuer Hilfsprozess aufgetaucht ist.

Das Anwendungsausschlussmodell, das ein Client dokumentiert, ist eine vernünftige Referenz dafür, wie diese Regeln beschrieben werden, obwohl die Details zwischen Produkten variieren. Lies deines, halte die verwendete Kennung fest und notiere das Datum. Diese Aufzeichnung verwandelt beim nächsten Launcher-Update ein Rätsel in eine Fünf-Minuten-Reparatur.

Kann der Client die Grenze, die du brauchst, einfach nicht ausdrücken, ist eine genehmigte breitere Richtlinie besser als ein Haufen undokumentierter Ausnahmen. Breit und verstanden schlägt eng und falsch, besonders wenn die enge Version das ist, was alle für gegeben halten.