Интернет работает, а сайты не открываются: в чём причина

Ситуация, когда интернет работает, а сайты не открываются, выглядит противоречиво только на первый взгляд. Мессенджер получает сообщения, пинг до 8.8.8.8 проходит, обновления скачиваются, а браузер показывает DNS_PROBE_FINISHED_NXDOMAIN, ERR_CONNECTION_TIMED_OUT, бесконечную загрузку страницы или ошибку прокси.

Дело в том, что «интернет» — это цепочка шагов, а не одна кнопка: DNS, TCP-соединение, TLS, прокси или VPN, маршрутизация, MTU, фильтры антивируса, настройки браузера и сам веб-сервер. Если ломается один участок, часть приложений продолжает работать, а сайты — нет.

Разберём самые частые причины: DNS, прокси, MTU, антивирус, IPv6, VPN, кэш браузера и проблемы на стороне сайта — от быстрых проверок к более технической диагностике.

Сначала отделите проблему сайта от проблемы устройства

Не стоит сразу менять DNS, отключать антивирус и сбрасывать сеть. Сначала важно понять масштаб: не открывается один сайт, группа сайтов или вообще все страницы в браузере.

1) Проверьте сайт с другого устройства — откройте тот же адрес с телефона через мобильный интернет. Если сайт открывается, проблема, скорее всего, в вашей сети, устройстве, браузере, DNS или прокси. Если не открывается нигде, возможно, упал сам сайт, домен, CDN или хостинг.

2) Сравните разные браузеры — попробуйте Chrome, Firefox, Edge, Safari. Если проблема только в одном браузере, смотрите расширения, кэш, настройки прокси, DNS-over-HTTPS и профиль пользователя.

3) Проверьте IP-доступность отдельно от домена — если вы знаете IP сервера, попробуйте ping, traceroute, mtr или зайти на него напрямую. Для HTTPS-сайтов прямой заход по IP часто не работает из-за SNI и сертификата, поэтому это только вспомогательная проверка.

4) Посмотрите текст ошибки — он сильно сужает круг поиска:

• DNS_PROBE_FINISHED_NXDOMAIN — не найден домен или проблема DNS.
• DNS_PROBE_FINISHED_BAD_CONFIG — некорректные DNS-настройки.
• ERR_CONNECTION_TIMED_OUT — соединение не установилось вовремя.
• ERR_CONNECTION_REFUSED — сервер или порт отклонил соединение.
• ERR_PROXY_CONNECTION_FAILED — проблема с прокси.
• NET::ERR_CERT_* — ошибка сертификата, времени, TLS или перехвата HTTPS.

Для общей диагностики полезен отдельный чеклист: «Не открывается сайт». Здесь же сфокусируемся на случаях, когда сеть вроде бы есть, но веб-страницы не загружаются.

DNS: интернет есть, но имена сайтов не разрешаются

Чаще всего за этим сценарием стоит DNS. Приложения могут использовать уже закэшированные адреса или собственные механизмы подключения, а браузеру для нового сайта нужно сначала преобразовать домен в IP-адрес.

Если DNS-сервер не отвечает, возвращает неправильные записи или провайдер фильтрует запросы, браузер не дойдёт даже до этапа соединения с сайтом.

1) Сделайте DNS-запрос вручную — на Linux и macOS удобно использовать dig:

dig example.com

На Windows выполните:

nslookup example.com

Если ответов нет, видите SERVFAIL, NXDOMAIN для существующего домена или слишком долгую задержку, проблема, вероятно, в DNS.

2) Сравните разные DNS-серверы — проверьте тот же домен через публичный резолвер:

dig example.com @8.8.8.8

dig example.com @1.1.1.1

Если через публичный DNS домен разрешается, а через DNS провайдера — нет, временно смените DNS в настройках сети или роутера.

3) Очистите локальный DNS-кэш — система и браузер могут хранить старые записи. На Windows:

ipconfig /flushdns

На macOS команда зависит от версии, часто используется:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

В Linux кэш может быть в systemd-resolved, dnsmasq, nscd или вовсе отсутствовать. Для systemd-resolved:

sudo resolvectl flush-caches

4) Проверьте DNS-over-HTTPS в браузере — Chrome, Firefox и Edge могут использовать DoH независимо от системных DNS. Тогда в системе всё выглядит корректно, а браузер ходит к другому резолверу. Временно отключите «Безопасный DNS» или смените провайдера DoH.

5) Учитывайте корпоративные и локальные домены — в офисных сетях внутренние домены часто доступны только через корпоративный DNS. Если включить публичный DNS или DoH, внешние сайты начнут открываться, а внутренние — нет.

