Insurgency: Sandstorm und Proxy: Welcher Traffic geht durch den Tunnel?

Wenn man bei Insurgency: Sandstorm über Proxys spricht, muss zuerst klar sein, dass das Spiel im Netzwerk nicht nur eine einzige Aufgabe erledigt. Die Oberfläche, die die Bibliothek öffnet, erzeugt Web-Requests, Update-Pakete kommen aus einer völlig anderen Verteilungsinfrastruktur, die Kontositzung läuft über einen separaten Authentifizierungspfad, und der eigentliche Match-Traffic gleicht keinem davon.

Setups, die diese Unterscheidung übergehen, enden mit einem ähnlichen Ergebnis: Die Oberfläche öffnet sich über den Proxy, die Serverliste erscheint, doch beim Betreten eines Servers kommt die Verbindung entweder nicht zustande oder läuft über Ihre reguläre Leitung. Das Problem ist nicht eine falsche Konfiguration, sondern ein geringerer Geltungsbereich als angenommen.

Die folgenden Abschnitte schlüsseln diesen Geltungsbereich Schicht für Schicht auf und markieren zudem getrennt, wo ein Proxy tatsächlich hilft und wo Grenzen liegen, die keine Einstellung überwinden kann.

Wie viele einzelne Verbindungen entstehen an einem einzigen Spieleabend?

Sobald Sie den Client starten, treten vier verschiedene Flows in Aktion. Der erste ist die Oberfläche der Vertriebsplattform: Shop-Seiten, Bibliothek, Freundesliste und Newsfeed sind gewöhnliche HTTPS-Requests und laufen über TCP. Der zweite ist der Content-Download; Patches und Repository-Dateien werden von geografisch verteilten Knoten bezogen. Der dritte ist die Kontositzung. Der vierte ist das Match selbst.

Die ersten drei sind die natürliche Aufgabe eines HTTP-Proxys. Für HTTPS-Ziele öffnet der Client einen Tunnel in der Form CONNECT hedef.example:443 und der Proxy transportiert die verschlüsselten Bytes; die Details dieser Methode werden im Beitrag CONNECT-Methode beschrieben. Der vierte ist anders: Die Pakete von Shootern, die Positions-, Schuss- und Trefferinformationen tragen, sind empfindlich gegenüber Latenz und werden üblicherweise über UDP übertragen.

UDP geht nicht von selbst in einen TCP-Tunnel. Ein klassischer HTTP-Proxy transportiert ausschließlich TCP; SOCKS5 kann UDP dagegen mit der Methode UDP ASSOCIATE übertragen, doch damit das funktioniert, muss sowohl der Proxy-Server diese Methode freigeschaltet haben als auch der Spiel-Client das Senden von UDP über SOCKS5 unterstützen. Bei den meisten Desktop-Spiel-Clients ist diese zweite Bedingung nicht erfüllt.

Das praktische Ergebnis lautet: Der Geltungsbereich des Proxys bleibt höchstwahrscheinlich auf Shop, Download, Konto und Web-Seite beschränkt. Das nicht als Mangel, sondern als Grenze des Setups zu akzeptieren und die Erwartung entsprechend auszurichten, erspart stundenlange Fehldiagnosen.

Launcher-Fenster und Match-Client lesen nicht dieselbe Regel

Der Client der Vertriebsplattform und die ausführbare Datei des Spiels sind getrennte Prozesse. Unter Windows betrifft die systemweite Proxy-Einstellung im Wesentlichen Anwendungen, die den WinINET/WinHTTP-Stack verwenden; die Oberfläche des Plattform-Clients kann davon beeinflusst werden, die Netzwerkschicht des Spiels öffnet dagegen meist direkt einen Socket und liest diese Einstellung überhaupt nicht.

Deshalb ist das Bild „Ich habe den Proxy aktiviert, das Spiel verbindet sich weiterhin über die alte IP“ kein Fehler, sondern erwartetes Verhalten. Ein Setup ohne prozessbezogene Unterscheidung kann das nicht erkennen; bei Tools mit anwendungsbasierter Weiterleitung können Sie dagegen einzeln auswählen, welcher Prozess in den Tunnel geht. Auch das Proxy-Feld im Einstellungsdialog des Plattform-Clients umfasst nur die Requests dieses Clients; zu den Einrichtungsschritten siehe Proxy-Einstellungen der Distributionsplattform heranziehen.

