ERR_CONNECTION_REFUSED: что за ошибка и как исправить

ERR_CONNECTION_REFUSED — браузерная ошибка: браузер попытался открыть TCP-соединение с сайтом, но удалённая сторона отказалась его принимать. Обычно это выглядит как «Не удается получить доступ к сайту» в Chrome или Edge с кодом ERR_CONNECTION_REFUSED.

Ошибка неприятна тем, что не похожа на обычный HTTP-код вроде 404, 500 или 503: страница вообще не успевает ответить, проблема возникает раньше — на уровне соединения с IP-адресом и портом. Причины могут быть на стороне пользователя (прокси, VPN, кэш DNS, антивирус) или на стороне сервера: упал веб-сервер, не слушается порт, сломался reverse proxy, фаервол режет входящие подключения.

Разберём, что означает ERR_CONNECTION_REFUSED, чем она отличается от таймаута и HTTP-ошибок, как быстро проверить проблему пользователю и как диагностировать её владельцу сайта или DevOps-инженеру.

Что означает ERR_CONNECTION_REFUSED

Когда вы открываете сайт, браузер проходит несколько этапов:

1) Находит IP-адрес домена — через DNS-запрос.

2) Пытается установить TCP-соединение — обычно с портом 80 для http:// или 443 для https://.

3) Если соединение установлено, начинает HTTP- или HTTPS-обмен — отправляет запрос, получает ответ, загружает HTML, CSS, JS и остальные ресурсы.

ERR_CONNECTION_REFUSED возникает на втором этапе: браузер уже знает, куда подключаться, но соединение не принимается.

Технически это обычно означает, что на целевом IP и порту нет процесса, слушающего входящие подключения, либо промежуточный сетевой компонент активно отклоняет соединение. В TCP это проявляется как быстрый ответ RST вместо обычного трёхстороннего рукопожатия SYN → SYN/ACK → ACK.

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

Для сравнения:

1) ERR_CONNECTION_REFUSED — соединение отклонено. Часто порт закрыт, сервис не запущен или фаервол отвечает отказом.

2) ERR_CONNECTION_TIMED_OUT — ответа нет. Пакеты уходят, но никто не отвечает или ответы теряются по пути.

3) DNS_PROBE_FINISHED_NXDOMAIN — домен не резолвится в IP-адрес.

4) 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout — соединение до веб-сервера или прокси уже состоялось, но дальше возникла проблема на уровне HTTP. Подробнее о таких случаях можно почитать в разборах 502 Bad Gateway, 503 Service Unavailable и 504 Gateway Timeout.

Ключевая мысль: ERR_CONNECTION_REFUSED — это не «сайт вернул ошибку», а «до сайта не удалось установить соединение».

Основные причины ошибки

У ERR_CONNECTION_REFUSED нет одной универсальной причины. Но почти все случаи укладываются в несколько групп.

1) Веб-сервер не запущен — на сервере остановлен nginx, apache2, caddy, Node.js-приложение или другой процесс, который должен принимать подключения. Например, на порту 443 никто не слушает.

2) Сервис слушает не тот порт — приложение запущено на 3000, а reverse proxy проксирует на 127.0.0.1:3001, или HTTPS-сервер настроен только на 80 вместо 443.

3) Сервис слушает только localhost — приложение привязано к 127.0.0.1, а подключиться пытаются извне. Для внешнего доступа нужно слушать, например, 0.0.0.0, если это безопасно и соответствует архитектуре.

4) Ошибка в reverse proxy — Nginx, Caddy, Apache или HAProxy принимает соединение, но upstream недоступен. Пользователь может увидеть не HTTP-ошибку, а отказ соединения, если сам proxy не поднят или слушает не тот порт. Разбор — в статье про Nginx reverse proxy.

5) Фаервол, security group или ACL отклоняют подключение — порт закрыт в ufw, iptables, облачной security group или на сетевом оборудовании. Локально с сервера всё может работать, а извне — ERR_CONNECTION_REFUSED.

6) Проблема с Docker или Docker Compose — контейнер работает, но порт не опубликован наружу, опубликован не тот порт, или приложение внутри контейнера слушает только 127.0.0.1. Подробнее — как работает Docker networking.

7) Неправильный IP в DNS — домен указывает на старый сервер, где нужного сайта уже нет. DNS работает, но соединение идёт не туда.

