Сайт не работает у всех или только у меня: как проверить

Когда сайт не открывается, первый вопрос обычно звучит так: сайт не работает у всех или только у меня? От ответа зависит всё остальное. Если проблема глобальная, нужно смотреть сервер, DNS, CDN, SSL, приложение и инфраструктуру. Если локальная — браузер, провайдера, корпоративную сеть, VPN, кэш DNS или настройки устройства.

Быстро понять масштаб сбоя можно без доступа к серверу: проверить сайт из другой сети, посмотреть HTTP-статус, выполнить DNS-запрос, открыть страницу через внешний сервис проверки доступности. Но важно не ограничиваться одним сигналом: сайт может быть доступен из Москвы и недоступен из Европы, открываться по IPv4 и падать по IPv6, отдавать главную страницу, но ломаться на API или авторизации.

Ниже — практический порядок проверки: от простых действий для владельца сайта или пользователя до команд, которые пригодятся разработчику и devops-инженеру.

Что означает «сайт не работает у всех или только у меня»

Фраза «сайт не работает» слишком общая. Для диагностики нужно уточнить, что именно происходит.

1) Сайт вообще не открывается — браузер показывает ERR_CONNECTION_TIMED_OUT, ERR_CONNECTION_REFUSED, DNS_PROBE_FINISHED_NXDOMAIN, ERR_NAME_NOT_RESOLVED или похожую сетевую ошибку. Это может быть DNS, сеть, фаервол, недоступный сервер или ошибка маршрутизации.

2) Сайт открывается, но показывает ошибку — например, 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout, 403 Forbidden. Домен и сеть в этом случае чаще всего работают, а проблема — на уровне веб-сервера, приложения, прокси, CDN или прав доступа.

3) Сайт открывается частично — грузится HTML, но не работают картинки, стили, JavaScript, личный кабинет, оплата, поиск или API. Внешне это выглядит как «сайт сломан», хотя главная страница отвечает 200 OK.

4) Сайт медленно открывается — формально он доступен, но загрузка занимает десятки секунд или заканчивается таймаутом. Для пользователя это почти то же самое, что простой. Причина может быть в базе данных, перегрузе backend-сервиса, сети, CDN или проблемах у провайдера.

5) Сайт недоступен только из части регионов — типичный сценарий для проблем с CDN, DNS anycast, региональной блокировкой, маршрутизацией, IPv6 или настройками WAF.

Поэтому вопрос «у всех или только у меня» лучше переформулировать так: из каких сетей, регионов, устройств и по каким протоколам сайт доступен, а где ломается.

Быстрая проверка за 2 минуты

Если нужно быстро понять масштаб проблемы, идите от простого к точному.

1) Откройте сайт в другом браузере или режиме инкогнито — это исключает часть проблем с расширениями, cookies, устаревшим кэшем, service worker и авторизацией. Если в обычном режиме сайт не работает, а в инкогнито открывается, причина почти наверняка локальная.

2) Проверьте сайт с мобильного интернета — отключите Wi‑Fi и откройте сайт через LTE/5G. Если через домашний интернет сайт не открывается, а через мобильную сеть работает, проблема может быть у провайдера, в DNS-резолвере, роутере, корпоративном прокси или локальной блокировке.

3) Попросите коллегу открыть сайт из другой сети — особенно полезно для коммерческого сайта, интернет-магазина или SaaS. Один внешний тест из независимой сети часто быстрее любых догадок.

4) Посмотрите статус-код через curl — команда curl -I https://example.com покажет HTTP-заголовки и код ответа. 200, 301, 302 означают, что сервер отвечает. 500, 502, 503, 504 — проблема уже не «интернет не дошёл», а в обработке запроса. Подробнее о работе с этим инструментом — в материале что такое curl и как им пользоваться.

5) Проверьте без HTTPS и с HTTPS — сравните http://example.com и https://example.com. Бывает, что HTTP открывается, а HTTPS падает из-за сертификата, SNI, TLS-настроек или редиректа.

6) Уточните, ломается ли весь домен или конкретная страница — главная может работать, а /login, /api/orders или /admin возвращать ошибку. Для пользователя это «сайт не работает», для инженера — разные зоны расследования.

Если после этих шагов сайт не открывается в нескольких независимых сетях, вероятность глобальной проблемы высокая. Если сбой видите только вы — переходите к проверке локального устройства и сети.

