A chat oldal betöltődik, de az élő kapcsolat meghiúsul: hol keressünk

Nyissa meg a hálózati panelt a chat oldal betöltése előtt, majd keresse meg az üzeneteket szállító kérést, nem azt, amely a héjat rajzolja. A dokumentum, a szkriptek, a bejelentkezési csere és a chat átvitele mind különböző gazdagépekre mehet. A legtöbb jelentés, miszerint a VPN tönkretette a chatet, valójában e négy kérés egyikének meghiúsulását írja le. Kövesse őket sorrendben, és a válasz általában az első két percben látható.

Keresse meg az üzeneteket szállító kérést

Szűrjön típus szerint, amikor az oldal megnyugszik: a WebSocket saját bejegyzésként jelenik meg, az eseményfolyam növekvő válasszal nyitva marad, a hosszú lekérdezés pedig rendszeres időközönként ismétlődik. Jegyezze fel a sémát, a gazdagépet, a portot és az állapotot annál, amely a frissítéseket szállítja. Figyelje meg, hogy bejelentkezés előtt vagy után indult-e, mert a hitelesítés előtt megnyitott átvitel általában más tervezésű, mint az utána megnyitott. Olvassa el a kérés fejléceit a frissítési kéréshez vagy az elfogadott tartalomtípushoz, mert ezek azonosítják az átvitelt, amelyet a telepített oldal valójában választott.

A régi fórumbejegyzések olyan átviteleket írnak le, amelyeket a termékek évekkel ezelőtt felhagytak, ezért bízzon abban, amit a böngésző rögzített, ne a cikkben. Ha a bejegyzés teljesen hiányzik, lehet, hogy az ügyfélkód soha nem próbált kapcsolatot, ami egy korábbi szkript- vagy konfigurációhibára utal. A betöltődő oldal csak azt bizonyítja, hogy a dokumentum megérkezett, és ez a különbség dönti el, hogy egyáltalán a hálózatot hibakeresi-e.

A beállítás, a kézbesítés és az élettartam eltérően hibázik

A WebSocket HTTP-frissítéssel nyílik, amelyre 101 állapot válaszol, és utána minden keretezett üzenet, nem oldalletöltés, két szakasz, amelyet a RFC 6455 kifejezetten külön tart. Az eseményfolyam streamelő tartalomtípussal válaszol, és nyitva tartja a válasz törzsét. Mindkettő meghiúsulhat a megnyitásban, megnyílhat és nem kézbesíthet semmit, vagy megnyílhat, kézbesíthet, majd csendben meghalhat.

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

Rögzítse az első értelmes hibát, mielőtt profilhoz nyúl, mert a három időpont különböző rétegekre utal. Ha a kézfogás soha nem fejeződik be, hasonlítsa össze egy egyszerű HTTPS-kéréssel ugyanahhoz a gazdagéphez, hogy lássa, egyáltalán eljut-e oda valami. Ha befejeződik és nem érkeznek üzenetek, figyelje a kereteket vagy a folyam törzsét, miközben valaki egy másik fiókból tesztüzenetet küld. Ha működik, majd leáll, jegyezze fel a pontos időt és a zárókódot, mert ez a pár azonosítja, melyik fél adta fel.

Az 1006 kód azt jelenti, hogy a socket zárókeret nélkül zárult le, így néz ki egy köztes eszköz vagy egy tétlenségi időtúllépés a böngésző belsejéből. A VPN szívverése nem bizonyítja, hogy a belső alkalmazásmunkamenet még él.

Az élő gazdagép külön célpont

A chat háttérrendszerei gyakran a saját gazdagépnevükön élnek, néha más porton vagy külön tanúsítvány mögött. Ennek a célpontnak saját feloldásra, útvonalra és proxykezelésre van szüksége, és a megosztott alagútépítés tartalmazhatja az oldalt, miközben kizárja a socketet. Oldja fel az élő gazdagépnevet az ügyfélgépből, és erősítse meg, hogy azzal a címmel válaszol, amelyet azon a hálózaton vár. Ellenőrizze a tanúsítványláncot kifejezetten arra a gazdagépnévre, mert a webhelyet lefedő helyettesítő tanúsítvány nem mindig fedi le a socket végpontját.

Ha proxy van az útvonalon, erősítse meg, hogy engedélyezi a frissítést vagy a hosszú életű választ, ahelyett hogy pufferelné. A HTML-t átíró vállalati proxyk gyakran rosszul kezelik a WebSocket-frissítéseket, ami olyan oldalt eredményez, amely megjelenik, miközben a chat soha nem csatlakozik. Két kérés ugyanahhoz a termékhez tehát nem két kérés ugyanahhoz a gazdagéphez.

A célpontlistát javítsa, ne a biztonsági ellenőrzéseket

A célpontlista javítása útválasztási változás, és ahhoz tartozik, aki az útvonalat birtokolja. A tanúsítvány-érvényesítés lazítása vagy az Origin fejléc eltávolítása biztonsági változás, és ahhoz tartozik, aki a szabályzatot birtokolja, aki ritkán a hibajegyet hibakereső személy. A kapcsolat megjelenésének leggyorsabb módja általában a leggyorsabb mód arra, hogy egy incidens lehetővé váljon.

Kérdezze meg az alkalmazás tulajdonosát, milyen forrásokat fogad el a háttérrendszer, mielőtt bármit módosít, és adja át ezt a választ annak, aki a proxyt irányítja. Ha tanúsítványhiba csak az alagúton keresztül jelenik meg, vizsgálja meg az elfogó eszközt, ne telepítsen megkerülést.

Jegyezzen fel eleget az átadáshoz

A hasznos dokumentum rövid: az oldal URL-je, az élő végpont, a kézfogás eredménye, az első hiba ideje, és hogy történt-e újracsatlakozási kísérlet. Adja hozzá a VPN-profil nevét és a hálózatot, amelyen volt, és bármely olvasó megismételheti a tesztet hat kérdés nélkül. Takarja ki a sütiket, az engedélyezési fejléceket és az üzenettörzseket, és a teljes archívumexport helyett részesítse előnyben az időoszlop képernyőképét. A keretek és a hálózati archívumok privát üzeneteket és munkamenet-tokeneket tartalmazhatnak, ezért bármit csatolás előtt vizsgáljon meg.

Ha a hiba csendes lezárás, adja meg a zárókódot és az azt megelőző tétlenségi intervallumot, mert ez a pár általában az időtúllépés tulajdonosát azonosítja. Adja át a feljegyzést az alkalmazás vagy az átjáró tulajdonosának, ahelyett hogy maga találgatna egy időtúllépési értéket. A támogatott keepalive-viselkedésről adott válaszuk az, amely lezárja a hibajegyet.