Die zweite Unterscheidung betrifft die Authentifizierung. Die Kontositzung wird über den Plattform-Client geöffnet, und das Spiel legt dem Server ein aus dieser Sitzung erhaltenes Ticket vor. Die Sitzung aus einem Land zu öffnen und das Match über einen anderen Exit zu betreten, kann kontoseitig zusätzliche Verifizierungen auslösen. Wenn Sie die Einstellung ändern, ändern Sie sie einmalig und konsistent.

Patch-Tag: Woher kommt der Download-Traffic, was macht der Proxy?

Update-Pakete kommen nicht vom Spielserver, sondern aus der Content-Delivery-Infrastruktur. Diese Infrastruktur leitet Sie unter normalen Bedingungen zu einem Knoten in der Nähe Ihres Netzes. Schalten Sie einen Proxy dazwischen, richtet sich die Routing-Entscheidung nicht mehr nach Ihrem Standort, sondern nach dem Exit-Standort des Proxys. Das Ergebnis ist manchmal besser, meistens schlechter: Das Paket läuft über ein anderes Land zu Ihnen zurück.

Das hat zwei konkrete Kosten. Die erste ist die Dauer; ein großer Patch dauert spürbar länger, wenn er von einem entfernten Knoten bezogen wird. Die zweite sind die Kosten: Da Residential- und Mobile-Pakete nach übertragenem Datenvolumen abgerechnet werden, schmilzt das Kontingent schnell dahin, wenn Sie einen Download von zig Gigabyte durch den Tunnel leiten. Wenn Sie im Voraus rechnen möchten, liefert der Beitrag Bandbreitenberechnung die Formel.

Das richtige Vorgehen ist in der Regel die Trennung: Wickeln Sie große Downloads über Ihre reguläre Leitung ab und setzen Sie den Proxy nur dort ein, wo er wirklich nötig ist. Wenn Sie in einem eingeschränkten Netz arbeiten und ein Download über die reguläre Leitung nicht möglich ist, ist ein Datacenter-Exit dafür am besten geeignet; er verkraftet Volumen und hat niedrige Stückkosten. Datacenter Proxy eignet sich genau für solche volumenstarken Aufgaben mit geringer Session-Empfindlichkeit.

In welcher Phase bricht die Verbindung ab?

Der schnellste Weg zur Fehlerbehebung besteht darin, direkt zu ermitteln, in welchem Schritt der Abbruch auftritt. Die Reihenfolge ist klar: Der Client startet, die Plattform-Sitzung wird verifiziert, die Serverliste wird per Abfrage geladen, eine Beitrittsanfrage geht an den ausgewählten Server, und anschließend wird für den Spielfluss eine separate Session aufgebaut. Jeder Schritt betrifft eine andere Komponente.

Erscheint die Serverliste nicht, liegt das Problem meist bei der Listenabfrage, und diese ist unabhängig vom Match-Traffic. Kommt die Liste zwar an, läuft die Beitrittsanfrage aber in ein Timeout, stockt der Weg an dem Punkt, an dem die Match-Session aufgebaut wird. Wenn Sie ins Spiel gelangen und nach wenigen Sekunden herausfliegen, ändert sich das Bild erneut: Die Session wurde aufgebaut, der kontinuierliche Flow konnte jedoch nicht gehalten werden.

Der Platz des Proxys in dieser Kette ist eng und klar. Auf der Web- und Listenseite kann er wirksam sein; bei der Match-Session ist er dagegen nicht im Spiel, solange die Kette UDP ASSOCIATE nicht vollständig aufgebaut ist. Wie diese Methode funktioniert und unter welchen Bedingungen sie greift, SOCKS5-UDP-Unterstuetzung behandelt der Beitrag ausfuehrlich.

Gehen Sie bei der Diagnose mit jeweils nur einer Variablen vor. Deaktivieren Sie den Proxy und wiederholen Sie denselben Schritt; schlägt der Schritt auch bei deaktiviertem Proxy fehl, liegt die Ursache woanders und das Herumspielen an Einstellungen ist Zeitverschwendung. Ob der Exit selbst erreichbar ist, mit dem Proxy-Check-Tool prüfen Sie außerdem.