Localhost не працює – причини та рішення

Повідомлення «Localhost відхилив підключення» сигналізує про те, що сервер не зміг встановити внутрішнє з’єднання з необхідним сервісом, який обробляє запити користувачів. 

Існує дві основні помилки, через які браузер показує повідомлення «Localhost відхилив підключення»:

• ERR_CONNECTION_REFUSED – сервер відхилив запит на з’єднання.
• ERR_CONNECTION_TIMEOUT – сервер не відповів на запит протягом встановленого часу.

Це може бути пов’язано з проблемами у роботі вебсерверу, бази даних або іншого компонента, який відповідає за функціонування сайту. У цій статті розглянемо найпоширеніші причини виникнення такої ситуації та шляхи їхнього усунення.

Поширені причини помилки «Localhost відхилив підключення» та їх рішення

Помилка «Localhost відхилив підключення» означає, що один із сервісів сайту намагається звернутись до іншого локального сервісу через адресу 127.0.0.1 або localhost, але підключення не вдається. Це може призводити до часткової або повної недоступності сайту, збоїв у роботі скриптів чи API.

Це може викликати:

• помилки під час відкриття сторінок;
• збої в роботі скриптів;
• порушення взаємодії між компонентами сайту.

Далі розглянемо поширені причини та кроки усунення цієї помилки..

Конфлікти портів і локальні служби

Коли браузер показує помилку «Localhost відхилив підключення», однією з поширених причин є відсутність відповіді від локального вебсервера. Це часто пов’язано з тим, що відповідна служба (наприклад, Apache, Nginx або інший сервер, який мав би обробляти запит) не запущена або не прослуховує очікуваний порт. 

За замовчуванням локальний вебсервер працює на порту 80 (для HTTP) або 443 (для HTTPS). У середовищах розробки часто залучаються й інші порти: 3000, 8000, 8080 тощо. Якщо запит іде на ці порти, але жодна служба не обробляє його, або якщо його вже зайнято іншим процесом, браузер не отримає відповіді на запит, і як результат – з’явиться помилка з відмовою у з’єднанні.

Вирішення:

Для виявлення того, чи зайнятий певний порт на вашому комп’ютері, а також який саме процес його використовує, потрібно виконувати спеціальні команди у відповідному інтерфейсі операційної системи. Цей інтерфейс називається командним рядком або терміналом.

У Windows для цього використовується командний рядок (Command Prompt). Його можна відкрити кількома способами. Найпростіший – це натиснути клавіші Win + R, у вікні «Виконати» ввести cmd і натиснути Enter. Також можна знайти його через меню Пуск, ввівши в пошуку «Командний рядок» або «cmd».

Рекомендується запускати командний рядок від імені адміністратора, щоб мати всі необхідні права для виконання системних команд. Для цього після пошуку правою кнопкою миші натискайте на «Командний рядок» і вибирайте «Запуск від імені адміністратора».

У цьому вікні можна виконати команду:

# netstat -aon | findstr :80

# netstat -aon | findstr :80

Ця команда покаже, чи прослуховується порт 80, і виведе ідентифікатор процесу (PID), що його використовує. Якщо порт зайнятий, ви дізнаєтесь, який процес це робить. Далі можна ввести:

# tasklist | findstr [PID]

# tasklist | findstr [PID]

де [PID] – номер процесу, який ви отримали в попередньому кроці. Ця команда дозволяє дізнатись назву програми, що займає порт.

Для зручнішої роботи можна скористатися графічною утилітою TCPView від Microsoft Sysinternals. Вона надає візуальний інтерфейс для перегляду відкритих портів і процесів у реальному часі.

У Linux перевірку портів та процесів здійснюють через термінал – текстовий інтерфейс командного рядка. Його можна відкрити через меню програм або поєднання клавіш (наприклад, Ctrl + Alt + T).

Для виявлення, які процеси слухають певний порт (наприклад, 80), можна використати команду:

# lsof -i :80

# lsof -i :80

або більш універсальну команду:

# ss -tulpn | grep :80

# ss -tulpn | grep :80

