Steam-inloggningen fungerar, spelet gör det inte: kontrollera varje väg

Starta Steam, logga in, och allt ser friskt ut tills spelet inte hittar en session. Behandla det som tre separata nätverksfrågor i stället för en. Butiken och kontoskärmsidorna, innehållsnedladdningen och spelsessionen kan var och en nå olika slutpunkter över olika transporter. Kör dessa kontroller i ordning och stanna vid den första som misslyckas, för allt efteråt är gissningar.

Steg 1: bekräfta att inloggningen var det enda som fungerade

Inloggningen bevisar att kontot nådde identitetstjänsten med inloggningsuppgifterna och eventuell andra faktor som kontot kräver. Den säger ingenting om innehållsleverans och ingenting om spelets egen hostingordning. Skriv ned vilken av de tre operationerna du faktiskt testade, eftersom folk rutinmässigt rapporterar ett misslyckat spel efter att bara ha testat startaren.

Läs feltexten före nätverket. Ett spel som rapporterar att inga servrar är tillgängliga säger dig något annat än en startare som inte når butiken. De två felen kommer från olika lager och betyder sällan samma sak. Skillnaden avgör om nästa kontroll gäller namnavläsning, UDP eller en regionsinställning.

Notera kontot, regionen, spelet och tiden. Utan de fyra värdena är en senare jämförelse mellan två olika tester som råkar dela samma namn.

Steg 2: namnge transporten för varje operation

Innehållsleverans beter sig som en stor HTTP-överföring och tål latens mycket bättre än förlust. Matchmaking och sessioner i spelet använder ofta UDP, där en väg som tappar paket ser ut som ett trasigt spel snarare än en långsam nedladdning. De två profilerna misslyckas olika på samma tunnel, därför förutsäger en snabb nedladdning ingen fungerande session.

Kontrollera destinationerna och de aktiva socketarna i stället för först leverantörens portlista. Listan säger vad plattformen får använda, medan socketarna säger vad den här klienten gör just nu.

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

Om spelprocessen håller en UDP-socket med trafik medan överföringsvägen är fin, ligger felet i UDP-delen. Det snävar in problemet till tunnelns hantering av UDP och inte till kontot eller butiken.

Steg 3: kontrollera inkluderingspolicyn före portlistan

Många VPN-klienter tillämpar policy per program, per adressområde eller per adressfamilj i stället för på hela maskinen. En startare kan vara inne i tunneln medan en separat startad spellbinär ligger utanför, och då är de två oense om världen. Inkludering på programnivå är den vanliga boven på spelbärbara datorer med en leverantörsklient installerad. Läs policyn som faktiskt gäller, inte profilen du sparade i förra månaden.

Titta på routingtabellen och gränssnittet som äger standardrutten. En split-tunnel-regel baserad på destinationsprefix kommer att synas där, och ett undantag på programnivå kommer inte att göra det. Den skillnaden är värd att känna till innan du ändrar någon av dem.

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

Om spelets trafik lämnar genom den fysiska adaptern medan butiken går genom tunneln, är inkluderingspolicyn fyndet. Inget portundantag kommer att fixa ett routingbeslut, och att lägga till ett gör bara ytan bredare.

Steg 4: uteslut en SOCKS-väg som inte kan bära UDP

Tor tillhandahåller en SOCKS-proxy, och SOCKS-stödet i ekosystemet är inkonsekvent när det gäller UDP. Tors dokumenterade beteende implementerar inte UDP ASSOCIATE, så ett spel vars sessionstrafik är UDP kan inte använda den vägen, hur klienten än riktas mot den. En webbläsare som fungerar genom proxyn bevisar bara att webbläsarens TCP-flöden fungerar.

Testa påståendet i stället för avsikten. Om spelet fortfarande rapporterar en otillgänglig session medan ett test med bara TCP genom samma proxy lyckas, bär proxyvägen inte trafiken som spelet behöver.

Behandla en routad VPN och en SOCKS-proxy som olika verktyg med olika förmågor. Att byta det ena mot det andra är en designändring, inte en konfigurationspreferens.

Håll registret mot avtalet

Nätverksnåbarhet och kontobehörighet är separata frågor, och bara den första besvaras av en fungerande tunnel. Begränsningen handlar om avsikten bakom proxyandet och inte om protokollet du valde. Det gällande avtalet begränsar IP-proxyande vars syfte är att dölja var kontoinnehavaren bor, så en väg som fungerar kan fortfarande ligga utanför villkoren du accepterade. Läs avtalet i stället för att behandla anslutning som godkännande.

För en ärlig jämförelse, ändra en variabel i taget och behåll samma spel, serverregion, konto och operation. Kontrollera sedan resultatet på samma fyra operationer som du noterade i början.

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/

När registret visar att inloggningen fungerar, nedladdningen fungerar och sessionen misslyckas, handlar den återstående frågan om UDP på vägen. När alla tre fungerar handlade det ursprungliga klagomålet om något annat, och nästa användbara steg är spelets egen logg snarare än tunneln. Hur som helst har checklistan ersatt en diskussion med en konkret observation.