Sådan løser du fejlen 'Redis Connection to 127.0.0.1:6379 Failed'

Kort svar: Hvis din applikation rapporterer Could not connect to Redis at 127.0.0.1:6379: Connection refused, skal du først tjekke, om en Redis-server faktisk lytter på den adresse og port. Redis CLI bruger som standard 127.0.0.1 og port 6379, så en afvisning peger typisk på en stoppet server, en anden port, en netværksmismatch i en container eller virtuel maskine, eller et problem med lytterkonfigurationen. Godkendelsesfejl er anderledes: De opstår normalt, efter at TCP-forbindelsen allerede er etableret.

Den hurtigste diagnose er redis-cli -h 127.0.0.1 -p 6379 PING. Hvis den returnerer PONG, er Redis tilgængelig, og du bør i stedet inspicere din applikations Redis-URL, legitimationsoplysninger, TLS-indstillinger eller konfiguration af forbindelsespool frem for blindt at genstarte Redis. Redis dokumenterer specifikt PING som en måde at teste, om en forbindelse er aktiv, og om serveren kan levere data. Se den officielle dokumentation for Redis PING-kommandoen.

Hurtig diagnosetabel

1. Replikér fejlen uden for din applikation

Brug Redis CLI, før du ændrer applikationskode. Redis' officielle CLI-dokumentation angiver, at redis-cli som standard opretter forbindelse til 127.0.0.1:6379. Du kan gøre målet eksplicit:

redis-cli -h 127.0.0.1 -p 6379 PING

En vellykket lokal server skal svare:

PONG

Hvis du får den samme meddelelse om afvist forbindelse, har du replikeret problemet på transportniveau. Det er nyttigt, fordi det fjerner dit framework, ORM, cache-bibliotek og applikationskode fra den umiddelbare undersøgelse. Redis CLI accepterer også -h for værten og -p for porten, som dokumenteret i Redis CLI-referencen.

Hvis PING allerede returnerer PONG, skal du springe til trin 5. Genstart ikke en sund Redis-instans; fokuser i stedet på applikationens forbindelsesstreng og køremiljø.

2. Sørg for, at Redis-serveren kører

På et Linux-system installeret via en pakkehåndtering kan Redis typisk styres som en systemtjeneste. Redis' Linux-installationsdokumentation viser systemctl start og systemctl stop, mens det bemærkes, at tjenestenavnet kan være redis eller redis-server afhængigt af platformen. En typisk Ubuntu/Debian-kontrol er:

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

Hvis din distribution bruger redis som tjenestenavn, skal du erstatte det navn. Hvis systemd ikke administrerer din Redis-proces, skal du bruge den opstartsmetode, der matcher, hvordan du installerede Redis, frem for at antage, at en tjeneste eksisterer. Den nuværende Redis Linux-vejledning er tilgængelig i den officielle Linux-installationsdokumentation.

Windows og WSL-bemærkning

Antag ikke, at der findes en native Windows Redis-tjeneste, bare fordi din applikation kører på Windows. Redis' nuværende installationsoversigt lister Windows under Docker-stien, mens Redis også vedligeholder Windows-vejledning for WSL og dets Windows-kompatibilitetspartner. Hvis Redis kører inde i WSL, skal du teste det fra det samme WSL-miljø først. Hvis Redis kører i Docker Desktop, skal du bruge Docker-kontrollerne i det næste afsnit. Se den nuværende oversigt over Redis Open Source-installation og Redis Windows/WSL-installationsdokumentationen.

3. Tjek port 6379 og ret Docker-netværk

Redis bruger normalt TCP-port 6379. Hvis Redis kører, men intet lytter på den port, skal du tjekke, om serveren blev startet med en anden konfiguration. På Linux kan en hurtig operativsystemkontrol som ss -ltnp vise lyttende TCP-sockets; på Windows kan PowerShell's Test-NetConnection 127.0.0.1 -Port 6379 hjælpe med at skelne mellem en lyttende port og en afvist port. Den afgørende test er dog stadig en fungerende Redis-kommando som PING.

Hvis Redis kører i Docker, og din app kører på værten

Containerporten skal publiceres til værten. Redis' Docker-dokumentation viser en host-til-container-mapping for port 6379. Til lokal udvikling kan du binde den publicerede port til værtsloopback-adressen:

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

Dockers egen dokumentation om portpublicering forklarer, at angivelse af 127.0.0.1 gør den publicerede port kun tilgængelig fra Docker-værten, hvilket er sikrere for en lokal udviklingscache end at publicere den på alle grænseflader. Redis' officielle Docker-hurtigstart og forbindelseseksempler findes i Kør Redis Open Source på Docker, og værtsadresseadfærden er beskrevet i Dockers dokumentation om portpublicering.

Hvis din applikation også kører i Docker

Dette er en almindelig kilde til forvirring. Indeni en container refererer 127.0.0.1 til selve containeren. Hvis Redis er en separat Compose-tjeneste, skal du oprette forbindelse til Redis-tjenestenavnet, såsom redis:6379, på det delte Compose-netværk frem for 127.0.0.1:6379. Docker dokumenterer, at Compose-tjenester på standardnetværket er opdagelige efter tjenestenavn i sin Compose-netværksvejledning.