Також популярним варіантом є команда:

# netstat -ntlup | grep :80

# netstat -ntlup | grep :80

Ця команда виводить інформацію про порти, які прослуховують TCP/UDP, із зазначенням процесів та PID.

Якщо потрібно звільнити порт, можна завершити відповідний процес командою:

# kill -9 [PID]

# kill -9 [PID]

де [PID] – це номер процесу, який потрібно завершити.

Важливі рекомендації! Завжди будьте уважні при завершенні процесів, щоб не припинити роботу важливих служб системи. Після перезавантаження або автоматичного рестарту деякі служби можуть займати той самий порт знову, тому для повного усунення конфлікту рекомендується внести зміни у конфігураційні файли відповідних програм.

Некоректна робота сервера

Сервіс, який має обробляти запити (наприклад, Apache, Nginx, MySQL, PHP-FPM або інший локальний вебкомпонент), не запущено або він працює з помилками. У такому випадку спроба з’єднання з localhost (наприклад, 127.0.0.1:80 для вебсервера чи 127.0.0.1:3306 для MySQL) завершується відмовою.

Це може виникнути, якщо:

• сервіс було зупинено вручну або через системну помилку;
• у процесі запуску сталася конфігураційна помилка;
• процес завершився аварійно через нестачу ресурсів або перевантаження.

У результаті інші частини сайту, що покладаються на цей сервіс, не можуть встановити підключення, що й спричиняє помилку «Localhost відхилив підключення».

Вирішення:

Передусім потрібно визначити, який саме сервіс відповідає за обробку локальних підключень. Це може бути вебсервер (Apache, Nginx, Litespeed), інтерпретатор (наприклад, PHP-FPM), база даних (MySQL, PostgreSQL), або будь-який інший локальний компонент. Якщо він неактивний – запити з localhost не зможуть бути оброблені, і система видаватиме помилку про відхилене підключення.

//LINUX

Для перевірки статусу потрібно служби на Linux OS скористайтесь командою:

# systemctl status apache2

# systemctl status apache2

Або підставте назву іншого сервісу, наприклад:

# systemctl status httpd – інша команда для перевірки Apache
# systemctl status nginx
# systemctl status mysql
# systemctl status php8.1-fpm

# systemctl status httpd – інша команда для перевірки Apache
# systemctl status nginx
# systemctl status mysql
# systemctl status php8.1-fpm

Зверніть увагу! Якщо у відповіді ви бачите, що сервіс має статус inactive, dead, failed або взагалі не працює – це і є джерелом проблеми.

Для відновлення його роботи достатньо спробувати запустити його вручну:

# systemctl start apache2

# systemctl start apache2

Після запуску перевірте ще раз статус, переконайтесь, що вивід містить active (running), а також не зазначено помилок.

У разі, якщо запуск не вдається (наприклад, сервіс одразу завершується або показує помилку), необхідно переглянути системні журнали. Вони підкажуть, що саме стало причиною зупинки. Найчастіше це некоректна конфігурація, конфлікт портів або брак ресурсів:

# journalctl -xe

# journalctl -xe

Або перегляньте лог-файли конкретного сервісу, наприклад:

# less /usr/local/apache/logs/error_log

# less /usr/local/apache/logs/error_log

# less /var/log/httpd/error.log

# less /var/log/httpd/error.log

Зверніть увагу! Шляхи до лог-файлів можуть відрізнятися залежно від операційної системи, дистрибутиву Linux, методу встановлення сервісу (через пакетний менеджер, компіляцію з джерел або панель керування), а також від конкретної версії.

Найпоширеніші шляхи до логів Apache (error logs):

/usr/local/apache/logs/error_log

/usr/local/apache/logs/error_log

/usr/local/apache/error_log

/usr/local/apache/error_log

/var/log/httpd/error_log

/var/log/httpd/error_log

Найпоширеніші шляхи до логів NGINX (error logs):

/var/log/nginx/error.log

/var/log/nginx/error.log

Найпоширеніші шляхи до логів MySQL / MariaDB:

