Kako odpraviti napako pri povezavi Redis na 127.0.0.1:6379

Hiter odgovor: če vaša aplikacija javlja Could not connect to Redis at 127.0.0.1:6379: Connection refused, začnite s preverjanjem, ali Redis strežnik dejansko posluša na tem naslovu in vratih. Redis CLI privzeto uporablja 127.0.0.1 in vrata 6379, zato zavrnitev običajno kaže na ustavljen strežnik, druga vrata, neskladje omrežja kontejnerja ali navirtualnega stroja ali težavo s konfiguracijo poslušalca. Napake preverjanja pristnosti so drugačne: običajno se pojavijo, ko je TCP povezava že vzpostavljena.

Najhitrejša diagnostika je redis-cli -h 127.0.0.1 -p 6379 PING. Če vrne PONG, je Redis dosegljiv in namesto slepega ponovnega zagona Redisa morate pregledati URL za Redis v vaši aplikaciji, poverilnice, nastavitve TLS ali konfiguracijo bazena povezav. Redis dokumentira PING izrecno kot način za preverjanje, ali je povezava živa in ali lahko strežnik streže podatke. Glejte uradno dokumentacijo ukaza Redis PING.

Tabela hitre diagnostike

1. Ponovite napako zunaj svoje aplikacije

Pred spreminjanjem aplikacijske kode uporabite Redis CLI. Uradna dokumentacija Redis CLI navaja, da se redis-cli privzeto poveže na 127.0.0.1:6379. Cilj lahko eksplicitno določite:

redis-cli -h 127.0.0.1 -p 6379 PING

Uspešen lokalni strežnik bi moral odgovoriti:

PONG

Če prejmete isto sporočilo o zavrnitvi povezave, ste težavo ponovili na transportni ravni. To je koristno, ker iz neposredne preiskave odstrani vaš okvir, ORM, knjižnico za predpomnjenje in aplikacijsko kodo. Redis CLI sprejema tudi -h za gostitelja in -p za vrata, kot je dokumentirano v referenci Redis CLI.

Če PING že vrne PONG, preskočite na korak 5. Ne ponavljajte ponovnega zagona zdrave instance Redisa; osredotočite se na niz za povezavo aplikacije in izvajalno okolje.

2. Prepričajte se, da je Redis strežnik zagnan

V Linux sistemu, nameščenem prek upravitelja paketov, je Redis pogosto mogoče upravljati kot sistemsko storitev. Dokumentacija za namestitev Redisa na Linuxu prikazuje systemctl start in systemctl stop, ob tem pa opozarja, da je ime storitve lahko redis ali redis-server, odvisno od platforme. Tipičen preizkus Ubuntu/Debian je:

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

Če vaša distribucija uporablja redis kot ime storitve, uporabite to ime. Če systemd ne upravlja vašega procesa Redis, uporabite način zagona, ki ustreza načinu namestitve Redisa, namesto da predpostavljate, da storitev obstaja. Trenutna navodila za Redis na Linuxu so na voljo v uradni dokumentaciji za namestitev na Linuxu.

Opomba za Windows in WSL

Ne predpostavljajte, da obstaja izvorna storitev Redis za Windows samo zato, ker se vaša aplikacija izvaja v sistemu Windows. Trenutni pregled namestitve Redisa navaja Windows pod potjo Docker, medtem ko Redis vzdržuje tudi navodila za Windows za WSL in svojega partnerja za združljivost z Windows. Če se Redis izvaja znotraj WSL, ga najprej preizkusite iz istega okolja WSL. Če se Redis izvaja v Docker Desktop, uporabite preglede Docker v naslednjem razdelku. Glejte trenutni pregled namestitve Redis Open Source in dokumentacijo za namestitev Redis na Windows/WSL.

3. Preverite vrata 6379 in popravite Docker omrežje

Redis običajno uporablja TCP vrata 6379. Če je Redis zagnan, a nič ne posluša na teh vratih, preverite, ali je bil strežnik zagnan z drugačno konfiguracijo. V Linuxu lahko hiter pregled operacijskega sistema, kot je ss -ltnp, prikaže TCP vtičnice, ki poslušajo; v sistemu Windows lahko PowerShell Test-NetConnection 127.0.0.1 -Port 6379 pomaga razlikovati med poslušajočimi in zavrnjenimi vrati. Odločilni test pa ostaja delujoč ukaz Redis, kot je PING.

Če se Redis izvaja v Docker in vaša aplikacija na gostitelju

Vrata kontejnerja morajo biti objavljena gostitelju. Dokumentacija Docker za Redis prikazuje preslikavo od gostitelja do kontejnerja za vrata 6379. Za lokalni razvoj lahko objavljena vrata vežete na zankovni naslov gostitelja:

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

Dockerjeva lastna dokumentacija o objavljanju vrat pojasnjuje, da določitev 127.0.0.1 naredi objavljena vrata dostopna samo iz Docker gostitelja, kar je varneje za lokalni razvojni predpomnilnik kot objavljanje na vmesnikih. Uradni Docker hitri začetek in primeri povezav za Redis so v Zagon Redis Open Source na Docker, obnašanje naslova gostitelja pa je opisano v Dockerjevi dokumentaciji o objavljanju vrat.

Če se vaša aplikacija prav tako izvaja v Docker

To je pogost vir zmede. Znotraj kontejnerja se 127.0.0.1 nanaša na ta kontejner sam. Če je Redis ločena storitev Compose, se povežite z imenom storitve Redis, kot je redis:6379, v skupnem omrežju Compose, namesto 127.0.0.1:6379. Docker dokumentira, da so storitve Compose v privzetem omrežju zaznavne po imenu storitve v svojem vodiču za omrežje Compose.

