Тое, што адзін сайт не працуе, а ўсё астатняе загружаецца, даказвае, што тунель перадае трафік, і гэта звужае праблему мацней, чым большасць чакае. Тры назіранні ўпарадкоўваюць рэшту: ці атрымалі вы наогул адказ HTTP, ці развязалася імя хоста ў адрас і ці праходзяць малыя запыты, пакуль вялікія завісаюць. Здагадкі пра VPN да атрымання гэтых адказаў звычайна пераносяць няспраўнасць, а не ўстараняюць яе.

Разбірайце назіранні па парадку, бо сайт, які адказаў, не мог адначасова не развязацца. Калі наогул нічога не загружаецца, вы ў іншай галіне, і дзейнічаюць праверкі для падключана, але без інтэрнэту.

Няхай паведамленне пра памылку выбера галіну

Адмова, антыботавая праверка або старонка памылкі азначаюць, што служба адказала, то-бок пакеты дайшлі да праграмы і вярнуліся. Гэта пераносіць пытанне да палітыкі доступу сайта, якая можа ўлічваць адрас выхаду, уліковы запіс або непублікаваныя шаблоны запытаў. Збой развязання імёнаў наогул не дайшоў да сайта, і адрас — першае, што трэба праверыць. Тайм-аўт ляжыць паміж імі: нешта было адпраўлена, і нішто гэта не пацвердзіла.

Папярэджанні пра сертыфікаты адносяцца да чацвёртай галіны. Яны азначаюць, што злучэнне абслугоўвала нешта, чыю асобу браўзер не змог праверыць: альбо проксі на вашым баку, альбо сапраўдная няўзгодненасць, праз якую не варта клацаць. Лічыце гэта пытаннем даверу, а не маршрутызацыі.

Сайт, які адказвае, яшчэ не даказаў паломку тунеля

Калі адказ — старонка блакавання, параўнайце тую самую старонку праз другі выхад, не змяняючы браўзер і машыну. Калі вынік ідзе за адрасам выхаду, сайт апрацоўвае гэты адрас інакш, і ніякая налада кліента гэтага не зменіць. Калі блакаванне ідзе за вашым браўзерам, прычына ў пашырэнні, захаваным проксі або наладзе развязальніка. Два прагоны танна раздзяляюць гэтыя тлумачэнні.

Збоі толькі ў браўзеры дастаткова частыя, каб правяраць іх рана. Старонка, якая загружаецца ў адным падтрыманым браўзеры і збоіць у іншым, паказвае на стан профілю, блакавальнік змесціва або зашыфраваны DNS, наладжаны ўнутры самога браўзера. Настаўленні Chrome пра бяспечны DNS паказваюць, дзе знаходзіцца гэта налада, і змяніць яе праз падтрыманы элемент кіравання лепш, чым скідваць прыладу.

Калі завісаюць толькі вялікія перадачы, глядзіце на памер пакета

Старонка, якая прамалёўвае загаловак і потым завісае, мае іншы подпіс, чым старонка, якая ніколі не пачынаецца. Малыя адказы могуць праходзіць, пакуль поўнапамерная карысная нагрузка недзе адкідваецца, што не можа сігналізаваць адпраўніку, і менавіта так выглядае збой MTU шляху з браўзера. Параўнайце крохкі запыт і вялікі да таго самага хоста, перш чым тэарэтызаваць пра фільтраванне. Выяўленне MTU шляху павінна вывучаць найменшы памер звяна на шляху, і яно залежыць ад водгукаў ICMP, якія фільтравальныя сеткі рэгулярна адкідваюць.

Праверце гэтую гіпотэзу пераборам памераў, а не адным пінгам. Збой, які пачынаецца пры пастаянным памеры карыснай нагрузкі, — моцны доказ, а збой, які зрушваецца, — не.

Пацвердзіце выпраўленне на запыце, які збоіў

Паўтарыце пачатковую аперацыю, а не галоўную старонку, бо кэшаваная абалонка можа прамалёўвацца, пакуль выклік API за ўваходам усё яшчэ збоіць. Каманды ніжэй раздзяляюць развязанне імёнаў, малы запыт і вялікі да таго самага хоста. Падстаўце імя хоста і шлях з запыту, які сапраўды зламаўся.

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

Калі адказ dig адрозніваецца ад таго, што выкарыстаў браўзер, зменнай з'яўляецца развязальнік, і ўласная налада DNS браўзера — месца, куды глядзець. Калі малы запыт вяртае статус, пакуль вялікі завісае, прапрацуйце галіну памеру пакета. Калі абодва вычэрпваюць час, шлях выхаду і стаўленне сайта да гэтага адрасу зноў на стале.

Захавайце змену, дзякуючы якой пачатковы запыт прайшоў, і адмяніце рэшту. Купа адначасовых правак у браўзеры, развязальніку і кліенце не дасць сказаць, якая з іх мела значэнне.

Падобныя артыкулы