Если хотите глубже понять цепочку от домена до IP, посмотрите материал «Как работает DNS» и практический разбор утилиты dig.

Прокси, VPN и корпоративные фильтры

Прокси может быть настроен явно, подхвачен автоматически через PAC-файл или установлен приложением. В итоге браузер отправляет трафик не напрямую на сайт, а через промежуточный сервер. Если этот сервер недоступен, требует авторизацию или блокирует часть доменов, сайты перестают открываться. Мессенджеры, игры и системные обновления при этом нередко работают напрямую — поэтому кажется, что с интернетом всё в порядке.

1) Проверьте системный прокси — на Windows откройте «Параметры → Сеть и Интернет → Прокси». Отключите ручной прокси и автоматический сценарий, если они не нужны. На macOS настройки находятся в «Сеть → Подробно → Прокси». В Linux всё зависит от окружения: переменные HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, настройки GNOME/KDE или браузера.

2) Посмотрите настройки браузера — Firefox, например, может использовать собственную конфигурацию прокси, не совпадающую с системной. Если проблема только в нём, откройте «Настройки сети» и переключитесь на «Использовать системные настройки» или «Без прокси».

3) Отключите VPN для проверки — VPN меняет маршрут, DNS, MTU и иногда проксирует трафик. Если сайты не открываются только с VPN, дело может быть в сервере VPN, политике маршрутизации, DNS внутри туннеля или блокировке со стороны сайта.

4) Проверьте PAC-файл — в корпоративных сетях часто используется автоматическая настройка прокси через wpad или URL вида http://proxy.example.local/proxy.pac. Если PAC-файл недоступен или содержит ошибку, часть доменов может уходить не туда.

5) Учитывайте SSL inspection — некоторые корпоративные прокси и антивирусы перехватывают HTTPS, подставляя свой сертификат. Если корневой сертификат не установлен или истёк, браузер покажет ошибки TLS.

Прокси сам по себе не проблема, но при диагностике его нужно исключить одним из первых. Подробнее о принципе работы — в статье «Что такое прокси-сервер».

MTU: когда маленькие запросы проходят, а сайты зависают

MTU — максимальный размер пакета, который проходит по каналу без фрагментации. Если он настроен неправильно, возникают странные симптомы: ping работает, DNS отвечает, простые сайты открываются, а тяжёлые HTTPS-страницы зависают, не догружаются или открываются через раз.

Это часто проявляется на PPPoE, VPN, GRE/IPsec-туннелях, в мобильных сетях и при неправильной настройке роутера: маленькие пакеты проходят, а большие теряются. Если при этом блокируются ICMP-сообщения о необходимости фрагментации, Path MTU Discovery не может подобрать правильный размер — TCP-соединение формально устанавливается, но данные не идут.

1) Проверьте симптоматику — если ping 8.8.8.8 работает, но HTTPS-сайты зависают на загрузке, а через мобильный интернет всё открывается, MTU стоит добавить в список подозреваемых.

2) Найдите рабочий размер пакета — на Linux используйте ping с запретом фрагментации:

ping -M do -s 1472 example.com

Для Ethernet с MTU 1500 полезная нагрузка ICMP обычно 1472 байта: 1500 минус заголовки IP и ICMP. Если такой пакет не проходит, уменьшайте размер: 1464, 1452, 1400.

На Windows:

ping example.com -f -l 1472

3) Проверьте VPN и PPPoE — для VPN часто нужен MTU ниже 1500, например 1420, 1400 или меньше. Для PPPoE типичное значение — 1492, но дополнительные туннели могут уменьшить его ещё сильнее.

4) Не лечите вслепую — резкое снижение MTU до совсем маленьких значений может ухудшить производительность. Сначала найдите порог, затем задайте значение с запасом.

5) Проверьте MSS clamping — на маршрутизаторах и VPN-шлюзах часто настраивают TCP MSS, чтобы клиенты не отправляли слишком большие сегменты. Если MSS clamping отсутствует или настроен неправильно, HTTPS может ломаться особенно неприятно.

Для глубокого разбора с примерами диагностики пригодится статья «MTU, MSS и fragmentation».

Антивирус, фаервол и расширения браузера

Антивирусы давно не ограничиваются проверкой файлов. Многие продукты фильтруют веб-трафик, проверяют HTTPS, блокируют трекеры, подменяют сертификаты и внедряются в сетевой стек. Из-за этого браузер может отказываться открывать сайты — в одном профиле или сразу во всех.

1) Временно отключите веб-защиту, а не весь антивирус — в настройках ищите функции вроде «Проверка HTTPS», «Защищённый браузер», «Веб-антивирус», «Фильтрация трафика». Отключайте их на короткое время только для проверки.

