Hiba 111: Connection refused – mit jelent és hogyan oldható meg?

Képzelje el: sietne, egy fontos weboldalt próbálna elérni, vagy épp a saját fejlesztésű alkalmazásával dolgozna, amikor hirtelen egy hideg, technikai üzenet köszön vissza a képernyőn: „Connection refused”. Ez a bosszantó pillanat sokunknak ismerős, és gyakran még egy „Error 111” vagy „ECONNREFUSED” kód is kíséri. De mit is jelent ez pontosan, és ami még fontosabb, hogyan szabadulhatunk meg tőle? Ne essen kétségbe! Ebben a cikkben alaposan körbejárjuk a „Connection refused” hiba okait és átfogó megoldási stratégiákat kínálunk, hogy Ön is magabiztosan nézhessen szembe ezzel a kihívással.

Mi is az a „Connection refused” hiba, és miért pont 111?

A „Connection refused”, magyarul „kapcsolat elutasítva”, egyértelmű üzenet a számítógépes hálózatok világában: a kliens (az Ön gépe, böngészője, alkalmazása) megpróbált kapcsolatot létesíteni egy szerverrel (az a gép, amely a kért szolgáltatást nyújtja), de a szerver aktívan visszautasította ezt a kísérletet. Fontos megkülönböztetni ezt a „Connection timed out” (kapcsolat időtúllépés) hibától, ahol a szerver egyáltalán nem válaszol, mintha nem is létezne vagy útközben elveszne a kérés. A „Connection refused” ezzel szemben azt jelenti, hogy a szerver *elérhető volt*, *látta* a kérést, de valamilyen okból *nem engedélyezte* a kapcsolat létrejöttét.

A „111” kód, vagy az „ECONNREFUSED” a Unix-alapú rendszereken (például Linuxon vagy macOS-en) jelzi ezt a konkrét hibát. Ez egy szabványos hibakód, amely pontosan azt jelöli, hogy a célgép aktívan elutasította a kapcsolatot. Windows környezetben más kódok is előfordulhatnak, de a jelentés maga ugyanaz.

A Hiba 111 Gyakori Okai: Miért utasít vissza a szerver?

A „Connection refused” hiba diagnosztizálása kulcsfontosságú a megoldáshoz, és ehhez ismernünk kell a leggyakoribb okokat. Íme a legvalószínűbb forgatókönyvek:

1. Szerver Inaktivitás vagy Leállás

Ez a leggyakoribb és legegyszerűbb ok. A szolgáltatás, amelyet elérni próbál, egyszerűen nem fut a szerveren. Lehet, hogy leállt egy hiba miatt, vagy sosem indult el, esetleg valaki manuálisan állította le. Egy weboldalnál ez azt jelenti, hogy az Apache, Nginx vagy más webszerver szoftver nem aktív. Adatbázisoknál (MySQL, PostgreSQL) a megfelelő adatbázisszerver folyamat hiányzik.

2. Tűzfal Blokkolás

A tűzfal (firewall) egy biztonsági réteg, amely szabályozza a bejövő és kimenő hálózati forgalmat. Ha a szerver tűzfala úgy van beállítva, hogy blokkolja a használni kívánt portot vagy IP-címet, a kapcsolat elutasításra kerül. Ez lehet a szerver operációs rendszerének beépített tűzfala (pl. UFW, iptables Linuxon, Windows Defender tűzfal), egy hardveres tűzfal a hálózaton, vagy akár a szolgáltató (cloud provider) biztonsági csoportjai (security groups).

3. Helytelen Portszám

Minden hálózati szolgáltatás egy bizonyos porton keresztül kommunikál (pl. HTTP alapértelmezetten a 80-as, HTTPS a 443-as, SSH a 22-es, MySQL a 3306-os porton). Ha a kliens rossz portra próbál csatlakozni, vagy a szerver nem a várt porton figyel, az eredmény „Connection refused” lesz.

4. Helytelen IP-cím vagy Domain Név

Ha a kliens rossz IP-címet vagy domain nevet használ, természetesen nem tud kapcsolatot létesíteni a cél szerverrel. Elképzelhető, hogy a domain név DNS-rekordja (Domain Name System) rossz IP-címre mutat, vagy a fejlesztő/felhasználó egyszerűen elgépelte a címet.

5. Szolgáltatás Nincs Konfigurálva a Figyelésre (Binding Address)

Sok szolgáltatás konfigurálható úgy, hogy csak bizonyos hálózati interfészeken vagy IP-címeken fogadjon kapcsolatokat. Például, ha egy webszerver csak a `127.0.0.1` (localhost) címen figyel, akkor csak a szerveren belülről lehet elérni. Ha külső IP-címről próbálnak csatlakozni hozzá, az elutasításra kerül, mert a szolgáltatás nem „hallgat” ezen a külső interfészen. Ahhoz, hogy kívülről is elérhető legyen, általában a `0.0.0.0` címen kell figyelnie (ami minden elérhető interfészt jelent).

