Chattsidan laddas men den direkta anslutningen misslyckas: var du ska leta

Öppna nätverkspanelen innan du laddar chattsidan och hitta sedan förfrågan som bär meddelandena i stället för den som ritar sidans ram. Dokumentet, skripten, utbytet vid inloggning och chattransporten kan alla gå till olika värdar. De flesta rapporter om att VPN förstörde chatten beskriver egentligen att en av dessa fyra förfrågningar misslyckas. Följ dem i ordning och svaret syns oftast inom de första två minuterna.

Hitta förfrågan som bär meddelandena

Filtrera på typ när sidan har lugnat sig: en WebSocket visas som en egen post, en händelseström hålls öppen med ett svar som växer och en lång polling upprepas med jämna intervall. Logga schema, värd, port och status för den som bär uppdateringarna. Notera om den startade före eller efter inloggningen, eftersom en transport som öppnas före autentiseringen oftast är en annan konstruktion än en som öppnas efter. Läs förfrågningsrubrikerna för uppgraderingsförfrågan eller den accepterade innehållstypen, eftersom de identifierar den transport som den utrullade sidan faktiskt valde.

Gamla foruminlägg beskriver transporter som produkterna slutade använda för år sedan, så lita på det webbläsaren registrerade och inte på artikeln. Om posten saknas helt kan klientkoden aldrig ha försökt ansluta, vilket pekar på ett tidigare skript- eller konfigurationsfel. Att sidan laddas bevisar bara att dokumentet kom fram, och den skillnaden avgör om du ens felsöker nätverket.

Uppsättning, leverans och livslängd misslyckas olika

En WebSocket öppnas med en HTTP-uppgradering som besvaras med status 101, och allt därefter är ramade meddelanden i stället för sidhämtning, två steg som RFC 6455 håller uttryckligen åtskilda. En händelseström svarar med en strömmande innehållstyp och håller svarets kropp öppen. Båda kan misslyckas med att öppnas, öppnas och inte leverera något, eller öppnas, leverera och sedan dö tyst.

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

Fånga det första meningsfulla felet innan du rör en profil, eftersom de tre tidpunkterna pekar på olika lager. Om handskakningen aldrig slutförs, jämför den med en vanlig HTTPS-förfrågan till samma värd för att se om något alls når fram. Om den slutförs och inga meddelanden kommer, följ ramarna eller strömmens kropp medan någon skickar ett testmeddelande från ett annat konto. Om det fungerar och sedan stannar, notera den exakta tiden och stängningskoden, eftersom det paret identifierar vilken sida som gav upp.

Kod 1006 betyder att socketen stängdes utan en stängningsram, och det är så en mellanliggande enhet eller en tidsgräns för inaktivitet ser ut inifrån webbläsaren. En VPN-heartbeat bevisar inte att den inre applikationssessionen fortfarande lever.

Den direkta värden är en egen destination

Chattbackendar bor ofta på sitt eget värdnamn, ibland på en annan port eller bakom ett separat certifikat. Den destinationen behöver sin egen uppslagning, rutt och proxyhantering, och delad tunnling kan inkludera sidan men utesluta socketen. Slå upp det direkta värdnamnet från klientmaskinen och bekräfta att det svarar med adressen du förväntar dig i det nätverket. Kontrollera certifikatkedjan särskilt för det värdnamnet, eftersom ett jokertecken som täcker webbplatsen inte alltid täcker socketens ändpunkt.

Om en proxy ligger i vägen, bekräfta att den tillåter uppgraderingen eller det långvariga svaret i stället för att buffra det. Företagsproxies som skriver om HTML hanterar ofta WebSocket-uppgraderingar dåligt, vilket ger en sida som ritas medan chatten aldrig ansluter. Två förfrågningar till samma produkt är därför inte två förfrågningar till samma värd.

Rätta destinationslistan, inte säkerhetskontrollerna

Att rätta en destinationslista är en routingändring och tillhör den som äger rutten. Att lätta på certifikatvalideringen eller ta bort Origin-huvudet är en säkerhetsändring och tillhör den som äger policyn, vilket sällan är personen som felsöker ärendet. Det snabbaste sättet att få en anslutning att se ut att fungera är oftast det snabbaste sättet att göra en incident möjlig.

Fråga applikationsägaren vilka ursprung backend accepterar innan du ändrar något, och lämna det svaret vidare till den som styr proxyn. Om ett certifikatfel bara visas genom tunneln, granska enheten som avlyssnar i stället för att installera en genväg.

Logga tillräckligt för att kunna lämna över

Den användbara artefakten är kort: sidans URL, direkt ändpunkt, handskakningsresultat, tidpunkt för första felet och om återanslutning försöktes. Lägg till VPN-profilens namn och nätverket du var på, och alla som läser det kan återskapa testet utan att ställa sex frågor. Maskera kakor, auktoriseringshuvuden och meddelandekroppar, och välj hellre en skärmbild av tidskolumnen än en full arkivexport. Ramar och nätverksarkiv kan innehålla privata meddelanden och sessionstoken, så granska innan du bifogar något.

Om felet är en tyst stängning, ta med stängningskoden och inaktivitetsintervallet före den, eftersom det paret oftast identifierar ägaren till tidsgränsen. Lämna loggen till applikations- eller gatewayägaren i stället för att själv gissa ett tidsgränsvärde. Deras svar om det stödda keepalive-beteendet är det som stänger ärendet.