Лог помилок визначається через команду:

# mysqladmin var | grep log_error

# mysqladmin var | grep log_error

За замовчуванням може бути відсутнім або вестися в:

/var/log/mysql/error.log
/var/log/mysqld.log

/var/log/mysql/error.log
/var/log/mysqld.log

Якщо логів немає за вказаним шляхом – скористайтесь командою find або перевірте відповідні параметри у конфігураційних файлах (наприклад, ErrorLog для Apache, log_error для MySQL).

# find / -name «error.log»

# find / -name «error.log»

Якщо в конфігураційних файлах (наприклад, httpd.conf, my.cnf, nginx.conf) було внесено зміни, варто перевірити їх на наявність синтаксичних помилок перед перезапуском:

# apachectl configtest

# apachectl configtest

# nginx -t

# nginx -t

# mysqld --validate-config

# mysqld --validate-config

Перевірка конфігурації Apache

Додатково окремо розглянемо перевірку конфігурації Apache. Щоб переконатися, що конфігураційні файли Apache не містять синтаксичних помилок, рекомендується перед перезапуском виконати тест конфігурації.

Стандартна команда (якщо Apache встановлено системно):

# httpd -t

# httpd -t

Або

# apache2ctl configtest

# apache2ctl configtest

Альтернативно:

# apachectl configtest

# apachectl configtest

Успішна відповідь має виглядати так:

Syntax OK

Syntax OK

Якщо використовується кастомна інсталяція Apache (наприклад, з панеллю CWP):

У Control Web Panel (CWP) Apache, як правило, встановлюється в окрему директорію – /usr/local/apache. У такому випадку використовуйте:

# /usr/local/apache/bin/httpd -t

# /usr/local/apache/bin/httpd -t

або

# /usr/local/apache/bin/apachectl configtest

# /usr/local/apache/bin/apachectl configtest

Ці команди перевіряють конфігурацію вебсервера незалежно від системного httpd.

У випадках, коли сервіс не запускається через нестачу пам’яті або вичерпаний ліміт процесів, варто перевірити завантаженість сервера:

# free -m
# top

# free -m
# top

Та вивільнити ресурси або оптимізувати автозапуск інших сервісів.

Також переконайтесь, що сервіс налаштований на автоматичний запуск при завантаженні системи, щоб уникнути повторної помилки після рестарту сервера:

# systemctl enable apache2

# systemctl enable apache2

//Windows

Якщо система працює під Windows, то принцип залишається той самий: помилка «Localhost відхилив підключення» виникає, коли необхідний локальний сервіс не запущений або зупинився через помилку.

Щоб переконатися, що необхідні служби вебсервера або бази даних запущені, скористайтесь стандартним менеджером служб Windows:

Натисніть Win + R, введіть services.msc та натисніть Enter.

У списку знайдіть служби, які відповідають вашому середовищу.

Зверніть увагу! Назви служб можуть відрізнятися залежно від встановленого програмного забезпечення.

Якщо ви користуєтесь локальними розробницькими пакетами, наприклад, WAMP, XAMPP або OpenServer, служби можуть мати інші імена, наприклад:

• wampapache64 (Apache у WAMP);
• xamppapache (Apache у XAMPP);
• nginx (якщо встановлений Nginx).

Якщо ви не впевнені у назві служби – перегляньте документацію вашого середовища або пошукайте службу за допомогою фільтра в менеджері служб.

Після того як ви знайшли потрібну службу у списку, зверніть увагу на її стан, який відображається у відповідній колонці. Якщо біля служби вказано статус «Запущено» або «Running», це означає, що вона активна і готова обробляти підключення. Якщо ж статус порожній або позначений як «Зупинено» (Stopped), це свідчить про те, що служба наразі не працює, і саме це може бути причиною помилки «Localhost відхилив підключення».

Щоб активувати службу, клацніть по ній правою кнопкою миші та оберіть пункт «Запустити» (Start). Це дозволить запустити необхідний вебсервер, базу даних або інший сервіс, який відповідає за локальні підключення. Якщо служба вже працює, але ви підозрюєте некоректну роботу, можна виконати її перезапуск. Для цього натисніть правою кнопкою на службу і виберіть «Перезапустити» (Restart). Перезапуск оновить процес і допоможе усунути тимчасові збої чи зависання.

