ERR_CONNECTION_REFUSED: что это значит и как исправить

Что такое ERR_CONNECTION_REFUSED?

ERR_CONNECTION_REFUSED — это ошибка Chrome, которая появляется, когда браузер достигает сервера сайта, но сервер активно отказывается принимать соединение. На сетевом уровне ваш компьютер отправил запрос на установку TCP-соединения (SYN) на IP-адрес и порт сервера, а вместо подтверждения сервер — или файрвол перед ним — ответил пакетом сброса (RST), который означает «здесь с вами никто разговаривать не будет».

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

Отказ обычно означает одно из трёх: на этом порту никто не слушает (веб-сервер остановлен или упал), файрвол отклоняет трафик на этот порт, либо ваше устройство подключается вообще не к тому IP-адресу — например, из-за устаревшего DNS-кеша или сломанного прокси.

Как эта ошибка выглядит в других браузерах

Каждый браузер сообщает об отклонённом соединении по-своему, но лежащий в основе TCP-отказ идентичен.

Браузеры на базе Chromium (Chrome, Edge, Brave, Opera) показывают «сырой» код ERR_CONNECTION_REFUSED. Firefox и Safari формулируют это простым языком, но причина и способы решения абсолютно те же.

Частые причины ERR_CONNECTION_REFUSED

Примерно в половине случаев проблема на стороне сервера, а в половине — что-то мешает на вашем устройстве или в сети. Вот самые частые причины — от наиболее к наименее распространённым.

• Сервер сайта не работает — Веб-сервис (nginx, Apache, Node.js) упал, перезапускается или был остановлен. Машина в сети, но на портах 80/443 никто не отвечает.

• Файрвол блокирует порт — Файрвол на сервере, в вашей сети или на вашем устройстве отклоняет подключения к этому порту.

• Неправильные настройки прокси — Система направляет трафик через прокси-сервер, который выключен или недоступен. Одна из самых частых причин на стороне клиента.

• Устаревший DNS-кеш — Сайт переехал на новый сервер, но закешированная DNS-запись всё ещё указывает на старый IP-адрес, где уже никто не слушает.

• Вмешательство VPN или антивируса — Защитное ПО перехватывает соединение и отклоняет его, либо выходной сервер VPN не может достучаться до сайта.

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

• Переопределение в файле hosts — Домен сопоставлен с неправильным IP (часто 127.0.0.1) в файле hosts, поэтому браузер подключается к вашей же машине, которая и отказывает.

• На localhost никто не слушает — Для разработчиков: локальный dev-сервер не запущен, упал или привязан к другому порту, а не к тому, который вы открыли.

• Проблема с роутером — Сбойнувший роутер или модем портит соединения, пока его не перезагрузят.

Решение 1: проверьте, не лежит ли сайт для всех

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

Самый надёжный способ проверить — зайти с другого сетевого пути. Откройте сайт на телефоне через мобильный интернет (Wi-Fi выключен). Если и там не работает, значит сервер сам отклоняет соединения, и остаётся только ждать, пока владелец сайта всё починит.

Также вы можете протестировать сервер напрямую с помощью этих инструментов DNS Robot:

• [Port Checker](/port-checker) — Введите домен сайта и проверьте порт 443 (HTTPS) и порт 80 (HTTP). Если оба показывают «закрыт», веб-сервер лежит или закрыт файрволом для всех, а не только для вас.

• [Ping Test](/ping) — Проверяет, отвечает ли серверная машина вообще. Если ping проходит, но порты закрыты, машина работает, а веб-сервис мёртв.

• [HTTP Headers Checker](/http-headers) — Отправляет настоящий HTTP-запрос с серверов DNS Robot. Если он получает ответ, а ваш браузер нет, проблема локальная — на вашем устройстве или в сети.

Решение 2: перезагрузите роутер и устройство

Классический первый шаг не просто так: перезагрузка очищает таблицу соединений роутера, DNS-кеш и сбойное состояние NAT, из-за которых соединения могут отклоняться.

Отключите роутер (и модем, если он отдельный) от питания, подождите 30 секунд, включите обратно и дайте ему 2–3 минуты на полное переподключение. Перезагрузите и компьютер или телефон, чтобы сбросить его сетевой стек, затем откройте сайт снова.

