Chattesiden lastes, men den direkte tilkoblingen feiler: hvor du skal lete
Siden og chattetransporten er forskjellige forespørsler. Sjekk WebSocket, hendelsesstrøm eller lang avspørring, og skill deretter oppsett, levering og levetid.
Åpne nettverkspanelet før du laster chattesiden, og finn deretter forespørselen som bærer meldingene i stedet for den som tegner rammen. Dokumentet, skriptene, innloggingsutvekslingen og chattetransporten kan alle gå til ulike verter. De fleste rapportene om at VPN ødela chatten beskriver egentlig at én av disse fire forespørslene feiler. Følg dem i rekkefølge, og svaret er som regel synlig i løpet av de første to minuttene.
Finn forespørselen som bærer meldingene
Filtrer på type når siden har roet seg: en WebSocket vises som en egen oppføring, en hendelsesstrøm holder seg åpen med et svar som vokser, og en lang avspørring gjentas med jevnt intervall. Logg skjema, vert, port og status for den som bærer oppdateringene. Noter om den startet før eller etter innlogging, fordi en transport som åpnes før autentisering, vanligvis er en annen konstruksjon enn en som åpnes etter. Les forespørselshodene for oppgraderingsforespørselen eller den godtatte innholdstypen, siden de identifiserer transporten den utrullede siden faktisk valgte.
Gamle foruminnlegg beskriver transporter som produktene sluttet å bruke for flere år siden, så stol på det nettleseren registrerte og ikke på artikkelen. Hvis oppføringen mangler helt, kan klientkoden aldri ha forsøkt en tilkobling, noe som peker på en tidligere skript- eller konfigurasjonsfeil. En side som lastes, beviser bare at dokumentet kom frem, og den forskjellen avgjør om du i det hele tatt feilsøker nettverket.
Oppsett, levering og levetid feiler ulikt
En WebSocket åpnes med en HTTP-oppgradering som besvares med status 101, og alt etterpå er rammede meldinger i stedet for sidehenting, to stadier som RFC 6455 holder eksplisitt atskilt. En hendelsesstrøm svarer med en strømmende innholdstype og holder svarteksten åpen. Begge kan feile med å åpne, åpne uten å levere noe, eller åpne, levere og deretter dø stille.
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
Fang den første meningsfulle feilen før du rører en profil, fordi de tre tidspunktene peker på ulike lag. Hvis håndtrykket aldri fullføres, sammenlign det med en vanlig HTTPS-forespørsel til samme vert for å se om noe i det hele tatt når frem. Hvis det fullføres og ingen meldinger kommer, følg med på rammene eller strømteksten mens noen sender en testmelding fra en annen konto. Hvis det virker og deretter stopper, noter nøyaktig tidspunkt og lukkekoden, fordi det paret identifiserer hvilken ende som ga opp.
Kode 1006 betyr at sockelen ble lukket uten en lukkeramme, og det er slik en mellomledd eller en inaktivitetstidsgrense ser ut fra innsiden av nettleseren. Et VPN-hjerteslag beviser ikke at den indre applikasjonsøkten fortsatt er i live.
Den direkte verten er en egen destinasjon
Chattebackender bor ofte på sitt eget vertsnavn, noen ganger på en annen port eller bak et eget sertifikat. Den destinasjonen trenger sin egen oppslag, rute og proxybehandling, og delt tunnellering kan ta med siden mens den utelater sockelen. Slå opp det direkte vertsnavnet fra klientmaskinen og bekreft at det svarer med adressen du forventer på det nettverket. Sjekk sertifikatkjeden spesielt for det vertsnavnet, fordi et jokertegn som dekker nettstedet ikke alltid dekker sockelendepunktet.
Hvis en proxy ligger i veien, bekreft at den tillater oppgraderingen eller det langvarige svaret i stedet for å bufret det. Bedriftsproxier som skriver om HTML håndterer ofte WebSocket-oppgraderinger dårlig, og det gir en side som tegnes mens chatten aldri kobles til. To forespørsler til samme produkt er derfor ikke to forespørsler til samme vert.
Rett opp destinasjonslisten, ikke sikkerhetskontrollene
Å rette opp en destinasjonsliste er en ruteendring og tilhører den som eier ruten. Å lempe på sertifikatvalideringen eller fjerne Origin-headeren er en sikkerhetsendring og tilhører den som eier policyen, som sjelden er personen som feilsøker saken. Den raskeste måten å få en tilkobling til å se ut som den virker, er vanligvis den raskeste måten å gjøre en hendelse mulig.
Spør applikasjonseieren hvilke opprinnelser backend godtar før du endrer noe, og gi svaret videre til den som styrer proxyen. Hvis en sertifikatfeil bare vises gjennom tunnelen, undersøk enheten som avskjærer i stedet for å installere en omvei.
Logg nok til å kunne overlate saken
Det nyttige artefaktet er kort: sideadresse, direkte endepunkt, håndtrykksresultat, tidspunkt for første feil og om ny tilkobling ble forsøkt. Legg til VPN-profilnavnet og nettverket du var på, og alle som leser det, kan gjenskape testen uten å stille seks spørsmål. Sladd informasjonskapsler, autorisasjonshoder og meldingstekst, og velg et skjermbilde av tidskolonnen fremfor en full arkiveksport. Rammer og nettverksarkiver kan inneholde private meldinger og sesjonstoken, så undersøk før du legger ved noe.
Hvis feilen er en stille lukking, ta med lukkekoden og inaktivitetsintervallet før den, fordi det paret vanligvis identifiserer eieren av tidsgrensen. Overlever loggen til applikasjons- eller gatewayeieren i stedet for å gjette en tidsgrense selv. Svaret deres om støttet keepalive-atferd er det som lukker saken.