Pagina de chat se încarcă, dar conexiunea live eșuează: unde să te uiți

Deschide panoul de rețea înainte de a încărca pagina de chat, apoi găsește cererea care transportă mesajele, nu pe cea care desenează scheletul paginii. Documentul, scripturile, schimbul de la autentificare și transportul chatului pot merge toate către gazde diferite. Majoritatea rapoartelor că VPN-ul a stricat chatul descriu de fapt eșecul uneia dintre acele patru cereri. Urmărește-le în ordine și răspunsul este de obicei vizibil în primele două minute.

Găsește cererea care transportă mesajele

Filtrează după tip când pagina s-a așezat: un WebSocket apare ca intrare proprie, un flux de evenimente rămâne deschis cu un răspuns care crește, iar un long poll se repetă la un interval regulat. Notează schema, gazda, portul și starea pentru cea care transportă actualizările. Observă dacă a început înainte sau după autentificare, pentru că un transport deschis înainte de autentificare este de obicei o construcție diferită de unul deschis după. Citește anteturile cererii de upgrade sau ale tipului de conținut acceptat, pentru că ele identifică transportul pe care pagina publicată l-a ales de fapt.

Postările vechi de pe forumuri descriu transporturi pe care produsele le-au abandonat acum ani, așa că ai încredere în ce a înregistrat browserul, nu în articol. Dacă intrarea lipsește complet, codul clientului poate să nu fi încercat niciodată o conexiune, ceea ce indică un eșec anterior de script sau de configurare. O pagină care se încarcă dovedește doar că documentul a ajuns, iar această distincție decide dacă depanezi rețeaua sau nu.

Configurarea, livrarea și durata de viață eșuează diferit

Un WebSocket se deschide cu un upgrade HTTP la care se răspunde cu starea 101, iar tot ce urmează sunt mesaje în cadre, nu aducerea de pagini, două etape pe care RFC 6455 le ține explicit separate. Un flux de evenimente răspunde cu un tip de conținut de streaming și ține corpul răspunsului deschis. Ambele pot eșua să se deschidă, se pot deschide și nu livrează nimic, sau se pot deschide, livra și apoi muri în liniște.

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

Prinde primul eșec semnificativ înainte de a atinge un profil, pentru că cele trei momente indică straturi diferite. Dacă strângerea de mână nu se termină niciodată, compar-o cu o cerere HTTPS simplă către aceeași gazdă pentru a vedea dacă ceva ajunge acolo. Dacă se termină și nu sosesc mesaje, urmărește cadrele sau corpul fluxului în timp ce cineva trimite un mesaj de test dintr-un alt cont. Dacă funcționează și apoi se oprește, notează ora exactă și codul de închidere, pentru că acea pereche identifică ce capăt a renunțat.

Codul 1006 înseamnă că socketul s-a închis fără un cadru de închidere, iar așa arată un intermediar sau un timeout de inactivitate din interiorul browserului. Un heartbeat VPN nu dovedește că sesiunea internă a aplicației este încă vie.

Gazda live este o destinație separată

Backend-urile de chat stau adesea pe propriul nume de gazdă, uneori pe alt port sau în spatele unui certificat separat. Acea destinație are nevoie de propria rezolvare, rută și tratare prin proxy, iar tunelarea divizată poate include pagina și exclude socketul. Rezolvă numele gazdei live de pe mașina clientului și confirmă că răspunde cu adresa pe care o aștepți în acea rețea. Verifică lanțul de certificate special pentru acel nume de gazdă, pentru că un wildcard care acoperă site-ul nu acoperă întotdeauna punctul final al socketului.

Dacă pe traseu există un proxy, confirmă că permite upgrade-ul sau răspunsul de lungă durată în loc să îl pună în buffer. Proxy-urile corporative care rescriu HTML tratează adesea prost upgrade-urile WebSocket, ceea ce produce o pagină care se randează în timp ce chatul nu se conectează niciodată. Două cereri către același produs nu sunt, așadar, două cereri către aceeași gazdă.

Repară lista de destinații, nu verificările de securitate

Repararea unei liste de destinații este o schimbare de rutare și aparține proprietarului rutei. Relaxarea validării certificatelor sau eliminarea antetului Origin este o schimbare de securitate și aparține proprietarului politicii, care rareori este persoana ce depanează tichetul. Cea mai rapidă cale de a face o conexiune să pară reușită este de obicei cea mai rapidă cale de a face un incident posibil.

Întreabă proprietarul aplicației ce origini acceptă backend-ul înainte de a schimba ceva și transmite acel răspuns celui care controlează proxy-ul. Dacă o eroare de certificat apare doar prin tunel, inspectează dispozitivul care interceptează, în loc să instalezi o ocolire.

Notează destul pentru a putea preda cazul

Artefactul util este scurt: URL-ul paginii, punctul final live, rezultatul strângerii de mână, momentul primei erori și dacă s-a încercat o reconectare. Adaugă numele profilului VPN și rețeaua în care erai, iar oricine îl citește poate reproduce testul fără să pună șase întrebări. Ascunde cookie-urile, anteturile de autorizare și corpurile mesajelor, și preferă o captură a coloanei de timpi în locul unui export complet al arhivei. Cadrele și arhivele de rețea pot conține mesaje private și tokenuri de sesiune, așa că verifică înainte de a atașa ceva.

Dacă eșecul este o închidere silențioasă, include codul de închidere și intervalul de inactivitate dinaintea lui, pentru că acea pereche identifică de obicei proprietarul timeout-ului. Predă înregistrarea proprietarului aplicației sau al gateway-ului în loc să ghicești singur o valoare de timeout. Răspunsul lor despre comportamentul keepalive acceptat este cel care închide tichetul.