Исправление ошибки ERR_CONNECTION_REFUSED в Chrome

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

Что нужно понять в первую очередь

• “Соединение отклонено” обычно значит: на IP/порту нет слушающего процесса или соединение блокируется промежуточным узлом. Это не всегда проблемa сертификата TLS (это другая ошибка).
• Диагностика идёт сверху вниз: сначала убедитесь, что сервер доступен, затем исключите локальные причины (браузер, ОС, сеть), и в конце — сервер/хостинг.

Быстрый план действий

1. Проверить статус сайта (удален ли он).
2. Перезагрузить маршрутизатор и компьютер.
3. Очистить кэш и куки в Chrome.
4. Сменить DNS на публичный (Google/OpenDNS) и пропинговать домен.
5. Отключить прокси, расширения, временно брандмауэр/антивирус.
6. Проверить файл hosts и локальные сетевые настройки.
7. Диагностировать с помощью curl / telnet / netstat / ss.
8. Сбросить настройки Chrome или переустановить.

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

1. Проверка доступности сайта

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

• Используйте сервисы проверки доступности: Down for Everyone or Just Me (или аналог в вашем регионе).
• Откройте сайт с другого устройства (смартфон по мобильному интернету) или попросите коллегу.
• Попробуйте запрос через curl или ping (если сервер отвечает на ping):

curl -I https://example.com
ping -c 4 example.com

Если ответов нет или возвращается “connection refused”, проблема, скорее всего, на стороне сервера или у хостинга.

2. Перезагрузка маршрутизатора и модема

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

Шаги:

1. Выключите модем/роутер на 30 секунд.
2. Включите обратно и дождитесь полной загрузки.
3. Переподключитесь и проверьте сайт.

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

3. Очистка кэша и данных Chrome

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

Инструкция:

1. Откройте Chrome.
2. Нажмите меню (три точки) → Настройки.
3. Слева выберите “Конфиденциальность и безопасность”.
4. Нажмите “Очистить данные просмотра”.
5. Во вкладке “Дополнительно” отметьте “Кэшированные изображения и файлы” и при необходимости “Файлы cookie и другие данные сайтов”.
6. Нажмите “Очистить данные”.
7. Перезапустите браузер.

Если проблема исчезла, причина была в локальном кэше.

4. Смена DNS‑серверов

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

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

• Google DNS: 8.8.8.8 и 8.8.4.4
• OpenDNS: 208.67.222.222 и 208.67.220.220

Инструкции для Windows:

1. Откройте «Параметры» → Сеть и Интернет → Изменить параметры адаптера.
2. Правой кнопкой по нужному адаптеру → Свойства.
3. Выберите “IP версии 4 (TCP/IPv4)” → Свойства.
4. Отметьте “Использовать следующие адреса DNS‑серверов” и введите 8.8.8.8 и 8.8.4.4.
5. OK → Закрыть.
6. Перезапустите Chrome.

Инструкции для macOS:

1. Откройте Системные настройки → Сеть.
2. Выберите подключение → Дополнительно → Вкладка DNS.
3. Удалите старые DNS, нажмите “+” и добавьте 8.8.8.8, затем 8.8.4.4.
4. OK → Применить.

После смены DNS выполните очистку кэша DNS в системе:

Windows:

ipconfig /flushdns

macOS (зависит от версии):

sudo killall -HUP mDNSResponder

Linux (systemd‑based):

sudo systemd-resolve --flush-caches

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

5. Отключение прокси

Прокси может перехватывать соединения и приводить к ошибкам. Отключите прокси и проверьте снова.

Windows:

1. Откройте Параметры → Сеть и Интернет → Прокси.
2. Отключите “Использовать прокси‑сервер“ и проверьте.

macOS:

1. Меню Wi‑Fi → Открыть настройки сети.
2. Выберите подключение → Дополнительно → Прокси.
3. Снимите все галочки прокси → OK → Применить.

Если вы используете корпоративную прокси‑сеть, согласуйте действия с IT‑отделом.

6. Проверка и временное отключение брандмауэра и антивируса

Локальный брандмауэр или антивирус может блокировать исходящие подключения Chrome.

Windows (временное):

1. Панель управления → Система и безопасность → Брандмауэр Защитника Windows.
2. Слева — “Включение и отключение брандмауэра Защитника Windows”.
3. Временно отключите для частной и публичной сетей.
4. Проверьте сайт — если заработало, настройте правило для Chrome, а затем снова включите брандмауэр.

macOS:

1. Системные настройки → Безопасность и безопасность → Вкладка “Брандмауэр“.
2. Отключите брандмауэр временно и проверьте.

Важно: не оставляйте систему без защиты длительное время; делайте временное отключение только для диагностики.

7. Отключение расширений Chrome

Иногда расширения вмешиваются в сетевые запросы (например, блокировщики рекламы, VPN‑расширения).

Шаги:

1. Меню → Дополнительные инструменты → Расширения.
2. Отключите все расширения.
3. Перезапустите Chrome и проверьте.
4. Включайте расширения по одному, чтобы найти проблемное.

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

8. Проверка файла hosts и локального сетевого конфигурирования

Файл hosts может форсировать резолв домена на неверный IP или 127.0.0.1, что ведёт к “соединение отклонено”.

Windows: файл расположен в C:\Windows\System32\drivers\etc\hosts.
macOS/Linux: /etc/hosts.

Откройте файл и убедитесь, что для проблемного домена нет строк типа:

127.0.0.1 example.com

Удалите или закомментируйте такие строки и сохраните файл (требуются права администратора).

9. Сброс настроек Chrome

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

Шаги:

