Så här åtgärdar du felet 'Redis Connection to 127.0.0.1:6379 Failed'

Kort svar: Om din applikation rapporterar Could not connect to Redis at 127.0.0.1:6379: Connection refused, börja med att kontrollera om en Redis-server faktiskt lyssnar på den adressen och porten. Redis CLI använder 127.0.0.1 och port 6379 som standard, så ett avslag pekar oftast på en stoppad server, en annan port, en nätverkskonflikt i en container eller virtuell maskin, eller ett problem med lyssnarkonfigurationen. Autentiseringsfel är annorlunda: de uppstår normalt först efter att TCP-anslutningen redan har etablerats.

Den snabbaste diagnostiken är redis-cli -h 127.0.0.1 -p 6379 PING. Om den returnerar PONG är Redis nåbar och du bör istället inspektera applikationens Redis-URL, autentiseringsuppgifter, TLS-inställningar eller konfiguration av anslutningspool, istället för att blindt starta om Redis. Redis dokumenterar PING specifikt som ett sätt att testa om en anslutning är levande och om servern kan tillhandahålla data. Se den officiella dokumentationen för Redis PING-kommandot.

Snabb diagnos-tabell

1. Reproducera felet utanför din applikation

Använd Redis CLI innan du ändrar applikationskod. Redis officiella CLI-dokumentation säger att redis-cli som standard ansluter till 127.0.0.1:6379. Du kan göra målet explicit:

redis-cli -h 127.0.0.1 -p 6379 PING

En framgångsrik lokal server bör svara:

PONG

Om du får samma meddelande om anslutningsavslag har du reproducerat problemet på transportnivå. Det är användbart eftersom det tar bort ditt ramverk, ORM, cache-bibliotek och applikationskod från den omedelbara utredningen. Redis CLI accepterar också -h för värden och -p för porten, enligt dokumentationen i Redis CLI-referensen.

Om PING redan returnerar PONG, hoppa till steg 5. Starta inte om en frisk Redis-instans upprepade gånger; fokusera på applikationens anslutningssträng och körningsmiljö.

2. Se till att Redis-servern körs

På ett Linux-system installerat via en pakethanterare kan Redis vanligtvis styras som en systemtjänst. Redis Linux-installationsdokumentation visar systemctl start och systemctl stop, med noteringen att tjänstenamnet kan vara redis eller redis-server beroende på plattform. En typisk Ubuntu/Debian-kontroll är:

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

Om din distribution använder redis som tjänstenamn, ersätt med det namnet. Om systemd inte hanterar din Redis-process, använd den startmetod som matchar hur du installerade Redis istället för att anta att en tjänst finns. Den nuvarande Redis Linux-vägledningen finns i den officiella Linux-installationsdokumentationen.

Windows och WSL-notering

Anta inte att en nativ Windows Redis-tjänst finns bara för att din applikation körs på Windows. Redis nuvarande installationsöversikt listar Windows under Docker-vägen, medan Redis också underhåller Windows-vägledning för WSL och dess Windows-kompatibilitetspartner. Om Redis körs inuti WSL, testa det från samma WSL-miljö först. Om Redis körs i Docker Desktop, använd Docker-kontrollerna i nästa avsnitt. Se den nuvarande installationsöversikten för Redis Open Source och Redis Windows/WSL installationsdokumentation.

3. Kontrollera port 6379 och åtgärda Docker-nätverk

Redis använder normalt TCP-port 6379. Om Redis körs men ingenting lyssnar på den porten, kontrollera om servern startades med en annan konfiguration. På Linux kan en snabb operativsystemkontroll som ss -ltnp visa lyssnande TCP-uttag; på Windows kan PowerShells Test-NetConnection 127.0.0.1 -Port 6379 hjälpa till att skilja på en lyssnande port och en avslagen port. Den avgörande testet förblir dock ett fungerande Redis-kommando som PING.

Om Redis körs i Docker och din app körs på värden

Containerporten måste publiceras till värden. Redis Docker-dokumentation visar en värd-till-container-mappning för port 6379. För lokal utveckling kan du binda den publicerade porten till värdens loopback-adress:

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

Dockers egen dokumentation för portpublicering förklarar att specificering av 127.0.0.1 gör den publicerade porten endast nåbar från Docker-värden, vilket är säkrare för en lokal utvecklingscache än att publicera den på alla gränssnitt. Redis officiella Docker-snabbstart och anslutningsexempel finns i Kör Redis Open Source på Docker, och värdadressbeteendet beskrivs i Dockers dokumentation för portpublicering.

Om din applikation också körs i Docker

Detta är en vanlig källa till förvirring. Inuti en container refererar 127.0.0.1 till själva containern. Om Redis är en separat Compose-tjänst, anslut till Redis-tjänstens namn, som redis:6379, på det delade Compose-nätverket istället för 127.0.0.1:6379. Docker dokumenterar att Compose-tjänster på standardnätverket är upptäckbara via tjänstenamn i sin Compose-nätverksguide.

Om applikationen finns i en Docker Desktop-container men Redis körs direkt på värden, rekommenderar Docker det speciella värdnamnet host.docker.internal för att nå värdtjänster. Det beteendet dokumenteras i Docker Desktop nätverks-FAQ.

