Kā novērst Redis savienojuma kļūdu ar 127.0.0.1:6379

Īsā atbilde: ja jūsu lietojumprogramma ziņo par kļūdu Could not connect to Redis at 127.0.0.1:6379: Connection refused, sāciet ar pārbaudi, vai Redis serveris tiešām klausās šajā adresē un portā. Redis CLI pēc noklusējuma izmanto 127.0.0.1 un portu 6379, tāpēc atteice parasti norāda uz apturētu serveri, citu portu, konteinera vai virtuālās mašīnas tīkla nesakritību vai klausītāja konfigurācijas problēmu. Autentifikācijas kļūdas ir atšķirīgas: tās parasti rodas pēc tam, kad TCP savienojums jau ir izveidots.

Ātrākā diagnostika ir komanda redis-cli -h 127.0.0.1 -p 6379 PING. Ja tā atgriež PONG, Redis ir sasniedzams, un jums jāpārbauda lietojumprogrammas Redis URL, akreditācijas dati, TLS iestatījumi vai savienojuma kopas konfigurācija, nevis aklai jāpārstartē Redis. Redis dokumentācija īpaši norāda PING kā veidu, kā pārbaudīt, vai savienojums ir dzīvs un vai serveris var apkalpot datus. Skatiet oficiālo Redis PING komandas dokumentāciju.

Ātrās diagnostikas tabula

1. Atkārtojiet kļūmi ārpus jūsu lietojumprogrammas

Izmantojiet Redis CLI, pirms maināt lietojumprogrammas kodu. Redis oficiālā CLI dokumentācija norāda, ka pēc noklusējuma redis-cli izveido savienojumu ar 127.0.0.1:6379. Jūs varat padarīt mērķi skaidru:

redis-cli -h 127.0.0.1 -p 6379 PING

Veiksmīgam lokālam serverim jāatbild:

PONG

Ja saņemat to pašu savienojuma atteices ziņojumu, esat atkārtojis problēmu transporta līmenī. Tas ir noderīgi, jo tas izslēdz jūsu ietvaru, ORM, kešatmiņas bibliotēku un lietojumprogrammas kodu no tūlītējas izmeklēšanas. Redis CLI arī pieņem -h resursdatoram un -p portam, kā dokumentēts Redis CLI atsauces dokumentācijā.

Ja PING jau atgriež PONG, dodieties uz 5. soli. Nepārtrauciet vesela Redis instances pārstartēšanu; koncentrējieties uz lietojumprogrammas savienojuma virkni un izpildes vidi.

2. Pārliecinieties, ka Redis serveris darbojas

Linux sistēmā, kas instalēta, izmantojot pakotņu pārvaldnieku, Redis parasti var kontrolēt kā sistēmas servisu. Redis Linux instalācijas dokumentācija parāda systemctl start un systemctl stop, norādot, ka servisa nosaukums var būt redis vai redis-server atkarībā no platformas. Tipiska Ubuntu/Debian pārbaude ir:

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

Ja jūsu distribūcija izmanto redis kā servisa nosaukumu, aizstājiet ar šo nosaukumu. Ja systemd nepārvalda jūsu Redis procesu, izmantojiet starta metodi, kas atbilst tam, kā instalējāt Redis, nevis pieņemiet, ka serviss eksistē. Pašreizējās Redis Linux vadlīnijas ir pieejamas oficiālajā Linux instalācijas dokumentācijā.

Piezīme par Windows un WSL

Nepieņemiet, ka eksistē natīvs Windows Redis serviss tikai tāpēc, ka jūsu lietojumprogramma darbojas Windows. Redis pašreizējā instalācijas pārskatā Windows ir norādīts Docker ceļā, savukārt Redis uztur arī Windows vadlīnijas WSL un tā Windows saderības partnerim. Ja Redis darbojas WSL iekšienē, vispirms testējiet to tajā pašā WSL vidē. Ja Redis darbojas Docker Desktop, izmantojiet Docker pārbaudes nākamajā sadaļā. Skatiet pašreizējo Redis Open Source instalācijas pārskatu un Redis Windows/WSL instalācijas dokumentāciju.

3. Pārbaudiet portu 6379 un novērsiet Docker tīkla problēmas