Проверка из разных сетей, стран и точек доступа

Один успешный или неуспешный запрос ничего не доказывает. Интернет неоднороден: разные провайдеры используют разные маршруты, DNS-резолверы, пиринг, фильтрацию и кэши.

1) Проверяйте минимум из двух сетей — домашний интернет и мобильная сеть, офис и домашний Wi‑Fi, VPN и прямое подключение. Если результаты разные, это важный диагностический сигнал.

2) Смотрите географию — сайт может быть доступен в России, но недоступен из Германии; работать из Москвы, но не открываться из Новосибирска; отвечать из одной CDN-точки и падать из другой. Отдельная проверка доступности из разных стран разобрана в статье как проверить доступность сайта из разных стран.

3) Учитывайте CDN и балансировщики — если сайт работает через Cloudflare, DDoS-Guard, Fastly, Akamai или другой CDN, разные пользователи могут попадать на разные edge-узлы. Один узел может быть здоров, другой — нет.

4) Проверяйте IPv4 и IPv6 отдельно — если у домена есть AAAA-запись, часть пользователей пойдёт по IPv6. Ошибка в IPv6-маршрутизации часто выглядит странно: у одних сайт работает, у других висит до таймаута. Проверить можно так: curl -4 -I https://example.com и curl -6 -I https://example.com.

5) Отключите VPN и прокси — VPN может как исправить проблему, так и создать её. Если сайт работает только через VPN, возможна региональная фильтрация, проблема маршрута или блокировка провайдера. Если не работает только через VPN — смотрите IP-репутацию, WAF, антифрод и правила доступа.

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

DNS: проверяем, куда указывает домен

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

Проверьте домен через dig:

dig example.com A

dig example.com AAAA

dig example.com NS

dig example.com CNAME

Если A или AAAA не возвращают IP-адрес, браузер не сможет понять, куда подключаться. Если возвращается старый IP, часть пользователей может попадать на старый сервер. Если CNAME указывает на несуществующий домен, сайт тоже перестанет открываться. Подробная диагностика DNS-записей описана в статье про утилиту dig.

На что смотреть в первую очередь:

1) NXDOMAIN — домен не найден. Возможные причины: домен истёк, зона удалена, ошибочно изменены NS-серверы, опечатка в имени.

2) SERVFAIL — DNS-сервер не смог ответить корректно. Часто связано с проблемами у авторитативных DNS-серверов, DNSSEC или неправильной конфигурацией зоны.

3) Разные ответы у разных резолверов — сравните системный DNS, 8.8.8.8, 1.1.1.1 и DNS провайдера: dig @8.8.8.8 example.com A и dig @1.1.1.1 example.com A.

4) Старые записи после миграции — если недавно переносили сайт на другой сервер или меняли CDN, часть пользователей может ещё попадать на старый IP из-за TTL и промежуточных кэшей.

5) Ошибки в www и корневом домене — example.com и www.example.com — разные имена. Один может работать, второй нет. Проверьте оба варианта.

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

HTTP и HTTPS: что отвечает сервер

Когда DNS работает и IP найден, следующий слой — соединение и HTTP-ответ. Здесь важно отличать «сервер недоступен» от «сервер доступен, но приложение возвращает ошибку».

Начните с простого запроса:

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

Флаг -I запрашивает только заголовки, -L следует за редиректами. В ответе смотрите код статуса, цепочку редиректов, заголовки CDN, сервер и время ответа.

1) 200 OK — страница отвечает успешно. Если при этом браузер показывает ошибку, ищите проблему в фронтенде, кэше, cookies, JavaScript, mixed content или конкретном пользовательском сценарии.

2) 301 или 302 — редирект. Сам по себе нормален, но цепочка может быть сломана. Если браузер показывает ERR_TOO_MANY_REDIRECTS, проверьте правила редиректа в Nginx, приложении, CDN и настройках HTTPS.

3) 403 Forbidden — доступ запрещён. Это может быть WAF, геоблокировка, IP-блокировка, неправильные права на файлы, закрытый раздел или ошибка конфигурации.

4) 404 Not Found — сервер доступен, но конкретный путь не найден. Если главная работает, а страница нет, это не глобальный простой сайта.

