Частичная недоступность легко создаёт спор: сотрудник открывает сайт, а клиент присылает ошибку. Оба наблюдения могут быть верными. Посетители используют разные DNS-резолверы, сети, версии протоколов и маршруты. При наличии CDN они могут обращаться и к разным промежуточным узлам.
Задача диагностики — сравнить условия успешного и неуспешного подключения. Не нужно сразу отключать защиту или менять сервер. Сначала сохраните точную ошибку, адрес, время с часовым поясом и сведения о сети. Это позволит отделить сбой соединения от отказа одной пользовательской операции.
Уточните, на каком этапе возникает ошибка
Спросите, открывается ли домен вообще, появляется ли предупреждение о сертификате или сервер возвращает страницу с кодом. Отдельно проверьте главную, нужный раздел и действие после входа. Если страница загружается, но кнопка не работает, причина может находиться в запросе приложения, а не в доступности сайта целиком.
Для первого сравнения достаточно другой сети, например мобильного интернета, и второго устройства. Запишите результат каждого теста. Не пересылайте пароль пользователя для воспроизведения: роль и тестовая учётная запись обычно безопаснее. Обязательные сведения можно собрать по примеру заявки в поддержку.
Сравните ответы DNS
Проверьте, какой адрес возвращает используемый резолвер и какие записи опубликованы у авторитетных серверов домена. После изменения адресов разные клиенты некоторое время могут видеть разные кешированные ответы. Снижение TTL одновременно с переключением не отменяет уже сохранённый старый срок.
Посмотрите не только A, но и AAAA, а также используемые CNAME. Ошибочная запись для IPv6 способна затронуть часть посетителей, хотя проверка только IPv4 будет успешной. При нескольких авторитетных серверах убедитесь, что сведения согласованы. Сохраните результаты с указанием источника, чтобы не спорить о разных ответах без контекста.
Проверьте оба семейства адресов
Если сайт публикует IPv6, на соответствующем адресе должны работать маршрутизация, веб-сервер, HTTPS и сетевые правила. Настройка IPv4 не распространяется автоматически на все остальные пути. Сравните соединение по каждому опубликованному адресу с сохранением правильного имени сайта.
Не удаляйте записи наугад ради одного успешного теста. Сначала выясните, используется ли адрес другими функциями и как настроен провайдер. При диагностике важно различать отсутствие маршрута, отказ соединения и ответ приложения. По этим признакам определяется следующий участок проверки, а не только список предполагаемых виновников.
Сверьте HTTPS и конфигурацию узлов
При нескольких адресах или балансировщиках один из узлов может отдавать старый сертификат или неверный виртуальный хост. Проверьте доменное имя, цепочку и срок на каждом публичном пути. Одинаковый файл на одном сервере не подтверждает настройку остальных участников схемы.
Учитывайте имя без www и с www, отдельные API и ресурсы страницы. Главная может открываться, пока браузер блокирует запрос к другому имени. Не советуйте посетителю отключать проверку сертификата. Неисправность нужно устранить на соответствующем узле, сохранив защищённое соединение для обычных пользователей.
Изучите правила CDN и защиты
Проверьте, не блокируются ли определённые сети, страны, адреса или характерные запросы. Общим IP могут пользоваться многие люди, поэтому слишком низкий лимит частоты способен затронуть реальных клиентов. Нужны журналы правила и совпадение по времени, а не предположение о блокировке по одному скриншоту.
Не отключайте всю фильтрацию как первый шаг. По возможности используйте режим наблюдения, временное точечное исключение и безопасную проверку. Сравните ответ через CDN и исходный сервер с учётом разрешённого доступа. Правила должны сохранять работу форм, оплаты, интеграций и мониторинга.
Отделите локальную проблему от серверной
Браузерные расширения, корпоративный прокси, локальный кеш и состояние аккаунта тоже влияют на результат. Сравнение с чистым профилем браузера помогает проверить часть гипотез. Однако успех в приватном окне не всегда означает именно ошибку кеша: могли измениться авторизация или набор расширений.
Если запрос дошёл до сервера, ищите его в журналах по времени и идентификатору. Проверьте роль пользователя и условия операции. Если записи нет, смотрите предыдущие участки: DNS, сеть, прокси и защиту. Отсутствие события в одном журнале нужно подтвердить правильностью выбранного узла и периода хранения.
Подтвердите исправление с затронутой стороны
Повторите исходный сценарий из сети, где возникала проблема, затем проверьте другие способы подключения. Убедитесь, что изменение не нарушило доступ остальным посетителям. После сетевой правки полезно отдельно открыть формы, вход и динамические разделы, а не ограничиваться главной страницей.
Сохраните установленную причину и добавьте подходящую внешнюю проверку. Для распределённой аудитории может потребоваться наблюдение из нескольких точек. Общие рекомендации есть в статье о мониторинге сайта. Не стоит создавать десятки сигналов, если никто не понимает, какое действие следует за каждым из них.
До изменения настроек сохраните исходные ответы и результаты подключения. Это позволит сравнить состояние после исправления, даже если локальный кеш уже обновился.
Если часть клиентов не может открыть ваш сайт, обратитесь в HOMEWEB. Передайте адрес, точное время, текст ошибки и результаты проверки из двух сетей — это поможет выбрать первую проверку.