Решение 3: очистите кеш и cookie браузера

Chrome мог закешировать сломанный редирект, старую запись HSTS или cookie, которые ведут вас на мёртвый сервер. Их очистка заставляет браузер установить полностью новое соединение.

• Откройте Chrome → нажмите меню с тремя точками → Удалить данные о работе в браузере

• Временной диапазон → выберите Всё время

• Отметьте «Файлы cookie и другие данные сайтов» и «Изображения и другие файлы, сохранённые в кеше»

• Нажмите «Удалить данные», перезапустите Chrome и попробуйте открыть сайт снова

Решение 4: отключите настройки прокси

Неправильно настроенный или мёртвый прокси — одна из самых частых причин ERR_CONNECTION_REFUSED сразу на всех сайтах. Когда система настроена направлять трафик через прокси, которого больше не существует — часто он остаётся от старого VPN, рабочей/учебной конфигурации или вредоносного ПО, — каждое соединение отклоняется.

Windows: откройте Параметры → Сеть и Интернет → Прокси-сервер. Выключите «Использовать прокси-сервер» в разделе ручной настройки прокси и выключите «Определять параметры автоматически», если вы не пользуетесь корпоративным прокси.

macOS: откройте Системные настройки → Сеть → Wi-Fi → Подробнее → Прокси. Снимите отметки со всех протоколов в списке (веб-прокси HTTP, защищённый веб-прокси HTTPS, прокси SOCKS), если они не требуются вашей организации, затем нажмите OK.

Chrome использует прокси-настройки операционной системы, поэтому после их изменения перезапустите браузер и проверьте снова.

Решение 5: очистите DNS-кеш

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

# Windows (Command Prompt as Administrator)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Also clear Chrome's internal DNS cache:
# chrome://net-internals/#dns → Clear host cache

После очистки сбросьте и собственный DNS-кеш Chrome на странице chrome://net-internals/#dns, а также пулы сокетов на chrome://net-internals/#sockets — Chrome хранит и то и другое отдельно от операционной системы. Полное пошаговое руководство — в нашей статье о том, как очистить DNS-кеш на любой ОС.

Проверить, в какой IP домен разрешается прямо сейчас, можно с помощью DNS Lookup от DNS Robot — если nslookup в вашем терминале показывает другой IP, чем глобальный результат, проблема была в кеше.

Решение 6: переключитесь на публичный DNS-сервер

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

Windows: Параметры → Сеть и Интернет → ваше подключение → Изменить назначение DNS-сервера → Вручную → включите IPv4 → введите 1.1.1.1 и 1.0.0.1 → Сохранить.

macOS: Системные настройки → Сеть → Wi-Fi → Подробнее → DNS → добавьте 1.1.1.1 и 1.0.0.1, удалите старые записи → OK.

Не уверены, какой резолвер быстрее из вашего местоположения? Запустите DNS Speed Test от DNS Robot — он за секунды измерит скорость Cloudflare, Google, Quad9 и других с вашего собственного подключения.

Решение 7: временно отключите VPN, антивирус и файрвол

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

Проверяйте в таком порядке: отключите VPN и обновите страницу. Затем на минуту отключите модуль веб-защиты антивируса и обновите страницу. Наконец, ненадолго выключите файрвол (брандмауэр Защитника Windows или файрвол macOS) и обновите страницу.

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

Решение 8: проверьте расширения в режиме инкогнито

Блокировщики рекламы, инструменты приватности и VPN-расширения могут незаметно блокировать подключения к отдельным хостам. Быстрый тест: откройте сайт в окне инкогнито (Ctrl+Shift+N / Cmd+Shift+N), где большинство расширений по умолчанию отключены.

Если в инкогнито сайт открывается, причина в расширении. Зайдите на chrome://extensions, отключите все расширения, а затем включайте их по одному, пока ошибка не вернётся, — это и есть виновник. Удалите его или исключите сайт из его фильтров.

Решение 9: проверьте файл hosts

Файл hosts переопределяет DNS для отдельных доменов. Если сайт сопоставлен там с 127.0.0.1, 0.0.0.0 или старым IP сервера, браузер подключается по этому адресу — и получает отказ. Обычные подозреваемые — забытые записи со времён разработки и hosts-списки блокировки рекламы.