Redis parasti izmanto TCP portu 6379. Ja Redis darbojas, bet nekas neklausās šajā portā, pārbaudiet, vai serveris netika startēts ar citu konfigurāciju. Linux sistēmā ātra operētājsistēmas pārbaude, piemēram, ss -ltnp, var parādīt klausīšanos TCP ligzdas; Windows sistēmā PowerShell Test-NetConnection 127.0.0.1 -Port 6379 var palīdzēt atšķirt klausīšanos portu no atteikta. Noteicošais tests tomēr joprojām ir darbojošās Redis komandas, piemēram, PING, izmantošana.

Ja Redis darbojas Docker un jūsu lietojumprogramma darbojas resursdatorā

Konteinera ports ir jāpublicē resursdatorā. Redis Docker dokumentācija parāda resursdatora un konteinera kartējumu portam 6379. Lokālai izstrādei jūs varat piesaistīt publicēto portu resursdatora cilpas adresi:

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

Docker paša porta publicēšanas dokumentācija skaidro, ka 127.0.0.1 norādīšana padara publicēto portu sasniedzamu tikai no Docker resursdatora, kas ir drošāk lokālai izstrādes kešatmiņai nekā publicēšana visās saskarnēs. Redis oficiālais Docker ātrais sākums un savienojumu piemēri ir pieejami Redis Open Source palaišana Docker, un resursdatora adreses uzvedība ir aprakstīta Docker porta publicēšanas dokumentācijā.

Ja jūsu lietojumprogramma arī darbojas Docker

Tas ir biežs neskaidrību avots. Konteinera iekšienē 127.0.0.1 attiecas uz pašu konteineru. Ja Redis ir atsevišķs Compose serviss, izveidojiet savienojumu ar Redis servisa nosaukumu, piemēram, redis:6379, kopīgajā Compose tīklā, nevis 127.0.0.1:6379. Docker dokumentē, ka Compose servisi noklusējuma tīklā ir atrodami pēc servisa nosaukuma tā Compose tīkla ceļvedī.

Ja lietojumprogramma atrodas Docker Desktop konteinerā, bet Redis darbojas tieši resursdatorā, Docker iesaka īpašo resursdatora nosaukumu host.docker.internal, lai sasniegtu resursdatora servisus. Šī uzvedība ir dokumentēta Docker Desktop tīkla BUJ.

4. Pārbaudiet redis.conf: bind, aizsargāto režīmu un portu

Ja process darbojas, bet klausās nepareizā saskarnē vai portā, pārbaudiet konfigurācijas failu, ko faktiski izmanto aktīvais Redis process. Trīs iestatījumi ir vissvarīgākie šai kļūdai:

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

Oficiālajā Redis konfigurācijas veidnē tiek izmantota cilpas piesaiste lokālai piekļuvei, pēc noklusējuma ir iespējots aizsargātais režīms un parastais TCP ports ir iestatīts uz 6379. Tajā arī dokumentēts, ka port 0 atspējo ne-TLS TCP klausītāju. Jūs varat apskatīt pašreizējo veidni oficiālajā Redis repozitorijā.

Lokālai izstrādes iestatīšanai tajā pašā resursdatorā cilpas piesaiste ir piemērota. Likumīgai attālinātai vai vairāku resursdatoru izvēršanai neatrisiniet savienojamību, vieglprātīgi mainot bind uz visām saskarnēm un izslēdzot protected-mode. Redis brīdina pret tā TCP porta atklāšanu neuzticamiem tīkliem. Tā vietā izmantojiet atbilstošu tīkla saskarni, ugunsmūra politiku un Redis autentifikāciju vai ACL. Pirms paplašināt tīkla piekļuvi, pārskatiet oficiālās Redis drošības vadlīnijas.

Pēc konfigurācijas maiņas pārstartējiet Redis, izmantojot to pašu servisa pārvaldnieku, konteinera komandu vai procesa uzraugu, kas pārvalda darbojošos instanci. Pēc tam atkārtojiet:

redis-cli -h 127.0.0.1 -p 6379 PING

5. Ja Redis atbild, novērsiet lietojumprogrammas savienojuma iestatījumus

