Honkai: Star Rail und Proxy: Welcher Traffic gelangt in den Tunnel?

Wenn Honkai: Star Rail startet, wird nicht eine einzige Verbindung aufgebaut. Der Launcher fragt die Versionsinformation ab und zieht bei Bedarf Dateien im Gigabyte-Bereich, die Kontoschicht erzeugt kurze und haeufige Anfragen, und die Spiel-Session ist ein langlebiger Kanal, der mit dem Server spricht, solange sie geoeffnet ist. Das Netzwerkverhalten dieser drei aehnelt sich nicht.

Ein Proxy deckt dieses Bild nicht von selbst vollstaendig ab. Der Umfang der Regel, die Sie schreiben, haengt davon ab, auf welche Schicht Sie sie legen und ob der Client diese Schicht ausliest. Die im Browser geoeffnete Kontoseite kann in den Tunnel gelangen, waehrend der eigene Socket des Spiels ueber Ihre normale Leitung nach aussen geht; auf dem Bildschirm erscheint dazu keine Warnung.

Der dritte Punkt betrifft die Erwartung: Ein Proxy ist kein Beschleuniger, er fuegt eine Station ein. Die folgenden Abschnitte behandeln getrennt, was diese Station zur Laufzeit beitraegt, welche Messung was aussagt und welches Symptom nichts mit dem Proxy zu tun hat.

Wann spricht das Netzwerk in einem rundenbasierten Spiel?

Da der Kampf rundenbasiert ist, verhaelt sich der Client nicht wie ein Actionspiel, das jede Feldbewegung an den Server meldet. Die Anfrage im Moment Ihrer Entscheidung, das vom Server zurueckgegebene Ergebnis und die Aktualisierung der Oberflaeche sind in einem einzigen Roundtrip erledigt. Deshalb faellt ein Latenzunterschied von einigen Dutzend Millisekunden im Spielgefuehl meist nicht auf; was auffaellt, ist der vollstaendige Verbindungsabbruch oder eine Anfrage, die unbeantwortet bleibt.

Demgegenueber durchlaeuft das Spiel bei jedem Start eine Verifizierungskette: Der Launcher vergleicht die Version, die Kontoschicht erneuert die Session, danach verbindet sich das Spiel mit seinem eigenen Gateway. Bleibt irgendein Glied dieser Kette ausserhalb des Tunnels, lautet das Symptom meist nicht "das Spiel startet nicht", sondern "es haengt im Login-Bildschirm". Der Nutzer haelt das fuer eine Serverstoerung; tatsaechlich ist der Umfang der Regel unvollstaendig.

Die vierte und fuenfte Schicht liegen im Hintergrund: Event- und Code-Seiten laufen ueber das Web und werden im Browser geoeffnet, Telemetrie und Fehlerberichte senden unbemerkt kleine Pakete. Ob diese beiden weitergeleitet werden, beeinflusst das Spielgefuehl nicht, verwirrt aber das Bild, wenn Sie pruefen, von wo der Traffic nach aussen geht: Eine IP-Abfrage aus dem Browser zeigt nicht den Ausgang des Spiels, sondern den des Browsers.

Was fuegt die zwischengeschaltete Station der Laufzeit hinzu?

Wenn Sie einen Proxy verwenden, geht das Paket nicht direkt zum Ziel: Es erreicht zuerst den Proxy-Server, wird von dort zum Ziel weitergeleitet, und die Antwort kommt denselben Weg zurueck. Die Gesamtzeit besteht deshalb aus drei Teilen — der Distanz zwischen Ihnen und dem Proxy, der Distanz zwischen Proxy und Spielserver sowie der aktuellen Auslastung der Proxy-Maschine. Die Summe dieser drei kann nicht kleiner sein als die direkte Verbindung; das uebliche Ergebnis ist ein Anstieg der Latenz.

Wie stark der Anstieg ausfaellt, haengt von der Geografie ab. Liegt Ihr Ausgang auf der Strecke zwischen Ihnen und dem Spielserver, ist der Zusatzaufwand vergleichsweise gering. Liegt der Ausgang in der Gegenrichtung — etwa in Nordamerika, waehrend Sie sich mit einem Server in Asien verbinden —, ueberquert das Paket in beiden Richtungen zusaetzlich einen Ozean, und der Unterschied wird im Spiel spuerbar. Die Standortwahl ist deshalb die Entscheidung, die noch vor der Typwahl kommt.