# Windows — open as Administrator:
notepad C:\Windows\System32\drivers\etc\hosts

# macOS / Linux:
sudo nano /etc/hosts

# Look for lines containing the domain, e.g.:
# 127.0.0.1   example.com   ← forces the connection to your own PC
# 203.0.113.7 example.com   ← forces an old server IP

# Delete the offending line, save, then flush DNS.

Localhost не позволяет установить соединение (для разработчиков)

Увидеть localhost refused to connect или ERR_CONNECTION_REFUSED на 127.0.0.1 — обряд посвящения для каждого разработчика. Это значит, что на вашей машине никто не принимает соединения на запрошенном порту. Обычные причины:

• Dev-сервер не запущен — Вы его не запустили, или он упал. Проверьте терминал, где должны работать npm run dev, rails s или python manage.py runserver.

• Не тот порт — Сервер запустился на другом порту (например, на 3001, потому что 3000 был занят), а вы открываете старый. Прочитайте строку в логе запуска — там указано, к какому порту он привязался.

• Привязка к другому интерфейсу — Сервер привязался к 0.0.0.0 или к внутреннему IP контейнера, а вы обращаетесь к localhost — или наоборот. Проброс портов в Docker (-p 3000:3000) должен совпадать с портом, который приложение слушает внутри контейнера.

• Файрвол или защитное ПО — Локальные файрволы могут блокировать даже loopback-порты; это частая ситуация на корпоративных машинах.

• HTTPS вместо HTTP — Вы открываете https://localhost:3000, а dev-сервер понимает только обычный HTTP. Попробуйте явно указать http://.

# Which process is listening on port 3000?
# macOS / Linux:
lsof -i :3000

# Windows (PowerShell):
netstat -ano | findstr :3000

# No output = nothing is listening = connection refused.
# Start your dev server, or kill the stale process and restart it.

Если нужно проверить, доступен ли порт вашего публичного сервера из интернета (а не только с самой машины), используйте Port Checker от DNS Robot — он проверяет соединение снаружи вашей сети, то есть именно так, как его видят ваши посетители.

Владельцам сайтов: ваш сайт отклоняет соединения

Если посетители сообщают об ERR_CONNECTION_REFUSED на вашем собственном сайте, сервер работает (DNS разрешается, машина, скорее всего, отвечает на ping), но веб-сервис не принимает соединения. Пройдитесь по этому чек-листу:

• Запущен ли процесс веб-сервера? Подключитесь по SSH и проверьте: systemctl status nginx (или apache2, caddy). Причина №1 — процесс, упавший после неудачного reload или убитый из-за нехватки памяти. Перезапустите его: sudo systemctl restart nginx.

• Слушает ли он нужные порты? Выполните ss -tlnp | grep -E ':80|:443'. Если на 443 никто не слушает, не загрузилась TLS-конфигурация — проверьте nginx -t на ошибки конфига.

• Открыт ли файрвол? Проверьте ufw status или security group вашего облачного провайдера. Порты 80 и 443 должны разрешать входящий TCP с 0.0.0.0/0.

• Не сменился ли IP сервера? Сравните A-запись в DNS с фактическим IP сервера через DNS Lookup. После миграции старая A-запись отправляет посетителей на прежнюю машину.

• Проверьте снаружи — Используйте Port Checker для портов 80 и 443 и HTTP Headers Checker, чтобы убедиться, что сервер отвечает на реальные запросы из публичного интернета.

Как убедиться, что проблема решена

После каждого исправления проверяйте соединение на сетевом уровне, а не просто обновляйте страницу — так вы узнаете, действительно ли порт открылся.

# Test the TCP connection directly (Mac/Linux):
nc -zv example.com 443
# "succeeded" = port open, "refused" = still rejected

# Windows (PowerShell):
Test-NetConnection example.com -Port 443
# TcpTestSucceeded : True = fixed

# Then confirm what IP you're actually connecting to:
nslookup example.com

Или обойдитесь без терминала: введите домен и порт в Port Checker от DNS Robot и мгновенно получите ответ «открыт/закрыт» из внешней сети. Если порт снаружи открыт, а браузер всё ещё показывает ERR_CONNECTION_REFUSED, блокировка на вашем устройстве — вернитесь к решениям с прокси, VPN, антивирусом и файлом hosts выше.