Slik løser du feilen «Redis Connection to 127.0.0.1:6379 Failed»

Kort svar: Hvis applikasjonen din rapporterer Could not connect to Redis at 127.0.0.1:6379: Connection refused, bør du først sjekke om en Redis-server faktisk lytter på den adressen og porten. Redis CLI bruker 127.0.0.1 og port 6379 som standard, så en avvisning peker vanligvis mot en stoppet server, en annen port, en nettverksfeil i en container eller virtuell maskin, eller et problem med lytterkonfigurasjonen. Autentiseringsfeil er annerledes: de oppstår normalt etter at TCP-forbindelsen allerede er etablert.

Den raskeste diagnostikken er redis-cli -h 127.0.0.1 -p 6379 PING. Hvis den returnerer PONG, er Redis tilgjengelig, og du bør i stedet inspisere applikasjonens Redis-URL, legitimasjon, TLS-innstillinger eller konfigurasjonen av tilkoblingspoolen, i stedet for å starte Redis på nytt uten videre. Redis dokumenterer PING spesifikt som en måte å teste om en tilkobling er aktiv og om serveren kan levere data. Se den offisielle dokumentasjonen for Redis PING-kommandoen.

Rask diagnosetabell

1. Reproduser feilen utenfor applikasjonen

Bruk Redis CLI før du endrer applikasjonskode. Redis' offisielle CLI-dokumentasjon sier at redis-cli som standard kobler seg til 127.0.0.1:6379. Du kan gjøre målet eksplisitt:

redis-cli -h 127.0.0.1 -p 6379 PING

En vellykket lokal server bør svare:

PONG

Hvis du får samme melding om tilkoblingsavvisning, har du reprodusert problemet på transportnivå. Det er nyttig fordi det fjerner rammeverket, ORM-en, cache-biblioteket og applikasjonskoden fra den umiddelbare etterforskningen. Redis CLI aksepterer også -h for verten og -p for porten, som dokumentert i Redis CLI-referansen.

Hvis PING allerede returnerer PONG, hopp til trinn 5. Ikke fortsett å starte en sunn Redis-instans på nytt; fokuser på applikasjonens tilkoblingsstreng og kjøretidsmiljø.

2. Sørg for at Redis-serveren kjører

På et Linux-system installert via en pakkebehandler kan Redis vanligvis styres som en systemtjeneste. Redis' Linux-installasjonsdokumentasjon viser systemctl start og systemctl stop, mens det bemerkes at tjenestenavnet kan være redis eller redis-server avhengig av plattformen. En typisk Ubuntu/Debian-sjekk er:

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

Hvis distribusjonen din bruker redis som tjenestenavn, erstatt det navnet. Hvis systemd ikke administrerer Redis-prosessen din, bruk oppstartsmetoden som samsvarer med hvordan du installerte Redis, i stedet for å anta at en tjeneste finnes. Den gjeldende Redis Linux-veiledningen er tilgjengelig i den offisielle Linux-installasjonsdokumentasjonen.

Merknad om Windows og WSL

Ikke anta at en native Windows Redis-tjeneste finnes bare fordi applikasjonen din kjører på Windows. Redis' gjeldende installasjonsoversikt lister Windows under Docker-stien, mens Redis også vedlikeholder Windows-veiledning for WSL og dets Windows-kompatibilitetspartner. Hvis Redis kjører inne i WSL, test den fra samme WSL-miljø først. Hvis Redis kjører i Docker Desktop, bruk Docker-sjekkene i neste avsnitt. Se den gjeldende Redis Open Source installasjonsoversikten og Redis Windows/WSL-installasjonsdokumentasjonen.

3. Sjekk port 6379 og fiks Docker-nettverk

Redis bruker normalt TCP-port 6379. Hvis Redis kjører, men ingenting lytter på den porten, sjekk om serveren ble startet med en annen konfigurasjon. På Linux kan en rask operativsystemsjekk som ss -ltnp vise lyttende TCP-sockets; på Windows kan PowerShell's Test-NetConnection 127.0.0.1 -Port 6379 hjelpe med å skille en lyttende port fra en avvist. Den avgjørende testen forblir imidlertid en fungerende Redis-kommando som PING.

Hvis Redis kjører i Docker og appen din kjører på verten

Containerporten må publiseres til verten. Redis' Docker-dokumentasjon viser en vert-til-container-mapping for port 6379. For lokal utvikling kan du binde den publiserte porten til vertens loopback-adresse:

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

Dockers egen dokumentasjon for portpublisering forklarer at spesifikasjon av 127.0.0.1 gjør den publiserte porten kun tilgjengelig fra Docker-verten, noe som er tryggere for en lokal utviklingscache enn å publisere den på alle grensesnitt. Redis' offisielle Docker-raskstart og tilkoblingseksempler finnes i Kjør Redis Open Source på Docker, og vertsadresseoppførselen er beskrevet i Dockers dokumentasjon for portpublisering.

Hvis applikasjonen din også kjører i Docker

Dette er en vanlig kilde til forvirring. Inne i en container refererer 127.0.0.1 til selve containeren. Hvis Redis er en separat Compose-tjeneste, koble deg til Redis-tjenestenavnet, som redis:6379, på det delte Compose-nettverket i stedet for 127.0.0.1:6379. Docker dokumenterer at Compose-tjenester på standardnettverket er oppdagbare via tjenestenavn i sin Compose-nettverksveiledning.

