Hogyan javítsd meg a Redis kapcsolat hibát a 127.0.0.1:6379 címen

Gyors válasz: Ha az alkalmazásod a Could not connect to Redis at 127.0.0.1:6379: Connection refused hibaüzenetet jelenti, először ellenőrizd, hogy egy Redis szerver valóban figyel-e ezen a címen és porton. A Redis CLI alapértelmezés szerint a 127.0.0.1 címet és a 6379-es portot használja, így az elutasítás általában leállt szerverre, eltérő portra, konténer vagy virtuálisgép-hálózati eltérésre, vagy figyelő konfigurációs problémára utal. A hitelesítési hibák eltérőek: ezek általában akkor fordulnak elő, amikor a TCP-kapcsolat már létrejött.

A leggyorsabb diagnosztikai módszer a redis-cli -h 127.0.0.1 -p 6379 PING parancs. Ha ez PONG-ot ad vissza, a Redis elérhető, és az alkalmazás Redis URL-jét, hitelesítő adatait, TLS-beállításait vagy kapcsolatkezelő konfigurációját kell ellenőrizned, ahelyett, hogy vakon újraindítanád a Redist. A Redis dokumentációja kifejezetten a PING parancsot említi arra, hogy teszteld, él-e a kapcsolat, és hogy a szerver képes-e adatokat kiszolgálni. Lásd a hivatalos Redis PING parancs dokumentációját.

Gyors diagnosztikai táblázat

1. A hiba reprodukálása az alkalmazáson kívül

Használd a Redis CLI-t az alkalmazáskód módosítása előtt. A Redis hivatalos CLI dokumentációja szerint alapértelmezés szerint a redis-cli a 127.0.0.1:6379 címhez csatlakozik. Explicit módon megadhatod a célt:

redis-cli -h 127.0.0.1 -p 6379 PING

Egy sikeres helyi szervernek így kell válaszolnia:

PONG

Ha ugyanazt a kapcsolat elutasítási üzenetet kapod, a problémát a transzportréteg szintjén reprodukáltad. Ez hasznos, mert kizárja a vizsgálatból a keretrendszert, az ORM-et, a gyorsítótár-könyvtárat és az alkalmazáskódot. A Redis CLI elfogadja a -h kapcsolót a hosthoz és a -p kapcsolót a porthoz, ahogy a Redis CLI referenciában is szerepel.

Ha a PING már PONG-ot ad vissza, ugorj az 5. lépésre. Ne indítsd újra folyamatosan egy egészséges Redis példányt; fókuszálj az alkalmazás kapcsolati karakterláncára és futtatókörnyezetére.

2. Győződj meg róla, hogy a Redis szerver fut

Linux rendszeren, amely csomagkezelőn keresztül lett telepítve, a Redis gyakran rendszer szolgáltatásként kezelhető. A Redis Linux telepítési dokumentációja a systemctl start és systemctl stop parancsokat mutatja, megjegyezve, hogy a szolgáltatás neve a platformtól függően redis vagy redis-server lehet. Egy tipikus Ubuntu/Debian ellenőrzés:

sudo systemctl status redis-server
sudo systemctl start redis-server
sudo systemctl status redis-server

Ha a disztribúciód a redis nevet használja szolgáltatásként, helyettesítsd azt a nevet. Ha a systemd nem kezeli a Redis folyamatodat, használd azt az indítási módszert, amely megfelel a Redis telepítési módjának, ahelyett, hogy feltételeznéd, hogy létezik szolgáltatás. A jelenlegi Redis Linux útmutató elérhető a hivatalos Linux telepítési dokumentációban.

Windows és WSL megjegyzés

Ne feltételezd, hogy natív Windows Redis szolgáltatás létezik csak azért, mert az alkalmazásod Windows-on fut. A Redis jelenlegi telepítési áttekintése a Windows-t a Docker útvonal alatt sorolja fel, miközben a Redis Windows útmutatót is fenntart a WSL és a Windows kompatibilitási partnere számára. Ha a Redis WSL-en belül fut, először ugyanabból a WSL környezetből teszteld. Ha a Redis Docker Desktopon fut, használd a következő szakasz Docker-ellenőrzéseit. Lásd a jelenlegi Redis Open Source telepítési áttekintést és a Redis Windows/WSL telepítési dokumentációt.

