Chattsida lastar, men den direkte tilkoplinga feilar: kvar du skal leite

Opne nettverkspanelet før du lastar chattsida, og finn deretter førespurnaden som ber meldingane i staden for den som teiknar ramma. Dokumentet, skripta, innloggingsutvekslinga og chattetransporten kan alle gå til ulike vertar. Dei fleste rapportane om at VPN øydela chatten skildrar eigentleg at éin av desse fire førespurnadene feilar. Følg dei i rekkefølgje, og svaret er som regel synleg i løpet av dei første to minutta.

Finn førespurnaden som ber meldingane

Filtrer på type når sida har roa seg: ein WebSocket viser seg som ein eigen oppføring, ein hendingsstraum held seg open med eit svar som veks, og ei lang avspørjing blir gjenteken med jamt intervall. Logg skjema, vert, port og status for den som ber oppdateringane. Noter om han starta før eller etter innlogging, fordi ein transport som blir opna før autentisering, vanlegvis er ein annan konstruksjon enn ein som blir opna etter. Les førespurnadshovuda for oppgraderingsførespurnaden eller den godtekne innhaldstypen, sidan dei identifiserer transporten den utrulla sida faktisk valde.

Gamle foruminnlegg skildrar transportar som produkta slutta å bruke for fleire år sidan, så stol på det nettlesaren registrerte og ikkje på artikkelen. Viss oppføringa manglar heilt, kan klientkoden aldri ha prøvd ei tilkopling, noko som peikar på ein tidlegare feil i skript eller konfigurasjon. Ei side som lastar, beviser berre at dokumentet kom fram, og den skilnaden avgjer om du i det heile feilsøkjer nettverket.

Oppsett, levering og levetid feilar ulikt

Ein WebSocket blir opna med ein HTTP-oppgradering som blir svart med status 101, og alt etterpå er ramma meldingar i staden for sidehenting, to steg som RFC 6455 held eksplisitt fråskilde. Ein hendingsstraum svarar med ein straumande innhaldstype og held svarteksten open. Begge kan feile med å opne, opne utan å levere noko, eller opne, levere og deretter døy 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 meiningsfulle feilen før du rører ein profil, fordi dei tre tidspunkta peikar på ulike lag. Viss handtrykket aldri blir fullført, samanlikn det med ein vanleg HTTPS-førespurnad til same vert for å sjå om noko i det heile når fram. Viss det blir fullført og ingen meldingar kjem, følg med på rammene eller straumteksten medan nokon sender ei testmelding frå ein annan konto. Viss det verkar og deretter stoppar, noter nøyaktig tidspunkt og lukkekoden, fordi det paret identifiserer kva ende som gav opp.

Kode 1006 betyr at sockelen vart lukka utan ei lukkeramme, og det er slik ein mellomboks eller ei inaktivitetstidsgrense ser ut frå innsida av nettlesaren. Eit VPN-hjarteslag beviser ikkje at den indre applikasjonsøkta framleis er levande.

Den direkte verten er ein eigen destinasjon

Chattebackendar bur ofte på sitt eige vertsnamn, stundom på ein annan port eller bak eit eige sertifikat. Den destinasjonen treng sitt eige oppslag, rute og proxyhandsaming, og delt tunnellering kan ta med sida medan ho utelèt sockelen. Slå opp det direkte vertsnamnet frå klientmaskina og stadfest at det svarar med adressa du ventar på det nettverket. Sjekk sertifikatkjeda spesielt for det vertsnamnet, fordi eit jokerteikn som dekkjer nettstaden ikkje alltid dekkjer sockelendepunktet.

Viss ein proxy ligg i vegen, stadfest at han tillèt oppgraderinga eller det langvarige svaret i staden for å bufre det. Bedriftsproxiar som skriv om HTML handterer ofte WebSocket-oppgraderingar dårleg, og det gir ei side som blir teikna medan chatten aldri blir kopla til. To førespurnader til same produkt er derfor ikkje to førespurnader til same vert.

Rett opp destinasjonslista, ikkje tryggingskontrollane

Å rette opp ei destinasjonsliste er ei ruteendring og høyrer til den som eig ruta. Å lempe på sertifikatvalideringa eller fjerne Origin-hovudet er ei tryggingsendring og høyrer til den som eig policyen, som sjeldan er personen som feilsøkjer saka. Den raskaste måten å få ei tilkopling til å sjå ut som ho verkar, er vanlegvis den raskaste måten å gjere ei hending mogleg.

Spør applikasjonseigaren kva opphav backend godtek før du endrar noko, og gi svaret vidare til den som styrer proxyen. Viss ein sertifikatfeil berre viser seg gjennom tunnelen, gransk eininga som avskjerer i staden for å installere ein omveg.

Logg nok til å kunne overlate saka

Det nyttige artefaktet er kort: sideadresse, direkte endepunkt, handtrykksresultat, tidspunkt for første feil og om ny tilkopling vart prøvd. Legg til VPN-profilnamnet og nettverket du var på, og alle som les det, kan gjenskape testen utan å stille seks spørsmål. Sladd informasjonskapslar, autorisasjonshovud og meldingstekst, og vel ein skjermdump av tidskolonnen framfor ein full arkiveksport. Rammer og nettverksarkiv kan innehalde private meldingar og sesjonstoken, så gransk før du legg ved noko.

Viss feilen er ei stille lukking, ta med lukkekoden og inaktivitetsintervallet før han, fordi det paret vanlegvis identifiserer eigaren av tidsgrensa. Overlever loggen til applikasjons- eller gatewayeigaren i staden for å gjette ei tidsgrense sjølv. Svaret deira om støtta keepalive-åtferd er det som lukkar saka.