Як перевірити, чи працює сайт: в усіх чи лише у вас

Сайт не відкривається. Він лежить у всіх чи проблема у вас — у Wi-Fi, DNS, браузері? А якщо це ваш власний сайт, з чого починати? Нижче — перевірки в тому порядку, який заощаджує найбільше часу: від «це лише в мене?» до самого сервера.

Крок 1: не працює в усіх чи лише у вас?

Найшвидше відповісти, подивившись на сайт з іншої точки:

• Відкрийте його на телефоні з вимкненим Wi-Fi: мобільний інтернет — інша мережа й зазвичай інший DNS.
• Спробуйте інший браузер або приватне вікно: розширення й кеш уміють ламати сторінки.
• Запустіть перевірку статусу сайту. Вона запитує сторінку з нашого сервера — з іншої мережі й іншого місця, ніж ви, — і показує HTTP-код, час відповіді, SSL і редиректи.

Якщо з нашого сервера й через мобільний інтернет сайт відкривається, а з домашньої мережі ні, проблема локальна: роутер, кеш DNS, VPN, антивірус або корпоративний фаєрвол. Перезавантажте роутер, очистіть кеш DNS, вимкніть VPN і спробуйте знову. Якщо сайт не відкривається ніде — читайте далі.

Крок 2: прочитайте текст помилки

Повідомлення браузера вже звужує коло причин:

• «Не вдається отримати доступ до сайту» / DNS_PROBE_FINISHED_NXDOMAIN — ім’я домену не перетворюється на адресу. Переходьте до кроку про DNS.
• Час очікування вичерпано / з’єднання відхилено — DNS працює, але сервер не відповідає: він вимкнений, перевантажений або фаєрвол відкидає з’єднання.
• Попередження про сертифікат (NET::ERR_CERT_DATE_INVALID і подібні) — сервер відповідає, але SSL-сертифікат прострочений, недійсний або виписаний на інше ім’я.
• Сторінка з кодом помилки (500, 502, 503, 404…) — сервер доступний і відповідає, проблема в застосунку, конфігурації чи адресі.

Увесь сайт чи одна сторінка?

Перш ніж лізти в сервер, оцініть масштаб. Відкрийте головну й ще дві-три сторінки, включно зі статичним файлом — зображенням або robots.txt. Якщо статичні файли віддаються, а сторінки ні, вебсервер живий, а падає застосунок (CMS, база даних, PHP). Якщо зламано лише один розділ, шукайте, чим він особливий: плагін, зовнішній API, важкий запит до бази. Якщо головна працює, а конкретне посилання віддає 404, сторінку, найімовірніше, перенесли без редиректу. А якщо все падає лише в адмінці, причина частіше в сесії, cookies чи правилі безпеки, а не в падінні сайту.

Крок 3: коди відповіді — 5xx проти 4xx

Відповідаючи, сервер повертає код стану. Перевірка коду відповіді сервера покаже точний код будь-якого URL, включно з усіма редиректами на шляху.

Просте правило: 5xx — проблема на боці сервера; 4xx — сервер працює, але відмовляє або не знаходить саме цей запит. Головна, що віддає 404, не «лежить» у звичному сенсі — щось не так з адресою чи маршрутизацією.

Крок 4: проблеми з DNS

Якщо домен не розв’язується, перевірте його записи через DNS Lookup: чи є запис A (або AAAA) і чи вказує він на потрібний сервер? Чи збігаються записи NS з тими, що видав ваш DNS-провайдер?

Часті причини:

• Домен не продовжено. Реєстратори часто перемикають DNS на сторінку-заглушку або прибирають його зовсім. Дату закінчення покаже WHOIS.
• Записи нещодавно змінювали. Після переїзду хостингу чи DNS-провайдера частина резолверів ще віддає стару адресу, доки не мине TTL у кеші. Перевірка оновлення DNS порівнює відповіді багатьох публічних резолверів з авторитетними серверами й показує, хто вже бачить нове значення.
• NS-сервери в реєстратора змінили, а зона в нового провайдера порожня чи неповна.

Докладно про кожен запис — у статті про перевірку DNS-записів домену.

Крок 5: прострочений SSL-сертифікат

Сайт із простроченим сертифікатом браузер закриває попередженням на весь екран, і відвідувачі сприймають це як «сайт не працює». Автоподовження зазвичай рятує, але мовчки ламається під час зміни DNS, підключення CDN або якщо завдання подовження перестало запускатися. Перевірка SSL покаже дату закінчення, ланцюжок та імена в сертифікаті. Докладніше — про перевірку SSL-сертифіката.

Крок 6: збої хостингу, CDN і сторонніх сервісів

Іноді справа зовсім не у вашому сайті. Великі хостинги, хмарні платформи й CDN публікують сторінки статусу (зазвичай status.провайдер.com) з поточними інцидентами. Якщо у вас CDN на кшталт Cloudflare, його власні сторінки помилок підказують, з якого боку збій: помилка, де фігурує ваш вихідний сервер, означає, що CDN працює, але не може достукатися до хостингу.

Перевіряйте й «повільно», а не лише «мертво»: час відгуку сайту розкладає запит на DNS, підключення, TLS і час до першого байта. TTFB у кілька секунд вказує на перевантажений сервер чи повільний застосунок — це часто передує помилкам 502 і 504.

Крок 7: блокування фаєрволом або WAF

Сайт може «не працювати» лише в частини відвідувачів. Вебфаєрволи, плагіни безпеки, DDoS-захист хостингу й блокування за країнами відсікають окрему IP-адресу, цілого провайдера чи країну. Ознаки: в одних 403 або сторінка перевірки, в інших усе відкривається; сайт працює через мобільний інтернет, але не з офісу. Якщо в публічний чорний список потрапила IP-адреса вашого сервера чи пошти, дивіться статтю чому IP у чорному списку.

Власнику сайту: що робити зараз і наступного разу

1. Підтвердьте падіння ззовні (перевірка статусу, мобільний інтернет).
2. Перевірте очевидне: терміни домену й сертифіката, призупинення хостингу через неоплачений рахунок, заповнений диск.
3. Загляньте в логи: журнал помилок вебсервера й застосунку саме на момент збою. Більшість помилок 500 пояснюються там.
4. Відкотіть останню зміну: оновлення плагіна, деплой, правку конфігурації. Спершу відкат, потім розслідування.
5. Перезапустіть служби (вебсервер, PHP-FPM, базу даних), якщо вони зависли, — і потім з’ясуйте чому.
6. Напишіть хостеру з конкретикою: час, адреса, код відповіді, текст помилки.

Щоб дізнаватися про проблему раніше за відвідувачів, налаштуйте моніторинг доступності: зовнішню перевірку що кілька хвилин зі сповіщенням на пошту чи в месенджер. Окремо поставте нагадування про закінчення сертифіката й домену — це найпростіше відвернути з усіх падінь.