La pagina della chat si carica ma la connessione live fallisce: dove guardare

Apri il pannello di rete prima di caricare la pagina della chat, poi individua la richiesta che trasporta i messaggi invece di quella che disegna lo scheletro. Il documento, gli script, lo scambio di accesso e il trasporto della chat possono andare tutti su host diversi. La maggior parte delle segnalazioni secondo cui la VPN ha rotto la chat descrive in realtà il fallimento di una di quelle quattro richieste. Osservale in ordine e di solito la risposta è visibile nei primi due minuti.

Trova la richiesta che trasporta i messaggi

Filtra per tipo quando la pagina si è assestata: un WebSocket compare come voce a sé, un event stream resta aperto con una risposta che cresce e un long poll si ripete a intervallo regolare. Registra schema, host, porta e stato per quella che trasporta gli aggiornamenti. Annota se è partita prima o dopo l'accesso, perché un trasporto aperto prima dell'autenticazione è di solito un progetto diverso da uno aperto dopo. Leggi le intestazioni della richiesta di upgrade o del tipo di contenuto accettato, perché identificano il trasporto che la pagina distribuita ha davvero scelto.

I vecchi post dei forum descrivono trasporti che i prodotti hanno smesso di usare anni fa, quindi fidati di ciò che il browser ha registrato, non dell'articolo. Se la voce manca del tutto, il codice client potrebbe non aver mai tentato una connessione, il che indica un guasto precedente di script o configurazione. Una pagina che si carica prova solo che il documento è arrivato, e quella distinzione decide se stai davvero eseguendo il debug della rete.

Configurazione, consegna e durata falliscono in modi diversi

Un WebSocket si apre con un upgrade HTTP a cui si risponde con lo stato 101, e tutto ciò che segue sono messaggi incorniciati invece di recupero di pagine, due fasi che RFC 6455 tiene esplicitamente separate. Un event stream risponde con un tipo di contenuto in streaming e tiene aperto il corpo della risposta. Entrambi possono non aprirsi, aprirsi e non consegnare nulla, oppure aprirsi, consegnare e poi morire in silenzio.

wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events

Cattura il primo guasto significativo prima di toccare un profilo, perché le tre tempistiche indicano livelli diversi. Se l'handshake non si completa mai, confrontalo con una normale richiesta HTTPS allo stesso host per vedere se qualcosa lo raggiunge. Se si completa e non arrivano messaggi, osserva i frame o il corpo dello stream mentre qualcuno invia un messaggio di prova da un altro account. Se funziona e poi si ferma, annota l'ora esatta e il codice di chiusura, perché quella coppia identifica quale estremità ha rinunciato.

Il codice 1006 significa che il socket si è chiuso senza frame di chiusura, ed è così che un middlebox o un timeout di inattività appare dall'interno del browser. Un heartbeat della VPN non dimostra che la sessione applicativa interna sia ancora viva.

L'host live è una destinazione separata

I backend della chat spesso vivono su un proprio nome host, a volte su una porta diversa o dietro un certificato separato. Quella destinazione richiede una propria risoluzione, rotta e gestione del proxy, e lo split tunnelling può includere la pagina escludendo il socket. Risolvi il nome host live dalla macchina client e verifica che risponda con l'indirizzo atteso su quella rete. Controlla la catena di certificati proprio per quel nome host, perché un carattere jolly che copre il sito non sempre copre l'endpoint del socket.

Se un proxy si trova sul percorso, verifica che permetta l'upgrade o la risposta di lunga durata invece di metterla in buffer. I proxy aziendali che riscrivono l'HTML spesso gestiscono male gli upgrade WebSocket, e il risultato è una pagina che si disegna mentre la chat non si connette mai. Due richieste allo stesso prodotto non sono quindi due richieste allo stesso host.

Correggi l'elenco delle destinazioni, non i controlli di sicurezza

Correggere un elenco di destinazioni è una modifica di routing e spetta a chi possiede la rotta. Allentare la validazione dei certificati o rimuovere l'intestazione Origin è una modifica di sicurezza e spetta a chi possiede la policy, che raramente è la persona che esegue il debug del ticket. Il modo più rapido per far apparire una connessione è di solito il modo più rapido per rendere possibile un incidente.

Chiedi al proprietario dell'applicazione quali origini accetta il backend prima di cambiare qualcosa, e passa quella risposta a chi controlla il proxy. Se un errore di certificato appare solo attraverso il tunnel, ispeziona il dispositivo che intercetta invece di installare un bypass.

Registra abbastanza per il passaggio di consegne

L'artefatto utile è breve: URL della pagina, endpoint live, esito dell'handshake, ora del primo guasto e se è stato tentato un riconnettersi. Aggiungi il nome del profilo VPN e la rete su cui eri, e chiunque lo legga può riprodurre il test senza fare sei domande. Oscura cookie, intestazioni di autorizzazione e corpi dei messaggi, e preferisci uno screenshot della colonna delle tempistiche a un export completo dell'archivio. Frame e archivi di rete possono contenere messaggi privati e token di sessione, quindi ispeziona prima di allegare qualsiasi cosa.

Se il guasto è una chiusura silenziosa, includi il codice di chiusura e l'intervallo di inattività che l'ha preceduta, perché quella coppia di solito identifica il proprietario del timeout. Consegna il verbale al proprietario dell'applicazione o del gateway invece di indovinare tu stesso un valore di timeout. La loro risposta sul comportamento di keepalive supportato è quella che chiude il ticket.