Kako riješiti grešku 'Redis Connection to 127.0.0.1:6379 Failed'

Kratak odgovor: ako vaša aplikacija prijavljuje Could not connect to Redis at 127.0.0.1:6379: Connection refused, počnite provjerom sluša li Redis poslužitelj na toj adresi i priključku. Redis CLI prema zadanim postavkama koristi 127.0.0.1 i priključak 6379, pa odbijanje veze obično ukazuje na zaustavljeni poslužitelj, drugi priključak, neslaganje u mrežnom povezivanju kontejnera ili virtualnog stroja ili problem s konfiguracijom slušatelja. Greške provjere autentičnosti su drugačije: one se obično javljaju nakon što je TCP veza već uspostavljena.

Najbrža dijagnostika je redis-cli -h 127.0.0.1 -p 6379 PING. Ako vrati PONG, Redis je dostupan i umjesto nasumičnog ponovnog pokretanja Redis instance, trebali biste pregledati Redis URL, vjerodajnice, TLS postavke ili konfiguraciju bazena veza vaše aplikacije. Redis dokumentacija navodi PING kao način testiranja je li veza aktivna i može li poslužitelj posluživati podatke. Pogledajte službenu dokumentaciju za Redis PING naredbu.

Tablica brze dijagnostike

1. Reproducirajte kvar izvan vaše aplikacije

Koristite Redis CLI prije mijenjanja koda aplikacije. Službena dokumentacija za Redis CLI navodi da se redis-cli prema zadanim postavkama povezuje na 127.0.0.1:6379. Cilj možete eksplicitno navesti:

redis-cli -h 127.0.0.1 -p 6379 PING

Ispravan lokalni poslužitelj trebao bi odgovoriti:

PONG

Ako dobijete istu poruku o odbijanju veze, reproducirali ste problem na razini prijenosa. To je korisno jer uklanja vaš okvir, ORM, biblioteku za predmemoriju i kod aplikacije iz neposredne istrage. Redis CLI također prihvaća -h za host i -p za priključak, kako je dokumentirano u referenci za Redis CLI.

Ako PING već vraća PONG, preskočite na korak 5. Nemojte nastavljati s ponovnim pokretanjem ispravne Redis instance; fokusirajte se na niz za povezivanje aplikacije i okruženje za izvršavanje.

2. Provjerite radi li Redis poslužitelj

Na Linux sustavima instaliranim putem upravitelja paketa, Redis se često može kontrolirati kao sistemska usluga. Dokumentacija za instalaciju Redis-a na Linuxu prikazuje systemctl start i systemctl stop, uz napomenu da naziv usluge može biti redis ili redis-server, ovisno o platformi. Tipična provjera na Ubuntu/Debian sustavima je:

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

Ako vaša distribucija koristi redis kao naziv usluge, zamijenite taj naziv. Ako systemd ne upravlja vašim Redis procesom, koristite metodu pokretanja koja odgovara načinu na koji ste instalirali Redis, umjesto da pretpostavljate da usluga postoji. Trenutne smjernice za Redis na Linuxu dostupne su u službenoj dokumentaciji za instalaciju na Linuxu.

Napomena za Windows i WSL

Nemojte pretpostavljati da postoji izvorna Windows Redis usluga samo zato što vaša aplikacija radi na Windowsu. Trenutni pregled instalacije Redis-a navodi Windows pod Docker putanjom, dok Redis također održava smjernice za Windows za WSL i svog partnera za kompatibilnost s Windowsom. Ako Redis radi unutar WSL-a, prvo ga testirajte iz istog WSL okruženja. Ako Redis radi u Docker Desktopu, koristite provjere za Docker u sljedećem odjeljku. Pogledajte trenutni pregled instalacije Redis Open Sourcea i dokumentaciju za instalaciju Redis-a na Windowsu/WSL-u.

3. Provjerite priključak 6379 i popravite Docker mrežno povezivanje

Redis obično koristi TCP priključak 6379. Ako Redis radi, ali ništa ne sluša na tom priključku, provjerite je li poslužitelj pokrenut s drugačijom konfiguracijom. Na Linuxu, brza provjera operativnog sustava poput ss -ltnp može prikazati TCP utičnice koje slušaju; na Windowsu, PowerShellova naredba Test-NetConnection 127.0.0.1 -Port 6379 može pomoći u razlikovanju priključka koji sluša od onoga koji odbija vezu. Odlučujući test, međutim, i dalje je ispravna Redis naredba poput PING.

Ako Redis radi u Dockeru, a vaša aplikacija na hostu

Priključak kontejnera mora biti objavljen na hostu. Docker dokumentacija za Redis prikazuje mapiranje od hosta do kontejnera za priključak 6379. Za lokalni razvoj, možete vezati objavljeni priključak na povratnu adresu hosta (loopback):

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

Dockerova vlastita dokumentacija o objavljivanju priključaka objašnjava da navođenje 127.0.0.1 čini objavljeni priključak dostupnim samo s Docker hosta, što je sigurnije za lokalnu predmemoriju za razvoj nego objavljivanje na svakom sučelju. Službeni Docker brzi početak i primjeri povezivanja za Redis nalaze se u Pokretanje Redis Open Sourcea na Dockeru, a ponašanje adrese hosta opisano je u Dockerovoj dokumentaciji o objavljivanju priključaka.

Ako vaša aplikacija također radi u Dockeru

Ovo je čest izvor zabune. Unutar kontejnera, 127.0.0.1 se odnosi na taj kontejner sam. Ako je Redis zasebna Compose usluga, povežite se na naziv Redis usluge, poput redis:6379, na zajedničkoj Compose mreži, a ne na 127.0.0.1:6379. Docker dokumentira da su Compose usluge na zadanoj mreži otkrivive po nazivu usluge u svom vodiču za Compose mrežno povezivanje.

