Что такое географическая недоступность сайта
Коротко о задаче
Иногда мониторинг показывает, что сайт доступен, а заявки в почту поступают с жалобой: «у нас не открывается». Внешне это выглядит как будто проблема «в воздухе». На практике нужно пройти чек‑лист, чтобы не пропустить источник инцидента и не тратить время на догадках.
Что сделать прямо сейчас
Начните с конкретного адреса, на котором клиент увидел ошибку: страницы услуги, формы заявки, корзины, оплаты или входа. Вставьте этот URL во внешнюю проверку Web-Puls, а не ограничивайтесь главной страницей. Сервис покажет HTTP-код, время ответа и базовую диагностику.
Затем откройте тот же адрес с телефона через мобильную сеть и сравните результаты, полученные примерно в одно время. Зафиксируйте четыре факта:
- точный URL и время проверки;
- сеть или регион, где возникла ошибка;
- HTTP-код, TLS-ошибку или таймаут;
- что менялось перед сбоем: DNS, CDN, сертификат, хостинг или релиз.
Матрица доказательств географического сбоя
Не называйте проблему географической только по одному скриншоту или проверке через случайный VPN. Сравните один URL в близкое время и запишите наблюдения по слоям:
| Слой | Что сравнить между рабочей и проблемной сетью | Что считать значимым расхождением | |---|---|---| | DNS | IP-адреса для домена, используемый DNS-резолвер, ответы для www и основного домена | одна сеть стабильно получает старый, чужой или отсутствующий адрес | | TLS и CDN | имя и срок сертификата, результат HTTPS-соединения, код или challenge от CDN/WAF | только проблемная сеть получает ошибку сертификата, 403, 429 или защитную страницу | | HTTP и контент | конечный URL, код ответа, наличие формы или контрольного текста | код или содержимое повторяемо отличаются для одного и того же адреса | | Маршрут | точка, после которой прекращается трасса, провайдер и время проверки | сбой повторяется у нескольких пользователей с общим провайдером или направлением маршрута |
Для заявки или внутреннего инцидента используйте короткую запись: время — URL — сеть/регион — DNS/IP — TLS — HTTP-код — конечный URL — что увидел пользователь. Такой формат позволяет сопоставить жалобу с логами, а не начинать диагностику заново.
Дальнейшее действие зависит от результата:
- Если внешняя проверка и мобильная сеть открывают страницу, но жалобы повторяются, посмотрите, как работает мониторинг доступности, и поставьте критичный URL на постоянный контроль.
- Если одна сеть получает ошибку, а другая — нормальную страницу, сравните DNS-ответы, конечный IP, сертификат и маршрут.
- Если расхождение уже мешает заявкам или продажам, передайте URL, время и ошибку через форму оценки. Этих данных достаточно для первого разбора.
Форма быстрой проверки внизу статьи требует только адрес сайта. Она отвечает на вопрос «что получает внешняя точка сейчас». Для разбора плавающей или региональной проблемы нужна история повторных проверок либо заявка с зафиксированными симптомами.
Что считать симптомом реальной проблемы
Симптом «у меня открывается, у клиентов нет» не означает автоматически «сайт упал навсегда». Он означает: нужно проверить путь клиента от DNS до страницы.
Лучше всего разбить диагностику на 4 слоя:
- Сеть и DNS — домен действительно резолвится в тот IP, который вы ожидаете.
- SSL и CDN/прокси — сертификат и промежуточные узлы не режут трафик из части сегментов.
- Обработчик страницы — HTTP-код и тело страницы для разных запросов.
- Логи и время — когда началось, была ли это единичная вспышка или повторяющийся паттерн.
Именно такая последовательность помогает быстро отличить локальную ошибку клиента, разовый сетевой сбой и проблему на стороне сайта.
1) Проверка DNS и маршрута как первого шага
Если домен не разрешается, часть пользователей инициализирует другое поведение: браузер уходит в таймаут или на старые адреса.
Как проверить быстро
- Отправьте проверку домена в разные инструменты, например через публичный DNS и внутренний маршрут.
- Сравните IP для разных регионов/сетей.
- Если IP отличается и часть сети видит «чужой» адрес, сразу проверяйте зону и настройки провайдеров DNS.
Если сотрудники из офиса видят новый сайт, а пользователи внешнего провайдера попадают на старый IP, сравните DNS-ответы и TTL. Такое расхождение после переноса или смены DNS сужает поиск до кеша резолвера, зоны и маршрута к нужному серверу.
2) SSL, прокси и промежуточные слои
Даже при корректном DNS сайт может открываться только в части сценариев, если проблема в цепочке HTTPS.
Что смотреть в таком случае
- Какой сертификат выдает соединение в проблемной точке и совпадает ли домен.
- Нет ли смешанного содержания (HTTP-ресурсы внутри HTTPS-страницы).
- Нет ли правил у CDN/хостинга, которые отличаются по зонам.
Сервер может отвечать, но браузер клиента остановит загрузку ещё до получения HTML из-за TLS-ошибки. Поэтому нормальный ответ в одном браузере не отменяет отдельную проверку сертификата и цепочки HTTPS из проблемной сети.
3) HTTP-код и содержимое страницы: не только «доступен/не доступен»
Ключевой момент: код 200 не означает, что пользователь получил нужный результат.
Мини-чеклист контента
- Для страницы важного действия убедитесь, что ключевые элементы присутствуют.
- Проверьте наличие служебных страничек, которые могли подставиться после ошибки.
- Откройте путь запроса клиента, а не только главную.
Например, кешированная главная страница отвечает 200 OK, а страница заявки возвращает 504 или показывает заглушку обслуживания. Сайт технически доступен, но целевой сценарий уже не работает.
4) Как зафиксировать инцидент и не терять время на «догадки»
Полезно иметь небольшую таблицу инцидента:
- время первого симптома;
- IP/регион/тип сети клиента;
- код ответа и заметные изменения на странице;
- какие действия уже выполнены.
Даже простая запись снижает хаос: вы уже видите, что это повторяется в одном провайдере и после него можно отфильтровать гипотезы.
Три типовых сценария и следующий шаг
Сайт после переноса. В офисе домен уже ведёт на новый сервер, а часть клиентов получает старый IP или ошибку сертификата. Сравните DNS из рабочей и проблемной сети, проверьте варианты с www и без www, затем контролируйте оба адреса до окончания TTL.
Лендинг с заявками. Главная открывается, но из мобильной сети не загружается форма или исчезает текст рядом с кнопкой. Проверьте именно URL лендинга, отправку формы и наличие стабильного контрольного текста. Если код 200, но целевого блока нет, это всё равно инцидент.
Сайт за CDN или WAF. Владелец видит страницу, а клиенты из части сетей получают 403, 429, challenge или таймаут. Сопоставьте время жалобы с логами CDN/WAF и правилами по IP, стране, ASN и частоте запросов. В заявку провайдеру передавайте URL, время, код и проблемную сеть.
Когда включать автоматический мониторинг и почему это работает
Разовая проверка показывает состояние страницы сейчас, но не поймает короткий сбой между ручными проверками. Автоматический мониторинг сохраняет время ошибки и восстановления, поэтому его результат можно сопоставить с жалобами клиентов и изменениями инфраструктуры.
Для типовой практики подойдет схема:
- базовая проверка доступности и DNS;
- отдельная проверка HTTPS;
- контроль ключевой страницы с формой/поиском/корзиной;
- уведомления о падениях и восстановлении.
Если нужен технический разбор цепочки, укажите симптомы, временной интервал и последний релиз сайта в форме оценки. Когда причина уже понятна и нужен только постоянный контроль, добавьте критичный URL в мониторинг Web-Puls.
Сравните с похожими сценариями
Если проблема зависит именно от региона или сети, сравните проверку недоступности в одном регионе и частичную недоступность сайта. Для общего случая, когда жалоба пришла от одного клиента, начните с более широкого чек-листа сайт открывается у вас, но не у клиентов.
Для настройки постоянного контроля также пригодятся:
Вывод
Когда у части клиентов сайт «не грузится», не надо сразу искать одну единственную причину. Сначала зафиксируйте слой: DNS → SSL → HTTP/контент → история времени, затем принимайте решение. Такой порядок снижает ложные гипотезы и ускоряет восстановление.
Сначала проверьте конкретный проблемный URL, затем выберите следующий шаг: повторные ручные проверки для единичной жалобы, постоянный мониторинг для важной страницы или диагностика, если сбой уже влияет на заявки и продажи.