Сайтът ви пада, а хостингът твърди, че всичко работи

TL;DR

Ако сайтът ви изчезва за минута-две и се връща сам, а хостингът отговаря „нямаме регистриран проблем”, и двете страни най-вероятно са прави. Грешките 521 и 525 се произвеждат от Cloudflare, не от сървъра, затова в неговите логове ги няма. Без независим монитор разговорът приключва с „не можем да възпроизведем”. С монитор приключва с причина.

Защо доставчикът наистина не вижда нищо

Когато Cloudflare стои пред сайта, всяка заявка минава през него. Ако при опит да се свърже с вашия сървър получи отказ, Cloudflare сам съчинява страница с грешка и я връща на посетителя.

Ключовото: тази страница никога не е стигала до сървъра. Затова я няма в access логовете, няма я в error логовете, и всяка автоматична проверка на доставчика показва зелено.

Двата кода, които ще видите:

Разликата има значение. 521 не е проблем със сертификата. Ако някой ви посъветва да свалите SSL режима на Flexible заради 521, съветът е грешен и ще разкриптира трафика между Cloudflare и сървъра, без да реши нищо.

Ако видите два различни кода в една и съща секунда за различни домейни на един акаунт, това почти изключва мрежов проблем между Cloudflare и сървъра — при прекъсната линия всички биха дали един и същ код.

Един акаунт, един контейнер

Тук е нещото, което изненадва повечето хора на споделен хостинг.

Повечето доставчици ползват CloudLinux, който слага всеки акаунт в собствен контейнер, наречен LVE. Контейнерът има свои тавани: процесорно време, входно-изходни операции, памет, и брой едновременни процеси.

Таваните са на акаунта, не на сайта.

Тоест ако имате петнайсет сайта в един акаунт и един от тях изяде процесорния таван, останалите четиринайсет спират да отговарят заедно с него. Сайт, който няма никакъв трафик, пада заради съсед в същия акаунт.

SSH обикновено оцелява през това, защото не минава нито през уеб сървъра, нито през Cloudflare. Затова „мога да вляза по SSH, значи сървърът работи” е подвеждащо — вие проверявате друг път до машината.

Как се доказва

Доставчикът не може да разследва „понякога пада”. Може да разследва „падна на 16 август в 18:11:01 UTC”.

Разликата между двете е монитор, който:

• проверява всяка минута, а не на пет или десет
• работи извън същия хостинг — проверка от машината, която проверяваме, не струва нищо в деня, когато има значение
• следи всички домейни в акаунта наведнъж, за да се види дали падат заедно
• включва поне един домейн, хостван другаде, като контрола

Последното е най-подценяваното. Ако пет домейна върнат 521, а шестият, който е на друг доставчик, върне 200 в същата секунда, вие вече знаете, че проблемът не е в интернет, не е у вас и не е в Cloudflare.

Минималната версия се събира в няколко реда:

for h in site1.bg site2.bg site3.com; do
  code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 15 "https://$h/")
  echo "$(date -u '+%F %T') $h=$code"
done >> ~/watch.log

Пуснато на cron всяка минута от външна машина, това е достатъчно. По-нататък се добавя проба на натоварването, за да има с какво да се сравни.

Прочитането на товара, което всички бъркат

Когато най-после хванете прекъсване, първият инстинкт е да погледнете натоварването и да кажете „ето, претоварено е”.

Проверете посоката, преди да заключите.

Ето реален отрязък от машина с 64 ядра, снет по време на прекъсване:

11:00 → 42.68   всички отговарят
11:10 → 32.09   всички отговарят
11:20 → 37.85   всички отговарят
11:21 → 17.97   ← пет от шест домейна не отговарят
11:25 → 87.61   всички отговарят

Товарът пада наполовина в минутата на срива и се удвоява четири минути след връщането.

Това е обратното на претоварване. При задавяне от товар кривата расте ДО срива и спада след него. Тук е точно наопаки, а обратното има само едно разумно обяснение: уеб процесът е спрял да работи, затова нищо не се е изпълнявало, а при вдигането си е поел натрупаната опашка наведнъж.

И още нещо: 64 ядра при товар 18 значи 0.28 на ядро. Машина не отказва връзки при такова натоварване. Без броя на ядрата числото на товара не значи нищо — 30 е спокойно на 64 ядра и е катастрофа на 4.

Какво можете да оправите сами

Преди да пишете тикет, вижте дали причината не е у вас.

Кеш. Ако сървърът е LiteSpeed, а нямате кеш плъгин, всяка заявка изпълнява PHP наново. Един сайт без кеш може сам да изяде процесорния таван на акаунта. LiteSpeed Cache е безплатен и вграден. Това е най-честата причина.

Плъгини, които се задавят в кръг. Има плъгини, чиито фонови задачи се провалят и веднага пускат нов опит. Сто и седемдесет провалени задачи в wp_actionscheduler_actions изяждат работниците на PHP и никой не забелязва защо. Проверете таблицата.

Автоматични обновявания. Някои хостинги пускат обновявания извън куките на WordPress, тоест филтрите на WordPress не ги спират. Едно мажорно обновяване на плъгин може да строши шаблона в три сутринта.

Node приложения в покой. Всяко постоянно приложение държи памет, дори когато никой не го ползва, и намалява мястото за PHP работниците при пик.

Как се води разговорът с поддръжката

Три неща работят, а едно не.

Работи: точни времена в UTC, до секундата. Всички кодове по домейни от една и съща минута. Домейн-контрола, който е бил жив. Предложение как да ви опровергаят — „ако снимката покаже изчерпан лимит точно в тези минути, приемаме заключението”.

Не работи: „сайтът пада понякога”.

И ако насреща получите обяснение, което не се връзва с датите ви, кажете го спокойно и с числата. Аз имах случай, в който прегледът намери четири събития на седми и четиринайсети, а прекъсванията бяха на шестнайсети и деветнайсети. Нито едно съвпадение. Това не е спор — това е информация, която насрещната страна няма как да види без вас.

Ако ви трябва помощ

Поддържаме WordPress сайтове на споделен хостинг и следим достъпността им отвън, с минутна точност. Когато нещо падне, идваме с лог, а не с предположение.

Вижте какво включва поддръжката или пишете ни.