Как проверить доступность сайта

Фраза «сайт не работает» слишком общая. Проблема может находиться в домене, DNS, IP-адресе, маршруте, закрытом порту, TLS, HTTP, CDN, reverse proxy или самом приложении.

Поэтому правильная проверка доступности сайта — это не одна команда и не один HTTP-код, а последовательная диагностика всех уровней соединения.

В этом руководстве разберём, как понять, где именно произошёл сбой, почему сайт может открываться у владельца и не открываться у пользователей, как отличить DNS-проблему от ошибки сервера и какие команды использовать для быстрой диагностики.

Что значит «сайт доступен»

Для обычного пользователя сайт считается доступным, если браузер может:

1. найти домен;
2. получить IP;
3. подключиться к серверу;
4. установить TLS для HTTPS;
5. получить HTTP-ответ;
6. загрузить приложение или страницу.

Сбой на любом этапе может выглядеть как «сайт не открывается».

Главная схема диагностики

Domain
  ↓
DNS
  ↓
IP
  ↓
Network route
  ↓
TCP
  ↓
TLS
  ↓
HTTP
  ↓
Application

Именно в таком порядке удобнее искать проблему.

Шаг 1. Проверить сам домен

Сначала убедитесь, что проблема не связана с регистрацией домена.

Проверьте:

• домен существует;
• срок регистрации не истёк;
• нет критических статусов;
• NS назначены ожидаемые.

Для этого пригодится WHOIS/RDAP.

Шаг 2. Проверить DNS

Если домен зарегистрирован, нужно определить, какие адреса он возвращает.

IPv4:

dig +short example.com A

IPv6:

dig +short example.com AAAA

NS:

dig +short example.com NS

Что искать в DNS

Типовые проблемы:

• A указывает на старый сервер;
• AAAA указывает не туда;
• у домена нет нужной записи;
• редактируется неправильная DNS-зона;
• NS не соответствуют текущему провайдеру;
• старый ответ остаётся в кеше.

Почему сайт может работать у одного человека и не работать у другого

Причин много:

• разные DNS-резолверы;
• разный кеш;
• IPv4 против IPv6;
• разные маршруты;
• региональная фильтрация;
• CDN;
• провайдерские проблемы;
• локальный браузерный кеш.

Шаг 3. Проверить IP

После DNS важно убедиться, что найденный IP действительно ожидаемый.

Если сайт недавно переносили, сравните текущий адрес с новым сервером.

Проверить адрес можно через NexIP IP Lookup.

Шаг 4. Проверить маршрут

Если IP правильный, но соединение не устанавливается, можно проверить путь до сервера.

Linux/macOS:

traceroute 203.0.113.10

Windows:

tracert 203.0.113.10

Но отсутствие ответа от промежуточного узла не всегда означает сбой: маршрутизаторы могут не отвечать на диагностические пакеты.

Что показывает ping

ping example.com

Ping помогает проверить ICMP-доступность, но это не полноценная проверка сайта.

Сервер может блокировать ICMP и при этом нормально отвечать по HTTPS.

Почему ping — не доказательство работы сайта

Возможны обе ситуации:

• ping проходит, но HTTP не работает;
• ping не проходит, но HTTPS работает.

Поэтому ping нужно использовать только как один из сигналов.

Шаг 5. Проверить TCP-порт

Для HTTPS нужен порт 443.

nc -vz example.com 443

Для HTTP:

nc -vz example.com 80

Если TCP-соединение не устанавливается, проблема может быть в:

• firewall;
• маршруте;
• сервере;
• закрытом порту;
• security group;
• провайдерской фильтрации.

Шаг 6. Проверить TLS

Для HTTPS недостаточно открытого TCP/443.

Нужно успешно установить TLS-соединение.

openssl s_client \
  -connect example.com:443 \
  -servername example.com

Проверьте:

• сертификат;
• hostname;
• цепочку;
• срок действия;
• TLS handshake.

Шаг 7. Проверить HTTP

Самый простой вариант:

curl -I https://example.com/

Пример:

HTTP/2 200
content-type: text/html
server: nginx

Что означает HTTP 200

200 OK обычно означает, что сервер успешно обработал запрос.

Но даже код 200 не всегда гарантирует, что приложение работает правильно: страница может возвращать 200 и при этом содержать сообщение об ошибке.

Что означают 301 и 302

Это перенаправления.

Проверить всю цепочку:

curl -IL https://example.com/

Так можно увидеть, куда реально переходит пользователь.

Что означает 403

403 Forbidden означает, что сервер понял запрос, но отказывает в доступе.

Причинами могут быть:

• правила доступа;
• WAF;
• IP-блокировка;
• GeoIP-фильтр;
• ошибка конфигурации веб-сервера.

Что означает 404

404 Not Found означает, что запрошенный ресурс не найден.

Если главная страница отдаёт 404 после переноса, возможно, запрос попадает не в тот virtual host или приложение.

Что означает 429

429 Too Many Requests означает ограничение частоты запросов.

Причина может быть в:

• rate limit;
• WAF;
• API gateway;
• защите от ботов.

Что означает 500

500 Internal Server Error — внутренняя ошибка приложения или серверной логики.

DNS и TLS при этом могут работать полностью нормально.

Что означает 502 Bad Gateway

502 часто появляется, когда reverse proxy не может получить корректный ответ от upstream.

Например:

Nginx
  ↓
PHP-FPM / application
  ↓
error

Что означает 503

503 Service Unavailable означает временную недоступность сервиса.

Причины:

• maintenance;
• перегрузка;
• отсутствие здоровых backend-узлов;
• ошибка приложения.

Что означает 504 Gateway Timeout

504 означает, что proxy или gateway не дождался ответа upstream за допустимое время.