Також важливо перевірити тип запуску служби. Щоб забезпечити автоматичний старт необхідного сервісу після перезавантаження комп’ютера, відкрийте властивості служби та переконайтеся, що у полі «Тип запуску» встановлено значення «Автоматично» (Automatic). Якщо там стоїть інше значення, змініть його, щоб уникнути повторних проблем із доступністю сервісу.

Фаєрвол або брандмауер блокує з’єднання

Ще однією поширеною причиною відмови у підключенні до localhost може бути блокування порту або самого процесу з боку системного брандмауера (фаєрволу). На Windows це може бути вбудований «Брандмауер Захисника Windows» або стороннє антивірусне ПЗ з власним мережевим екраном. Якщо служба, наприклад Apache або MySQL, використовує порт, який обмежено або заблоковано для вхідних чи вихідних з’єднань, то спроба доступу до localhost завершиться помилкою. Аналогічна ситуація можлива і на Linux-системах – iptables, firewalld або nftables можуть мати активні правила, що обмежують доступ до певних портів, наприклад 80, 443 або 3306.

Вирішення:

Щоб перевірити, чи правильно ви визначили проблему, на Windows відкрийте «Брандмауер Windows із розширеним захистом» та перегляньте правила вхідного і вихідного трафіку – зверніть увагу, чи дозволено з’єднання для потрібної програми або порту.

У Linux системах блокування локальних з’єднань також може відбуватись на рівні системного фаєрволу. Найпоширенішими засобами керування правилами є iptables, firewalld та nftables. Для перевірки активних правил можна використати одну з таких команд:

# iptables -L -n

# iptables -L -n

# firewall-cmd --list-all

# firewall-cmd --list-all

# nft list ruleset

# nft list ruleset

Якщо вивід цих команд показує правила типу DROP або REJECT для потрібного порту (наприклад, 80 або 3306), це може бути причиною відмови у підключенні. У такому випадку слід змінити або видалити відповідне правило.

На серверах із панелями керування або специфічними налаштуваннями може бути встановлений додатковий захист, як-от CSF (ConfigServer Security & Firewall). CSF інтегрується з iptables і додає власні правила – їх можна переглянути через:

# csf -l

# csf -l

Також можливо, що доступ блокує вебаплікаційний фаєрвол, наприклад ModSecurity. У цьому випадку підозрілі або масові локальні запити можуть бути розцінені як потенційна атака й автоматично заблоковані. Для перевірки варто переглянути журнали ModSecurity:

/usr/local/apache/logs/modsec_audit.log
/var/log/httpd/modsec_audit.log

/usr/local/apache/logs/modsec_audit.log
/var/log/httpd/modsec_audit.log

або інші шляхи, залежно від дистрибутива та конфігурації.

Загалом, варто перевіряти усі рівні фільтрації – від базових системних фаєрволів до сторонніх рішень безпеки, які можуть непомітно для адміністратора блокувати потрібні порти або IP.

Зверніть увагу! Для тимчасового тестування можна також повністю вимкнути брандмауер і перевірити, чи зникає проблема. Проте важливо пам’ятати: вимкнення фаєрволу – це лише діагностичний крок, і в жодному разі не варто залишати систему без активного захисту після перевірки.

Тимчасове вимкнення фаєрволу в Linux

У Linux метод вимкнення залежить від того, який фаєрвол використовується. Найчастіше це firewalld, iptables або nftables. Якщо на сервері активний firewalld, його можна зупинити через systemd – після цього всі правила блокування перестають діяти до наступного запуску служби. У випадку iptables, для тимчасового вимкнення зазвичай обнуляють таблиці правил, що також дає змогу перевірити, чи саме вони спричиняють проблему. Якщо використовується nftables, достатньо вивантажити активний ruleset. 