6. Túlterheltség vagy Erőforráshiány

Ritkábban, de előfordulhat, hogy a szerver annyira túlterhelt (CPU, memória, hálózati erőforrások), vagy annyi aktív kapcsolatot kezel, hogy nem képes továbbiakat elfogadni. Ilyenkor is elutasíthatja az új kéréseket, mintha nem lenne képes azokat feldolgozni.

7. Hibás Konfiguráció a Szolgáltatásban

Magának a szolgáltatásnak (pl. Apache, Nginx, MySQL) a konfigurációs fájljában is lehetnek hibák, amelyek megakadályozzák, hogy megfelelően elinduljon, vagy elfogadja a kapcsolatokat. Például egy rosszul beállított virtuális host, vagy egy hiányzó adatbázis felhasználó/engedély.

Hogyan Oldjuk Meg a Hiba 111-et? Lépésről Lépésre Útmutató

A hibaelhárítás kulcsa a módszeres megközelítés. Kövesse az alábbi lépéseket a lehetséges problémák kizárására:

1. Ellenőrizze a Szerver Állapotát és a Szolgáltatást

Ez az első és legfontosabb lépés. Győződjön meg róla, hogy a szerver be van kapcsolva, és a kért szolgáltatás fut rajta.

• Ping: Próbálja meg pingelni a szerver IP-címét (ping [szerver IP]). Ha ez nem válaszol, akkor alapvető hálózati probléma van, vagy a szerver nincs bekapcsolva.
• Szolgáltatás státusza (Linux): Jelentkezzen be az SSH-n keresztül a szerverre (ha lehetséges) és ellenőrizze a szolgáltatás státuszát. Például egy webszerver esetén: sudo systemctl status apache2 vagy sudo systemctl status nginx. Adatbázisoknál: sudo systemctl status mysql vagy sudo systemctl status postgresql. Ha a szolgáltatás nem fut, próbálja meg elindítani: sudo systemctl start [szolgáltatás neve] és engedélyezni az automatikus indulást: sudo systemctl enable [szolgáltatás neve].
• Log fájlok: Ellenőrizze a szolgáltatás log fájljait (pl. /var/log/apache2/error.log, /var/log/nginx/error.log, /var/log/mysql/error.log, vagy journalctl -xe Linuxon). Ezek gyakran árulkodnak arról, hogy miért nem indul el a szolgáltatás, vagy miért utasítja el a kapcsolatokat.

2. Tűzfal Konfiguráció Ellenőrzése

A tűzfal a „Connection refused” hiba egyik leggyakoribb oka. Ellenőrizze a tűzfal szabályait a szerveren.

• Linuxon:
  • UFW (Uncomplicated Firewall): sudo ufw status. Győződjön meg róla, hogy a használt port engedélyezve van (pl. sudo ufw allow 80/tcp vagy sudo ufw allow ssh).
  • FirewallD: sudo firewall-cmd --list-all vagy sudo firewall-cmd --list-ports. Engedélyezze a portot: sudo firewall-cmd --add-port=80/tcp --permanent, majd sudo firewall-cmd --reload.
  • Iptables: sudo iptables -L -n -v. Ez a legbonyolultabb, de ha közvetlenül iptables-t használ, ellenőrizze, hogy a releváns szabályok engedélyezik-e a bejövő forgalmat a porton.
• Windows szerveren: Ellenőrizze a Windows Defender Tűzfal beállításait, hogy engedélyezve van-e a port a bejövő kapcsolatok számára.
• Cloud szolgáltatók: Ha felhőalapú szervert használ (AWS, Azure, Google Cloud), ellenőrizze a Security Group, Network ACL vagy Virtual Network beállításait, amelyek virtuális tűzfalakként működnek.
• Router: Ha a szerver egy otthoni vagy irodai hálózaton belül van, ellenőrizze a router beállításait is (port forwarding, NAT), hogy az engedélyezi-e a külső forgalmat a szerverre.
• Ideiglenes teszt: Szigorúan csak tesztelés céljából, és csak rövid időre: próbálja meg ideiglenesen kikapcsolni a szerver tűzfalát (pl. sudo ufw disable vagy sudo systemctl stop firewalld), majd tesztelje újra a kapcsolatot. Ha így működik, akkor a tűzfal a ludas, és vissza kell kapcsolnia, majd megfelelően konfigurálnia.

3. Portszám és IP-cím Ellenőrzése

Győződjön meg róla, hogy a kliens a megfelelő IP-címre és portra próbál csatlakozni, és a szerver is ott figyel, ahol kell.