8) Локальная проблема у пользователя — VPN, корпоративный прокси, антивирус, расширение браузера, файл hosts, кэш DNS или блокировка провайдера.

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

10) Перегрузка или исчерпание ресурсов — реже, но возможно: если сервер не успевает принимать соединения или процессы постоянно рестартуют, пользователь может увидеть отказ соединения.

Что проверить пользователю

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

1) Откройте сайт с другого устройства или сети — например, с мобильного интернета вместо Wi-Fi. Если сайт открывается, проблема, скорее всего, в вашей локальной сети, DNS, прокси или у провайдера.

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

3) Отключите VPN и прокси — особенно если ошибка возникает только на некоторых доменах. В Chrome системные proxy-настройки лучше проверять через настройки ОС: браузер обычно использует их напрямую.

4) Очистите DNS-кэш — на Windows это ipconfig /flushdns, на macOS и Linux команда зависит от DNS-службы. Затем перезапустите браузер.

5) Проверьте файл hosts — на Windows это C:\Windows\System32\drivers\etc\hosts, на Linux и macOS — /etc/hosts. Неправильный IP в этом файле заставит браузер идти не на реальный сервер.

6) Временно отключите проверку HTTPS в антивирусе — только для диагностики и если понимаете риск: некоторые антивирусы перехватывают трафик и могут ломать соединения.

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

8) Попробуйте открыть сайт без https:// или, наоборот, с https:// — если редиректы или порты настроены неправильно, одна схема может отказывать, а другая работать.

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

Как диагностировать проблему владельцу сайта

Если вы отвечаете за сайт, начните с проверки цепочки: DNS → IP → порт → процесс → reverse proxy → приложение.

1) Проверьте, куда указывает домен — dig example.com A или dig example.com AAAA покажет IP-адреса. Если недавно меняли сервер, DNS может ещё не обновиться везде из-за кэша. Подробнее — в статье про утилиту dig.

2) Проверьте порт снаружи — с другой машины выполните curl -v https://example.com/. Если соединение отклонено, curl покажет Connection refused и явно укажет, на каком этапе всё ломается. Если хотите глубже разобраться с ключами, есть отдельный материал что такое curl и как им пользоваться.

3) Проверьте, слушает ли сервер порт — на сервере выполните ss -lntp или netstat -lntp. Ищите строки с :80 и :443, а также порты внутренних приложений: :3000, :8000, :8080. Про ss есть подробный разбор: современная альтернатива netstat.

4) Проверьте статус служб — systemctl status nginx, systemctl status apache2, systemctl status caddy, systemctl status your-app. Если сервис упал, смотрите журнал: journalctl -u nginx -xe, journalctl -u your-app -n 100.

5) Проверьте конфигурацию веб-сервера — nginx -t для Nginx, apachectl configtest для Apache. Ошибка в конфиге может не дать сервису перезапуститься после деплоя.

6) Проверьте логи доступа и ошибок — для Nginx это обычно /var/log/nginx/access.log и /var/log/nginx/error.log. Если при обращении снаружи в access-логе нет записей, запросы могут не доходить до Nginx вообще: смотрите DNS, фаервол, security group, балансировщик.

7) Проверьте фаервол — ufw status, правила iptables или nftables, облачные security groups. Если порт 443 закрыт, браузер не подключится, даже если Nginx работает.

8) Проверьте IPv6 — если у домена есть AAAA-запись, браузер может пробовать IPv6. Сайт может быть доступен по IPv4, но отказывать по IPv6 из-за отсутствующего слушателя или фаервола. Проверьте curl -4 -v https://example.com/ и curl -6 -v https://example.com/.

9) Проверьте балансировщик или CDN — если перед сервером стоит Cloudflare, HAProxy, Nginx ingress или облачный load balancer, отказ может происходить между клиентом и балансировщиком либо между балансировщиком и origin-сервером. Уточните, на каком участке рвётся соединение.

10) Сравните с мониторингом доступности — если внешний мониторинг показывает падение сразу после деплоя или изменения DNS, это сильно сужает поиск. Например, Statuser проверяет сайт с заданным интервалом и присылает уведомление о сбое — так проще понять, когда началась проблема и была ли она видна извне.

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

Исправление зависит от причины. Ниже — типовые действия, которые чаще всего возвращают сайт в рабочее состояние.

