L'accesso a Steam funziona, il gioco no: controlla ogni percorso

Avvia Steam, accedi e tutto sembra sano finché il gioco non trova una sessione. Trattalo come tre domande di rete separate invece di una. Lo store e le schermate dell'account, il download dei contenuti e la sessione di gioco possono ciascuno raggiungere endpoint diversi tramite trasporti diversi. Esegui questi controlli in ordine e fermati al primo che fallisce, perché tutto ciò che segue è una supposizione.

Passo 1: conferma che l'accesso è l'unica cosa che ha funzionato

L'accesso dimostra che l'account ha raggiunto il servizio di identità con le credenziali e qualsiasi secondo fattore richiesto dall'account. Non dice nulla sulla distribuzione dei contenuti e nulla sulla disposizione di hosting del gioco stesso. Annota quale delle tre operazioni hai davvero testato, perché le persone di solito segnalano un gioco guasto dopo aver testato solo il launcher.

Leggi il testo dell'errore prima della rete. Un gioco che segnala che non ci sono server disponibili ti dice qualcosa di diverso da un launcher che non raggiunge lo store. I due errori provengono da livelli diversi e raramente significano la stessa cosa. La distinzione decide se il prossimo controllo riguarda la risoluzione dei nomi, UDP o un'impostazione di regione.

Annota l'account, la regione, il gioco e l'ora. Senza quei quattro valori, un confronto successivo è tra due test diversi che condividono per caso lo stesso nome.

Passo 2: assegna un nome al trasporto di ogni operazione

La distribuzione dei contenuti si comporta come un grande trasferimento HTTP e tollera la latenza molto meglio della perdita. Il matchmaking e le sessioni in gioco usano spesso UDP, dove un percorso che perde pacchetti sembra un gioco rotto e non un download lento. Questi due profili falliscono in modo diverso sullo stesso tunnel, per questo un download veloce non predice una sessione funzionante.

Controlla le destinazioni e le socket attive invece della lista delle porte del fornitore. La lista dice cosa può usare la piattaforma, mentre le socket dicono cosa sta facendo questo client proprio ora.

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

Se il processo del gioco tiene una socket UDP con traffico mentre il percorso di trasferimento è a posto, il guasto è nella gamba UDP. Questo restringe il problema a come il tunnel gestisce UDP e non all'account o allo store.

Passo 3: controlla la politica di inclusione prima della lista delle porte

Molti client VPN applicano la politica per applicazione, per intervallo di indirizzi o per famiglia di indirizzi invece che all'intera macchina. Un launcher può essere dentro il tunnel mentre un binario del gioco avviato separatamente è fuori, e allora i due non sono d'accordo sul mondo. L'inclusione a livello di applicazione è il colpevole abituale sui portatili da gioco con un client del fornitore installato. Leggi la politica realmente in vigore, non il profilo salvato il mese scorso.

Guarda la tabella di routing e l'interfaccia che possiede la rotta predefinita. Una regola di tunnel diviso basata sui prefissi di destinazione apparirà lì, mentre un'esclusione a livello di applicazione no. Vale la pena conoscere questa differenza prima di cambiare una delle due.

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

Se il traffico del gioco esce dall'adattatore fisico mentre lo store passa dal tunnel, la politica di inclusione è la scoperta. Nessuna eccezione di porta correggerà una decisione di routing, e aggiungerne una allarga solo la superficie.

Passo 4: escludi un percorso SOCKS che non può trasportare UDP

Tor fornisce un proxy SOCKS, e il supporto SOCKS nell'ecosistema è incoerente riguardo a UDP. Il comportamento documentato di Tor non implementa UDP ASSOCIATE, quindi un gioco il cui traffico di sessione è UDP non può usare quel percorso, per quanto il client vi sia indirizzato. Un browser che funziona attraverso il proxy dimostra solo che i flussi TCP del browser funzionano.

Metti alla prova l'affermazione e non l'intenzione. Se il gioco segnala ancora una sessione non disponibile mentre un test solo TCP attraverso lo stesso proxy riesce, il percorso del proxy non trasporta il traffico che serve al gioco.

Tratta una VPN instradata e un proxy SOCKS come strumenti diversi con capacità diverse. Scambiare l'una con l'altro è un cambio di progettazione, non una preferenza di configurazione.

Confronta il resoconto con l'accordo

La raggiungibilità di rete e l'autorizzazione dell'account sono domande separate, e solo la prima trova risposta in un tunnel funzionante. La restrizione riguarda l'intenzione dietro il proxying e non il protocollo scelto. L'accordo in vigore limita il proxying IP il cui scopo è nascondere dove vive il titolare dell'account, quindi un percorso che funziona può restare fuori dai termini accettati. Leggi l'accordo invece di trattare la connettività come approvazione.

Per un confronto onesto, cambia una variabile alla volta e mantieni lo stesso gioco, la stessa regione del server, lo stesso account e la stessa operazione. Poi controlla l'esito sulle stesse quattro operazioni annotate all'inizio.

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/

Quando il resoconto mostra che l'accesso funziona, il download funziona e la sessione fallisce, la domanda restante riguarda UDP sul percorso. Quando tutte e tre funzionano, la lamentela originale riguardava altro, e il prossimo passo utile è il registro del gioco stesso e non il tunnel. In ogni caso, la lista ha sostituito una discussione con un'osservazione precisa.