3. Ellenőrizd a 6379-es portot és javítsd a Docker hálózatot

A Redis általában a 6379-es TCP-portot használja. Ha a Redis fut, de semmi nem figyel ezen a porton, ellenőrizd, hogy a szervert eltérő konfigurációval indították-e el. Linuxon egy gyors operációs rendszer ellenőrzés, mint például az ss -ltnp, megmutathatja a figyelő TCP socketeket; Windowson a PowerShell Test-NetConnection 127.0.0.1 -Port 6379 parancsa segíthet megkülönböztetni a figyelő portot az elutasítottól. A döntő teszt azonban továbbra is egy működő Redis parancs, mint például a PING.

Ha a Redis Dockerben fut, és az alkalmazás a hoston

A konténer portját közzé kell tenni a hoston. A Redis Docker dokumentációja mutatja a host-konténer leképezést a 6379-es portra. Helyi fejlesztéshez a közzétett portot a host loopback címéhez kötheted:

docker run -d --name redis -p 127.0.0.1:6379:6379 redis
docker ps

A Docker saját portközzétételi dokumentációja elmagyarázza, hogy a 127.0.0.1 megadása azt jelenti, hogy a közzétett port csak a Docker hostról érhető el, ami biztonságosabb egy helyi fejlesztési gyorsítótár számára, mint minden interfészen közzétenni. A Redis hivatalos Docker gyors kezdés és kapcsolati példák a Redis Open Source futtatása Dockerben című oldalon találhatók, és a host-cím viselkedése a Docker portközzétételi dokumentációjában van leírva.

Ha az alkalmazás is Dockerben fut

Ez egy gyakori zavarforrás. Egy konténeren belül a 127.0.0.1 magát a konténert jelenti. Ha a Redis egy külön Compose szolgáltatás, a Redis szolgáltatás nevéhez csatlakozz, például redis:6379, a közös Compose hálózaton, nem pedig a 127.0.0.1:6379 címhez. A Docker dokumentálja, hogy a Compose szolgáltatások az alapértelmezett hálózaton szolgáltatásnévvel érhetők el a Compose hálózati útmutatóban.

Ha az alkalmazás egy Docker Desktop konténerben van, de a Redis közvetlenül a hoston fut, a Docker a host.docker.internal speciális hostnevet ajánlja a host szolgáltatások eléréséhez. Ez a viselkedés a Docker Desktop hálózati GYIK-ben van dokumentálva.

4. Ellenőrizd a redis.conf-ot: bind, protected mode és port

Ha a folyamat fut, de rossz interfészen vagy porton figyel, vizsgálja meg azt a konfigurációs fájlt, amelyet az aktív Redis folyamat valóban használ. Három beállítás a legfontosabb ennél a hibánál:

bind 127.0.0.1 -::1
protected-mode yes
port 6379

A hivatalos Redis konfigurációs sablon loopback kötését használja a helyi hozzáféréshez, alapértelmezés szerint engedélyezi a védett módot, és a normál TCP-portot 6379-re állítja. Azt is dokumentálja, hogy a port 0 letiltja a nem-TLS TCP figyelőt. A jelenlegi sablont a hivatalos Redis repóban vizsgálhatod meg.

Ugyanazon a hoston futó fejlesztési környezetben a loopback kötés megfelelő. Egy jogos távoli vagy több hostos telepítésnél ne oldd meg a kapcsolatot azzal, hogy gondtalanul minden interfészre átállítod a bind beállítást, és kikapcsolod a protected-mode-ot. A Redis figyelmeztet a TCP-port megbízhatatlan hálózatokra való kitettségére. Használj megfelelő hálózati interfészt, tűzfal szabályzatot és Redis hitelesítést vagy ACL-eket ehelyett. Vizsgáld át a hivatalos Redis biztonsági útmutatót, mielőtt szélesítenéd a hálózati hozzáférést.

A konfiguráció módosítása után indítsd újra a Redist ugyanazzal a szolgáltatáskezelővel, konténer paranccsal vagy folyamatfelügyelővel, amely a futó példányt kezeli. Ezután ismételd meg:

redis-cli -h 127.0.0.1 -p 6379 PING

5. Ha a Redis válaszol, javítsd az alkalmazás kapcsolati beállításait

