Сайт работает, а у вас не открывается: DNS, кэш и провайдер

Если сайт открывается у всех, кроме вас, виноват один из четырёх кэшей DNS: браузера, системы, роутера или провайдера. Чистят обычно только первый. Второй частый источник это забытая строка в файле hosts после переноса сайта.

Ситуация знакомая до зубовного скрежета: вы пишете подрядчику «сайт лежит», он открывает ссылку и отвечает «у меня всё грузится». Коллега из соседнего кабинета тоже видит главную. Сайт работает, но не открывается только у вас, и непонятно, чинить сервер или собственный ноутбук. Разберём, как за пять минут отделить локальную проблему от настоящей аварии, что и в каком порядке чистить в DNS на Windows, macOS и Android, и что делать, если виноват провайдер, блокировка или фаервол хостинга, который забанил ваш IP.

За шесть лет абонентки я разбирал такие обращения десятками. По моей статистике примерно семь из десяти случаев «сайт не открывается» оказываются проблемой на стороне клиента: кэш, старый hosts, забаненный за перебор паролей офисный IP. Остальные три действительно требуют лезть на сервер. Ниже порядок проверок от самых быстрых к самым долгим, чтобы не начинать диагностику с перезапуска nginx.

Первая минута: у всех или только у вас

Прежде чем трогать что-либо, надо ответить на один вопрос: сайт недоступен всей планете или конкретно вашему устройству. Это разные истории, и лечатся они в разных местах.

Быстрая проверка на три действия:

1. Возьмите телефон, выключите Wi-Fi и откройте сайт по мобильному интернету. Другая сеть, другой провайдер, другие DNS-серверы. Если открылось, проблема локальная.
2. Прогоните адрес через сервис доступности из нескольких точек: ping-admin.ru проверяет из двух десятков городов, host-tracker.com из разных стран. Смотрите не только «доступен или нет», а код ответа и время.
3. Откройте страницу в режиме инкогнито и в другом браузере. Расширения и кэш браузера отпадут сразу.

Проверяйте точный адрес, на котором споткнулись, а не просто домен. Бывает, что главная жива, а страница услуги отдаёт 500, и половина диалога с подрядчиком уходит на выяснение, что именно вы открывали.

Если под рукой есть терминал, одна команда экономит десять минут переписки:

curl -sS -o /dev/null -w "code=%{http_code} ip=%{remote_ip} dns=%{time_namelookup}s connect=%{time_connect}s total=%{time_total}sn" https://example.ru/

Вывод сразу показывает, на каком этапе всё встало. Пустой remote_ip и ошибка резолва означают, что до сервера дело даже не дошло. Долгий time_connect при нормальном time_namelookup говорит, что адрес получен, но сервер молчит. Код 200 при полностью белой странице в браузере переводит разговор в область кэша и скриптов, а не доступности.

Читаем текст ошибки, а не гадаем

Браузер честно пишет, что именно у него не получилось. Люди этот текст пролистывают, а он экономит половину диагностики.

Что показывает браузер	Что реально произошло	Куда смотреть первым делом
ERR_NAME_NOT_RESOLVED, «не удаётся найти DNS-адрес»	Домен не превратился в IP	Кэш DNS, файл hosts, делегирование домена
ERR_CONNECTION_TIMED_OUT	IP получен, сервер не отвечает	Фаервол хостинга, бан вашего IP, маршрут провайдера
ERR_CONNECTION_REFUSED	Сервер ответил отказом на порт	Веб-сервер лежит или слушает не тот порт
ERR_CONNECTION_RESET	Соединение разорвано на середине	Фильтрация трафика, антивирус, оборудование провайдера
ERR_CERT_DATE_INVALID, ERR_CERT_AUTHORITY_INVALID	Проблема с сертификатом	Срок SSL, кривая дата на вашем компьютере, антивирус с подменой сертификата
ERR_TOO_MANY_REDIRECTS	Петля перенаправлений	Правила в htaccess, настройки CMS, кэш браузера с куками
502, 503, 504	Сервер жив, приложение нет	Логи хостинга, это уже авария

