ERR_CONNECTION_REFUSED: Что это означает и как полностью исправить эту ошибку

Ошибка ERR_CONNECTION_REFUSED означает, что ваш браузер отправил запрос на подключение к веб-серверу, и этот сервер активно отклонил его — не проигнорировал, а явно отказал в TCP-рукопожатии. Это принципиально иной тип сбоя по сравнению с таймаутом (ERR_CONNECTION_TIMED_OUT) или ошибкой DNS (ERR_NAME_NOT_RESOLVED), и это различие крайне важно при диагностике первопричины.

На практике, когда Chrome отображает «Этот сайт недоступен. ERR_CONNECTION_REFUSED», это означает одно из трёх: целевой сервер не прослушивает запрошенный порт, брандмауэр или уровень безопасности отправляет TCP RST (сброс) пакет обратно клиенту, или локальный сетевой стек настроен неправильно и маршрутизирует запрос некорректно ещё до того, как он достигает сервера. Определение того, какая из этих трёх категорий применима к вашей ситуации, — это кратчайший путь к решению проблемы.

Понимание механики на уровне TCP

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

Это различие имеет практическое значение для диагностики: если бы соединение молча отбрасывалось брандмауэром, вы бы увидели ERR_CONNECTION_TIMED_OUT. Отказ в соединении означает, что что-то активно отвечает — то есть хост доступен на сетевом уровне, но служба на целевом порту недоступна или заблокирована.

Распространённые причины на уровне портов:

• Процесс веб-сервера (Apache, Nginx, Node.js) завис или остановлен
• Сервер прослушивает нестандартный порт, и URL его не указывает
• Хостовый брандмауэр (iptables, ufw, Windows Defender Firewall) отклоняет подключения на порту 80 или 443
• Обратный прокси (HAProxy, Nginx, Cloudflare) настроен неправильно и возвращает RST-пакеты на вышестоящий уровень
• Приложение за прокси завершило работу с ошибкой, и прокси не имеет бэкенда для перенаправления запросов

Первопричины: структурированный разбор

Причины на стороне клиента

Причины на стороне сервера

Пошаговое руководство по диагностике и устранению

Шаг 1: Определите, является ли проблема глобальной или локальной

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

• downforeveryoneorjustme.com — простая проверка доступности
• isitdownrightnow.com — включает историю времени отклика
• ping.pe — одновременно пингует цель из нескольких глобальных точек

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

Для администраторов серверов, управляющих собственной инфраструктурой, глобально недоступный сайт требует немедленного расследования процесса веб-сервера, правил брандмауэра и вышестоящей сети. Если вы используете среду VPS Хостинга, сначала проверьте список процессов вашего сервера и конфигурацию брандмауэра.

Шаг 2: Убедитесь, что сервер действительно прослушивает (для администраторов серверов)

Если вы администрируете данный сервер, подключитесь по SSH и выполните следующую команду, чтобы подтвердить, что прослушивается на каких портах:

sudo ss -tlnp | grep -E ':80|:443'

Если вывод пуст для порта 80 или 443, процесс веб-сервера не запущен. Перезапустите его:

# For Nginx
sudo systemctl restart nginx

# For Apache
sudo systemctl restart apache2

# Check status
sudo systemctl status nginx

Также убедитесь, что ваш брандмауэр не блокирует входящие соединения:

# Check iptables rules
sudo iptables -L INPUT -n -v

# If using ufw
sudo ufw status verbose

Если порт 443 заблокирован, разрешите его:

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw reload

Для администраторов, использующих Выделенные серверы, также проверьте, не блокирует ли вышестоящий брандмауэр вашего хостинг-провайдера или правила группы безопасности порт на сетевом периметре — это отдельно от брандмауэра на уровне ОС.

Шаг 3: Перезапустите роутер и сбросьте локальное состояние сети

При проблемах на стороне клиента перезапуск роутера очищает таблицы NAT, аренды DHCP и любые временные сбои маршрутизации. Отключите роутер на 30 секунд, затем подключите снова. Это особенно эффективно, когда ошибка появилась внезапно без каких-либо изменений конфигурации.

Шаг 4: Очистите кэш DNS

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

В Windows:

ipconfig /flushdns

В macOS (Ventura, Sonoma и большинство современных версий):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

В Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

После очистки проверьте, какой IP теперь разрешается для домена:

nslookup example.com
# or
dig +short example.com

