Как проверить, находится ли сайт в белых списках
Магазин открывается с рабочего компьютера, но покупатели жалуются, что с телефона не загружаются каталог и личный кабинет. Администратор проверяет сервер и не находит неисправностей. Реклама продолжает приводить посетителей, однако часть из них не может даже посмотреть товары. Причина может быть в ограничениях мобильного интернета, при которых оператор сохраняет доступ только к определенным ресурсам.
Проверка через офисный Wi-Fi такую ситуацию не воспроизводит. Нужно открыть тот же адрес через мобильную сеть, которой пользуется покупатель, а затем сравнить доступность через другое подключение.
Для первичного замера можно использовать онлайн-сервис, отправляющий запросы из сетей операторов. После этого сайт проверяют в браузере.
При этом доступность и официальный статус - разные вещи. Сайт может открываться через промежуточный узел, хотя его собственное включение в государственный перечень этим не подтверждено. Поэтому сначала определяют задачу - проверить доступ для посетителей или найти официальное подтверждение включения в белый список.
Как проверить белый список и доступность сайта
Под такой проверкой обычно понимают выяснение доступности сайта при ограничениях мобильного интернета. Например, страница открывается через домашний Wi-Fi, но не загружается через сеть оператора. Для владельца бизнеса важно воспроизвести именно условия посетителя. Проверка только через офисное подключение не покажет, сможет ли покупатель открыть каталог с телефона и завершить заказ.
Для проверки нужны домен, сеть и время замера. Эти сведения помогают повторить ее после изменения настроек.
Сайт может открываться через узел прокси или CDN, хотя его собственное включение в государственный перечень этим не подтверждено. Для подтверждения официального статуса нужна публикация уполномоченного ведомства, в которой назван соответствующий ресурс, либо документ о его включении. Упоминание бренда не следует автоматически распространять на все принадлежащие ему домены. Если такого подтверждения нет, корректно говорить о проверке доступности сайта, а не о документально установленном включении в перечень.
Сначала определите, какой адрес нужно проверять
Начните с точного доменного имени, которое вводит посетитель. Главная страница магазина, личный кабинет и API приложения могут использовать разные имена для обслуживания запросов. Например, example.ru открывает каталог, а account.example.ru отвечает за авторизацию. Если проверяли только первый домен, доступность второго еще предстоит установить.
Имеет значение и перенаправление между адресами. Посетитель может вводить имя без www, а браузер переводит его на вариант с www. В таком случае полезно проверить оба имени, поскольку ошибка может возникнуть еще до перехода на конечную страницу.
Для магазина удобно заранее выписать имена каталога, кабинета и платежного компонента. Для образовательного проекта - страницы входа, учебных материалов и видеозанятий. Такой список помогает проверять обязательные части проекта последовательно и не забывать компоненты, которые появляются только после авторизации. Назначение каждого имени записывают рядом с ним, чтобы разработчик и владелец проекта одинаково понимали, какую часть сайта предстоит проверить.
Компания использует основной домен для витрины, отдельный поддомен для кабинета и стороннюю платформу записи на консультацию. Посетитель начинает с главной страницы. Затем выбирает услугу и нажимает кнопку записи. Браузер переводит его на другую платформу. Владелец заносит ее адрес в список обязательных компонентов и сохраняет ссылку перехода. После этого проходит авторизацию и открывает расписание, чтобы проверить весь путь от выбора услуги до доступного времени приема. Если остановиться на витрине, важнейшая часть обращения клиента останется за пределами проверки.
Как проверить доступность сайта через мобильные сети
Для первичного замера можно использовать проверку Taucloud. Достаточно ввести домен; доступы к серверу и установка программы на стороне владельца сайта не нужны. По описанию сервиса, запросы проходят через модемы в сетях, где включены белые списки. Это позволяет проверять подключение через мобильные сети, а не только доступность из дата-центра.
Порядок действий следующий.
- Скопируйте доменное имя сайта, с которым возникают ошибки.
- Введите его в поле проверки Taucloud и запустите запрос.
- Сохраните домен и время измерения для сравнения после изменений.
- Отдельно проверьте другие имена, необходимые для работы проекта.
- Откройте сайт с телефона и пройдите основные действия посетителя.
Проверка занимает около минуты. Без авторизации может отображаться сохраненный ответ за текущий день, поэтому обращайте внимание на время измерения. Для немедленного нового запуска предусмотрен вход в аккаунт. Заявленный лимит - пять новых проверок в сутки с одного IP.
До изменения настроек сохраните исходный замер. Затем меняйте то, что относится к выбранной задаче, например подключение домена к прокси или размещение определенного компонента. После этого повторите проверку того же имени. Такой порядок помогает сравнить состояние до и после настройки, а не смешивать перенос сайта, обновление приложения и смену подключения в одну попытку.
Как проверить сайт вручную с телефона
Отключите Wi-Fi и убедитесь, что телефон использует мобильную передачу данных. Если включен КВН или прокси, отключите его на время прямой проверки сети оператора. Затем откройте точный адрес проблемной страницы. Запишите время, название оператора и действие, на котором возникает ошибка, например открытие каталога или вход в кабинет. После этого загрузите ту же страницу через домашнее фиксированное подключение. Используйте тот же телефон, браузер и адрес, чтобы не менять сразу несколько условий.
Перед повторной попыткой перезагрузите страницу. Если браузер показывает ранее сохраненную копию, ее отображение не подтверждает нового соединения с сайтом.
Важно учитывать источник Wi-Fi. Домашний роутер с кабелем провайдера и точка доступа другого телефона используют разные подключения. Во втором случае трафик по-прежнему идет через мобильного оператора и может подпадать под ограничения. Поэтому рядом с адресом страницы записывают не только способ подключения телефона, но и сеть, через которую он выходит в интернет.
Само наличие нескольких доступных сервисов еще не подтверждает действие белых списков. Отдельный сайт может не работать из-за собственной аварии, а приложение - из-за ошибки обновления.
Как проверять сайт с компьютера через сеть телефона
На компьютере удобнее исследовать сложные формы, перенаправления и запросы приложения. Для этого ноутбук можно подключить к точке доступа телефона, который использует нужную мобильную сеть. Предварительно отключите на компьютере КВН, прокси и другие соединения, способные изменить маршрут. Иначе браузер может обращаться к сайту не через то подключение, которое требуется проверить.
Сначала убедитесь, что телефон не раздает домашний Wi-Fi вместо мобильной передачи данных. Затем откройте сайт и повторите действие, о котором сообщил посетитель. Если жалоба касается входа по одноразовому коду, проверяют именно этот сценарий, а не только открытие формы авторизации. Если проблема возникает при загрузке документа, нужно дойти до соответствующей кнопки и повторить скачивание.
Почему нужно проверять не только главную страницу
Браузер получает страницу, а затем загружает изображения, скрипты, форму входа, карту доставки и другие компоненты. Часть запросов может уходить на сторонние домены. Поэтому открывшаяся главная страница еще не означает, что покупатель сможет завершить заказ. Обязательные функции проекта проверяют по отдельности.
Для подробного разбора разработчик использует панель Network в инструментах браузера. Сначала открывает панель, затем повторяет проблемное действие. В ней можно увидеть запросы, их адреса и сообщения об ошибках. Компьютер при этом должен использовать нужное подключение - наблюдение через офисный интернет не воспроизводит условия мобильного посетителя.
Представим магазин, в котором открываются каталог и карточки товаров. Покупатель добавляет товар в корзину. Затем выбирает доставку, но список пунктов выдачи остается пустым. Разработчик повторяет действие через затронутую сеть с открытой панелью запросов. Находит обращение к внешнему сервису доставки. Затем проверяет тот же адрес через фиксированное подключение. После устранения проблемы команда снова проходит весь заказ, включая переход к оплате. Так проверка охватывает действия покупателя, а не заканчивается загрузкой первой страницы.
Почему белый IP не подтверждает присутствие сайта в белом списке
Вопрос, как понять, белый IP или нет, касается типа сетевого адреса. Белым обычно называют публичный IP, а не адрес, который оператор разрешил при ограничениях мобильного интернета. Публичность сама по себе не гарантирует доступность сайта через такую сеть. Статичность IP тоже означает только постоянство адреса, а не особый статус ресурса.
Если нужно проверить, белый адрес или нет, сначала определите, чье подключение рассматривается.
Внешний IP телефона относится к самому телефону, а адрес сайта - к серверу или промежуточному узлу, с которого загружается страница. Для задачи владельца магазина важно проверять домен из нужных мобильных сетей. Определение собственного IP посетителя эту проверку не заменяет.
То же относится к покупке выделенного IP у хостинга. Отдельный адрес может быть нужен для архитектуры проекта, но сам факт его выделения не устанавливает доступность при ограничениях. После такой смены проверяют доменное имя и действия посетителя заново. Если сайт использует CDN или обратный прокси, браузер может обращаться к промежуточному узлу, а не непосредственно к серверу хостинга.
Когда повторно проверять статус белых списков
Повторная проверка нужна после смены DNS, подключения прокси, изменения серверных адресов или появления новых жалоб. Сохраняйте домен, время, оператора и содержание ошибки. Отдельно записывайте действия, которые действительно прошли проверку в браузере. Фразы "не работает с телефона" недостаточно, поскольку она не сообщает ни сеть, ни адрес, ни шаг, на котором возникла проблема.
После изменения DNS разные устройства некоторое время могут использовать разные закэшированные ответы. Это означает, что посетители не обязательно сразу обращаются к одной точке доставки контента. Поэтому при повторной проверке полезно установить, какой адрес получает конкретный клиент. Затем сайт открывают через нужное подключение и снова проходят основные функции.
Не стоит одновременно менять несколько независимых настроек без записи последовательности.
Перенос сервера, обновление приложения и смена прокси затрагивают разные части проекта. Если выполнять их по очереди и после каждого шага повторять один сценарий, разработчику проще связать возникшую проблему с конкретным изменением. Для владельца это также сокращает число повторных проверок, которые не помогают установить причину.
Как подготовить описание проблемы для разработчика
В описании полезно разделять наблюдения и предположения. Наблюдение - "после нажатия кнопки входа браузер переходит на account.example.ru и страница не загружается". Предположение - "сайт заблокирован оператором". Первое можно воспроизвести, а второе еще предстоит проверить, сопоставив подключения, настройки приложения и сетевые запросы.
Сохраните адрес страницы, название оператора, время, устройство и браузер. Добавьте последовательность действий до ошибки. Если переход происходит после авторизации, используйте предназначенную для проверки учетную запись. Снимок экрана может дополнить описание.
Полезно также указать, какие действия выполнялись перед появлением проблемы. Например, менялся ли домен кабинета, подключался ли новый платежный модуль или переносились ли изображения на другой узел.
Для регулярной проверки достаточно одного согласованного сценария. Например, открыть каталог, найти товар, войти в кабинет и дойти до страницы оплаты, не совершая реальную покупку. После изменений команда повторяет именно эту последовательность. Так проверяют важные функции одинаковым способом, а случайный просмотр главной страницы не подменяет проверку всего магазина.
Как обеспечить доступность сайта
Если сервер не отвечает через разные подключения, сначала проверяют инфраструктуру и приложение. Если сайт открывается через фиксированный интернет, но недоступен через мобильную сеть с ограничениями, отдельно рассматривают способ доставки трафика. Когда главная страница доступна, а функция не работает, проверяют ее запросы и внешние зависимости. Это помогает исправлять конкретную проблему вместо переноса всего проекта из-за одного компонента.
Для доставки сайта через адреса, которые, по заявлению компании, пропускают операторы, можно использовать Taucloud.
Домен должен работать через прокси сервиса. Основной сервер остается на прежнем хостинге, а для посетителей используется промежуточный узел Taucloud. Такое подключение обеспечивает техническую доступность и не означает официального включения ресурса в государственный перечень. Одна подписка охватывает одно доменное имя. Поэтому каталог и кабинет на разных именах учитываются отдельно, как и внешние компоненты оплаты и доставки.