2) Проверьте сертификаты — если антивирус перехватывает HTTPS, в цепочке сертификатов сайта появится корневой сертификат антивируса или корпоративного прокси. Когда он повреждён, удалён или истёк, браузер показывает ошибки доверия.

3) Отключите расширения браузера — блокировщики рекламы, анти-трекеры, VPN-расширения и менеджеры безопасности могут ломать отдельные сайты. Быстрый тест — открыть страницу в режиме инкогнито с отключёнными расширениями или в чистом профиле браузера.

4) Проверьте фаервол — локальный фаервол может блокировать браузер, порт 443, DNS-запросы или отдельные IP-диапазоны. Особенно часто это встречается после установки VPN-клиента, корпоративного агента безопасности или сетевого фильтра.

5) Смотрите логи блокировок — хорошие security-продукты показывают, какой домен, процесс или сертификат был заблокирован. Это быстрее, чем угадывать.

Если браузер показывает именно TLS-ошибки, полезно отдельно разобрать, где ломается рукопожатие: сертификат, SNI, версия TLS, прокси или время на устройстве. Для этого есть материал «Ошибка TLS-рукопожатия».

IPv6, маршрутизация и проблемы провайдера

Иногда сайт не открывается из-за маршрута, а не из-за самого сайта. У провайдера может быть проблема с определённым пирингом, подсетью, CDN-регионом или IPv6-маршрутизацией — при этом другие сайты работают нормально.

1) Проверьте IPv4 и IPv6 отдельно — домен может иметь записи A и AAAA, и браузер сам выбирает подходящий адрес. Если IPv6 у провайдера сломан, сайт с AAAA может долго открываться или не открыться вовсе.

Проверка через dig:

dig A example.com

dig AAAA example.com

Можно временно отключить IPv6 на интерфейсе и посмотреть, изменится ли поведение. Это не универсальное решение, но полезный диагностический шаг.

2) Используйте трассировку — traceroute, tracert, mtr или WinMTR покажут, где растёт задержка или начинаются потери. Один потерянный ICMP-ответ на промежуточном узле не всегда значит проблему, но потери на последнем хопе или резкий обрыв маршрута — важный сигнал.

3) Сравните разные сети — домашний провайдер, мобильный интернет, офисная сеть, VPN. Если сайт не открывается только у одного провайдера, вероятна проблема маршрутизации, фильтрации или DNS на его стороне.

4) Проверьте CDN — крупные сайты часто отдают контент с ближайшей CDN-точки, и один и тот же домен у пользователей из разных регионов может резолвиться в разные IP. Поэтому «у меня не открывается» и «у коллеги открывается» могут быть одновременно правдой.

5) Не делайте вывод по одному ping — многие серверы и CDN ограничивают ICMP. Сайт может не отвечать на ping, но отлично работать по HTTPS. Проверяйте именно HTTP-запросы через браузер или curl.

Для анализа маршрута пригодится разбор mtr и WinMTR — он помогает отличать реальную потерю пакетов от нормального поведения маршрутизаторов.

Браузер, кэш, cookies и локальные настройки

Если проблема воспроизводится только в одном браузере, сетевой уровень может быть ни при чём. Браузеры хранят DNS-кэш, HTTP-кэш, HSTS-политики, cookies, сервис-воркеры, данные расширений и настройки безопасности.

1) Откройте сайт в приватном режиме — это быстрый способ исключить часть cookies, кэша и расширений. Если в приватном режиме сайт работает, проблема в профиле браузера.

2) Очистите данные конкретного сайта — не обязательно чистить весь кэш. В Chrome и Edge можно открыть сведения о сайте и удалить данные только для нужного домена. Это помогает при битых cookies, старых service worker и конфликтующем local storage.

3) Проверьте HSTS — если сайт раньше открывался по HTTPS с HSTS, браузер может принудительно переводить его на HTTPS. Если сертификат сломан или HTTPS временно недоступен, зайти по HTTP не получится.

4) Отключите экспериментальные функции — DNS-over-HTTPS, QUIC/HTTP3, изоляция сети, privacy-функции и расширенные блокировки иногда несовместимы с конкретными сайтами или корпоративными прокси.

5) Создайте новый профиль — если ничего не помогает, новый профиль браузера быстрее, чем поиск испорченной настройки. Это особенно полезно на рабочих станциях, где браузер годами копит расширения и политики.

Отдельно проверьте системное время: неверная дата ломает проверку сертификатов, из-за чего HTTPS-сайты могут массово не открываться.

Если вы владелец сайта: как понять, что дело не в пользователе

Для владельца сайта жалоба «у меня интернет работает, а ваш сайт не открывается» сложна тем, что причина может быть где угодно: у пользователя, провайдера, DNS, CDN, хостинга или в самом приложении. Нужны внешние проверки, а не только взгляд изнутри сервера.

