Varför misslyckas vissa webbplatser bara när VPN:t är på?

Att en webbplats misslyckas medan allt annat laddas bevisar att tunneln bär trafik, vilket snävar in problemet mer än de flesta väntar sig. Tre observationer sorterar resten: om du alls fick ett HTTP-svar, om värdnamnet löstes upp till en adress och om små förfrågningar går igenom medan stora hänger. Att gissa på VPN:t innan du har de svaren flyttar oftast felet i stället för att åtgärda det.

Arbeta igenom observationerna i ordning, för en webbplats som svarade kan inte samtidigt ha misslyckats med upplösningen. Om inget alls laddas är du i fel gren, och kontrollerna för ansluten men utan internet gäller i stället.

Låt felmeddelandet välja gren

En vägran, en botutmaning eller en felsida betyder att tjänsten svarade, alltså nådde paketen en applikation och kom tillbaka. Det flyttar frågan till webbplatsens åtkomstpolicy, som kan väga in utgångsadressen, kontot eller förfrågningsmönster som den inte publicerar. Ett fel i namupplösningen nådde aldrig webbplatsen, och adressen är det första att undersöka. En timeout ligger mellan de två: något skickades och inget bekräftade det.

Certifikatvarningar hör till en fjärde gren. De betyder att anslutningen besvarades av något vars identitet webbläsaren inte kunde verifiera, vilket antingen är en proxy på din sida eller en verklig avvikelse som du inte bör klicka igenom. Behandla det som en tillitsfråga snarare än en routingfråga.

En webbplats som svarar bevisar inte en trasig tunnel

När svaret är en blockeringssida, jämför samma sida genom en andra utgång medan webbläsaren och maskinen är oförändrade. Följer resultatet utgångsadressen behandlar webbplatsen den adressen annorlunda, och ingen klientkonfiguration ändrar det. Följer blockeringen i stället din webbläsare sitter orsaken i ett tillägg, en sparad proxy eller en resolverinställning. Två körningar skiljer de förklaringarna billigt.

Fel som bara sker i webbläsaren är vanliga nog att testa tidigt. En sida som laddas i en webbläsare som stöds och misslyckas i en annan pekar på profiltillstånd, en innehållsblockerare eller krypterad DNS som konfigurerats inuti webbläsaren själv. Chromes vägledning för säker DNS visar var den inställningen finns, och att ändra den via den stödda kontrollen slår att återställa enheten.

När bara stora överföringar hänger, titta på paketstorleken

En sida som renderar sitt huvud och sedan hänger har en annan signatur än en sida som aldrig startar. Små svar kan gå igenom medan en nyttolast i full storlek tappas någonstans som inte kan signalera till avsändaren, och det är så ett path-MTU-fel ser ut från en webbläsare. Jämför en pytteliten förfrågan och en stor till samma värd innan du teoretiserar om filtrering. Path-MTU-discovery ska lära sig den minsta länkstorleken längs vägen, och den beror på ICMP-återkoppling som filtrerade nätverk rutinmässigt kastar.

Testa den hypotesen med en storlekssvepning i stället för en enda ping. Ett fel som börjar vid en konsekvent nyttolaststorlek är starkt bevis, medan ett fel som flyttar sig runt inte är det.

Bekräfta åtgärden på den förfrågan som misslyckades

Testa den ursprungliga åtgärden igen, inte startsidan, för ett cachat skal kan renderas medan API-anropet bakom en inloggning fortfarande misslyckas. Kommandona nedan skiljer namupplösning, en liten förfrågan och en stor mot samma värd. Byt ut värdnamn och sökväg mot dem från förfrågan som faktiskt gick sönder.

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

Om dig-svaret skiljer sig från det webbläsaren använde är resolvern variabeln, och webbläsarens egen DNS-inställning är stället att titta på. Om den lilla förfrågan returnerar en status medan den stora hänger, arbeta med paketstorleksgrenen. Om båda får timeout ligger utgångsvägen och webbplatsens hantering av den adressen åter på bordet.

Behåll ändringen som fick den ursprungliga förfrågan att lyckas och ångra resten. En hög samtidiga ändringar av webbläsare, resolver och klient gör att du inte längre kan säga vilken som spelade roll.