Отдельно отмечу разницу между «не удаётся найти адрес» и «превышено время ожидания». Первое почти всегда локальное или доменное. Второе почти всегда сетевое, и там уже интересен ваш внешний IP.

Кэш DNS: четыре уровня, а чистят обычно один

Путь от домена к IP проходит несколько кэширующих узлов, и каждый держит ответ своё время. Браузер (у Chrome собственный кэш), операционная система, роутер, резолвер провайдера. Запись живёт столько, сколько указано в TTL зоны: обычно от 300 секунд до суток. Поэтому после переезда сайта коллега с новым адресом работает, а вы ещё несколько часов стучитесь на мёртвый сервер. Подробно этот сценарий разобран в статье про перенос сайта на новый хостинг, там же про то, зачем TTL снижают заранее.

Сброс по системам:

# Windows, командная строка от администратора
ipconfig /flushdns
ipconfig /displaydns | more

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux с systemd-resolved
resolvectl flush-caches
resolvectl statistics

В Chrome есть свой кэш, который живёт отдельно от системного: откройте chrome://net-internals/#dns и нажмите Clear host cache, затем на вкладке Sockets сделайте Flush socket pools. Без второго шага уже открытые соединения продолжают идти по старому адресу.

На Android отдельной кнопки нет. Работает включение авиарежима на десять секунд, а если не помогло, забыть сеть Wi-Fi и подключиться заново. На iOS помогает то же самое плюс сброс настроек сети в крайнем случае.

Роутер держит собственный кэш и часто раздаёт клиентам себя в качестве DNS-сервера. Перезагрузка на тридцать секунд решает это без захода в веб-интерфейс. Если в офисе не открывается у всех, начинайте именно с роутера, а не с обзвона сотрудников.

Проверить, что получилось, можно так:

nslookup example.ru
nslookup example.ru 77.88.8.8

Первая команда спрашивает у вашего текущего резолвера, вторая напрямую у публичного DNS Яндекса. Если ответы разные, вы поймали устаревший кэш. Если совпадают и адрес правильный, тема DNS закрыта, идём дальше.

Файл hosts: любимые грабли после переноса

Это первое, что я проверяю у клиента, чей сайт недавно переезжал. Схема стандартная: подрядчик прописал новому серверу IP в hosts, чтобы посмотреть сайт до смены записей у регистратора, показал результат, а строку убрать забыл. Через неделю старый сервер отключают, и у одного конкретного человека сайт перестаёт открываться навсегда, пока он сам не найдёт эту строку.

Где лежит файл:

• Windows: C:WindowsSystem32driversetchosts, открывать блокнотом, запущенным от имени администратора;
• macOS и Linux: /etc/hosts, править через sudo nano /etc/hosts.

Внутри вы ищете строки со своим доменом:

# лишняя строка после тестового переноса, удалить
185.12.34.56  example.ru www.example.ru

Всё, что не закомментировано решёткой и упоминает ваш домен, подлежит проверке. Диагностический признак: nslookup показывает один IP, а ping example.ru отвечает с другого. Это ровно то расхождение, которое даёт hosts, потому что nslookup ходит в DNS напрямую, а ping идёт через системный резолвер и правило из файла.

Отдельная разновидность той же болячки: вредоносный софт дописывает в hosts строки с редиректом на левые адреса. Если видите там незнакомые домены, это уже вопрос к антивирусу на компьютере, а не к сайту.

Публичный DNS: проверка на одном флаге

Смена DNS-сервера на публичный не столько чинит, сколько доказывает. Если через 77.88.8.8 или 1.1.1.1 сайт открывается, а через сервер провайдера нет, значит виноват провайдер, и разговор дальше с ним.

Что подставлять в настройки сетевого адаптера:

