Сайт не работает только по Wi‑Fi: план проверки двух сетей до сброса настроек

Короткий ответ: если один и тот же сайт работает через мобильную сеть, но не через Wi‑Fi, он был доступен хотя бы по одному сетевому пути. Важно понять, чем отличается работающий мобильный путь от неработающего Wi‑Fi.

Могут отличаться публичный IP, DNS, прокси/VPN, IPv4, IPv6, маршрутизация и обработка на стороне назначения. Успешный DNS не доказывает работу HTTPS; VPN создаёт другой путь; звёздочки в трассировке не доказывают блокировку.

Основные понятия

Wi‑Fi соединяет устройство с точкой доступа; далее могут быть провайдер, фильтр, межсетевой экран или VPN. Мобильная сеть обычно использует другой публичный выход. DNS разрешает имена: A — IPv4, AAAA — IPv6. Публичный IP виден сайту и отличается от внутреннего адреса роутера; см. IANA и частные IP-адреса. ASN обозначает сеть маршрутизации и является контекстом, а не доказательством причины.

Главное правило: всё остальное оставьте неизменным

1. Запишите точное имя хоста; app.example.com и www.example.com могут различаться.
2. Используйте те же устройство, браузер и URL.
3. По возможности используйте приватное окно.
4. Отключите необязательные VPN/прокси; не обходите корпоративную политику, а зафиксируйте её.
5. Проверьте обе сети за короткий срок, укажите время, часовой пояс и сообщение.
6. Определите результат: тайм-аут, сброс, сертификат, отказ, неполная или обычная страница.

Карточка доказательств

Геолокация IP — лишь контекст или оценка, а не подтверждённое физическое местоположение; см. EFF. Не публикуйте полный IP, учётные данные, ссылки сеансов, внутренние хосты и неотредактированные трассы.

Порядок проверки

1. Один сайт или многие?

Если по Wi‑Fi не работают многие несвязанные сайты, проверяйте доступ, роутер или DNS. Если не работает один хост, сравните DNS, семейства IP, маршрут, прокси и политику назначения. Если не работает только авторизованная страница, учитывайте состояние браузера, учётную запись и приложение.

2. VPN, прокси, управляемая сеть

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

3. DNS точного хоста

Используйте поиск DNS; в Windows:

nslookup -type=A example.com
nslookup -type=AAAA example.com

DNS отвечает только на вопрос об имени. Разные ответы могут быть нормальным распределением нагрузки; важнее тайм-аут, блокировка, отсутствие ответа или постоянный сбой одного семейства.

4. IPv4 и IPv6 отдельно

При наличии A и AAAA доступны два семейства; это описано в RFC 8305. Сравните:

curl -4 -I https://example.com
curl -6 -I https://example.com

Сбой одного семейства — признак различия для него. Если по Wi‑Fi не работают оба, а мобильная сеть работает, вернитесь к прокси, DNS, политике и маршруту. Если оба работают, но браузер — нет, проверьте расширения, кэш, HTTPS-инспекцию, service wилиkers или приложение. Не отключайте IPv6 навсегда как первое решение.

5. Трассировка — только подсказка

tracert -4 example.com
tracert -6 example.com

Руководство Microsизt TRACERT объясняет TTL. Роутер может ограничивать диагностические ответы и передавать веб-трафик; скрывайте чувствительные данные.

Результаты и действия

Много сайтов не работают: проверьте другое устройство и при необходимости обратитесь к провайдеру. Один хост: сравните A/AAAA, прокси и IPv4/IPv6. DNS блокирует: сохраните ответ и тестируйте разрешённый резолвер. Работает только VPN: сравните IP, DNS, маршрут и семейство. Явный корпоративный отказ: отправьте текст и время администратору. Звёздочки: не назначайте виновный узел без подтверждения.

Сценарии, мифы и маршрутизация

Если медицинский портал работает через мобильный tethering, но IPv6 по Wi‑Fi стабильно завершается тайм-аутом, это конкретное наблюдение для провайдера или оператора, а не доказательство блокировки IPv6. Одинаковый отказ у сотрудников в управляемом офисе может быть связан с выходным IP, прокси, списком разрешений или политикой.

• Работа мобильной сети не доказывает поломку роутера.
• DNS не доказывает доступность сайта.
• Смена DNS или VPN не доказывает первопричину.
• Геолокация IP не является проверенным адресом.
• Звёздочки не указывают на неисправный роутер.

BGP и RPKI обычно нужны операторам. ROA разрешает ASN анонсировать префикс; см. ARIN, RFC 6811 и RIPE NCC. RIPE Atlas предлагает проверки IPv4, IPv6, DNS, TLS, HTTP, ping и traceroute, но не воспроизводит конкретного клиента.

Что отправить в поддержку

Отправьте конфиденциально хост/URL, даты, время и пояс, ошибку с редактированием, устройство/браузер, VPN/прокси, мобильный результат, контекст через проверку IP, A/AAAA, сравнение IPv4/IPv6 и отредактированную трассу, если она полезна. WHOIS используйте для контекста организации, не для идентификации людей.

Конфиденциальность, будущее и вывод

Публичный IP может быть динамическим, общим или использоваться через прокси/VPN; это не имя и не адрес человека. Не публикуйте пароли, сеансы, внутренние имена и полные трассы. При зашифрованном DNS, relay, VPN и инспекции записывайте что произошло, прежде чем утверждать почему. Повторяйте карточку через набор IP-инструментов.

Частые вопросы

Что означает работа через мобильную сеть, но не Wi‑Fi?

Сайт был доступен мобильным путём; могут отличаться IP, DNS, прокси, семейства, маршрут или политика.

Как сравнивать честно?

Используйте то же устройство, браузер, хост и короткий интервал; сначала зафиксируйте состояние.

Успешный DNS гарантирует сайт?

Нет, позже могут не сработать соединение, TLS или запрос.

Как проверить IPv6 без отключения?

Сравните A/AAAA, curl -4 и curl -6.

Звёздочки доказывают поломку?

Нет, диагностические зонды могут игнорироваться или ограничиваться.

Что посылать поддержке?

Хост, время, ошибку, устройство, VPN/прокси, приватный контекст IP, A/AAAA, IPv4/IPv6 и отредактированную трассу при необходимости.