Če je aplikacija v kontejnerju Docker Desktop, a se Redis izvaja neposredno na gostitelju, Docker priporoča posebno ime gostitelja host.docker.internal za dostop do storitev gostitelja. To obnašanje je dokumentirano v pogosto zastavljenih vprašanjih o omrežju Docker Desktop.

4. Preverite redis.conf: bind, zaščiteni način in vrata

Če je proces zagnan, a posluša na napačnem vmesniku ali vratih, preglejte konfiguracijsko datoteko, ki jo dejansko uporablja aktivni proces Redis. Za to napako so najpomembnejše tri nastavitve:

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

Uradna predloga konfiguracije Redisa uporablja vezavo na zanko za lokalni dostop, privzeto omogoča zaščiteni način in nastavi običajna TCP vrata na 6379. Prav tako dokumentira, da port 0 onemogoči ne-TLS TCP poslušalca. Trenutno predlogo lahko pregledate v uradnem repozitoriju Redisa.

Za razvojno namestitev na istem gostitelju je vezava na zanko ustrezna. Za legitimno oddaljeno ali večgostiteljsko namestitev ne rešujte povezljivosti s površinsko spremembo bind na vse vmesnike in izklopom protected-mode. Redis opozarja proti izpostavljanju svojih TCP vrat nepreverjenim omrežjem. Namesto tega uporabite ustrezen omrežni vmesnik, pravilnik požarnega zidu in Redis preverjanje pristnosti ali ACL. Pred razširitvijo omrežnega dostopa preglejte uradne varnostne smernice Redisa.

Po spremembi konfiguracije ponovno zaženite Redis z uporabo istega upravitelja storitev, ukaza kontejnerja ali nadzornika procesov, ki ima v lasti zagnano instanco. Nato ponovite:

redis-cli -h 127.0.0.1 -p 6379 PING

5. Če Redis odgovori, popravite nastavitve povezave aplikacije

Ko Redis CLI vrne PONG iz istega izvajalnega okolja kot vaša aplikacija, prvotna težava zavrnitve povezave ni več težava poslušalca Redis. Primerjajte nastavitve aplikacije z uspešnim testom. Preverite vse te vrednosti:

• Ime gostitelja ali naslov IP
• TCP vrata
• Številka baze, če vaša aplikacija izbere neprivzeto bazo
• Uporabniško ime in geslo, ko je omogočeno preverjanje pristnosti ACL
• Ali povezava uporablja navadni Redis ali TLS
• Ali se aplikacija izvaja na gostitelju, v WSL, v kontejnerju ali na drugem računalniku

Lokalni URL brez TLS je pogosto videti takole:

redis://127.0.0.1:6379/0

Redis CLI podpira tudi URI Redis in dokumentira rediss:// za TLS. Če strežnik zahteva preverjanje pristnosti, uporabite ustrezno uporabniško ime in geslo. Za testiranje CLI Redis priporoča spremenljivko okolja REDISCLI_AUTH namesto neposrednega vnašanja gesla v ukazno vrstico. Glejte možnosti povezave Redis CLI.

Ne zamenjujte napak preverjanja pristnosti in TLS z zavrnitvijo povezave

Če se sporočilo spremeni iz Connection refused v NOAUTH, WRONGPASS ali napako ACL, je to napredek: odjemalec je dosegel strežnik Redis in zdaj potrebuje veljavne poverilnice. Redis priporoča preverjanje pristnosti na osnovi ACL za sodobne namestitve; uradna dokumentacija Redis ACL pojasnjuje model.

Prav tako, če končna točka zahteva TLS, lahko navadni TCP odjemalec Redis odpove med vzpostavitvijo protokola, čeprav so vrata dosegljiva. Redis CLI podpira --tls, URI Redis pa uporabljajo shemo rediss za povezave TLS. Za podrobnosti TLS na strani strežnika glejte dokumentacijo Redis TLS.

Cilji povezave, specifični za okolje

Hitri kontrolni seznam

• Izvedite redis-cli -h 127.0.0.1 -p 6379 PING.
• Če je zavrnjeno, potrdite, da je proces ali storitev Redis zagnana.
• Potrdite, da Redis res posluša na vratih 6379, ali posodobite odjemalca na konfigurirana vrata.
• Če uporabljate Docker, preverite preslikavo vrat in ali je odjemalec na gostitelju ali v drugem kontejnerju.
• Če sta obe storitvi v Compose, uporabite ime storitve Redis namesto 127.0.0.1.
• Preverite aktivno redis.conf za bind, protected-mode in port.
• Redisa ne izpostavljajte javnemu internetu; ne onemogočajte varnostnih nastavitev samo zato, da bi napaka izginila.
• Ko PING deluje, preidite na poverilnice aplikacije, TLS, URL, številko baze in omrežje, specifično za izvajalno okolje.

Kaj običajno odpravi to napako?

Za razvijalčev računalnik je najpogostejša uspešna pot preprosta: zaženite Redis, zagotovite, da posluša na končni točki, ki jo vaša aplikacija dejansko uporablja, nato preverite s PING. Docker spremeni pomen »localhosta«, zato kontejnerizirane aplikacije pogosto potrebujejo ime storitve ali host.docker.internal namesto 127.0.0.1. Spremembe konfiguracije bi morale biti zadnja možnost, ne prva.

Ključna diagnostična meja je, ali je mogoče vzpostaviti TCP povezavo. Zavrnitev pomeni, da odjemalec ni dosegel uporabnega poslušalca Redis na zahtevani končni točki. Napaka Redis, kot je NOAUTH, pomeni, da je. Različno obravnavanje teh dveh primerov prepreči nepotrebne spremembe konfiguracije in vas hitreje pripelje do pravega vzroka.