1) Запустите или перезапустите веб-сервер — если nginx остановлен, выполните systemctl restart nginx и проверьте systemctl status nginx. Если сервис не стартует, не перезапускайте его по кругу вслепую: сначала смотрите ошибку в journalctl и проверяйте конфигурацию через nginx -t.

2) Убедитесь, что порт открыт и прослушивается — ss -lntp должен показывать процесс на 0.0.0.0:80, 0.0.0.0:443, [::]:80 или [::]:443, если сайт должен быть доступен извне. Если видите только 127.0.0.1:443, внешние подключения не попадут на сервис.

3) Исправьте listen в конфигурации — в Nginx для HTTPS обычно нужны директивы listen 443 ssl; и корректный server_name, для HTTP — listen 80;. После правок: nginx -t и systemctl reload nginx.

4) Проверьте upstream приложения — если Nginx проксирует на http://127.0.0.1:3000, приложение должно реально слушать этот адрес. Выполните curl -v http://127.0.0.1:3000/ прямо на сервере: если и локальный запрос получает отказ, проблема не в Nginx, а в приложении.

5) Исправьте привязку адреса в приложении — в Node.js, Go, Python и других рантаймах сервис может слушать только localhost. Для контейнера это частая ошибка: приложение внутри Docker слушает 127.0.0.1, и порт недоступен через проброс. Обычно нужно слушать 0.0.0.0, но не забывайте ограничивать доступ через reverse proxy и фаервол.

6) Откройте порты в фаерволе — для UFW это ufw allow 80/tcp и ufw allow 443/tcp. Перед изменениями проверьте текущие правила, чтобы не открыть лишнее. Практические основы есть в инструкции как настроить фаервол с помощью UFW в Ubuntu.

7) Проверьте облачные security groups — в AWS, Selectel, Yandex Cloud, VK Cloud и других платформах локальный фаервол может быть открыт, а внешний доступ закрыт на уровне виртуальной сети. Разрешите входящие TCP-подключения на 80 и 443 от нужных источников.

8) Исправьте Docker-публикацию портов — в docker run должен быть проброс вида -p 80:80 или -p 443:443, в Docker Compose — секция ports, например "80:80". Если указали только expose, порт останется доступен в рамках сети контейнеров, но не опубликуется на хосте и будет недоступен снаружи.

9) Проверьте, не занят ли порт другим процессом — если Nginx не стартует с ошибкой address already in use, найдите процесс через ss -lntp или lsof -i :443 и решите, какой сервис должен слушать этот порт.

10) Откатите последний деплой или конфигурацию — если ошибка началась сразу после релиза, первые кандидаты на проверку — изменения в nginx.conf, Docker Compose, systemd unit, переменных окружения или DNS. Быстрый откат часто лучше долгой правки на продакшене, особенно если сайт уже недоступен пользователям.

ERR_CONNECTION_REFUSED на localhost: типичные причины у разработчиков

ERR_CONNECTION_REFUSED часто встречается не только на продакшене, но и при локальной разработке: http://localhost:3000, http://127.0.0.1:8000, http://localhost:5173. Причины здесь немного другие.

1) Dev-сервер не запущен — забыли выполнить npm run dev, pnpm dev, python manage.py runserver, uvicorn app:app --reload или аналогичную команду.

2) Порт отличается от ожидаемого — Vite поднялся на 5174, потому что 5173 занят. Backend слушает 8000, а frontend обращается к 3000.

3) Процесс упал после старта — в терминале могла быть ошибка компиляции, отсутствующая переменная окружения или конфликт версий Node.js или Python.

4) Используется неверный host — приложение в WSL, Docker или виртуальной машине может быть доступно не там, где вы ожидаете. Например, localhost внутри контейнера — это сам контейнер, а не хостовая машина.

5) Неправильно настроен proxy в dev-сервере — frontend-приложение работает, но API-запросы уходят на http://localhost:5000, где ничего не слушает.

6) Конфликт IPv4 и IPv6 — localhost может резолвиться в ::1, а приложение слушает только 127.0.0.1. Попробуйте явно открыть http://127.0.0.1:3000 или настроить сервер на оба адреса.

7) Браузер обращается к HTTPS вместо HTTP — сервер поднят на http://localhost:3000, а в адресной строке или редиректе используется https://localhost:3000. Если TLS на этом порту не настроен, результат может быть похожим на сетевую ошибку.