• Kliens oldalon: Ellenőrizze az alkalmazás konfigurációját, a böngésző URL-jét, vagy az SSH parancsban megadott IP-címet/hostnevet és portot.
• Szerver oldalon:
  • Hallgató portok ellenőrzése: Használja a netstat vagy ss parancsot a szerveren, hogy lássa, melyik szolgáltatás milyen porton figyel: sudo netstat -tulnp | grep LISTEN vagy sudo ss -tulnp | grep LISTEN. Ellenőrizze, hogy a keresett szolgáltatás (pl. Apache a 80-as, Nginx a 80-as vagy 443-as, SSH a 22-es, MySQL a 3306-os) valóban figyel-e a megfelelő porton.
  • Binding address: Ellenőrizze a szolgáltatás konfigurációs fájljában, hogy milyen IP-címen figyel. Például Apache esetén a Listen direktíva, Nginx esetén a listen direktíva a server blokkban. MySQL-nél a bind-address opció a my.cnf fájlban. Győződjön meg róla, hogy a 0.0.0.0 van beállítva, ha kívülről is elérhetőnek kell lennie, vagy a szerver külső IP-címe.

4. Hálózati Problémák Diagnosztizálása

Bár a „refused” hibánál a szerver elérhető, érdemes ellenőrizni az alapvető hálózati kommunikációt.

• DNS feloldás: Ha domain nevet használ, ellenőrizze, hogy az helyesen oldódik-e fel a szerver IP-címére: nslookup [domain.com] vagy dig [domain.com].
• Útvonal ellenőrzés: A traceroute [szerver IP] (Linux/macOS) vagy tracert [szerver IP] (Windows) parancs megmutatja az útvonalat a kliens és a szerver között, segítve az esetleges útválasztási problémák azonosítását.

5. Erőforrás-felhasználás Ellenőrzése

Ha a szerver erőforráshiányos (kevés RAM, CPU, vagy betelt lemez), az is okozhatja a hibát.

• Memória és CPU: Használja a top, htop, vagy free -m parancsokat a szerveren, hogy ellenőrizze a memória és CPU kihasználtságot.
• Lemezterület: df -h paranccsal ellenőrizze a lemezterületet. Egy telített lemez megakadályozhatja a szolgáltatások indulását vagy a naplózást.

6. Szoftverfrissítések és Verziókompatibilitás

Bár ritka, de előfordulhat, hogy egy frissítés után, vagy inkompatibilis verziók miatt jelentkezik a hiba. Győződjön meg róla, hogy minden szoftver (kliens és szerver oldalon is) naprakész, és kompatibilis egymással.

7. Részletesebb Logok Keresése

Sok szolgáltatás részletesebb naplózást kínál (debug logolás), amit ideiglenesen bekapcsolhat a konfigurációs fájlban. Ez rendkívül hasznos lehet a rejtett problémák feltárásában.

8. Újraindítás

Mint minden IT probléma esetén, a klasszikus „újraindítottad már?” kérdés itt is releváns. Próbálja meg újraindítani a szóban forgó szolgáltatást (sudo systemctl restart [szolgáltatás neve]), vagy végső esetben magát a szervert.

Gyakori forgatókönyvek és tippek

• Webszerver (Apache, Nginx): Győződjön meg arról, hogy a webszerver fut, a 80-as (HTTP) és 443-as (HTTPS) portok nyitva vannak a tűzfalon, és a webszerver a 0.0.0.0-n vagy a szerver külső IP-címén figyel. Ellenőrizze a virtuális host konfigurációkat is.
• Adatbázis (MySQL, PostgreSQL): Az adatbázis-szervernek futnia kell, a 3306 (MySQL) vagy 5432 (PostgreSQL) portnak nyitva kell lennie. A bind-address (MySQL) vagy listen_addresses (PostgreSQL) beállításoknak engedélyezniük kell a külső kapcsolatokat. Ezen felül az adatbázis felhasználói engedélyek is fontosak lehetnek.
• SSH: Győződjön meg róla, hogy az SSH démon (sshd) fut a szerveren, és a 22-es port (vagy egyéni port) nyitva van a tűzfalon. Ellenőrizze az /etc/ssh/sshd_config fájlt is.
• Fejlesztői környezetek (Docker, Vagrant): Ha virtuális gépeken vagy konténerekben futtatja a szolgáltatásokat, győződjön meg róla, hogy a port mapping (port átirányítás) helyesen van beállítva a host gépről a virtuális gépre/konténerre.

Összegzés és Jó Tanácsok

A Hiba 111: Connection refused üzenet elsőre ijesztőnek tűnhet, de a legtöbb esetben egy viszonylag egyszerű probléma áll mögötte, mint például egy leállt szolgáltatás, egy rossz tűzfalbeállítás, vagy egy helytelenül beállított port. A kulcs a módszeres hibaelhárítás és a türelem. Kezdje a szerver állapotának ellenőrzésével, haladjon a tűzfalon, majd a port- és IP-cím beállításokon keresztül. Használja ki a rendelkezésre álló eszközöket, mint a ping, netstat, systemctl, és ami a legfontosabb: figyelje a log fájlokat!

Reméljük, ez az átfogó útmutató segít Önnek megérteni és sikeresen megoldani a „Connection refused” hibát. Ne feledje, minden hiba egy tanulási lehetőség, és a hálózati problémák megoldása fejleszti a leginkább a rendszergazdai képességeket!