Amint a Redis CLI PONG-ot ad vissza ugyanabból a futtatókörnyezetből, mint az alkalmazásod, az eredeti kapcsolat elutasítási probléma már nem Redis-figyelő probléma. Hasonlítsd össze az alkalmazás beállításait a sikeres teszttel. Ellenőrizd az összes következő értéket:

• Hostnév vagy IP-cím
• TCP port
• Adatbázis szám, ha az alkalmazás nem alapértelmezett adatbázist választ
• Felhasználónév és jelszó, ha az ACL hitelesítés engedélyezve van
• Hogy a kapcsolat sima Redis-t vagy TLS-t használ-e
• Hogy az alkalmazás a hoston, WSL-ben, konténerben vagy egy másik gépen fut-e

Egy helyi, nem-TLS URL gyakran így néz ki:

redis://127.0.0.1:6379/0

A Redis CLI támogatja a Redis URI-kat és dokumentálja a rediss:// sémát TLS-hez. Ha a szerver hitelesítést igényel, használd a megfelelő felhasználónevet és jelszót. CLI teszteléshez a Redis a REDISCLI_AUTH környezeti változót ajánlja ahelyett, hogy a jelszót közvetlenül a parancssorba írná. Lásd a Redis CLI kapcsolati lehetőségeit.

Ne keverd össze a hitelesítési és TLS hibákat a kapcsolat elutasítással

Ha az üzenet Connection refused-ról NOAUTH-ra, WRONGPASS-ra vagy ACL hibára változik, az előrelépés: az ügyfél elérte a Redis szervert, és most érvényes hitelesítő adatokra van szüksége. A Redis az ACL-alapú hitelesítést ajánlja modern telepítésekhez; a hivatalos Redis ACL dokumentáció elmagyarázza a modellt.

Hasonlóképpen, ha a végpont TLS-t igényel, egy sima TCP Redis ügyfél a protokoll beállítása során is elbukhat, még akkor is, ha a port elérhető. A Redis CLI támogatja a --tls kapcsolót, és a Redis URI-k a rediss sémát használják TLS kapcsolatokhoz. A szerveroldali TLS részletekért lásd a Redis TLS dokumentációt.

Környezet-specifikus kapcsolati célok

Gyors ellenőrzőlista

• Futtasd a redis-cli -h 127.0.0.1 -p 6379 PING parancsot.
• Ha elutasítják, győződj meg róla, hogy a Redis folyamat vagy szolgáltatás fut.
• Győződj meg róla, hogy a Redis valóban a 6379-es porton figyel, vagy frissítsd az ügyfelet a konfigurált portra.
• Ha Docker-t használsz, ellenőrizd a port leképezést és azt, hogy az ügyfél a hoston vagy egy másik konténerben van-e.
• Ha mindkét szolgáltatás Compose-ban van, használd a Redis szolgáltatás nevét a 127.0.0.1 helyett.
• Ellenőrizd az aktív redis.conf-ot a bind, protected-mode és port beállítások miatt.
• Tartsd a Redist távol a nyilvános internettől; ne tiltsd le a biztonsági beállításokat csak azért, hogy eltűnjön a hiba.
• Amikor a PING működik, térj át az alkalmazás hitelesítő adataira, TLS-re, URL-re, adatbázis számára és környezet-specifikus hálózatra.

Mi szokta megoldani ezt a hibát?

Egy fejlesztői gépen a leggyakoribb sikeres út egyszerű: indítsd el a Redist, győződj meg róla, hogy azon a végponton figyel, amelyet az alkalmazásod ténylegesen használ, majd ellenőrizd a PING paranccsal. A Docker megváltoztatja a „localhost” jelentését, így a konténeresített alkalmazásoknak gyakran szükségük van egy szolgáltatásnévre vagy a host.docker.internal címre a 127.0.0.1 helyett. A konfigurációs változtatásoknak az utolsó, nem az első lépésnek kell lenniük.

A kulcsfontosságú diagnosztikai határ az, hogy létrejön-e a TCP-kapcsolat. Az elutasítás azt jelenti, hogy az ügyfél nem ért el használható Redis figyelőt a kért végponton. Egy Redis hiba, mint például a NOAUTH, azt jelenti, hogy igen. Ezen két eset eltérő kezelése elkerüli a felesleges konfigurációs változtatásokat, és sokkal gyorsabban elvezet a valódi okhoz.