1) Проверьте сайт из разных точек — доступность сайта из вашей сети не гарантирует доступность для всех, нужны проверки из других регионов и сетей. Сервис мониторинга доступности помогает увидеть, когда сайт перестал отвечать снаружи: Statuser проверяет URL с заданным интервалом и присылает уведомление о сбое.

2) Смотрите HTTP-статус и время ответа — 200 с задержкой в 15 секунд и 503 — разные проблемы. Проверяйте не только факт ответа, но и код, latency, редиректы, размер ответа.

3) Используйте curl для воспроизводимой проверки — он показывает, на каком этапе запрос тормозит:

curl -v https://example.com/

Полезны параметры:

• -I — запросить только заголовки.
• --resolve example.com:443:IP — проверить конкретный IP, минуя DNS.
• --connect-timeout 5 — ограничить время установки соединения.
• -4 и -6 — проверить IPv4 или IPv6.

Подробнее о возможностях инструмента — в статье «Что такое curl и как им пользоваться».

4) Проверьте DNS-зону — ошибки в A, AAAA, CNAME, NS, истёкшая делегация, DNSSEC или разные ответы авторитативных серверов могут ломать доступность не для всех пользователей сразу, а выборочно.

5) Проверьте TLS и сертификат — истёкший сертификат, неправильная цепочка, отсутствие SNI-конфигурации или несовместимые TLS-настройки часто выглядят для пользователя как «сайты не открываются», хотя сеть работает.

6) Смотрите логи веб-сервера и балансировщика — если запросы от проблемного пользователя вообще не доходят, ищите причину в DNS, маршруте, CDN, WAF, фаерволе. Если доходят и получают 5xx, проблема уже на вашей стороне: приложение, upstream, база, лимиты, очереди.

Для владельцев проектов полезна статья «Проверка доступности сайта»: она помогает выстроить регулярную внешнюю проверку, а не узнавать о сбоях из сообщений пользователей.

Быстрый алгоритм диагностики

Когда сайты не открываются, лучше двигаться по слоям — так вы не будете хаотично менять настройки и усложнять проблему.

1) Определите масштаб — один сайт, несколько сайтов или все сайты. Проверьте другой браузер, другое устройство и другую сеть.

2) Зафиксируйте ошибку — скопируйте код из браузера: DNS_PROBE_*, ERR_CONNECTION_*, NET::ERR_CERT_*, HTTP 502/503/504. По нему часто понятно, куда смотреть.

3) Проверьте DNS — nslookup, dig, смена DNS-сервера, отключение DoH, очистка кэша.

4) Исключите прокси и VPN — временно отключите VPN, проверьте системный прокси, PAC-файл и настройки браузера.

5) Проверьте антивирус и расширения — отключите веб-фильтрацию на короткое время, откройте сайт в чистом профиле или приватном режиме.

6) Проверьте маршрут и IPv6 — сравните IPv4/IPv6, сделайте mtr или tracert, попробуйте мобильный интернет.

7) Подумайте про MTU — если соединение устанавливается, но HTTPS-страницы зависают или грузятся частично, проверьте MTU и MSS, особенно при VPN и PPPoE.

8) Если вы администратор сайта — проверьте снаружи — мониторинг доступности, curl -v, DNS-зона, TLS, логи балансировщика и приложения.

Главное — разделять уровни: DNS-ошибку не исправить очисткой cookies, а проблему MTU не решить сменой браузера. Двигаясь по цепочке, причину обычно удаётся найти быстро.

FAQ

Почему мессенджеры работают, а сайты не открываются?
Мессенджеры могут использовать уже установленные соединения, собственные DNS, другие порты или IP-адреса. Браузеру же нужно заново пройти DNS, TCP, TLS и загрузить множество ресурсов страницы.

Поможет ли смена DNS на 8.8.8.8 или 1.1.1.1?
Да, если проблема именно в DNS провайдера или локальном резолвере. Но при прокси, MTU, антивирусе, TLS-ошибке или падении сайта смена DNS ничего не исправит.

Почему сайт открывается через VPN, но не открывается напрямую?
VPN меняет маршрут, DNS и внешний IP. Значит, проблема может быть у провайдера, в блокировке по IP или региону, в маршрутизации, CDN или DNS-ответах для вашей сети.

Что делать, если не открывается только один сайт?
Проверьте его из другой сети, через curl, посмотрите DNS и TLS. Если вы не владелец сайта, вероятно, остаётся ждать исправления или написать в поддержку. Если владелец — проверяйте внешнюю доступность, DNS, CDN, логи и ошибки приложения.