Hvis applikationen er i en Docker Desktop-container, men Redis kører direkte på værten, anbefaler Docker det specielle værtsnavn host.docker.internal for at nå host-tjenester. Denne adfærd er dokumenteret i Docker Desktop-netværks FAQ.

4. Verificér redis.conf: bind, beskyttet tilstand og port

Hvis processen kører, men lytter på den forkerte grænseflade eller port, skal du inspicere konfigurationsfilen, som den aktive Redis-proces faktisk bruger. Tre indstillinger er vigtigst for denne fejl:

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

Den officielle Redis-konfigurationsskabelon bruger loopback-binding til lokal adgang, aktiverer beskyttet tilstand som standard og indstiller den normale TCP-port til 6379. Den dokumenterer også, at port 0 deaktiverer den ikke-TLS TCP-lytter. Du kan inspicere den nuværende skabelon i det officielle Redis-repositorium.

For en udviklingsopsætning på samme host er loopback-binding passende. For en legitim fjern- eller multi-host-implementering skal du ikke løse forbindelsesproblemer ved lemfældigt at ændre bind til alle grænseflader og slå protected-mode fra. Redis advarer mod at eksponere sin TCP-port for upålidelige netværk. Brug i stedet en passende netværksgrænseflade, firewall-politik og Redis-godkendelse eller ACL'er. Gennemgå den officielle Redis-sikkerhedsvejledning, før du udvider netværksadgangen.

Efter ændring af konfigurationen skal du genstarte Redis ved hjælp af den samme tjenestehåndtering, containerkommando eller procesovervåger, der ejer den kørende instans. Gentag derefter:

redis-cli -h 127.0.0.1 -p 6379 PING

5. Hvis Redis svarer, skal du rette applikationens forbindelsesindstillinger

Når Redis CLI returnerer PONG fra det samme køremiljø som din applikation, er det oprindelige problem med afvist forbindelse ikke længere et Redis-lytterproblem. Sammenlign applikationens indstillinger med den vellykkede test. Tjek alle disse værdier:

• Værtsnavn eller IP-adresse
• TCP-port
• Databasenummer, hvis din applikation vælger en ikke-standarddatabase
• Brugernavn og adgangskode, når ACL-godkendelse er aktiveret
• Om forbindelsen bruger almindelig Redis eller TLS
• Om appen kører på værten, i WSL, i en container eller på en anden maskine

En lokal, ikke-TLS URL ser ofte sådan ud:

redis://127.0.0.1:6379/0

Redis CLI understøtter også Redis-URI'er og dokumenterer rediss:// for TLS. Hvis serveren kræver godkendelse, skal du bruge det korrekte brugernavn og adgangskode. Til CLI-test anbefaler Redis miljøvariablen REDISCLI_AUTH frem for at sætte en adgangskode direkte på kommandolinjen. Se Redis CLI-forbindelsesmulighederne.

Forveksl ikke godkendelses- og TLS-fejl med afvist forbindelse

Hvis meddelelsen ændrer sig fra Connection refused til NOAUTH, WRONGPASS eller en ACL-fejl, er det fremgang: Klienten har nået Redis-serveren og har nu brug for gyldige legitimationsoplysninger. Redis anbefaler ACL-baseret godkendelse for moderne implementeringer; den officielle Redis ACL-dokumentation forklarer modellen.

Ligeledes, hvis slutpunktet kræver TLS, kan en almindelig TCP Redis-klient fejle under protokoletablering, selvom porten er tilgængelig. Redis CLI understøtter --tls, og Redis-URI'er bruger rediss-skemaet for TLS-forbindelser. For server-side TLS-detaljer, se Redis TLS-dokumentationen.

Miljøspecifikke forbindelsesmål

Hurtig tjekliste

• Kør redis-cli -h 127.0.0.1 -p 6379 PING.
• Hvis afvist, bekræft at Redis-processen eller -tjenesten kører.
• Bekræft at Redis virkelig lytter på port 6379, eller opdater klienten til den konfigurerede port.
• Hvis du bruger Docker, skal du verificere portkortlægningen og om klienten er på værten eller i en anden container.
• Hvis begge tjenester er i Compose, skal du bruge Redis-tjenestenavnet frem for 127.0.0.1.
• Tjek den aktive redis.conf for bind, protected-mode og port.
• Hold Redis væk fra det offentlige internet; deaktiver ikke sikkerhedsindstillinger blot for at få fejlen til at forsvinde.
• Når PING virker, skal du gå videre til applikationslegitimationsoplysninger, TLS, URL, databasenummer og miljøspecifikt netværk.

Hvad løser typisk denne fejl?

For en udviklermaskine er den mest almindelige vellykkede vej enkel: Start Redis, sørg for, at den lytter på det slutpunkt, din app faktisk bruger, og verificér derefter med PING. Docker ændrer betydningen af “localhost”, så containeriserede applikationer har ofte brug for et tjenestenavn eller host.docker.internal frem for 127.0.0.1. Konfigurationsændringer bør være det sidste udvej, ikke det første.

Den vigtigste diagnostiske grænse er, om en TCP-forbindelse kan etableres. En afvisning betyder, at klienten ikke har nået en brugbar Redis-lytter på det anmodede slutpunkt. En Redis-fejl som NOAUTH betyder, at den har det. At behandle disse to tilfælde forskelligt undgår unødige konfigurationsændringer og bringer dig til den reelle årsag meget hurtigere.