Chatsiden indlæses, men den live forbindelse fejler: hvor du skal kigge

Åbn netværkspanelet, før du indlæser chatsiden, og find derefter den anmodning, der bærer beskederne, frem for den, der tegner skallen. Dokumentet, scriptene, login-udvekslingen og chat-transporten kan alle gå til forskellige værter. De fleste rapporter om, at VPN’en brød chatten, beskriver i virkeligheden, at en af de fire anmodninger fejler. Følg dem i rækkefølge, og svaret er normalt synligt inden for de første to minutter.

Find den anmodning, der bærer beskeder

Filtrér efter type, når siden er faldet til ro: en WebSocket vises som sin egen post, en hændelsesstrøm forbliver åben med et voksende svar, og en long poll gentages med et fast interval. Notér skema, vært, port og status for den, der bærer opdateringerne. Bemærk, om den startede før eller efter login, fordi en transport, der åbnes før godkendelse, normalt er et andet design end en, der åbnes efter. Læs anmodningsheadere for opgraderingsanmodningen eller den accepterede indholdstype, fordi de identificerer den transport, den udrullede side faktisk valgte.

Gamle forumindlæg beskriver transports, som produkter stoppede med at bruge for år siden, så stol på det, browseren registrerede, frem for artiklen. Hvis posten helt mangler, har klientkoden måske aldrig forsøgt en forbindelse, hvilket peger på en tidligere script- eller konfigurationsfejl. En side, der indlæses, beviser kun, at dokumentet ankom, og den forskel afgør, om du overhovedet fejlfinder netværket.

Opsætning, levering og levetid fejler forskelligt

En WebSocket åbner med en HTTP-opgradering, der besvares med status 101, og alt derefter er indrammede beskeder frem for sidehentning, to faser som RFC 6455 holder udtrykkeligt adskilt. En hændelsesstrøm svarer med en streamende indholdstype og holder svarlegemet åbent. Begge kan fejle med at åbne, åbne og levere intet, eller åbne, levere og derefter 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 meningsfulde fejl, før du rører en profil, fordi de tre tidspunkter peger på forskellige lag. Hvis håndtrykket aldrig fuldføres, sammenlign det med en almindelig HTTPS-anmodning til samme vært for at se, om noget overhovedet når den. Hvis det fuldføres, og der ikke kommer beskeder, så hold øje med frames eller strømlegemet, mens nogen sender en testbesked fra en anden konto. Hvis det virker og derefter stopper, notér det præcise tidspunkt og lukkekoden, fordi det par identificerer, hvilken ende der gav op.

Kode 1006 betyder, at socketen lukkede uden en lukkeramme, hvilket er, hvordan en mellembox eller en inaktivitetstimeout ser ud indefra browseren. Et VPN-heartbeat beviser ikke, at den indre applikationssession stadig er levende.

Den live vært er en separat destination

Chat-backends bor ofte på deres eget værtsnavn, nogle gange på en anden port eller bag et separat certifikat. Den destination kræver sin egen opløsning, rute og proxybehandling, og split tunnelling kan inkludere siden og udelukke socketen. Opløs det live værtsnavn fra klientmaskinen, og bekræft, at det svarer med den adresse, du forventer på det netværk. Kontrollér certifikatkæden specifikt for det værtsnavn, fordi et wildcard, der dækker webstedet, ikke altid dækker socket-endpointet.

Hvis en proxy ligger i vejen, så bekræft, at den tillader opgraderingen eller det langvarige svar i stedet for at buffer det. Virksomhedsproxier, der omskriver HTML, håndterer ofte WebSocket-opgraderinger dårligt, hvilket giver en side, der vises, mens chatten aldrig forbinder. To anmodninger til det samme produkt er derfor ikke to anmodninger til den samme vært.

Ret destinationslisten, ikke sikkerhedskontrollerne

At rette en destinationsliste er en routingændring og hører til den, der ejer ruten. At lempe certifikatvalidering eller fjerne Origin-headeren er en sikkerhedsændring og hører til den, der ejer politikken, hvilket sjældent er den person, der fejlfinder billetten. Den hurtigste måde at få en forbindelse til at vises er normalt den hurtigste måde at gøre en hændelse mulig.

Spørg applikationsejeren, hvilke origins backenden accepterer, før du ændrer noget, og giv svaret videre til den, der styrer proxyen. Hvis en certifikatfejl kun vises gennem tunnelen, så undersøg den opfangende enhed i stedet for at installere en omgåelse.

Registrér nok til at overdrage

Det nyttige artefakt er kort: side-URL, live-endpoint, håndtryksresultat, tidspunkt for første fejl, og om en genopkobling blev forsøgt. Tilføj VPN-profilens navn og det netværk, du var på, og enhver læser kan genskabe testen uden at stille seks spørgsmål. Slør cookies, autorisationsheadere og beskedindhold, og foretræk et skærmbillede af tidskolonnen frem for en fuld arkiveksport. Frames og netværksarkiver kan indeholde private beskeder og sessionstokens, så undersøg, før du vedhæfter noget.

Hvis fejlen er en stille lukning, så inkludér lukkekoden og det inaktive interval, der gik forud, fordi det par normalt identificerer timeout-ejeren. Overdrag registreringen til applikations- eller gatewayejeren i stedet for selv at gætte en timeoutværdi. Deres svar om understøttet keepalive-adfærd er det, der lukker billetten.