4. Verifiera redis.conf: bind, skyddat läge och port

Om processen körs men lyssnar på fel gränssnitt eller port, inspektera konfigurationsfilen som den aktiva Redis-processen faktiskt använder. Tre inställningar är viktigast för detta fel:

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

Den officiella Redis-konfigurationsmallen använder loopback-bindning för lokal åtkomst, aktiverar skyddat läge som standard och ställer in den normala TCP-porten till 6379. Den dokumenterar också att port 0 inaktiverar den icke-TLS TCP-lyssnaren. Du kan inspektera den nuvarande mallen i det officiella Redis-repositoriet.

För en utvecklingsmiljö på samma värd är loopback-bindning lämplig. För en legitim fjärr- eller flervärd-deployering, lös inte anslutningsproblem genom att slarvigt ändra bind till alla gränssnitt och stänga av protected-mode. Redis varnar mot att exponera dess TCP-port för okända nätverk. Använd ett lämpligt nätverksgränssnitt, brandväggspolicy och Redis-autentisering eller ACL istället. Granska den officiella Redis säkerhetsvägledningen innan du vidgar nätverksåtkomsten.

Efter att du ändrat konfigurationen, starta om Redis med samma tjänsthanterare, containerkommando eller processövervakare som äger den körande instansen. Upprepa sedan:

redis-cli -h 127.0.0.1 -p 6379 PING

5. Om Redis svarar, åtgärda applikationens anslutningsinställningar

När Redis CLI returnerar PONG från samma körningsmiljö som din applikation, är det ursprungliga anslutningsavslagsproblemet inte längre ett problem med Redis-lyssnaren. Jämför applikationens inställningar med det framgångsrika testet. Kontrollera alla dessa värden:

• Värdnamn eller IP-adress
• TCP-port
• Databasnummer, om din applikation väljer en icke-standard databas
• Användarnamn och lösenord när ACL-autentisering är aktiverad
• Huruvida anslutningen använder vanlig Redis eller TLS
• Huruvida appen körs på värden, i WSL, i en container eller på en annan maskin

En lokal, icke-TLS URL ser ofta ut så här:

redis://127.0.0.1:6379/0

Redis CLI stöder också Redis-URI:er och dokumenterar rediss:// för TLS. Om servern kräver autentisering, använd lämpligt användarnamn och lösenord. För CLI-testning rekommenderar Redis miljövariabeln REDISCLI_AUTH istället för att sätta ett lösenord direkt på kommandoraden. Se Redis CLI anslutningsalternativ.

Förväxla inte autentiserings- och TLS-fel med anslutningsavslag

Om meddelandet ändras från Connection refused till NOAUTH, WRONGPASS eller ett ACL-fel, är det framsteg: klienten nådde Redis-servern och behöver nu giltiga autentiseringsuppgifter. Redis rekommenderar ACL-baserad autentisering för moderna deployeringar; den officiella Redis ACL-dokumentationen förklarar modellen.

På samma sätt, om slutpunkten kräver TLS, kan en vanlig TCP Redis-klient misslyckas under protokolluppsättningen även om porten är nåbar. Redis CLI stöder --tls, och Redis-URI:er använder rediss-schemat för TLS-anslutningar. För server-sidans TLS-detaljer, se Redis TLS-dokumentation.

Miljöspecifika anslutningsmål

Snabb checklista

• Kör redis-cli -h 127.0.0.1 -p 6379 PING.
• Om avslaget, bekräfta att Redis-processen eller tjänsten körs.
• Bekräfta att Redis verkligen lyssnar på port 6379, eller uppdatera klienten till den konfigurerade porten.
• Om du använder Docker, verifiera portmappningen och om klienten är på värden eller i en annan container.
• Om båda tjänsterna finns i Compose, använd Redis-tjänstens namn istället för 127.0.0.1.
• Kontrollera den aktiva redis.conf för bind, protected-mode och port.
• Håll Redis borta från det offentliga internet; inaktivera inte säkerhetsinställningar enbart för att få felet att försvinna.
• När PING fungerar, gå vidare till applikationsautentiseringsuppgifter, TLS, URL, databasnummer och miljöspecifikt nätverk.

Vad löser vanligtvis detta fel?

För en utvecklingsmaskin är den vanligaste framgångsrika vägen enkel: starta Redis, se till att den lyssnar på den slutpunkt din app faktiskt använder, och verifiera sedan med PING. Docker ändrar betydelsen av “localhost”, så containeriserade applikationer behöver ofta ett tjänstenamn eller host.docker.internal istället för 127.0.0.1. Konfigurationsändringar bör vara det sista utvägen, inte det första.

Den viktiga diagnostiska gränsen är om en TCP-anslutning kan etableras. Ett avslag betyder att klienten inte har nått en användbar Redis-lyssnare på den begärda slutpunkten. Ett Redis-fel som NOAUTH betyder att den har det. Att behandla dessa två fall olika undviker onödiga konfigurationsändringar och får dig till den verkliga orsaken mycket snabbare.