Hvis applikasjonen er i en Docker Desktop-container, men Redis kjører direkte på verten, anbefaler Docker det spesielle vertsnavnet host.docker.internal for å nå vertstjenester. Den oppførselen er dokumentert i Docker Desktop nettverks-FAQ.

4. Verifiser redis.conf: bind, beskyttet modus og port

Hvis prosessen kjører, men lytter på feil grensesnitt eller port, inspiser konfigurasjonsfilen som den aktive Redis-prosessen faktisk bruker. Tre innstillinger betyr mest for denne feilen:

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

Den offisielle Redis-konfigurasjonsmalen bruker loopback-binding for lokal tilgang, aktiverer beskyttet modus som standard, og setter den normale TCP-porten til 6379. Den dokumenterer også at port 0 deaktiverer den ikke-TLS TCP-lytteren. Du kan inspisere den gjeldende malen i det offisielle Redis-repositoriet.

For en utviklingsoppsett på samme vert er loopback-binding hensiktsmessig. For en legitim fjern- eller flervertsutplassering, ikke løs tilkoblingsproblemer ved å tilfeldig endre bind til alle grensesnitt og slå av protected-mode. Redis advarer mot å eksponere TCP-porten mot upålitelige nettverk. Bruk et passende nettverksgrensesnitt, brannmurpolicy og Redis-autentisering eller ACL-er i stedet. Gå gjennom den offisielle Redis-sikkerhetsveiledningen før du utvider nettverkstilgangen.

Etter at du har endret konfigurasjonen, start Redis på nytt ved hjelp av samme tjenestehåndterer, containerkommando eller prosessovervåker som eier den kjørende instansen. Gjenta deretter:

redis-cli -h 127.0.0.1 -p 6379 PING

5. Hvis Redis svarer, fiks applikasjonens tilkoblingsinnstillinger

Når Redis CLI returnerer PONG fra samme kjøretidsmiljø som applikasjonen din, er det opprinnelige tilkoblingsavvisningsproblemet ikke lenger et Redis-lytterproblem. Sammenlign applikasjonens innstillinger med den vellykkede testen. Sjekk alle disse verdiene:

• Vertsnavn eller IP-adresse
• TCP-port
• Databasenummer, hvis applikasjonen din velger en ikke-standard database
• Brukernavn og passord når ACL-autentisering er aktivert
• Om tilkoblingen bruker vanlig Redis eller TLS
• Om appen kjører på verten, i WSL, i en container, eller på en annen maskin

En lokal, ikke-TLS URL ser ofte ut som:

redis://127.0.0.1:6379/0

Redis CLI støtter også Redis-URI-er og dokumenterer rediss:// for TLS. Hvis serveren krever autentisering, bruk riktig brukernavn og passord. For CLI-testing anbefaler Redis miljøvariabelen REDISCLI_AUTH i stedet for å sette et passord direkte på kommandolinjen. Se Redis CLI tilkoblingsalternativer.

Ikke forveksle autentiserings- og TLS-feil med tilkoblingsavvisning

Hvis meldingen endres fra Connection refused til NOAUTH, WRONGPASS, eller en ACL-feil, er det fremgang: klienten nådde Redis-serveren og trenger nå gyldige legitimasjoner. Redis anbefaler ACL-basert autentisering for moderne utplasseringer; den offisielle Redis ACL-dokumentasjonen forklarer modellen.

På samme måte, hvis endepunktet krever TLS, kan en vanlig TCP Redis-klient feile under protokolloppsett selv om porten er tilgjengelig. Redis CLI støtter --tls, og Redis-URI-er bruker rediss-skjemaet for TLS-tilkoblinger. For detaljer om TLS på serversiden, se Redis TLS-dokumentasjonen.

Miljøspesifikke tilkoblingsmål

Rask sjekkliste

• Kjør redis-cli -h 127.0.0.1 -p 6379 PING.
• Hvis avvist, bekreft at Redis-prosessen eller tjenesten kjører.
• Bekreft at Redis faktisk lytter på port 6379, eller oppdater klienten til den konfigurerte porten.
• Hvis du bruker Docker, verifiser portmappingen og om klienten er på verten eller i en annen container.
• Hvis begge tjenestene er i Compose, bruk Redis-tjenestenavnet i stedet for 127.0.0.1.
• Sjekk den aktive redis.conf for bind, protected-mode og port.
• Hold Redis utenfor det offentlige internettet; deaktiver ikke sikkerhetsinnstillinger bare for å få feilen til å forsvinne.
• Når PING fungerer, gå videre til applikasjonslegitimasjon, TLS, URL, databasenummer og miljøspesifikk nettverk.

Hva løser vanligvis denne feilen?

For en utviklermaskin er den mest vanlige vellykkede veien enkel: start Redis, sørg for at den lytter på endepunktet appen faktisk bruker, og verifiser deretter med PING. Docker endrer betydningen av «localhost», så containerte applikasjoner trenger ofte et tjenestenavn eller host.docker.internal i stedet for 127.0.0.1. Konfigurasjonsendringer bør være det siste tiltaket, ikke det første.

Den viktigste diagnostiske grensen er om en TCP-tilkobling kan etableres. En avvisning betyr at klienten ikke har nådd en brukbar Redis-lytter på det forespurte endepunktet. En Redis-feil som NOAUTH betyr at den har det. Å behandle disse to tilfellene ulikt unngår unødvendige konfigurasjonsendringer og får deg til den virkelige årsaken mye raskere.