• 77.88.8.8 и 77.88.8.1 у Яндекса, в России обычно самый стабильный и быстрый вариант;
• 8.8.8.8 и 8.8.4.4 у Google, работает, но иногда с задержками;
• 1.1.1.1 у Cloudflare, быстрый, но чаще остальных попадает под фильтрацию.

Есть нюанс, на котором люди теряют время. Chrome и Firefox по умолчанию умеют DNS поверх HTTPS: браузер ходит к своему резолверу мимо настроек системы. В такой конфигурации ipconfig /flushdns честно чистит системный кэш, а браузер продолжает получать старый ответ. Ищите в настройках Chrome пункт «Использовать безопасный DNS-сервер» и на время диагностики отключайте его.

Если публичный DNS не помог, а nslookup вообще не возвращает адрес ни от одного сервера, проблема не у вас. Смотрите срок регистрации домена: просроченный домен снимается с делегирования, и сайт исчезает для всех разом. Что там происходит по дням, я расписывал в материале про продление домена.

Браузер, расширения, антивирус и корпоративный прокси

Когда DNS чистый, а страница всё равно не грузится, остаются программы на вашем устройстве.

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

Антивирусы с веб-защитой. Kaspersky, Dr.Web и ESET проверяют https-трафик подменой сертификата: ставят в систему свой корневой сертификат и расшифровывают соединение. Когда этот механизм сбоит, вы получаете ошибку сертификата на сайте, у которого с сертификатом всё в порядке. Отключите модуль проверки защищённых соединений на пять минут и повторите.

Корпоративная сеть. Прокси с белым списком доменов, фильтрация по категориям, собственный DNS внутри домена Active Directory. Если сайт не открывается на рабочем компьютере и открывается на телефоне через мобильный интернет, идите к системному администратору, а не к веб-разработчику.

VPN. Тут интереснее: после включения VPN ваш трафик выходит из другой страны. На хостинге может стоять гео-фильтр или правило WAF, разрешающее доступ только из России. Симптом характерный: с VPN сайт отдаёт 403 или таймаут, без VPN открывается. Проверяется отключением на одну попытку.

Кривая системная дата. Сдвиг на месяц вперёд или год назад ломает проверку срока действия сертификата, и любой https-сайт начинает ругаться. Если ошибка сертификата вылезла разом на нескольких сайтах, смотрите часы на компьютере первым делом.

Блокировки и баны: когда виноват не браузер

Если локальные проверки прошли, а сайт по-прежнему недоступен именно вам, остаётся сетевой слой.

Провайдер и маршрут. Бывает точечный сбой на магистрали, когда пакеты до конкретного дата-центра не доходят. Смотрится через tracert example.ru на Windows или traceroute example.ru на Linux и macOS: цепочка узлов обрывается и дальше идут звёздочки. Скопируйте вывод и отправьте в поддержку провайдера, это единственный аргумент, который они принимают всерьёз.

Блокировка по IP на уровне страны. Хостинг с общим внешним адресом иногда попадает под ограничение из-за соседа по shared-серверу. Ваш сайт при этом полностью исправен, но часть операторов его не пропускает. Проверяется по тому же признаку: недоступен у клиентов одного провайдера и открывается у другого.

Гео-фильтр и WAF на стороне хостинга. Настройка «принимать запросы только из РФ» ставится ради снижения ботового трафика и потом бьёт по владельцу, который зашёл через VPN или уехал в отпуск.

Бан вашего IP фаерволом или плагином безопасности. Мой личный чемпион по частоте. Кто-то трижды ошибся паролем в админке, плагин ограничения попыток входа забанил IP на сутки, а IP в офисе один на всех. В результате сайт «не открывается» у всей команды, а с мобильного интернета работает.

Проверка занимает минуту. Узнайте внешний адрес офиса на 2ip.ru, затем попросите подрядчика поискать его в логах:

# сколько раз этот адрес стучался и с каким результатом
grep '203.0.113.45' ~/logs/example.ru.access.log | tail -30