Die einzige Ausnahme von der Regel ist folgende: Wenn Ihre Standardroute Umwege macht und das Backbone des Proxy-Anbieters direkter mit dem Ziel verbunden ist, kann die zusaetzliche Station in der Summe einen Gewinn bringen. Das ist kein Versprechen, sondern eine Ausnahme, die ohne Messung nicht angenommen werden darf und verifiziert werden muss. Um vor dem Messen zu wissen, welche Zahl was aussagt, proxy latency die Definition und Ping-Erwartungen in Spielen nach.

Die praktische Methode ist einfach: Messen Sie dasselbe Ziel einmal mit deaktiviertem und einmal mit aktiviertem Proxy, wiederholen Sie die Messung zu verschiedenen Tageszeiten und stellen Sie die beiden Ergebnisse nebeneinander. Ping-Test liefert eine einmalige Momentaufnahme; fuer eine Entscheidung braucht es mindestens mehrere Aufnahmen, denn bei geteilten Ausgaengen ist der Unterschied zur Hauptverkehrszeit genau die Variable, die eine Einzelmessung verbirgt.

Paketverlust oder Latenz? Die beiden trennen

Spieler beschreiben zwei verschiedene Probleme mit demselben Wort. Latenz ist die Zeit, die ein Paket bis zur Ankunft braucht; Paketverlust bedeutet, dass das Paket gar nicht ankommt. Die Symptome unterscheiden sich: Bei hoher Latenz laeuft alles spaet, aber regelmaessig; bei Verlust friert die Oberflaeche kurz ein und holt dann sprunghaft auf. Verlust kann das Spielerlebnis selbst dann stoeren, wenn der Latenzdurchschnitt niedrig aussieht.

Um eine Messung richtig zu lesen, bewerten Sie drei Zahlen gemeinsam: durchschnittliche Latenz, Latenzschwankung (Jitter) und Verlustrate. Ist der Durchschnitt gut, die Schwankung aber hoch, liegt das Problem meist an der Leitung selbst oder an der Auslastung eines geteilten Ausgangs. Gibt es Verluste, muss zuerst gefunden werden, wo der Verlust beginnt; Rueckschluesse allein aus dem Durchschnittswert fuehren in die Irre.

Die Diagnosereihenfolge wird so aufgebaut: Messen Sie zuerst bei deaktiviertem Proxy. Tritt der Verlust auch dann auf, liegt die Ursache bei Ihrem Hausanschluss, Ihrer WLAN-Verbindung oder dem Backbone Ihres Anbieters; in diesem Fall verdeckt das Einschalten eines Proxys das Problem nicht, sondern legt nur eine weitere Schicht darueber. Tritt der Verlust nur bei aktiviertem Proxy auf, wechseln Sie den Ausgang und wiederholen Sie dieselbe Messung; das Problem kann an einer einzelnen Ausgangsmaschine liegen. Fuer den Verfuegbarkeits- und Antworttest ist Proxy-Check-Tool der erste Schritt.

Die praktische Grenze des SOCKS5-UDP-Relays

Ein HTTP-Proxy transportiert HTTPS-Traffic, indem er ihn mit der Methode CONNECT tunnelt, und dieser Tunnel transportiert ausschliesslich TCP. Da ein erheblicher Teil des Spiel-Traffics UDP nutzt, kann ein klassischer HTTP-Proxy den Echtzeitkanal des Spiels nicht transportieren. Das ist kein Konfigurationsmangel, sondern die Definition des Protokolls.

SOCKS5 unterscheidet sich an dieser Stelle: Der Standard definiert UDP ASSOCIATE eine Methode mit diesem Namen und erlaubt die Weiterleitung von UDP-Datagrammen ueber den Proxy. Zwei Bedingungen muessen jedoch gemeinsam erfuellt sein. Erstens muss der Proxy-Server diese Methode tatsaechlich unterstuetzen; viele Setups erlauben nur TCP-Verbindungen. Zweitens muss der Client diese Methode zu nutzen wissen — die meisten Spiel-Clients oeffnen ihren eigenen Socket und lesen die SOCKS5-Einstellung des Systems gar nicht aus.

Sind diese beiden Bedingungen nicht gemeinsam erfuellt, ist das Ergebnis lautlos: Die Anwendung meldet keinen Fehler, die UDP-Pakete gehen ohne den Tunnel ueber Ihre normale Leitung nach aussen. In der Praxis bedeutet das: Kontoseite, Launcher und Patch-Download laufen durch den Tunnel, die eigene Session des Spiels nicht. Nutzer, die den Umfang erweitern wollen, greifen deshalb meist zu anwendungsbasierter Weiterleitung oder einem Tunnel auf Geraeteebene. Fuer die Details der UDP-Seite des Protokolls ist SOCKS5-UDP-Unterstuetzung der Beitrag ausfuehrlich; fuer einen allgemeinen Vergleich SOCKS5 Proxy Seite ansehen.