При локальной разработке самый быстрый путь — посмотреть терминал с процессом, проверить порт через ss -lntp или lsof -i :3000, затем выполнить curl -v http://127.0.0.1:3000/.

Чем ошибка отличается от проблем HTTPS, DNS и HTTP

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

1) DNS не резолвится — браузер не знает IP-адрес, это проблема до TCP-соединения. Проверяется через dig, nslookup и записи A, AAAA, CNAME.

2) TLS/HTTPS сломан — TCP-соединение установлено, но handshake или сертификат не проходят: браузер покажет ERR_SSL_PROTOCOL_ERROR, NET::ERR_CERT_DATE_INVALID или похожий код. Подробнее — как работает HTTPS.

3) Сервер отвечает HTTP-ошибкой (500, 502, 503, 504) — соединение уже установлено, веб-сервер или прокси жив, но приложение, upstream или зависимость работают неправильно.

4) Таймаут — браузер ждёт, но не получает ответа: пакеты может молча дропать фаервол, либо проблема в маршрутизации или на перегруженном сервере.

5) Отказ соединения (ERR_CONNECTION_REFUSED) — ответ обычно приходит быстро: «на этом адресе и порту подключение не принимается». Поэтому в первую очередь проверяют слушающие порты, запущенные процессы и правила фаервола.

Такой порядок проверки экономит время: не стоит разбираться с сертификатом, если curl даже не может установить TCP-соединение с 443, и наоборот — если TCP работает, а браузер ругается на сертификат, перезапуск приложения на 3000 не поможет.

Как снизить риск повторения

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

1) Проверяйте конфигурацию перед reload — nginx -t, apachectl configtest, валидация Docker Compose, проверка systemd units. Ошибка в конфиге не должна попадать в продакшен незамеченной.

2) Добавьте health checks — у приложения должен быть простой endpoint вроде /health, который проверяет не только факт запуска процесса, но и критичные зависимости. Для Node.js-сервисов есть отдельный практический материал про health checks.

3) Настройте автозапуск сервисов — systemd unit должен иметь корректный Restart=, зависимости и переменные окружения. Если процесс падает из-за временной ошибки, он должен восстановиться или хотя бы явно показать причину в логах.

4) Не деплойте без smoke-теста — после релиза автоматически проверяйте главную страницу, API endpoint, HTTPS, редиректы и ключевые маршруты. Минимальный curl -f https://example.com/health уже лучше, чем отсутствие проверки.

5) Следите за портами и процессами — мониторинг сервера должен видеть, что nginx запущен, порт 443 слушается, а приложение не находится в цикле рестартов.

6) Настройте внешний мониторинг доступности — внутренняя проверка на сервере не заменяет взгляд пользователя снаружи. Statuser, например, проверяет сайт с заданным интервалом и отправляет уведомление при сбое; это помогает заметить отказ соединения, даже если сам сервер «думает», что всё работает. Подробнее о подходе — в статье что такое uptime monitoring и как он работает.

7) Документируйте изменения инфраструктуры — DNS, firewall, security groups, reverse proxy, Docker Compose и переменные окружения должны меняться через понятный процесс. Тогда при сбое проще откатиться и найти причину.

8) Разделяйте проверки разных уровней — DNS, TCP, TLS, HTTP, приложение, база данных. Если мониторинг показывает только «сайт не работает», расследование займёт больше времени. Лучше видеть, где именно рвётся цепочка.

FAQ

Почему Chrome пишет ERR_CONNECTION_REFUSED, а сайт у других открывается?

Скорее всего, проблема локальная: VPN, прокси, DNS-кэш, файл hosts, антивирус или сеть провайдера. Проверьте сайт с мобильного интернета и другого браузера.

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

Обычно нет. Ошибки сертификата возникают после установки TCP-соединения. Но неправильная настройка HTTPS-порта или веб-сервера может привести к отказу соединения на 443.

Что первым проверить на сервере?

Проверьте, слушает ли кто-то порты 80 и 443: ss -lntp. Затем статус веб-сервера, логи, фаервол и DNS-записи домена.

Почему localhost выдаёт ERR_CONNECTION_REFUSED?

На указанном порту нет запущенного процесса, приложение слушает другой порт или привязано к другому адресу. Проверьте терминал dev-сервера и выполните curl -v http://127.0.0.1:порт/.