5) 500 — ошибка приложения или backend-сервера. Смотрите логи приложения, исключения, подключение к базе данных, переменные окружения, релиз и зависимости.

6) 502, 503, 504 — часто проблема между прокси и upstream: Nginx не может достучаться до приложения, backend перегружен, контейнер упал, балансировщик не видит здоровых инстансов, запросы упираются в таймаут. Подробнее о конкретных кодах — в материалах про 502 Bad Gateway, 503 Service Unavailable и 504 Gateway Timeout.

Отдельно проверьте TLS. Если сертификат истёк, выпущен не на тот домен, не совпадает цепочка доверия или сервер не поддерживает нужный протокол, часть клиентов может не открыть сайт. Особенно это заметно на старых устройствах, корпоративных прокси и при ошибках в SNI.

Как понять, что проблема локальная

Если сайт открывается у коллег, через мобильный интернет и во внешних проверках, но не открывается у вас, почти наверняка причина на вашей стороне. Это не значит, что проблема несерьёзная: локальные сбои тоже мешают работе, особенно если затрагивают офис, корпоративную сеть или клиентов одного провайдера.

Проверьте следующие варианты.

1) Кэш браузера и cookies — откройте сайт в инкогнито, очистите данные сайта, отключите расширения. Иногда старый service worker продолжает обслуживать сломанную версию приложения.

2) DNS-кэш устройства — операционная система может помнить старый IP. На Windows выполните ipconfig /flushdns, на macOS очистите кэш через dscacheutil и mDNSResponder, на Linux способ зависит от резолвера: systemd-resolved, dnsmasq, nscd.

3) Файл hosts — проверьте, нет ли записи для домена в /etc/hosts на Linux/macOS или C:\Windows\System32\drivers\etc\hosts на Windows. Старые записи после тестового стенда часто приводят к загадочным проблемам.

4) Роутер и провайдерский DNS — перезагрузите роутер, смените DNS на публичный резолвер, проверьте сайт через другую сеть. Если проблема исчезла, виноват не сайт.

5) VPN, прокси, антивирус, корпоративный фильтр — они могут подменять сертификаты, блокировать домены, резать WebSocket-соединения или запрещать отдельные категории сайтов.

6) Локальное время на устройстве — если дата и время сильно неверные, HTTPS-сертификаты могут считаться недействительными.

7) Блокировка по IP — ваш IP мог попасть в denylist на WAF, fail2ban, CDN или серверном фаерволе. Признаки: сайт не работает только с одного подключения, но открывается через мобильную сеть или VPN.

Для пользовательской диагностики полезен общий чеклист что делать, если не открывается сайт — он помогает пройти базовые причины без доступа к инфраструктуре.

Если это ваш сайт: где искать причину глобального сбоя

Если проверки показывают, что сайт недоступен не только у вас, переходите к инфраструктуре. Здесь лучше не гадать, а идти по слоям: DNS → сеть → веб-сервер → приложение → база данных → внешние зависимости.

1) Проверьте хостинг или сервер — доступен ли сервер по SSH, отвечает ли IP на ping, открыт ли порт 80/443, нет ли аварии у провайдера. Если SSH тоже недоступен, смотрите панель хостинга, консоль VPS, статус дата-центра, фаервол и оплату услуг.

2) Проверьте веб-сервер — Nginx, Apache, Caddy или другой reverse proxy должен быть запущен и слушать нужные порты. Часто начинают с systemctl status nginx, systemctl status apache2, ss -lntp и проверки логов.

3) Проверьте приложение — Node.js, Python, Go, PHP-FPM, Java-сервис или контейнер могли упасть после релиза, исчерпать память, зависнуть на подключении к базе или уйти в бесконечные ретраи. Смотрите process manager, orchestrator, health checks и application logs.

4) Проверьте базу данных и кэш — сайт может отдавать 500 или 504, если недоступны PostgreSQL, MySQL, Redis, Elasticsearch, S3-совместимое хранилище или очередь сообщений.

5) Проверьте место на диске — переполненный диск ломает запись логов, сессии, загрузки файлов, работу базы данных и временные файлы. Это частая причина внезапных сбоев.

6) Сравните с последними изменениями — релиз, миграция базы, обновление пакетов, изменение DNS, перевыпуск сертификата, новая настройка WAF, изменение firewall rules. Если сбой начался после изменения, сначала проверяйте его.

