Иногда владелец сайта открывает главную страницу и видит, что все работает, а клиенты из другого города пишут: сайт не загружается, форма не открывается, вместо каталога появляется ошибка. В такой ситуации легко спорить о браузерах и интернете, но правильнее быстро отделить локальную проблему пользователя от настоящей частичной недоступности сайта.
Частичная недоступность особенно неприятна тем, что она не всегда видна из офиса владельца. Сайт может отвечать из кеша, открываться через одного провайдера и падать через другого, работать рядом с сервером и ломаться на дальнем маршруте. Ниже разберем, почему так бывает, что проверить вручную и как настроить мониторинг, чтобы узнавать о проблеме раньше жалоб.
Почему сайт может работать не у всех
Когда сайт не открывается совсем, диагностика обычно понятна: проверяем домен, хостинг, сервер, SSL и код ответа. С региональной проблемой сложнее: часть пользователей видит сайт, а часть получает ошибку. Причина часто находится не в одной странице, а в цепочке между пользователем и сервером.
DNS отдает разные или устаревшие ответы
После переноса сайта, смены IP-адреса, подключения CDN или изменения DNS-записей разные резолверы могут некоторое время отдавать разные ответы. У владельца уже открывается новый сервер, а у клиента провайдер продолжает использовать старый кеш. Обратная ситуация тоже возможна: у администратора все работает за счет локального DNS, а публичные резолверы не находят домен или получают ошибочную запись.
Практический пример: интернет-магазин переехал на новый хостинг, но часть клиентов все еще попадает на старый IP, где уже отключена копия сайта. Владелец открывает сайт из офиса и видит новую версию, а покупатели из других сетей получают ошибку подключения. В такой ситуации нужно проверять не только браузер, но и фактический DNS-ответ для домена.
CDN или прокси ломается в одной точке сети
Если сайт использует CDN, WAF или внешний прокси, пользователь может подключаться не к вашему серверу напрямую, а к ближайшей точке сети провайдера CDN. Одна точка может временно отдавать ошибку, пока другая работает нормально. Поэтому владелец из одного региона видит сайт, а пользователь из другого получает 502, 503, таймаут или страницу ошибки CDN.
Здесь важно не делать быстрый вывод, что «хостинг лежит». Исходный сервер может быть доступен, но конкретная промежуточная точка не может до него достучаться, неправильно кеширует страницу или отклоняет запрос.
Маршрут до сервера нестабилен
Даже без CDN запрос проходит через несколько сетей. На маршруте могут быть потери, перегрузка, временная фильтрация или ошибка у магистрального оператора. Сайт в этом случае выглядит исправным при проверке с одного подключения и недоступным при проверке с другого.
Для владельца это неудобный сценарий: сервер не показывает явной аварии, панель хостинга может быть зеленой, но часть аудитории фактически не может дойти до сайта. Поэтому полезно проверять доступность снаружи, а не только с рабочего компьютера.
Разные страницы зависят от разных сервисов
Иногда пользователи говорят «сайт не работает», хотя главная открывается. Не работает каталог, поиск, форма заказа, личный кабинет, оплата или API. Для владельца главная страница может выглядеть нормальной, потому что она статическая или закешированная, а важное действие клиента зависит от базы данных, внешнего сервиса или отдельного backend-модуля.
Если жалобы приходят из конкретного региона, причина может быть смешанной: например, главная страница отдается CDN, а форма обращается к серверу напрямую и упирается в сетевой таймаут.
Как быстро понять, что проблема не только у одного пользователя
Сначала нужно собрать несколько независимых признаков. Один скриншот от клиента полезен, но его недостаточно для технического вывода.
Проверьте сайт так:
- откройте точный URL, на который жалуется пользователь, а не только главную страницу;
- проверьте сайт с другого подключения: мобильный интернет, домашняя сеть, рабочая сеть;
- используйте внешний инструмент, например проверку доступности сайта, чтобы получить взгляд не из вашего браузера;
- уточните у клиента город, провайдера, время ошибки и текст сообщения в браузере;
- посмотрите статус-страницы хостинга, DNS-провайдера, CDN и внешних сервисов, если они используются;
- проверьте, меняется ли ошибка при открытии `https://` и `http://`, с `www` и без `www`, если эти варианты настроены.
Если проблема повторяется минимум с двух независимых подключений, ее уже нельзя списывать на кеш браузера конкретного пользователя. Даже если сайт открывается у вас, нужно продолжать диагностику как частичную недоступность.
Что проверить в DNS
DNS лучше проверять поэтапно. Задача не в том, чтобы найти «красивую» запись, а в том, чтобы понять, какой адрес реально получает пользователь.
A, AAAA и CNAME
Проверьте, куда указывает домен. Для обычного сайта важны A-запись и, если используется IPv6, AAAA-запись. Для сайтов через CDN часто используется CNAME на домен провайдера. Ошибка в любой из этих записей может привести к тому, что часть пользователей попадет не туда.
Пример ручной проверки:
```bash nslookup example.com nslookup www.example.com ```
Если `example.com` и `www.example.com` ведут себя по-разному, это отдельная подсказка. Один вариант может быть настроен на CDN, другой на старый сервер или вообще не иметь записи.
Авторитетные DNS-серверы
Важно отличать ответ публичного резолвера от настроек на авторитетных DNS-серверах домена. Если авторитетные серверы уже отдают правильный IP, а часть резолверов еще показывает старый, проблема похожа на кеш. Если авторитетные серверы сами отдают неверный ответ, нужно исправлять DNS-зону.
Для более глубокого разбора можно использовать `dig`:
```bash dig example.com A dig example.com CNAME dig +trace example.com ```
Команды нужны не для красоты отчета, а для сравнения: какой ответ видит ваш компьютер, публичный резолвер и цепочка DNS целиком.
Что проверить в CDN, SSL и сервере
Если DNS выглядит правильно, переходите к следующему слою.
CDN и кеш
В панели CDN проверьте, нет ли правил, которые отличаются для отдельных стран, путей или типов запросов. Иногда ошибка затрагивает не весь сайт, а только страницы с формами, API-запросы или файлы, которые не должны кешироваться. Также стоит временно сравнить ответ через CDN и напрямую на origin-сервер, если такая проверка предусмотрена вашей схемой и не ломает безопасность.
SSL-сертификат
SSL обычно воспринимается как единая настройка, но ошибка сертификата может проявляться по-разному. Например, один вариант домена покрыт сертификатом, а другой нет; старый домен ведет на другой сервер; промежуточная цепочка сертификата настроена некорректно. Для базовой проверки можно использовать проверку SSL-сертификата и отдельно открыть варианты с `www` и без `www`.
Код ответа и время ответа
Попросите технического специалиста или хостинг проверить код ответа снаружи. Важно видеть не только «открывается или нет», но и конкретный результат: 200, 301, 403, 404, 500, 502, 503, 504, таймаут или ошибка TLS. Разные коды ведут к разным причинам: от настроек доступа до перегруженного backend-сервера.
Какие данные собрать перед обращением в поддержку
Чем точнее вводные, тем быстрее можно найти причину. Не стоит отправлять в поддержку только фразу «сайт иногда не работает». Лучше подготовить короткий технический набор.
Соберите:
- точный URL проблемной страницы;
- время, когда ошибка была замечена;
- город или хотя бы страну пользователя;
- провайдера или тип подключения, если известно;
- текст ошибки в браузере;
- скриншот ошибки;
- результат проверки с другого подключения;
- DNS-ответы для домена и `www`;
- информацию о недавних изменениях: перенос хостинга, смена DNS, подключение CDN, обновление CMS, изменение SSL.
Если проблему нужно не только заметить, но и разобрать технически, можно отправить заявку через форму профессиональной поддержки или воспользоваться контактной информацией. Это особенно уместно, когда в цепочке есть DNS, SSL, CDN, хостинг или серверные ошибки.
Как автоматический мониторинг помогает не спорить с жалобами
Ручная проверка нужна для первичной диагностики, но она не заменяет регулярный контроль. Если сайт недоступен только части клиентов, владелец часто узнает об этом слишком поздно: когда уже есть обращения, потерянные заявки или проваленная рекламная кампания.
Автоматический мониторинг полезен тем, что он регулярно проверяет сайт снаружи и фиксирует результат во времени. Для владельца важны не только аварии «сайт полностью упал», но и более тихие признаки: выросло время ответа, важная страница стала отдавать ошибку, SSL скоро потребует внимания, домен начал открываться не так, как ожидается.
Чтобы не проверять сайт вручную, можно настроить автоматический мониторинг в Web-Puls. Он помогает регулярно контролировать доступность сайта и быстрее заметить, если проблема появилась не в вашем браузере, а на реальном пути пользователя к сайту.
Пример чеклиста для владельца интернет-магазина
Допустим, клиенты из одного региона жалуются, что не могут оформить заказ, а у администратора сайт работает. Последовательность действий может быть такой:
- Открыть не только главную, но и страницу товара, корзину, оформление заказа.
- Проверить сайт с мобильного интернета и через внешний инструмент.
- Сравнить домен с `www` и без `www`.
- Проверить DNS-записи и SSL для обоих вариантов домена.
- Посмотреть, не было ли недавно переноса сайта, смены CDN или обновления платежного модуля.
- Зафиксировать код ответа и время ошибки.
- Передать собранные данные хостингу, разработчику или специалисту поддержки.
- После исправления оставить мониторинг включенным, чтобы увидеть повтор проблемы, если она вернется.
Такой подход быстрее обычного спора «у меня открывается». Он переводит ситуацию в проверяемые факты: какой URL, где, когда и какой ответ отдает.
Вывод
Если сайт открывается в одном регионе и не открывается в другом, это не обязательно фантазия клиента и не всегда полное падение сервера. Причина может быть в DNS-кеше, CDN, маршруте, SSL, отдельной странице или внешнем сервисе. Проверяйте точный URL, сравнивайте несколько подключений, фиксируйте коды ответов и не ограничивайтесь главной страницей.
Главная задача владельца — быстрее понять масштаб проблемы. Ручная проверка помогает начать диагностику, а автоматический мониторинг снижает риск пропустить частичную недоступность, пока она уже мешает клиентам пользоваться сайтом.