Варто пам’ятати, що після перезавантаження системи або запуску служби фаєрволу правила можуть знову активуватись, тож це – тимчасове рішення виключно для тестування. 

Окремі фаєрвол-рішення, як-от CSF (ConfigServer Security & Firewall) та ModSecurity, теж можуть блокувати локальні з’єднання, тому для повноцінної діагностики їх варто окремо вимкнути або перевірити їхній вплив на трафік.

CSF (ConfigServer Security & Firewall) – це популярний фаєрвол для Linux-серверів, який працює поверх iptables. Для тимчасового вимкнення CSF:

# csf -x

# csf -x

Ця команда повністю зупиняє CSF і видаляє всі його правила з iptables. Якщо ви хочете потім знову ввімкнути CSF:

# csf -e

# csf -e

Перед вимкненням бажано переконатися, що у вас є прямий доступ до сервера, адже у випадку помилкової блокади доступу після ввімкнення назад – віддалено відновити з’єднання може бути неможливо.

ModSecurity – це фаєрвол, який інтегрується з вебсервером (Apache, Nginx або LiteSpeed). Він може блокувати запити, навіть якщо мережеві порти відкриті, якщо вважає їх потенційно шкідливими. Щоб тимчасово вимкнути ModSecurity в Apache:

На рівні глобальної конфігурації (httpd.conf або через панель керування) змінити:

# SecRuleEngine Off

# SecRuleEngine Off

Після чого потрібно перезапустити Apache:

# systemctl restart httpd

# systemctl restart httpd

Якщо використовується cPanel, простіше вимкнути ModSecurity через WHM: “ModSecurity Configuration” → “Disable ModSecurity” для конкретного домену або глобально.

Для перевірки, чи саме ModSecurity блокує запити, можна подивитися журнали:

/usr/local/apache/logs/modsec_audit.log
/var/log/httpd/modsec_audit.log

/usr/local/apache/logs/modsec_audit.log
/var/log/httpd/modsec_audit.log

Там будуть вказані заблоковані запити, причина блокування та відповідний Rule ID.

Тимчасове вимкнення фаєрволу в Windows

У Windows фаєрвол можна вимкнути через графічний інтерфейс або з командного рядка, якщо є адмінські права. Класичний спосіб – через «Брандмауер Windows із розширеним захистом», де можна деактивувати як профіль для домену, так і для приватних чи публічних мереж.

Також існують PowerShell-команди, які дають змогу миттєво вимкнути всі політики фаєрволу. Це дозволяє перевірити, чи блокує з’єднання саме система безпеки, без необхідності шукати конкретне правило.

⚠️ Увага: після тестування обов’язково увімкніть фаєрвол повторно, щоб не залишати систему вразливою до зовнішніх атак. Це лише діагностичний крок для локалізації проблеми з підключенням.

Неправильна конфігурація файлу hosts

Однією з причин відмови у з’єднанні може бути неправильна конфігурація файлу hosts. Цей файл використовується операційною системою для локального зіставлення доменних імен з IP-адресами до звернення до DNS. Якщо записи у ньому некоректні – наприклад, localhost вказує не на 127.0.0.1, або певний домен прив’язано до помилкової адреси – це може призвести до помилок підключення до локального сервера або бази даних.

Вирішення:

Необхідно перевірити вміст файлу hosts і переконатись, що в ньому немає неправильних записів.

У Linux файл hosts розташований за шляхом:

/etc/hosts

/etc/hosts

Типова правильна конфігурація:

127.0.0.1 localhost
127.0.1.1 your-hostname

127.0.0.1 localhost
127.0.1.1 your-hostname

У Windows файл розташований тут:

C:\Windows\System32\drivers\etc\hosts

C:\Windows\System32\drivers\etc\hosts

Правильна конфігурація виглядає приблизно так:

127.0.0.1 localhost
127.0.0.1 mysite.local

127.0.0.1 localhost
127.0.0.1 mysite.local

Зверніть увагу! У Windows файл hosts не має розширення. Для його редагування потрібно запускати текстовий редактор (наприклад, Notepad) з правами адміністратора, інакше не вдасться зберегти зміни.

