Stránka chatu sa načíta, ale živé spojenie zlyháva: kde hľadať
Stránka a transport chatu sú rôzne požiadavky. Skontrolujte WebSocket, prúd udalostí alebo dlhé dopytovanie a potom oddeľte nastavenie, doručenie a životnosť.
Panel siete otvorte pred načítaním stránky chatu a potom nájdite požiadavku, ktorá prenáša správy, a nie tú, ktorá kreslí kostru stránky. Dokument, skripty, výmena pri prihlásení a transport chatu môžu ísť na rôznych hostiteľov. Väčšina hlásení, že VPN pokazila chat, v skutočnosti opisuje zlyhanie jednej z týchto štyroch požiadaviek. Sledujte ich v poradí a odpoveď je zvyčajne viditeľná v prvých dvoch minútach.
Nájdite požiadavku, ktorá prenáša správy
Keď sa stránka upokojí, filtrujte podľa typu: WebSocket sa zobrazí ako samostatná položka, prúd udalostí zostane otvorený s rastúcou odpoveďou a dlhé dopytovanie sa opakuje v pravidelnom intervale. Zaznamenajte schému, hostiteľa, port a stav tej, ktorá prenáša aktualizácie. Poznamenajte, či sa začala pred prihlásením alebo po ňom, pretože transport otvorený pred overením má zvyčajne inú konštrukciu než ten otvorený po ňom. Čítajte hlavičky požiadavky na upgrade alebo prijatý typ obsahu, pretože určujú transport, ktorý nasadená stránka skutočne zvolila.
Staré príspevky na fórach opisujú transporty, ktoré produkty opustili pred rokmi, takže dôverujte tomu, čo zaznamenal prehliadač, a nie článku. Ak položka úplne chýba, klientsky kód možno nikdy neskúsil spojenie, čo poukazuje na skoršie zlyhanie skriptu alebo konfigurácie. Načítanie stránky dokazuje len to, že dokument dorazil, a práve tento rozdiel rozhoduje, či vôbec ladíte sieť.
Nastavenie, doručenie a životnosť zlyhávajú rôzne
WebSocket sa otvára upgrade HTTP, na ktorý sa odpovedá stavom 101, a všetko po tom sú správy v rámcoch namiesto sťahovania stránok, dve fázy, ktoré RFC 6455 výslovne oddeľuje. Prúd udalostí odpovedá streamovacím typom obsahu a drží telo odpovede otvorené. Oba môžu zlyhať pri otvorení, otvoriť sa a nič nedoručiť, alebo sa otvoriť, doručiť a potom ticho zomrieť.
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
Zachyťte prvé zmysluplné zlyhanie predtým, než sa dotknete profilu, pretože tri časové body ukazujú na rôzne vrstvy. Ak sa handshake nikdy nedokončí, porovnajte ho s obyčajnou požiadavkou HTTPS na toho istého hostiteľa, aby ste videli, či sa k nemu niečo dostane. Ak sa dokončí a správy neprichádzajú, sledujte rámce alebo telo prúdu, kým niekto posiela testovaciu správu z iného účtu. Ak to funguje a potom sa zastaví, poznamenajte presný čas a kód zatvorenia, pretože táto dvojica určuje, ktorá strana to vzdala.
Kód 1006 znamená, že socket sa zatvoril bez rámca zatvorenia, a takto vyzerá prostredník alebo časový limit nečinnosti zvnútra prehliadača. Pulz VPN nedokazuje, že vnútorná relácia aplikácie je stále živá.
Živý hostiteľ je samostatný cieľ
Backendy chatu často sídlia na vlastnom názve hostiteľa, niekedy na inom porte alebo za samostatným certifikátom. Ten cieľ potrebuje vlastné rozlíšenie, trasu a spracovanie cez proxy a rozdelené tunelovanie môže zahrnúť stránku a vylúčiť socket. Rozlíšte názov živého hostiteľa z klientskeho počítača a potvrďte, že odpovedá adresou, ktorú v tejto sieti očakávate. Skontrolujte reťaz certifikátov špecificky pre ten názov hostiteľa, pretože zástupný znak pokrývajúci lokalitu nie vždy pokrýva koncový bod socketu.
Ak je v ceste proxy, potvrďte, že povoľuje upgrade alebo dlhotrvajúcu odpoveď namiesto jej ukladania do vyrovnávacej pamäte. Podnikové proxy prepisujúce HTML často zle spracúvajú upgrady WebSocket, čo vedie k stránke, ktorá sa vykreslí, ale chat sa nikdy nepripojí. Dve požiadavky na ten istý produkt preto nie sú dve požiadavky na toho istého hostiteľa.
Opravte zoznam cieľov, nie bezpečnostné kontroly
Oprava zoznamu cieľov je zmena smerovania a patrí vlastníkovi trasy. Zmiernenie overovania certifikátov alebo odstránenie hlavičky Origin je bezpečnostná zmena a patrí vlastníkovi politiky, ktorým je zriedka osoba ladiace tiket. Najrýchlejší spôsob, ako dosiahnuť, aby spojenie vyzeralo úspešné, je zvyčajne najrýchlejší spôsob, ako umožniť incident.
Pred akoukoľvek zmenou sa spýtajte vlastníka aplikácie, ktoré zdroje backend akceptuje, a túto odpoveď odovzdajte tomu, kto spravuje proxy. Ak sa chyba certifikátu objavuje len cez tunel, preskúmajte zariadenie, ktoré zachytáva, namiesto inštalácie obchádzky.
Zaznamenajte dosť na odovzdanie
Užitočný artefakt je krátky: URL stránky, živý koncový bod, výsledok handshake, čas prvého zlyhania a či sa skúsilo opätovné pripojenie. Pridajte názov profilu VPN a sieť, na ktorej ste boli, a každý čitateľ dokáže test zopakovať bez šiestich otázok. Zakryte cookies, autorizačné hlavičky a telá správ a uprednostnite snímku stĺpca časov pred úplným exportom archívu. Rámce a sieťové archívy môžu obsahovať súkromné správy a tokeny relácie, preto pred priložením čohokoľvek skontrolujte.
Ak je zlyhanie tiché zatvorenie, uveďte kód zatvorenia a interval nečinnosti pred ním, pretože táto dvojica zvyčajne určuje vlastníka časového limitu. Odovzdajte záznam vlastníkovi aplikácie alebo brány namiesto hádania hodnoty časového limitu. Ich odpoveď o podporovanom správaní keepalive je tá, ktorá uzatvára tiket.