Logowanie do Steam działa, gra nie: sprawdź każdą ścieżkę

Logowanie do Steam, pobieranie i sesja matchmakingu mogą przebiegać różnymi ścieżkami. Przejdź listę kontrolną po kolei i zapisz, który krok naprawdę zawiódł.

Uruchom Steam, zaloguj się, i wszystko wygląda zdrowo, dopóki gra nie znajdzie sesji. Potraktuj to jako trzy osobne pytania sieciowe, a nie jedno. Sklep i ekrany konta, pobieranie zawartości i sesja gry mogą każde dotrzeć do innych punktów końcowych przez inne transporty. Wykonaj te kontrole po kolei i zatrzymaj się na pierwszej, która zawiedzie, bo wszystko po niej jest domysłem.

Krok 1: potwierdź, że logowanie było jedyną rzeczą, która zadziałała

Logowanie dowodzi, że konto dotarło do usługi tożsamości z poświadczeniami i dowolnym drugim czynnikiem, którego konto wymaga. Nie mówi nic o dostarczaniu treści ani nic o własnym układzie hostingu gry. Zapisz, którą z trzech operacji naprawdę przetestowałeś, bo ludzie zwykle zgłaszają niesprawną grę po przetestowaniu tylko launchera.

Przeczytaj tekst błędu przed siecią. Gra, która zgłasza brak dostępnych serwerów, mówi ci coś innego niż launcher, który nie dociera do sklepu. Oba błędy pochodzą z różnych warstw i rzadko znaczą to samo. To rozróżnienie decyduje, czy następna kontrola dotyczy rozwiązywania nazw, UDP czy ustawienia regionu.

Zapisz konto, region, grę i czas. Bez tych czterech wartości późniejsze porównanie jest między dwoma różnymi testami, które przypadkiem dzielą tę samą nazwę.

Krok 2: nazwij transport dla każdej operacji

Dostarczanie treści zachowuje się jak duży transfer HTTP i toleruje opóźnienie znacznie lepiej niż utratę. Matchmaking i sesje w grze często używają UDP, gdzie ścieżka gubiąca pakiety wygląda jak zepsuta gra, a nie jak wolne pobieranie. Te dwa profile zawodzą inaczej na tym samym tunelu, dlatego szybkie pobieranie nie prognozuje działającej sesji.

Sprawdź cele i aktywne gniazda, a nie najpierw listę portów dostawcy. Lista mówi, czego platforma może używać, podczas gdy gniazda mówią, co robi ten klient teraz.

nslookup api.steampowered.com
ss -uanp | head -20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://store.steampowered.com/

Jeśli proces gry trzyma gniazdo UDP z ruchem, a ścieżka przesyłania jest w porządku, usterka jest w części UDP. To zawęża problem do sposobu, w jaki tunel obchodzi się z UDP, a nie do konta czy sklepu.

Krok 3: sprawdź politykę włączania przed listą portów

Wiele klientów VPN stosuje politykę dla każdej aplikacji, zakresu adresów lub rodziny adresów, a nie dla całej maszyny. Launcher może być w tunelu, podczas gdy osobno uruchomiony plik binarny gry jest poza nim, i wtedy oba nie zgadzają się co do świata. Włączanie na poziomie aplikacji to zwykły winowajca na laptopach do gier z zainstalowanym klientem dostawcy. Czytaj politykę, która naprawdę obowiązuje, a nie profil zapisany w zeszłym miesiącu.

Spójrz na tablicę routingu i interfejs, który posiada trasę domyślną. Reguła podzielonego tunelu oparta na prefiksach celu pojawi się tam, a wykluczenie na poziomie aplikacji nie. Warto znać tę różnicę, zanim zmienisz którąkolwiek z nich.

ip route show default
ip -brief addr
Get-NetAdapter | Select-Object Name, Status, InterfaceDescription

Jeśli ruch gry wychodzi przez adapter fizyczny, a sklep idzie przez tunel, polityka włączania jest ustaleniem. Żaden wyjątek portu nie naprawi decyzji routingu, a dodanie jednego tylko poszerza powierzchnię.

Krok 4: wyklucz ścieżkę SOCKS, która nie może przenosić UDP

Tor udostępnia proxy SOCKS, a wsparcie SOCKS w ekosystemie jest niespójne w kwestii UDP. Udokumentowane zachowanie Tora nie implementuje UDP ASSOCIATE, więc gra, której ruch sesji to UDP, nie może użyć tej ścieżki, niezależnie od tego, jak klient jest na nią kierowany. Przeglądarka działająca przez proxy dowodzi tylko, że przepływy TCP przeglądarki działają.

Testuj twierdzenie, a nie intencję. Jeśli gra nadal zgłasza niedostępną sesję, podczas gdy test tylko TCP przez to samo proxy się udaje, ścieżka proxy nie przenosi ruchu, którego gra potrzebuje.

Traktuj routowanego VPN i proxy SOCKS jako różne narzędzia o różnych możliwościach. Zamiana jednego na drugie to zmiana projektu, a nie preferencja konfiguracji.

Porównaj zapis z umową

Osiągalność sieci i uprawnienie konta to osobne pytania, a tylko na pierwsze odpowiada działający tunel. Ograniczenie dotyczy intencji stojącej za proxyingiem, a nie wybranego protokołu. Obowiązująca umowa ogranicza proxying IP, którego celem jest ukrycie, gdzie mieszka posiadacz konta, więc działająca ścieżka może nadal leżeć poza zaakceptowanymi warunkami. Czytaj umowę, zamiast traktować łączność jako zgodę.

Dla uczciwego porównania zmieniaj jedną zmienną naraz i zachowaj tę samą grę, region serwera, konto i operację. Potem sprawdź wynik na tych samych czterech operacjach, które zapisałeś na początku.

tracert -h 12 store.steampowered.com
ss -uanp | grep -i -E 'game|steam'
curl -sS -o /dev/null -w '%{remote_ip} %{time_connect}\n' https://store.steampowered.com/

Gdy zapis pokazuje, że logowanie działa, pobieranie działa, a sesja zawodzi, pozostałe pytanie dotyczy UDP na ścieżce. Gdy wszystkie trzy działają, pierwotna skarga dotyczyła czegoś innego, a kolejnym użytecznym krokiem jest własny log gry, a nie tunel. Tak czy inaczej, lista kontrolna zastąpiła spór konkretną obserwacją.

Powiązane artykuły