Сравните это с известным IP сайта. Если они различаются, распространение DNS может ещё продолжаться.

Шаг 5: Очистите кэш и куки браузера

В Google Chrome перейдите по адресу chrome://settings/clearBrowserData или используйте сочетание клавиш:

• Windows/Linux: Ctrl + Shift + Delete
• macOS: Cmd + Shift + Delete

Установите временной диапазон За всё время, отметьте Кэшированные изображения и файлы и Файлы cookie и другие данные сайтов, затем нажмите Удалить данные. Полностью перезапустите Chrome (не только вкладку) перед повторной проверкой.

Для быстрой проверки без удаления данных откройте окно Инкогнито (Ctrl + Shift + N). Если сайт загружается в режиме инкогнито, но не в обычном окне, причиной является кэшированный ресурс или расширение браузера.

Шаг 6: Проверьте и отключите настройки прокси

Неправильно настроенный или неработающий прокси-сервер является частой причиной ERR_CONNECTION_REFUSED на всех сайтах одновременно. Chrome по умолчанию использует системные настройки прокси.

В Windows:

Перейдите в Параметры > Система > Прокси и отключите «Использовать прокси-сервер», если он включён без вашего ведома. Либо выполните следующую команду в командной строке с повышенными правами:

netsh winhttp reset proxy

В macOS:

Перейдите в Системные настройки > Сеть, выберите активный интерфейс, нажмите Подробнее, затем вкладку Прокси и снимите отметки со всех активных протоколов прокси.

После отключения прокси проверьте сайт. Если он загружается, причиной была конфигурация прокси. Либо настройте её правильно, либо удалите полностью.

Шаг 7: Измените DNS-резолвер

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

Рекомендуемые публичные DNS-резолверы:

В Windows (через PowerShell):

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","1.0.0.1")

В macOS:

Перейдите в Системные настройки > Сеть > [Ваш интерфейс] > Подробнее > DNS, удалите существующие записи и добавьте 1.1.1.1 и 1.0.0.1.

В Linux (systemd-resolved):

Отредактируйте /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4

Затем перезапустите резолвер:

sudo systemctl restart systemd-resolved

Шаг 8: Временно отключите брандмауэр и антивирус

Некоторые антивирусные продукты и хостовые брандмауэры перехватывают HTTPS-трафик через локальный прокси и могут отправлять RST-пакеты при сбое их механизма проверки или когда целевой домен находится в списке блокировки. Временное отключение (только в диагностических целях) подтверждает, являются ли они причиной.

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

Шаг 9: Проверьте в другом браузере и сети

Проверьте URL в Firefox, Edge или Safari. Если он загружается в другом браузере, проблема специфична для Chrome — вероятно, повреждённый профиль, неисправное расширение или специфичная для Chrome настройка прокси. Попробуйте создать новый профиль Chrome для изоляции проблемы.

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

Шаг 10: Проверьте проблемы с конфигурацией SSL/TLS (для администраторов серверов)

Неправильно настроенный SSL-сертификат может привести к сбою сервера или отказу от TLS-соединений, что Chrome в некоторых крайних случаях сообщает как ERR_CONNECTION_REFUSED, а не как ошибку сертификата. Используйте следующую команду для проверки из командной строки:

curl -vI https://yourdomain.com

Обратите внимание на этап TLS-рукопожатия в подробном выводе. Сбой на этом этапе указывает на проблему с сертификатом или набором шифров. Также можно проверить с помощью:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

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

ERR_CONNECTION_REFUSED в сравнении с похожими ошибками браузера

Понимание того, чем эта ошибка отличается от связанных ошибок, предотвращает неверную диагностику:

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

Конфликты разрешения IPv6 и IPv4: Если домен разрешается в IPv6-адрес, но ваша сеть не поддерживает IPv6 должным образом, Chrome может попытаться установить IPv6-соединение, которое будет отклонено, а затем не успеет переключиться на IPv4. Временное отключение IPv6 на сетевом адаптере может подтвердить это. В Linux можно принудительно использовать IPv4 с помощью curl -4 https://example.com.

Кэширование устаревших ошибок источника Cloudflare или CDN: Если сайт использует Cloudflare и исходный сервер выходит из строя, Cloudflare может некоторое время отдавать кэшированную версию, а затем начать возвращать ошибки 521 (origin refused connection) или 522, которые Chrome может отображать как ERR_CONNECTION_REFUSED в зависимости от того, как ошибка проксируется.

