Kaip ištaisyti Redis prisijungimo prie 127.0.0.1:6379 klaidą

Trumpas atsakymas: jei jūsų programa praneša Could not connect to Redis at 127.0.0.1:6379: Connection refused, pirmiausia patikrinkite, ar Redis serveris iš tikrųjų klausosi tame adrese ir prievade. Redis CLI pagal nutylėjimą naudoja 127.0.0.1 ir prievadą 6379, todėl atmetimas dažniausiai rodo sustabdytą serverį, kitą prievadą, konteinerio ar virtualios mašinos tinklo neatitikimą arba klausiklio konfigūracijos problemą. Autentifikacijos klaidos yra kitokios: jos paprastai kyla jau užmezgus TCP ryšį.

Greičiausia diagnostika yra redis-cli -h 127.0.0.1 -p 6379 PING. Jei grąžinama PONG, Redis yra pasiekiamas, ir vietoj aklai perkraunamo Redis serverio turėtumėte patikrinti savo programos Redis URL, prisijungimo duomenis, TLS nustatymus arba ryšių baseino konfigūraciją. Redis dokumentuose PING specifikuojamas kaip būdas patikrinti, ar ryšys yra gyvas, ir ar serveris gali aptarnauti duomenis. Žiūrėkite oficialią Redis PING komandos dokumentaciją.

Greitos diagnostikos lentelė

1. Atkartokite nesėkmę ne programoje

Prieš keisdami programos kodą, naudokite Redis CLI. Oficialioje Redis CLI dokumentacijoje nurodoma, kad pagal nutylėjimą redis-cli jungiasi prie 127.0.0.1:6379. Galite aiškiai nurodyti tikslą:

redis-cli -h 127.0.0.1 -p 6379 PING

Sėkmingai veikiantis vietinis serveris turėtų atsakyti:

PONG

Jei gaunate tą pačią ryšio atmetimo žinutę, problemą atkūrėte perdavimo lygmenyje. Tai naudinga, nes pašalina jūsų karkasą, ORM, talpyklos biblioteką ir programos kodą iš tiesioginio tyrimo. Redis CLI taip pat priima -h hostui ir -p prievadui, kaip aprašyta Redis CLI nuorodoje.

Jei PING jau grąžina PONG, pereikite prie 5 žingsnio. Neperkraukite sveiko Redis egzemplioriaus; sutelkite dėmesį į programos ryšio eilutę ir vykdymo aplinką.

2. Įsitikinkite, kad Redis serveris veikia

Linux sistemoje, įdiegtoje per paketų tvarkyklę, Redis dažniausiai galima valdyti kaip sistemos tarnybą. Redis Linux diegimo dokumentuose rodomi systemctl start ir systemctl stop, nurodant, kad tarnybos pavadinimas gali būti redis arba redis-server, priklausomai nuo platformos. Tipiškas Ubuntu/Debian patikrinimas yra:

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

Jei jūsų distribucija naudoja redis kaip tarnybos pavadinimą, pakeiskite jį tuo pavadinimu. Jei systemd nevaldo jūsų Redis proceso, naudokite paleidimo metodą, atitinkantį būdą, kuriuo įdiegėte Redis, o ne darykite prielaidą, kad tarnyba egzistuoja. Dabartinė Redis Linux gairė yra prieinama oficialioje Linux diegimo dokumentacijoje.

Windows ir WSL pastaba

Nedarykite prielaidos, kad egzistuoja natyvi Windows Redis tarnyba vien todėl, kad jūsų programa veikia Windows. Dabartinis Redis diegimo apžvalgos sąrašas Windows įtraukia į Docker kelią, o Redis taip pat palaiko Windows gaires WSL ir jo Windows suderinamumo partneriui. Jei Redis veikia WSL viduje, pirmiausia jį išbandykite toje pačioje WSL aplinkoje. Jei Redis veikia Docker Desktop, naudokite Docker patikrinimus kitame skyriuje. Žiūrėkite dabartinę Redis Open Source diegimo apžvalgą ir Redis Windows/WSL diegimo dokumentaciją.

3. Patikrinkite prievadą 6379 ir sutvarkykite Docker tinklą