Також варто перевірити, чи немає дублікатів або зайвих пробілів/символів у рядках, оскільки це може вплинути на коректність обробки записів. Якщо ви тестуєте сайт локально, переконайтесь, що домен, який ви використовуєте у браузері або скриптах, присутній у hosts і вказує на 127.0.0.1.

Після внесення змін до файлу hosts, система може продовжувати використовувати кешовані DNS-записи, тому рекомендується очистити DNS-кеш, щоб переконатись, що застосовано актуальні записи.

DNS-кеш та помилка ERR_CONNECTION_REFUSED на localhost

Помилка ERR_CONNECTION_REFUSED означає, що браузер намагався підключитися до сервера за адресою 127.0.0.1 або localhost, але з’єднання було відхилено. Це зазвичай свідчить про те, що на вказаному порту не працює жоден сервер, або з’єднання блокується локальними налаштуваннями. 

Варто зазначити, що IP-адреса 127.0.0.1 – це локальний loopback, який не потребує DNS-резолвінгу. Однак при використанні імені localhost система повинна правильно його розпізнати, що зазвичай відбувається через файл hosts. Якщо цей файл змінено або DNS-кеш зберігає застарілі дані, то резолвінг може працювати некоректно. У результаті браузер може не знайти потрібний IP або неправильно на нього звертатись.

Вирішення:

Щоб виключити проблеми, пов’язані з кешем DNS або некоректним резолвінгом localhost, рекомендується очистити DNS-кеш. Це допоможе оновити відповідності між доменними іменами та IP-адресами у вашій системі.

У Windows така проблема вирішується очищенням DNS-кешу. Це дозволяє повністю скинути збережені записи, які могли викликати конфлікти при зверненні до локального хосту. Команда, яка використовується для цього в системі:

# ipconfig /flushdns

# ipconfig /flushdns

Її необхідно виконувати в командному рядку з правами адміністратора, щоб система могла внести відповідні зміни.

У Linux підхід залежить від того, яка саме служба кешування DNS використовується – наприклад, systemd-resolved, dnsmasq, nscd або bind. Щоб очистити кеш, зазвичай потрібно перезапустити відповідну службу або виконати команду, яка скидає DNS-таблиці.

Окрім операційної системи, DNS-кеш може зберігатися і в браузерах. Деякі з них, як Chrome, Edge або Firefox, мають внутрішні інтерфейси для очищення цього кешу. У певних випадках саме збережені DNS-записи в браузері можуть заважати коректному завантаженню локального сайту або вебінтерфейсу, доступного через 127.0.0.1.

Щоб скинути DNS-кеш безпосередньо у браузері, потрібно ввести в адресний рядок одну з таких адрес:

• Google Chrome: chrome://net-internals/#dns
• Microsoft Edge: edge://net-internals/#dns
• Firefox: about:networking#dns
• Opera: opera://net-internals/#dns

Після переходу на відповідну сторінку слід натиснути кнопку для очищення DNS-кешу.

Очищення DNS є простою, але дієвою дією, яка дозволяє швидко виключити одну з можливих причин відмови у з’єднанні. Якщо після очищення ситуація не змінюється – варто досліджувати інші рівні мережевої взаємодії, зокрема, конфігурацію локального вебсервера, фаєрволів або hosts-файлу.

Проблеми, специфічні для браузера

У деяких випадках з’єднання з локальним або віддаленим сервером блокується саме на рівні браузера. Однією з найпоширеніших причин можуть бути пошкоджені або застарілі кешовані дані, а також cookie, які містять застарілі токени доступу або некоректну інформацію про сесію. Очищення кешу та cookie дозволяє усунути цей фактор і виключити його з кола потенційних причин.

Ще однією поширеною причиною можуть бути браузерні розширення – особливо ті, що працюють із мережею, безпекою або проксі-серверами. Наприклад, блокувальники реклами, VPN-розширення або навіть інструменти для розробників можуть впливати на мережеву взаємодію сторінки. Для тестування варто тимчасово вимкнути всі розширення, особливо якщо проблема виникає лише в одному браузері.

