Chatpagina laadt, maar de liveverbinding faalt: waar je moet kijken

Open het netwerkpaneel voordat je de chatpagina laadt en zoek daarna het verzoek dat de berichten draagt in plaats van het verzoek dat de pagina opbouwt. Het document, de scripts, de uitwisseling bij het inloggen en het chattransport kunnen allemaal naar andere hosts gaan. De meeste meldingen dat de VPN de chat heeft gesloopt beschrijven in werkelijkheid dat een van die vier verzoeken mislukt. Volg ze op volgorde en het antwoord is meestal binnen de eerste twee minuten zichtbaar.

Vind het verzoek dat berichten draagt

Filter op type zodra de pagina tot rust is gekomen: een WebSocket verschijnt als een eigen regel, een eventstream blijft open met een groeiend antwoord en een long poll herhaalt zich met een vast interval. Noteer schema, host, poort en status van degene die de updates draagt. Let op of die voor of na het inloggen begon, want een transport dat voor de authenticatie opengaat is meestal een ander ontwerp dan een dat erna opengaat. Lees de requestheaders voor het upgradeverzoek of het geaccepteerde contenttype, want die wijzen het transport aan dat de uitgerolde pagina echt heeft gekozen.

Oude forumposts beschrijven transporten die producten jaren geleden hebben verlaten, dus vertrouw op wat de browser vastlegde en niet op het artikel. Ontbreekt de regel helemaal, dan heeft de clientcode misschien nooit een verbinding geprobeerd, wat wijst op een eerdere fout in script of configuratie. Een pagina die laadt bewijst alleen dat het document aankwam, en dat onderscheid bepaalt of je uberhaupt het netwerk aan het debuggen bent.

Opzet, levering en levensduur falen verschillend

Een WebSocket opent met een HTTP-upgrade die met status 101 wordt beantwoord, en alles daarna zijn ingekaderde berichten in plaats van paginabezoeken, twee fasen die RFC 6455 expliciet gescheiden houdt. Een eventstream antwoordt met een streamend contenttype en houdt de antwoordbody open. Beide kunnen niet opengaan, opengaan en niets leveren, of opengaan, leveren en daarna stil sterven.

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

Vang de eerste betekenisvolle fout voordat je een profiel aanraakt, want de drie momenten wijzen op verschillende lagen. Als de handshake nooit voltooit, vergelijk die dan met een gewoon HTTPS-verzoek naar dezelfde host om te zien of er uberhaupt iets aankomt. Als die voltooit en er komen geen berichten, kijk dan naar de frames of de streambody terwijl iemand vanaf een ander account een testbericht stuurt. Als het werkt en daarna stopt, noteer dan het exacte tijdstip en de sluitcode, want dat paar wijst aan welke kant het opgaf.

Code 1006 betekent dat de socket zonder sluitframe is gesloten, en zo ziet een middlebox of een idle timeout er van binnenuit de browser uit. Een VPN-heartbeat bewijst niet dat de interne applicatiesessie nog leeft.

De livehost is een aparte bestemming

Chatbackends wonen vaak op hun eigen hostnaam, soms op een andere poort of achter een apart certificaat. Die bestemming heeft eigen resolutie, route en proxybehandeling nodig, en split tunnelling kan de pagina meenemen terwijl de socket buiten blijft. Los de live hostnaam op vanaf de clientmachine en bevestig dat die antwoordt met het adres dat je op dat netwerk verwacht. Controleer de certificaatketen specifiek voor die hostnaam, want een wildcard die de site dekt, dekt niet altijd het socket-eindpunt.

Staat er een proxy in het pad, bevestig dan dat die de upgrade of het langlevende antwoord toestaat in plaats van te bufferen. Bedrijfsproxies die HTML herschrijven gaan vaak slecht om met WebSocket-upgrades, wat een pagina oplevert die rendert terwijl de chat nooit verbindt. Twee verzoeken naar hetzelfde product zijn daarom niet twee verzoeken naar dezelfde host.

Repareer de bestemmingslijst, niet de beveiligingscontroles

Een bestemmingslijst repareren is een routeringswijziging en hoort bij wie de route bezit. Certificaatvalidatie versoepelen of de Origin-header strippen is een beveiligingswijziging en hoort bij wie het beleid bezit, en dat is zelden de persoon die de ticket debugt. De snelste manier om een verbinding te laten lijken te werken is meestal de snelste manier om een incident mogelijk te maken.

Vraag de applicatie-eigenaar welke origins de backend accepteert voordat je iets wijzigt, en geef dat antwoord door aan wie de proxy beheert. Verschijnt een certificaatfout alleen via de tunnel, onderzoek dan het onderscheppende apparaat in plaats van een omweg te installeren.

Leg genoeg vast om over te dragen

Het bruikbare artefact is kort: pagina-URL, live-eindpunt, handshakeresultaat, tijdstip van de eerste fout en of een herverbinding is geprobeerd. Voeg de naam van het VPN-profiel en het netwerk toe waarop je zat, en iedereen die het leest kan de test reproduceren zonder zes vragen te stellen. Verberg cookies, autorisatieheaders en berichtinhoud, en kies liever een schermafbeelding van de timingkolom dan een volledige archiefexport. Frames en netwerkarchieven kunnen priveberichten en sessietokens bevatten, dus kijk eerst voordat je iets bijvoegt.

Is de fout een stille sluiting, neem dan de sluitcode en het idle-interval ervoor op, want dat paar wijst meestal de eigenaar van de timeout aan. Geef het verslag aan de applicatie- of gateway-eigenaar in plaats van zelf een timeoutwaarde te gokken. Hun antwoord over ondersteund keepalive-gedrag is het antwoord dat de ticket sluit.