Kad Redis CLI atgriež PONG no tās pašas izpildes vides kā jūsu lietojumprogramma, sākotnējā savienojuma atteices problēma vairs nav Redis klausītāja problēma. Salīdziniet lietojumprogrammas iestatījumus ar veiksmīgo testu. Pārbaudiet visas šīs vērtības:

• Resursdatora nosaukums vai IP adrese
• TCP ports
• Datubāzes numurs, ja jūsu lietojumprogramma izvēlas noklusējuma neatbilstošu datubāzi
• Lietotājvārds un parole, ja ir iespējota ACL autentifikācija
• Vai savienojums izmanto parasto Redis vai TLS
• Vai lietojumprogramma darbojas resursdatorā, WSL, konteinerā vai citā mašīnā

Lokāla, ne-TLS URL bieži izskatās šādi:

redis://127.0.0.1:6379/0

Redis CLI atbalsta arī Redis URI un dokumentē rediss:// TLS. Ja serveris pieprasa autentifikāciju, izmantojiet atbilstošo lietotājvārdu un paroli. CLI testēšanai Redis iesaka izmantot REDISCLI_AUTH vides mainīgo, nevis ievietot paroli tieši komandrindā. Skatiet Redis CLI savienojuma opcijas.

Nesajauciet autentifikācijas un TLS kļūmes ar savienojuma atteici

Ja ziņojums mainās no Connection refused uz NOAUTH, WRONGPASS vai ACL kļūdu, tas ir progress: klients sasniedza Redis serveri un tagad tam ir nepieciešami derīgi akreditācijas dati. Redis iesaka ACL balstītu autentifikāciju mūsdienu izvēršanām; oficiālā Redis ACL dokumentācija izskaidro modeli.

Tāpat, ja galapunkts pieprasa TLS, parasts TCP Redis klients var neizdoties protokola iestatīšanas laikā, pat ja ports ir sasniedzams. Redis CLI atbalsta --tls, un Redis URI izmanto rediss shēmu TLS savienojumiem. Servera puses TLS detaļām skatiet Redis TLS dokumentāciju.

Videi specifiski savienojuma mērķi

Ātra pārbaudes saraksts

• Palaist redis-cli -h 127.0.0.1 -p 6379 PING.
• Ja atteikts, pārliecinieties, ka Redis process vai serviss darbojas.
• Pārliecinieties, ka Redis tiešām klausās portā 6379, vai atjauniniet klientu uz konfigurēto portu.
• Ja izmantojat Docker, pārbaudiet porta kartējumu un to, vai klients atrodas resursdatorā vai citā konteinerā.
• Ja abi servisi ir Compose, izmantojiet Redis servisa nosaukumu, nevis 127.0.0.1.
• Pārbaudiet aktīvo redis.conf attiecībā uz bind, protected-mode un port.
• Nepubliskojiet Redis publiskajā internetā; neizslēdziet drošības iestatījumus tikai tāpēc, lai kļūda pazustu.
• Kad PING darbojas, pārejiet uz lietojumprogrammas akreditācijas datiem, TLS, URL, datubāzes numuru un videi specifisku tīklošanu.

Kas parasti novērš šo kļūdu?

Izstrādātāja mašīnai visbiežāk veiksmīgais ceļš ir vienkāršs: startējiet Redis, pārliecinieties, ka tas klausās galapunktā, ko jūsu lietojumprogramma faktiski izmanto, un pēc tam pārbaudiet ar PING. Docker maina “localhost” nozīmi, tāpēc konteinerizētām lietojumprogrammām bieži ir nepieciešams servisa nosaukums vai host.docker.internal, nevis 127.0.0.1. Konfigurācijas izmaiņām jābūt pēdējai iespējai, nevis pirmajai.

Galvenā diagnostikas robeža ir tā, vai var izveidot TCP savienojumu. Atteice nozīmē, ka klients nav sasniedzis izmantojamu Redis klausītāju pieprasītajā galapunktā. Redis kļūda, piemēram, NOAUTH, nozīmē, ka tas ir to izdarījis. Šo divu gadījumu atšķirīga ārstēšana ļauj izvairīties no nevajadzīgām konfigurācijas izmaiņām un daudz ātrāk nonākt pie īstā cēloņa.