Redis paprastai naudoja TCP prievadą 6379. Jei Redis veikia, bet niekas neklauso tame prievade, patikrinkite, ar serveris nebuvo paleistas su kita konfigūracija. Linux sistemoje greitas operacinės sistemos patikrinimas, pvz., ss -ltnp, gali parodyti klausiančius TCP lizdus; Windows sistemoje PowerShell Test-NetConnection 127.0.0.1 -Port 6379 gali padėti atskirti klausiantį prievadą nuo atmesto. Tačiau lemiamas testas lieka veikianti Redis komanda, tokia kaip PING.

Jei Redis veikia Docker, o programa – hoste

Konteinerio prievadas turi būti paskelbtas hostui. Redis Docker dokumentuose rodomas hosto ir konteinerio prievado 6379 atvaizdavimas. Vietiniam kūrimui galite susieti paskelbtą prievadą su hosto kilpos (loopback) adresu:

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

Docker prievadų paskelbimo dokumentacija aiškina, kad nurodžius 127.0.0.1, paskelbtas prievadas tampa pasiekiamas tik iš Docker hosto, kas yra saugiau vietinei kūrimo talpyklai nei skelbiant jį visuose sąsajos. Oficialūs Redis Docker greito paleidimo ir ryšio pavyzdžiai yra Run Redis Open Source on Docker, o hosto adreso elgsena aprašyta Docker prievadų paskelbimo dokumentacijoje.

Jei jūsų programa taip pat veikia Docker

Tai dažnas painiavos šaltinis. Konteineryje 127.0.0.1 reiškia patį tą konteinerį. Jei Redis yra atskira Compose tarnyba, prisijunkite prie Redis tarnybos pavadinimo, pvz., redis:6379, bendrame Compose tinkle, o ne 127.0.0.1:6379. Docker dokumentuose nurodoma, kad Compose tarnybos numatytajame tinkle yra aptinkamos pagal tarnybos pavadinimą Compose tinklo vadove.

Jei programa yra Docker Desktop konteineryje, bet Redis veikia tiesiogiai hoste, Docker rekomenduoja specialų hostname host.docker.internal, norint pasiekti hosto tarnybas. Toks elgesys dokumentuotas Docker Desktop tinklo DUK.

4. Patikrinkite redis.conf: bind, apsaugos režimas ir prievadas

Jei procesas veikia, bet klauso neteisingos sąsajos ar prievado, apžiūrėkite konfigūracijos failą, kurį aktyvus Redis procesas iš tikrųjų naudoja. Šiai klaidai svarbiausi trys nustatymai:

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

Oficiali Redis konfigūracijos šablono versija naudoja kilpos (loopback) susiejimui vietinei prieigai, pagal nutylėjimą įjungia apsaugos režimą ir nustato įprastą TCP prievadą 6379. Joje taip pat dokumentuojama, kad port 0 išjungia ne-TLS TCP klausiklį. Dabartinį šabloną galite apžiūrėti oficialiame Redis repozitorijoje.

Vietinės kūrimo aplinkoje, kai naudojamas tas pats hostas, kilpos (loopback) susiejimas yra tinkamas. Legitimiam nuotoliniam arba kelių hostų diegimui, nespręskite ryšio problemų lengvai keisdami bind į visas sąsajas ir išjungdami protected-mode. Redis perspėja prieš atidarydama savo TCP prievadą nepatikimiems tinklams. Vietoj to naudokite tinkamą tinklo sąsają, ugniasienės politiką ir Redis autentifikaciją arba ACL. Peržiūrėkite oficialias Redis saugumo gaires prieš plėsdami tinklo prieigą.

Po konfigūracijos pakeitimo, perkraukite Redis naudodami tą patį tarnybų tvarkyklę, konteinerio komandą arba proceso prižiūrėtoją, kuris valdo veikiančią instanciją. Tada pakartokite:

redis-cli -h 127.0.0.1 -p 6379 PING

5. Jei Redis atsako, sutvarkykite programos ryšio nustatymus