Ako je aplikacija u Docker Desktop kontejneru, ali Redis radi izravno na hostu, Docker preporučuje posebno host ime host.docker.internal za pristup host uslugama. To ponašanje dokumentirano je u Docker Desktop FAQ-u za mrežno povezivanje.

4. Provjerite redis.conf: bind, zaštićeni način i priključak

Ako proces radi, ali sluša na pogrešnom sučelju ili priključku, pregledajte konfiguracijsku datoteku koju aktivni Redis proces stvarno koristi. Tri postavke su najvažnije za ovu grešku:

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

Službeni Redis konfiguracijski predložak koristi vezanje na povratnu adresu (loopback) za lokalni pristup, omogućuje zaštićeni način prema zadanim postavkama i postavlja uobičajeni TCP priključak na 6379. Također dokumentira da port 0 onemogućuje ne-TLS TCP slušatelja. Trenutni predložak možete pregledati u službenom Redis repozitoriju.

Za postavke razvoja na istom hostu, vezanje na povratnu adresu je prikladno. Za legitimno udaljeno ili višehostno uvođenje, nemojte rješavati povezanost olako mijenjajući bind na sva sučelja i isključujući protected-mode. Redis upozorava protiv izlaganja svog TCP priključka nepouzdanim mrežama. Umjesto toga, koristite odgovarajuće mrežno sučelje, politiku vatrozida i Redis provjeru autentičnosti ili ACL pravila. Pregledajte službene smjernice za sigurnost Redis-a prije proširenja mrežnog pristupa.

Nakon promjene konfiguracije, ponovno pokrenite Redis koristeći isti upravitelj usluga, naredbu za kontejner ili nadzornika procesa koji posjeduje pokrenutu instancu. Zatim ponovite:

redis-cli -h 127.0.0.1 -p 6379 PING

5. Ako Redis odgovara, popravite postavke veze aplikacije

Jednom kada Redis CLI vrati PONG iz istog okruženja za izvršavanje kao i vaša aplikacija, izvorni problem odbijanja veze više nije problem s Redis slušateljem. Usporedite postavke aplikacije s uspješnim testom. Provjerite sve ove vrijednosti:

• Naziv hosta ili IP adresa
• TCP priključak
• Broj baze podataka, ako vaša aplikacija odabire nedefoltnu bazu podataka
• Korisničko ime i lozinka kada je omogućena ACL provjera autentičnosti
• Koristi li veza obični Redis ili TLS
• Radi li aplikacija na hostu, u WSL-u, u kontejneru ili na drugom računalu

Lokalni, ne-TLS URL često izgleda ovako:

redis://127.0.0.1:6379/0

Redis CLI također podržava Redis URI-je i dokumentira rediss:// za TLS. Ako poslužitelj zahtijeva provjeru autentičnosti, koristite odgovarajuće korisničko ime i lozinku. Za CLI testiranje, Redis preporučuje varijablu okruženja REDISCLI_AUTH umjesto stavljanja lozinke izravno u naredbeni redak. Pogledajte opcije povezivanja za Redis CLI.

Nemojte miješati neuspjehe provjere autentičnosti i TLS-a s odbijanjem veze

Ako se poruka promijeni iz Connection refused u NOAUTH, WRONGPASS ili ACL grešku, to je napredak: klijent je dosegao Redis poslužitelj i sada su potrebne valjane vjerodajnice. Redis preporučuje provjeru autentičnosti temeljenu na ACL-u za moderne implementacije; službena dokumentacija za Redis ACL objašnjava model.

Slično tome, ako krajnja točka zahtijeva TLS, obični TCP Redis klijent može neuspjeti tijekom postavljanja protokola iako je priključak dostupan. Redis CLI podržava --tls, a Redis URI-ji koriste shemu rediss za TLS veze. Za detalje o TLS-u na strani poslužitelja, pogledajte Redis TLS dokumentaciju.

Ciljevi povezivanja specifični za okruženje

Brzi popis za provjeru

• Pokrenite redis-cli -h 127.0.0.1 -p 6379 PING.
• Ako je veza odbijena, potvrdite radi li Redis proces ili usluga.
• Potvrdite sluša li Redis stvarno na priključku 6379, ili ažurirajte klijenta na konfigurirani priključak.
• Ako koristite Docker, provjerite mapiranje priključka i nalazi li se klijent na hostu ili u drugom kontejneru.
• Ako su obje usluge u Composeu, koristite naziv Redis usluge umjesto 127.0.0.1.
• Provjerite aktivnu redis.conf za bind, protected-mode i port.
• Držite Redis izvan javnog interneta; nemojte onemogućavati sigurnosne postavke samo kako bi nestala greška.
• Kada PING radi, prijeđite na vjerodajnice aplikacije, TLS, URL, broj baze podataka i mrežno povezivanje specifično za okruženje za izvršavanje.

Što obično rješava ovu grešku?

Za razvojno računalo, najčešći uspješan put je jednostavan: pokrenite Redis, provjerite sluša li na krajnjoj točki koju vaša aplikacija stvarno koristi, a zatim potvrdite putem PING. Docker mijenja značenje "localhosta", pa kontejnerizirane aplikacije često trebaju naziv usluge ili host.docker.internal umjesto 127.0.0.1. Promjene konfiguracije trebale bi biti posljednje utočište, a ne prva radnja.

Ključna dijagnostička granica je može li se uspostaviti TCP veza. Odbijanje znači da klijent nije dosegao upotrebljiv Redis slušatelj na traženoj krajnjoj točki. Redis greška poput NOAUTH znači da jest. Različito tretiranje ta dva slučaja izbjegava nepotrebne promjene konfiguracije i dovodi vas do stvarnog uzroka mnogo brže.