Локальные среды разработки: Разработчики часто видят ERR_CONNECTION_REFUSED при обращении к localhost:3000 или аналогичным адресам. Причиной почти всегда является то, что процесс сервера разработки не запущен, завершился с ошибкой или привязан к 127.0.0.1 на другом порту, чем ожидается. Выполните ss -tlnp | grep node (или соответствующий процесс), чтобы подтвердить, что фактически прослушивается.

Конфликты портов почтового сервера: Если вы используете Почтовый хостинг на том же сервере, что и веб-приложение, убедитесь, что конфликты портов между SMTP (25, 587), IMAP (993) и HTTP/HTTPS (80, 443) не приводят к тому, что веб-сервер не может выполнить привязку.

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

Практическая матрица решений: какое исправление применить первым

Используйте этот контрольный список для эффективной сортировки:

• Ошибка появляется на всех сайтах одновременно — сначала проверьте настройки прокси и конфигурацию VPN/брандмауэра
• Ошибка появляется только на одном конкретном домене — проверьте, недоступен ли сайт глобально; затем очистите кэш DNS
• Ошибка появляется только в Chrome, но не в других браузерах — очистите кэш Chrome, отключите расширения или создайте новый профиль Chrome
• Ошибка появляется только в вашей сети, но не через мобильные данные — перезапустите роутер; проверьте DNS или брандмауэр на уровне интернет-провайдера
• Ошибка появилась после изменения конфигурации сервера — проверьте статус процесса веб-сервера, привязки портов и правила брандмауэра на сервере
• Ошибка появляется периодически под нагрузкой — исследуйте исчерпание ресурсов (файловые дескрипторы, память, лимиты соединений) на сервере
• Ошибка появляется только на HTTPS, но не на HTTP — исследуйте действительность SSL-сертификата и конфигурацию TLS
• Ошибка появилась после изменения настроек DNS — отмените изменения DNS и очистите кэш; убедитесь, что новый резолвер доступен

Часто задаваемые вопросы

В чём разница между ERR_CONNECTION_REFUSED и ERR_CONNECTION_TIMED_OUT?

ERR_CONNECTION_REFUSED означает, что сервер (или брандмауэр) активно отправил пакет сброса TCP, немедленно отклонив соединение. ERR_CONNECTION_TIMED_OUT означает, что ответ не был получен в течение периода ожидания — пакеты были молча отброшены. Отказ в соединении появляется быстрее и указывает на активное отклонение, тогда как таймаут свидетельствует о правиле DROP маршрутизации или брандмауэра.

Может ли ERR_CONNECTION_REFUSED быть вызван истёкшим SSL-сертификатом?

Косвенно — да. В некоторых конфигурациях сервера истёкший или неправильно настроенный SSL-сертификат приводит к тому, что процесс веб-сервера не запускается или завершается с ошибкой при обработке TLS-соединений, в результате чего на порту 443 нет прослушивателя. Chrome тогда сообщает ERR_CONNECTION_REFUSED, потому что ничего не прослушивается, хотя основная причина — проблема с сертификатом.

Почему ERR_CONNECTION_REFUSED появляется только на одном конкретном сайте?

Если ошибка изолирована на одном домене, наиболее вероятные причины: веб-служба целевого сервера завершила работу с ошибкой, брандмауэр сервера блокирует ваш диапазон IP, DNS-записи домена указывают на старый IP-адрес, где служба не запущена, или сайт был отключён. Используйте curl -v https://thatdomain.com из другой сети или сервера для изоляции причины.

Как исправить ERR_CONNECTION_REFUSED на localhost?

Сервер приложений не запущен или привязан к другому порту, чем вы запрашиваете. Подтвердите, что прослушивается, с помощью ss -tlnp в Linux/macOS или netstat -ano | findstr :PORT в Windows. Запустите процесс сервера приложений и убедитесь, что он привязан к 0.0.0.0 или 127.0.0.1 на ожидаемом порту.

Всегда ли очистка DNS исправляет ERR_CONNECTION_REFUSED?

Только когда первопричиной является устаревшая запись кэша DNS, указывающая на IP-адрес, где служба больше не работает. Если сервер недоступен, брандмауэр блокирует соединение или прокси настроен неправильно, очистка DNS не даст никакого эффекта. Используйте dig или nslookup для проверки разрешения DNS до и после очистки, чтобы подтвердить, был ли DNS действительно причиной проблемы.