Сайт не открывается только у меня: что делать

Почему сайт может не открываться только у вас

Ситуация знакомая: коллега говорит «да всё работает», а у вас браузер упорно показывает ошибку. Прежде чем звонить разработчику или в техподдержку хостинга, стоит понять простую вещь: недоступность сайта почти всегда бывает либо глобальной (сайт лежит для всех), либо локальной (проблема на вашей стороне — устройство, сеть, провайдер, DNS). Эта статья — про второй случай: что делать, когда сайт не открывается только у вас, а у остальных всё в порядке.

Отделить одно от другого помогает внешняя проверка. Прежде чем копаться в собственном роутере, откройте инструмент проверки доступности сайта и введите адрес проблемного ресурса. Проверка выполняется с внешних серверов, а не с вашего устройства — если сайт отвечает кодом 200 и нормальным временем отклика, значит, он жив, и искать причину нужно локально. Если же внешняя проверка тоже показывает недоступность — это уже другой сценарий, ему посвящён отдельный материал о том, что делать, когда сайт упал.

Шаг 0. Убедитесь, что сайт вообще жив

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

Самый быстрый способ — внешняя проверка. Введите домен в чекер доступности. На что смотреть в результате:

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

Шаг 1. Проверьте соединение с сайтом с вашего устройства

Начните с простого: определите, на каком этапе рвётся соединение. Для этого достаточно ping и curl, они есть в любой операционной системе.

Сначала проверьте, резолвится ли домен и отвечает ли хост по ICMP:

ping example.com

Что смотреть в выводе:

PING example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=54 time=12.3 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=54 time=11.8 ms

Строка с IP-адресом в скобках означает, что DNS-имя разрешилось в адрес — это хороший знак. Если вместо этого вы видите ping: example.com: Temporary failure in name resolution или Не удалось найти узел, значит, проблема в разрешении имени — переходите к шагу про DNS.

Однако ping отвечает далеко не всегда: многие сайты отключают ICMP, чтобы экономить ресурсы и скрываться от сканеров. Поэтому после пинга обязательно проверьте именно HTTP-ответ:

curl -I -L https://example.com

Ключи здесь: -I — запросить только заголовки (HEAD), -L — следовать редиректам. В выводе ищите первую строку:

HTTP/2 200

Если видите 200 (или хотя бы 301/302 с последующим 200 после редиректа) — соединение на уровне приложения работает, сайт доступен, а проблема, скорее всего, в браузере или в том, что открывается конкретно не тот ресурс. Если curl возвращает Could not resolve host — проблема с DNS. Если зависает и падает по таймауту (curl: (28) Connection timed out) — проблема с сетью или маршрутом до сервера.

Шаг 2. Проверьте DNS-резолвинг

Очень часто «сайт не открывается только у меня» на деле означает «мой DNS-резолвер возвращает устаревший или неверный адрес». Это может быть кэш роутера, DNS-сервер провайдера или локальный hosts-файл.

Проверьте, какой адрес реально возвращает ваш текущий резолвер:

nslookup example.com

Сравните ответ вашего резолвера с ответом публичного DNS, например 1.1.1.1 или 8.8.8.8:

nslookup example.com 8.8.8.8