7) Смотрите логи по времени инцидента — веб-сервер, приложение, systemd journal, база данных, CDN, балансировщик. Если к моменту расследования всё уже восстановилось, логи и метрики становятся главным источником фактов.

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

Как узнавать о сбое раньше пользователей

Ручная проверка хороша для разового вопроса «сайт не работает у всех или только у меня», но не заменяет постоянный контроль. Проблема может начаться ночью, затронуть только один регион, длиться пять минут и исчезнуть до того, как инженер откроет ноутбук.

Минимальный набор для владельца сайта:

1) Проверка главной страницы — мониторинг делает HTTP-запрос к сайту и проверяет, что ответ пришёл вовремя и имеет ожидаемый статус, например 200 OK.

2) Проверка важных URL — главная страница не всегда показатель. Отдельно стоит проверять /login, /checkout, /api/health, страницу оплаты, личный кабинет или другой критичный путь.

3) Проверка HTTPS-сертификата — сертификат может истечь или перестать корректно обновляться. Для пользователя это выглядит как опасное предупреждение браузера или полный отказ открыть сайт.

4) Уведомления — если проверка падает несколько раз подряд, сервис должен отправить алерт в Telegram, email, Slack или другой канал. Statuser, например, проверяет сайт с заданным интервалом и присылает уведомление о сбое, чтобы команда увидела проблему раньше клиентов.

5) История инцидентов — важно знать не только факт падения, но и время начала, длительность, частоту повторов и восстановление. Это помогает отличать случайный сетевой сбой от системной проблемы.

6) Проверка из разных точек — снижает риск ложных выводов. Если ошибка видна только с одной проверочной точки, это может быть проблема маршрута или временный сетевой сбой. Если падают несколько точек — инцидент вероятнее на стороне сайта.

Если вы только выбираете подход к проверкам, начните с базовой темы что такое uptime monitoring и как он работает. Для практической настройки доступности пригодятся инструкции по проверке доступности сайта.

Короткий алгоритм диагностики

Чтобы не прыгать между гипотезами, используйте один и тот же порядок.

1) Зафиксируйте симптом — что именно видит пользователь: код ошибки, текст в браузере, URL, время, сеть, устройство, регион.

2) Проверьте из другой сети — мобильный интернет, VPN, коллега, внешний сервис проверки доступности.

3) Проверьте DNS — есть ли A/AAAA, совпадают ли ответы у разных резолверов, нет ли NXDOMAIN или SERVFAIL.

4) Проверьте HTTP-ответ — curl -I -L https://example.com, статус-код, редиректы, заголовки, время ответа.

5) Сравните HTTP и HTTPS, IPv4 и IPv6 — так можно быстро найти проблемы сертификата, редиректа или IPv6.

6) Если проблема локальная — чистите кэш, проверяйте DNS, VPN, hosts, роутер и провайдера.

7) Если проблема глобальная — смотрите сервер, reverse proxy, приложение, базу данных, CDN, логи и последние изменения.

Главная цель — быстро определить границу ответственности. «Только у меня» ведёт к локальной сети и устройству. «У всех» — к инфраструктуре сайта. «У части пользователей» — к DNS, регионам, CDN, провайдерам, IPv6, WAF и маршрутизации.

FAQ

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

Частые причины: разные DNS-кэши, региональная проблема CDN, блокировка по IP, IPv6, корпоративный прокси, VPN, провайдерская фильтрация или WAF. Попросите клиента прислать ошибку, регион, провайдера и результат проверки через другую сеть.

Если ping не проходит, значит сайт упал?

Не обязательно. Многие серверы и CDN блокируют ICMP, поэтому ping может не отвечать при полностью рабочем сайте. Для веб-сайта полезнее проверять curl -I https://example.com и доступность портов 80/443.

Сайт отдаёт 200 OK, но пользователь говорит, что он не работает. Почему?

200 OK для главной страницы не гарантирует, что работают авторизация, API, оплата, JavaScript, изображения и личный кабинет. Проверяйте конкретный URL и сценарий, который сломан у пользователя.

Как часто нужно проверять доступность сайта?

Зависит от критичности проекта. Для важных коммерческих сайтов обычно выбирают короткий интервал, для менее критичных — более редкий. Главное — проверять не только главную страницу, но и ключевые пользовательские сценарии.