Також варто враховувати, що деякі браузери (наприклад, Chrome) мають власні політики безпеки щодо локального доступу, змішаного контенту чи самопідключення (localhost to localhost). В окремих випадках це може викликати помилки з’єднання, навіть якщо серверна частина функціонує коректно. Тому важливо перевірити сайт у різних браузерах, щоби виключити вплив конкретної програми.

Автоматичне перенаправлення з HTTP на HTTPS у браузері

Сучасні браузери, зокрема Chrome і Firefox, часто автоматично перенаправляють HTTP-запити на HTTPS. Для локальних середовищ це може спричинити помилку  «Localhost відхилив підключення» , якщо сервер не налаштовано на прийом HTTPS-запитів. 

У таких випадках доцільно спробувати відкрити http://localhost у браузері, який не зберігає HSTS-політику або в якому вимкнено режим HTTPS-only. Наприклад, у Chrome можна вручну видалити запис про localhost з HSTS-політик, а у Firefox – відключити примусову політику використання HTTPS у налаштуваннях конфіденційності. Якщо після цього з’єднання встановлюється, проблема, ймовірно, пов’язана саме з політикою безпеки браузера, а не з конфігурацією сервера або DNS.

Видалення HSTS-політик у Chrome

У браузері Google Chrome використовується механізм HSTS (HTTP Strict Transport Security), який автоматично перенаправляє HTTP-запити на HTTPS. Це може викликати помилку при доступі до localhost, якщо на локальному сервері не налаштовано обробку HTTPS-запитів. Для розв’язання цієї проблеми слід вручну видалити запис про localhost з динамічної політики HSTS.

Для цього у Chrome передбачено спеціальний інструмент керування політиками, доступний за адресою:

chrome://net-internals/#hsts

chrome://net-internals/#hsts

У розділі «Політика безпеки домену» можна вказати localhost у полі для видалення домену та застосувати зміни.

Після цього потрібно перезапустити браузер, щоб зміни набрали чинності. Це дозволить уникнути автоматичного перенаправлення http://localhost на https://localhost та допоможе перевірити, чи проблема справді була пов’язана з політикою безпеки Chrome.

Вимкнення режиму HTTPS-only у Firefox

У браузері Firefox також може бути активований режим, що примусово використовує HTTPS-з’єднання навіть для локальних ресурсів, зокрема localhost. Така поведінка може викликати помилку під час спроби відкриття локального сайту без підтримки SSL.

Щоб перевірити, чи саме цей режим є причиною помилки, його можна тимчасово вимкнути. У налаштуваннях браузера перейдіть до розділу «Конфіденційність і безпека», знайдіть опцію «Режим лише HTTPS» та оберіть варіант «Не вмикати режим лише HTTPS».

Після внесення змін рекомендовано перезапустити браузер, щоб вони набрали чинності. Це дозволить завантажувати сторінки через звичайне HTTP-з’єднання та визначити, чи проблема пов’язана саме з примусовим використанням HTTPS.

Висновок

Помилка «Localhost відхилив підключення» може виникати з різних причин – від неправильної роботи сервісів та блокувань на рівні фаєрволів до некоректних налаштувань файлу hosts або конфліктів із портами. Важливо системно перевірити кожен із потенційних факторів, починаючи з діагностики активності серверів і служб, контролю доступу через фаєрволи, коректності локальних DNS-записів і завершуючи перевіркою браузера.

Використання базових команд для перевірки прослуховуваних портів, аналізу логів, очищення кешу DNS і правильного налаштування файлу hosts допоможе швидко локалізувати проблему та усунути її. Також важливо враховувати особливості різних операційних систем, щоб коректно застосовувати методи діагностики та виправлення.

Дотримуючись описаних у статті рекомендацій, навіть користувачі з базовими знаннями зможуть успішно розв’язати проблему з відмовою у підключенні до localhost і відновити стабільну роботу локальних вебсервісів.

Наш телеграм

з важливими анонсами, розіграшами й мемами

Приєднатися