Если адреса различаются — ваш резолвер отдаёт устаревшие данные. Если ваш резолвер вообще не возвращает запись (server can't find example.com: NXDOMAIN), а публичный возвращает, — у вас проблемы с DNS-сервером провайдера или роутера.

Полную картину по DNS-записям домена удобно снять отдельным инструментом — проверкой DNS-записей. Она покажет A, AAAA, NS, MX и другие записи с точки зрения публичных резолверов, без влияния вашего локального кэша.

Порядок действий, если DNS — виновник:

1. Сбросьте локальный DNS-кэш. На Windows: ipconfig /flushdns. На macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. На Linux — зависит от системы, часто sudo systemd-resolve --flush-caches.
2. Перезагрузите роутер — его DNS-кэш тоже устаревает.
3. Смените DNS-сервер на публичный (1.1.1.1, 8.8.8.8, 9.9.9.9) в настройках сетевого адаптера.
4. Проверьте hosts-файл. На Windows — C:\Windows\System32\drivers\etc\hosts, на macOS/Linux — /etc/hosts. Если там есть строка с вашим доменом, ведущая на неправильный IP, закомментируйте или удалите её.

Шаг 3. Проверьте прокси, VPN и расширения браузера

Если DNS в порядке, следующий частый виновник — прокси-сервер, VPN или браузерное расширение, которое «ломает» конкретные сайты.

Прокси и VPN. Сверните VPN и отключите прокси, затем повторите проверку. VPN-сервер может быть в стране, откуда сайт заблокирован по гео, либо сам VPN-провайдер использует нестабильные выходные узлы. В настройках системы проверьте, не прописан ли системный прокси: на Windows — «Параметры → Сеть и Интернет → Прокси», на macOS — «Системные настройки → Сеть → Дополнительно → Прокси».

Расширения браузера. Блокировщики рекламы, анти-трекеры и VPN-расширения — самый частый источник «сайт открывается, но пустой» или «бесконечная загрузка». Быстрый способ локализовать — открыть сайт в режиме инкогнито (расширения в нём обычно отключены). Если в инкогнито сайт открывается — отключайте расширения по одному.

Браузерный кэш. Иногда мешает повреждённый кэш. Жёсткая перезагрузка: Ctrl+Shift+R (Windows/Linux) или Cmd+Shift+R (macOS). Если не помогло — очистите кэш и cookies для конкретного сайта.

Шаг 4. Проверьте сетевой маршрут до сервера

Когда всё перечисленное не помогло, стоит посмотреть, где именно по пути до сервера рвётся соединение. Для этого используется трассировка маршрута:

traceroute example.com

На Windows команда называется tracert example.com. В выводе — последовательность узлов (хопов) от вас до сервера с временем отклика каждого:

 1  _gateway (192.168.1.1)  1.204 ms  1.110 ms  1.087 ms
 2  10.20.0.1  8.311 ms  8.222 ms  8.190 ms
 3  87.245.192.1  10.501 ms  9.988 ms  10.112 ms
 4  * * *

Здесь важны две вещи. Во-первых, на каком хопе начинаются звёздочки * * * — это признак, что дальше этого узла пакеты не проходят или не возвращаются. Во-вторых, резкий рост задержки на каком-то участке говорит о перегруженном или неисправном промежуточном узле. Если трасса «умирает» на узле вашего провайдера — проблема на его стороне, и это объясняет, почему сайт не открывается только у вас и соседей по этому провайдеру, но работает у остального мира.

Шаг 5. Проверьте IPv6 и MTU

Ещё два «тихих» виновника, о которых часто забывают, — протокол IPv6 и размер пакета (MTU). Они дают ровно тот симптом «у меня не открывается, у других открывается».

IPv6. Современные браузеры пробуют подключаться и по IPv6, и по IPv4. Если у сайта есть AAAA-запись, но IPv6-маршрут до него у вашего провайдера сломан, браузер может долго висеть или падать с ошибкой, тогда как пользователи с корректным IPv6 подключаются нормально. Проверьте, есть ли у домена IPv6-адрес:

dig example.com AAAA +short

Если запись есть, а сайт у вас не открывается, временно отключите IPv6 на сетевом адаптере и проверьте снова. Это классический источник «плавающих» проблем, которые сложно воспроизвести у другого человека.

MTU. Если сайт открывается, но «зависает» на середине загрузки — грузится шапка, а картинки и скрипты нет, — причиной может быть неправильный размер пакета (MTU) на пути, особенно через VPN или PPPoE-подключения провайдеров. Большие пакеты теряются, мелкие проходят. Диагностируется это так:

ping -M do -s 1472 example.com

Ключ -M do запрещает фрагментацию пакета. Если пинг с большим размером пакета не проходит, а обычный проходит, — на пути есть узел с меньшим MTU, и нужно уменьшить MTU на вашем интерфейсе или в настройках VPN.

Шаг 6. Проверьте доступность по IP и по порту

Полезный приём — разделить проблему DNS и проблему сети. Если домен не резолвится, но вы знаете IP-адрес сайта (например, из внешней проверки DNS), попробуйте обратиться напрямую по IP:

curl -I -k --resolve example.com:443:93.184.216.34 https://example.com

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

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

nc -zv example.com 443

Или через telnet (Windows): telnet example.com 443. Успешный вывод Connection to example.com 443 port [tcp/https] succeeded! означает, что порт открыт и проблема выше по стеку. Если соединение отклоняется или виснет — порт закрыт фильтром (файрволом, провайдером) либо сервер физически недоступен.

Сводная таблица: симптом → причина → решение

Проверьте с другого устройства и из другой сети

Лучший способ быстро сузить круг причин — сменить точку наблюдения. Это занимает минуту и даёт очень много информации:

1. Другое устройство в той же сети. Включите мобильный интернет на телефоне и откройте сайт оттуда. Если на мобильном интернете сайт работает, а на домашнем Wi-Fi — нет, проблема в вашей сети (роутер, провайдер), а не в устройстве.
2. Другая сеть на том же устройстве. Подключите ноутбук к мобильной точке доступа. Если сайт заработал — проблема в домашней сети или её DNS.
3. Сосед по Wi-Fi. Попросите кого-то из той же сети открыть сайт — если и у него не работает, это сеть или провайдер, а не ваш браузер.

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

Блокировка сайта провайдером или по гео

Отдельный и довольно частый в определённых юрисдикциях сценарий — сайт заблокирован на уровне провайдера или государственного реестра. Симптомы похожи на «упал», но у остального мира сайт отлично работает, а внешняя проверка доступности показывает 200.

Как распознать блокировку:

• Внешняя проверка доступности показывает, что сайт жив и отвечает нормально.
• traceroute «умирает» на одном и том же узле провайдера, дальше пакеты не идут.
• При прямом обращении по IP сайт тоже не открывается, хотя DNS резолвится.
• С другого провайдера или через VPN сайт открывается без проблем.

Проверить доступность с разных точек помогает тот же чекер доступности — если с внешних серверов сайт отвечает 200, а у вас нет, и локальные шаги (DNS, прокси, браузер) исключены, вероятность сетевой блокировки высока. В таком случае решение — сменить DNS-резолвер (некоторые блокировки обходятся через альтернативный DNS) или использовать VPN, помня о юридической стороне вопроса в вашей стране.

Что делать, если причина — не у вас

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

1. Подождите. Кратковременные сбои при деплоях и перезапусках сервера — обычное дело.
2. Свяжитесь с владельцем. Если сайт важен, сообщите о проблеме — укажите время, что именно вы видите (код ошибки, сообщение браузера) и результат внешней проверки.
3. Проверьте позже. Настройте повторную проверку через инструмент мониторинга доступности, чтобы узнать, когда сайт снова заработает.

Владельцу сайта в такой ситуации пригодится систематический подход — мы разобрали его в отдельном материале: «Сайт упал: чек-лист диагностики».

Коротко

Сайт не открывается только у вас — в девяти случаях из десяти это локальная проблема: DNS-кэш, VPN, расширение браузера или сеть провайдера. Порядок действий простой: сначала убедиться внешней проверкой, что сайт вообще жив, затем идти от быстрого к сложному — curl и ping, DNS, прокси и расширения, трассировка и порты. Каждый шаг описан выше с конкретными командами, которые вы можете выполнить прямо сейчас. А чтобы не гадать в следующий раз, добавьте проблемный сайт в регулярную проверку UptimeChecker — она покажет, когда недоступность была глобальной, а когда всё-таки на вашей стороне.