Hvorfor feiler noen nettsteder bare når VPN-en er på?

At ett nettsted feiler mens alt annet lastes, beviser at tunnelen bærer trafikk, og det snevrer inn problemet mer enn de fleste forventer. Tre observasjoner sorterer resten: om du i det hele tatt fikk et HTTP-svar, om vertsnavnet ble slått opp til en adresse, og om små forespørsler går gjennom mens store henger. Å gjette på VPN-en før du har de svarene flytter som regel feilen i stedet for å fjerne den.

Arbeid deg gjennom observasjonene i rekkefølge, for et nettsted som svarte kan ikke samtidig ha feilet med oppslaget. Hvis ingenting lastes i det hele tatt, er du i feil gren, og kontrollene for tilkoblet men uten internett gjelder i stedet.

La feilmeldingen velge grenen

En avvisning, en bot-utfordring eller en feilside betyr at tjenesten svarte, altså nådde pakkene en applikasjon og kom tilbake. Det flytter spørsmålet til nettstedets tilgangspolicy, som kan veie inn utgangsadressen, kontoen eller forespørselsmønstre den ikke publiserer. En feil i navneoppslaget nådde aldri nettstedet, og adressen er det første som skal undersøkes. En tidsavbrudd ligger mellom de to: noe ble sendt, og ingenting bekreftet det.

Sertifikatadvarsler hører til en fjerde gren. De betyr at tilkoblingen ble besvart av noe hvis identitet nettleseren ikke kunne verifisere, som enten er en proxy på din side eller en ekte avvikelse du ikke bør klikke deg gjennom. Behandle det som et tillitsspørsmål snarere enn et rutingspørsmål.

Et nettsted som svarer beviser ikke en ødelagt tunnel

Når svaret er en blokkeringsside, sammenlign den samme siden gjennom en annen utgang mens nettleseren og maskinen holdes uendret. Følger resultatet utgangsadressen, behandler nettstedet den adressen annerledes, og ingen klientkonfigurasjon vil endre det. Følger blokkeringen i stedet nettleseren din, sitter årsaken i en utvidelse, en lagret proxy eller en oppløserinnstilling. To kjøringer skiller de forklaringene billig.

Feil som bare skjer i nettleseren er vanlige nok til å testes tidlig. En side som lastes i én støttet nettleser og feiler i en annen, peker på profiltilstand, en innholdsblokkerer eller kryptert DNS konfigurert inne i nettleseren selv. Chromes veiledning for sikker DNS dekker hvor den innstillingen ligger, og å endre den gjennom den støttede kontrollen slår å tilbakestille enheten.

Når bare store overføringer henger, se på pakkestørrelsen

En side som rendrer hodet sitt og deretter henger, har en annen signatur enn en side som aldri starter. Små svar kan gå gjennom mens en nyttelast i full størrelse slippes et sted som ikke kan signalere til avsenderen, og det er hvordan en path-MTU-feil ser ut fra en nettleser. Sammenlign en bitte liten forespørsel og en stor mot samme vert før du teoretiserer om filtrering. Path-MTU-discovery skal lære den minste leddstørrelsen langs veien, og den avhenger av ICMP-tilbakemelding som filtrerte nettverk rutinemessig forkaster.

Test den hypotesen med en størrelsessveip i stedet for en enkelt ping. En feil som begynner ved en konsistent nyttelaststørrelse er sterkt bevis, mens en feil som flytter seg rundt ikke er det.

Bekreft løsningen på forespørselen som feilet

Test den opprinnelige handlingen på nytt, ikke forsiden, for et bufret skall kan rendres mens API-kallet bak en innlogging fortsatt feiler. Kommandoene nedenfor skiller navneoppslag, en liten forespørsel og en stor mot samme vert. Erstatt vertsnavn og sti med dem fra forespørselen som faktisk brøt sammen.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

Hvis dig-svaret avviker fra det nettleseren brukte, er oppløseren variabelen, og nettleserens egen DNS-innstilling er stedet å se. Hvis den lille forespørselen returnerer en status mens den store henger, arbeid med pakkestørrelsesgrenen. Hvis begge får tidsavbrudd, er utgangsveien og nettstedets håndtering av den adressen igjen på bordet.

Behold endringen som fikk den opprinnelige forespørselen til å lykkes, og angre resten. En haug med samtidige endringer av nettleser, oppløser og klient gjør at du ikke kan si hvilken som betydde noe.