Чаще это уже проблема backend или связности между компонентами.

Как получить подробную диагностику curl

curl -v https://example.com/

Verbose-режим помогает увидеть:

• DNS;
• IP;
• TCP;
• TLS;
• HTTP-заголовки;
• redirect;
• ошибки соединения.

Как измерить время ответа

curl -o /dev/null -s \
  -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\nTotal: %{time_total}\n' \
  https://example.com/

Это помогает понять, где возникает задержка.

Как проверить конкретный IP без изменения DNS

curl -I \
  --resolve example.com:443:203.0.113.10 \
  https://example.com/

Это особенно полезно перед переключением DNS на новый сервер.

Как проверить IPv4 отдельно

curl -4 -I https://example.com/

Как проверить IPv6 отдельно

curl -6 -I https://example.com/

Если IPv4 работает, а IPv6 нет, проверьте AAAA и IPv6-инфраструктуру.

Почему сайт может работать дома и не работать с мобильной сети

Возможные причины:

• IPv4/IPv6;
• разные DNS;
• маршрутизация;
• фильтрация;
• GeoIP;
• CDN;
• разные кеши.

Почему сайт работает через мобильную сеть, но не через Wi-Fi

Тогда особенно полезно сравнить:

• DNS-ответ;
• публичный IP клиента;
• маршрут;
• IPv6;
• локальный роутер;
• DNS провайдера.

Почему сайт открывается у владельца из кеша

Браузер может показывать ранее загруженный контент, service worker или локальный кеш.

Поэтому внешняя проверка важнее простого обновления страницы на своём компьютере.

CDN и доступность сайта

При использовании CDN пользователь может подключаться не к origin напрямую, а к edge-узлу.

Тогда сбой может находиться:

• между пользователем и CDN;
• на edge;
• между CDN и origin;
• на origin.

Reverse proxy и load balancer

Сайт может иметь архитектуру:

User
 ↓
CDN
 ↓
Load Balancer
 ↓
Nginx
 ↓
Application
 ↓
Database

Ошибка любого элемента может выглядеть как недоступность сайта.

Почему важно проверять сайт извне

Локальная проверка с самого сервера может быть успешной даже при проблемах:

• DNS;
• firewall;
• маршрута;
• CDN;
• внешнего TLS;
• балансировщика.

Поэтому NexIP полезен именно как внешний наблюдатель.

Как проверить доступность через NexIP

Инструмент проверки сайта NexIP позволяет быстро увидеть внешний результат.

Полезно анализировать:

• HTTP status;
• конечный URL;
• redirect;
• время ответа;
• HTTPS;
• основные сетевые признаки.

Если результат выглядит подозрительно, переходите к специализированным инструментам DNS, SSL, Headers и IP Lookup.

Правильный порядок диагностики

1. WHOIS/RDAP.
2. NS.
3. A и AAAA.
4. IP.
5. Маршрут.
6. TCP/80 и TCP/443.
7. TLS.
8. HTTP status.
9. Redirect.
10. HTTP headers.
11. Application logs.
12. Backend и database.

Что сохранить перед обращением в поддержку

Если проблема повторяется, сохраните:

• точное время;
• URL;
• HTTP status;
• IP;
• результат DNS;
• ошибку TLS;
• скриншот;
• публичный IP клиента;
• провайдера;
• результат из другой сети.

Это значительно ускоряет поиск причины.

Типовые сценарии

DNS не возвращает IP

Проверяйте зону, NS и регистрацию домена.

DNS правильный, порт закрыт

Проверяйте firewall, сервер и маршрутизацию.

TCP работает, TLS нет

Проверяйте сертификат, SNI и TLS-конфигурацию.

TLS работает, HTTP 500

Проблема уже на уровне приложения.

HTTP 502

Проверяйте reverse proxy и upstream.

HTTP 504

Проверяйте timeout и производительность backend.

Работает только IPv4

Проверяйте AAAA и IPv6.

Связанные материалы

DNS подробно разобран в руководстве по DNS.

HTTPS и сертификаты — в статье про SSL/TLS.

Следующий отдельный материал будет посвящён HTTP-заголовкам и их диагностике.

Что важно запомнить

• «Сайт не работает» — это не диагноз.
• Проверяйте систему по уровням.
• Ping не заменяет HTTP-проверку.
• DNS может быть исправен при сломанном сервере.
• TCP может работать при сломанном TLS.
• TLS может работать при HTTP 500.
• IPv4 и IPv6 нужно сравнивать отдельно.
• CDN и reverse proxy усложняют диагностику.
• Внешняя проверка важнее локальной.
• NexIP должен помогать быстро определить уровень сбоя.

FAQ

Как быстро понять, работает ли сайт?

Начните с внешней HTTP-проверки. Если она неуспешна, последовательно проверяйте DNS, TCP, TLS и HTTP.

Если ping проходит, сайт работает?

Не обязательно. Ping проверяет ICMP, а веб-сайт требует TCP, TLS и HTTP.

Если сайт отдаёт 200, он точно исправен?

Не всегда. Приложение может вернуть страницу ошибки с кодом 200.

Почему сайт работает у меня, но не у клиента?

Сравните DNS, IPv4/IPv6, сеть, кеш, GeoIP и маршрут.

Как проверить новый сервер до смены DNS?

Используйте curl --resolve с нужным IP.

Что сначала проверять при 502?

Reverse proxy, upstream, сокет или порт backend и журналы приложения.

Что сначала проверять при 504?

Время ответа backend, timeout proxy и связность между компонентами.

Зачем проверять из внешнего сервиса?

Потому что локальный сервер или браузер не всегда видит проблемы публичного DNS, маршрута, CDN и внешнего TLS.