# он же в списке заблокированных на уровне сервера
sudo iptables -L INPUT -n --line-numbers | grep '203.0.113.45'
sudo fail2ban-client status wordpress

В WordPress с плагинами вроде Limit Login Attempts список банов лежит в админке и снимается в два клика. На уровне сервера правило убирается через iptables -D INPUT по номеру строки или через fail2ban-client set wordpress unbanip. Заодно посмотрите, за что прилетел бан: если это перебор паролей с чужих адресов, у вас на подходе другая проблема, и её лучше решать заранее.

Когда проблема всё-таки на стороне сайта

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

• сервис доступности показывает ошибку минимум из двух разных точек;
• curl из другой сети возвращает 502, 503 или 504;
• сайт открывается, но отдаёт белый экран либо ошибку подключения к базе;
• проблема началась ровно после обновления, деплоя или правки в админке.

Дальше это уже сценарий аварии, а не локальной диагностики: логи, откат последнего изменения, при необходимости восстановление из копии. Порядок действий по ночному падению я разбирал отдельно в статье про то, что делать, когда сайт упал ночью. А чтобы про такие вещи узнавать от системы, а не от клиента через два дня, нужен мониторинг доступности: минимальная связка обходится в пределах 400 рублей в месяц, а бесплатного тарифа UptimeRobot хватает большинству визиток.

Чек-лист перед обращением к подрядчику

Чем точнее данные, тем короче переписка. Соберите до того, как писать:

• точный URL страницы, а не название сайта;
• время, когда это началось, и что делали перед этим;
• дословный текст ошибки или её код, лучше скриншотом целиком, вместе с адресной строкой;
• ваш внешний IP с 2ip.ru;
• сеть и устройство: офисный Wi-Fi, домашний интернет, мобильный, VPN включён или нет;
• воспроизводится ли на другом устройстве в той же сети и на телефоне по мобильному интернету;
• вывод nslookup example.ru и tracert example.ru, если умеете их запустить.

Семь пунктов вместо фразы «у меня не грузится» сокращают диагностику с часа до нескольких минут. Мне такие обращения приходят от клиентов на абонентке, потому что в регламенте это прописано, и разница в скорости ответа заметна невооружённым глазом.

Ещё один нюанс про деньги. Разовое обращение «почините, у меня не открывается» почти всегда заканчивается тем, что чинить нечего: проблема оказывается в кэше или в бане IP, а время на разбор потрачено. В абонентском формате это входит в тариф и не превращается в отдельный счёт, что для владельца сайта обычно спокойнее. Сравнить форматы можно на странице с тарифами: годовой стоит 35 000 рублей, помесячный от 15 000 рублей.

Что сделать прямо сейчас

Порядок короткий: телефон по мобильному интернету, сервис доступности, текст ошибки, сброс DNS, проверка hosts, инкогнито без расширений, VPN выключить, внешний IP проверить на бан. Восемь шагов, десять минут, и вы точно знаете, чинить компьютер или сервер.

Если прошли всё и сайт по-прежнему недоступен, а подрядчик разводит руками, напишите мне через форму на главной с собранным по чек-листу набором данных. Обычно на такой вводной причина находится в первые полчаса. Остальные разборы аварий и диагностик лежат в рубрике про поддержку.

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

Что делать, если сайт открывается не у меня одного

Проверить с мобильного интернета. Работает там значит проблема в вашей сети: кэш DNS, файл hosts, расширение браузера, антивирус или корпоративный прокси.

Как почистить кэш DNS

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

Что за файл hosts и почему он мешает

Это локальная подмена адреса. Строку туда добавляют, когда проверяют сайт на новом хостинге до переключения домена, и регулярно забывают убрать. После переезда она отправляет вас на старый сервер.

Как проверить, что дело не в сайте

Переключиться на публичный сервер имён и открыть сайт заново. Если открылось, проблема была в DNS вашего провайдера, а сайт всё это время работал.