Kai Redis CLI grąžina PONG iš tos pačios vykdymo aplinkos kaip ir jūsų programa, pradinė ryšio atmetimo problema nebėra Redis klausiklio problema. Palyginkite programos nustatymus su sėkmingu testu. Patikrinkite visas šias reikšmes:

• Hosto pavadinimas arba IP adresas
• TCP prievadas
• Duomenų bazės numeris, jei jūsų programa pasirenka ne numatytąją duomenų bazę
• Vartotojo vardas ir slaptažodis, kai įjungta ACL autentifikacija
• Ar ryšys naudoja paprastą Redis ar TLS
• Ar programa veikia hoste, WSL, konteineryje ar kitoje mašinoje

Vietinis, ne-TLS URL dažnai atrodo taip:

redis://127.0.0.1:6379/0

Redis CLI taip pat palaiko Redis URI ir dokumentuoja rediss:// TLS. Jei serveris reikalauja autentifikacijos, naudokite tinkamą vartotojo vardą ir slaptažodį. CLI testavimui Redis rekomenduoja REDISCLI_AUTH aplinkos kintamąjį vietoj slaptažodio tiesiogiai komandinėje eilutėje. Žiūrėkite Redis CLI ryšio parinktis.

Nesupainiokite autentifikacijos ir TLS nesėkmių su ryšio atmetimu

Jei žinutė pasikeičia iš Connection refused į NOAUTH, WRONGPASS arba ACL klaidą, tai yra pažanga: klientas pasiekė Redis serverį ir dabar jam reikia galiojančių prisijungimo duomenų. Redis rekomenduoja ACL pagrįstą autentifikaciją moderniems diegimams; oficiali Redis ACL dokumentacija paaiškina modelį.

Taip pat, jei galinis taškas reikalauja TLS, paprastas TCP Redis klientas gali nepavykti protokolo nustatymo metu, nors prievadas yra pasiekiamas. Redis CLI palaiko --tls, o Redis URI naudoja rediss schemą TLS ryšiams. Serverio pusės TLS detalėms žiūrėkite Redis TLS dokumentaciją.

Aplinkai specifiniai ryšio tikslai

Greitas sąrašas

• Vykdykite redis-cli -h 127.0.0.1 -p 6379 PING.
• Jei atmesta, patvirtinkite, kad Redis procesas arba tarnyba veikia.
• Patvirtinkite, kad Redis iš tikrųjų klauso prievade 6379, arba atnaujinkite klientą į sukonfigūruotą prievadą.
• Jei naudojate Docker, patikrinkite prievado atvaizdavimą ir ar klientas yra hoste, ar kitame konteineryje.
• Jei abi tarnybos yra Compose, naudokite Redis tarnybos pavadinimą vietoj 127.0.0.1.
• Patikrinkite aktyvų redis.conf dėl bind, protected-mode ir port.
• Laikykite Redis nuo viešojo interneto; neišjunkite saugumo nustatymų vien tam, kad klaida dingtų.
• Kai PING veikia, pereikite prie programos prisijungimo duomenų, TLS, URL, duomenų bazės numerio ir aplinkai specifinio tinklo.

Kas dažniausiai išsprendžia šią klaidą?

Kūrėjo mašinoje dažniausiai sėkmingas kelias yra paprastas: paleiskite Redis, įsitikinkite, kad jis klauso galinio taško, kurį jūsų programa iš tikrųjų naudoja, ir tada patvirtinkite su PING. Docker pakeičia „localhost“ reikšmę, todėl konteinerizuotoms programoms dažnai reikia tarnybos pavadinimo arba host.docker.internal vietoj 127.0.0.1. Konfigūracijos pakeitimai turėtų būti paskutinė priemonė, o ne pirmoji.

Svarbi diagnostinė riba yra tai, ar gali būti užmegztas TCP ryšys. Atmetimas reiškia, kad klientas nepasiekė naudojamą Redis klausiklio prašomame galiniame taške. Redis klaida, tokia kaip NOAUTH, reiškia, kad pasiekė. Šių dviejų atvejų skirtingas traktavimas padeda išvengti nereikalingų konfigūracijos pakeitimų ir greičiau rasti tikrąją priežastį.