1. Меню → Настройки.
2. Слева — Дополнительно → Сброс настроек.
3. Нажмите «Восстановить настройки по умолчанию».
4. Подтвердите и перезапустите браузер.

10. Переустановка Chrome

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

Windows: Параметры → Приложения → Google Chrome → Удалить.
macOS: используйте AppCleaner или удалите Chrome вручную, затем установите заново с официального сайта.

11. Продвинутая диагностика для администраторов и разработчиков

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

• netstat / ss — есть ли локальные слушатели на нужном порту?

# Linux
sudo ss -ltnp | grep :80
sudo ss -ltnp | grep :443

# Windows PowerShell
Get-NetTCPConnection -LocalPort 80,443

• Попробуйте подключиться с помощью telnet или curl, чтобы увидеть поведение TCP:

telnet example.com 80
curl -v http://example.com/
curl -vk https://example.com/

• Проверьте логи сервера (nginx/apache/systemd) на предмет ошибок привязки к порту, исчерпания дескрипторов или блокировок по IP.
• Проверьте настройки брандмауэра сервера (iptables, ufw, security groups в облаке) — может быть правило, которое сбрасывает соединения.

Методология диагностики: пошаговый SOP

1. Репликация: подтвердите проблему независимо (другой браузер/устройство/мобильный интернет).
2. Сбор базовых фактов: домен, IP, время, скриншоты, curl/telnet вывод.
3. Локальные проверки: кэш, DNS, hosts, прокси, расширения, брандмауэр.
4. Сетевая проверка: перезагрузка роутера, traceroute, проверка портов.
5. Серверная проверка: слушатели, логи, правила брандмауэра.
6. Фикс и валидация: применить изменение, повторно протестировать.
7. Откат: если изменение ухудшило ситуацию — вернуть положение по шагам (см. блок “Откат” ниже).

Критерии приёмки:

• При успешном результате сайт доступен из локальной сети и с внешних сетей.
• Нет ошибок ERR_CONNECTION_REFUSED в Chrome при повторном тесте.
• Логи сервера и системные журналы не показывают новых ошибок.

Откат:

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

Когда перечисленные шаги не помогают — возможные причины

• Сервер действительно не слушает порт (процесс упал).
• Сеть между вами и сервером блокирует порт (на промежуточном маршрутизаторе или у провайдера).
• Сервер защищён WAF/Fail2Ban, который сбрасывает соединения по правилам.
• Перехват TLS на уровне корпоративного прокси, который закрывает соединение.

В таких случаях свяжитесь с администратором сервера или провайдером хостинга и предоставьте собранные данные (curl, traceroute, логи).

Роль‑ориентированные чек‑листы

Для конечного пользователя:

• Попробовать открыть сайт с другого устройства/сети.
• Перезагрузить маршрутизатор и компьютер.
• Очистить кэш Chrome.
• Отключить всё расширения и прокси.
• Временно отключить антивирус/брандмауэр для проверки.

Для IT‑поддержки:

• Проверить DNS и выполнить ipconfig /flushdns.
• Проверить hosts файл и сетевые настройки.
• Снять трассировку (traceroute) и проверить на packet loss.
• Проверить журналы брандмауэра и прокси.
• При необходимости — связаться с хостингом.

Для веб‑разработчика/админа сервера:

• Проверить, слушает ли приложение нужный порт (ss/netstat).
• Проверить логи приложения и web‑сервера.
• Проверить ограничения firewall/security groups.
• Проверить состояние сервиса (systemctl status).

Быстрые команды‑чекеры

# Проверка порта
nc -vz example.com 80
nc -vz example.com 443

# Traceroute
traceroute example.com

Мини‑глоссарий

• DNS — система преобразования доменных имён в IP‑адреса.
• hosts — локальный файл сопоставления имён и IP.
• NAT — трансляция адресов, которая используется маршрутизаторами.
• RST — TCP‑сегмент, сигнализирующий об отклонении соединения.

Диагностическое дерево (Mermaid)

flowchart TD
  A[Пользователь видит ERR_CONNECTION_REFUSED] --> B{Сайт доступен с других сетей?}
  B -- Да --> C[Проверить локальные настройки: кэш, DNS, hosts, прокси, расширения]
  B -- Нет --> D[Проверить сервер: слушает ли порт, логи, брандмауэр хостинга]
  C --> E{Проблема решена?}
  D --> E
  E -- Да --> F[Закрыть инцидент, документировать фиксы]
  E -- Нет --> G[Связаться с провайдером/хостингом, предоставить логи]

Частые ошибки и когда предложенные решения не подойдут

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

Короткая памятка для публикации в соцсетях (100–200 слов)

Если Chrome показывает ERR_CONNECTION_REFUSED, сначала убедитесь, что сайт действительно недоступен с внешней сети. Затем перезагрузите роутер, очистите кэш браузера, смените DNS на публичный (8.8.8.8), отключите прокси и расширения, временно выключите брандмауэр и проверьте файл hosts. Если ничего не помогает — проверьте серверные логи и слушатели портов или обратитесь к хостингу. Следуйте по этапам диагностики: пользователь → IT → сервер. Этот подход позволяет быстро локализовать причину и вернуть сайт в работу.

Итог — что запомнить

• ERR_CONNECTION_REFUSED чаще всего означает, что на стороне сервера нет слушающего процесса или соединение блокируется где‑то посередине.
• Всегда начинайте с проверки доступности сайта извне и только затем переходите к локальной диагностике.
• Документируйте изменения и возвращайте конфигурации в исходное состояние при откате.

Важное: выполняйте сетевые изменения аккуратно, особенно в корпоративных сетях. Если вы не уверены — привлеките специалиста сетевой поддержки.