Näin korjaat virheen: Redis-yhteys osoitteeseen 127.0.0.1:6379 epäonnistui

Pikavastaus: Jos sovelluksesi ilmoittaa virheestä Could not connect to Redis at 127.0.0.1:6379: Connection refused, aloita tarkistamalla, kuunteleeko Redis-palvelin todella kyseisessä osoitteessa ja portissa. Redis CLI käyttää oletuksena osoitetta 127.0.0.1 ja porttia 6379, joten yhteyden hylkäys viittaa yleensä pysäytettyyn palvelimeen, eri porttiin, kontin tai virtuaalikoneen verkkoasetusten ristiriitaan tai kuuntelija-asetusten ongelmaan. Todennusvirheet ovat erilaisia: ne tapahtuvat yleensä vasta sen jälkeen, kun TCP-yhteys on jo muodostettu.

Nopein diagnostiikkatoimenpide on komento redis-cli -h 127.0.0.1 -p 6379 PING. Jos se palauttaa PONG, Redis on saavutettavissa, ja sinun tulisi tarkistaa sovelluksesi Redis-URL, kirjautumistiedot, TLS-asetukset tai yhteyspoolin konfiguraatio sen sijaan, että käynnistäisit Redisin sokeasti uudelleen. Redis dokumentoi PING-komennon nimenomaan tavaksi testata, onko yhteys elossa ja pystyykö palvelin palvelemaan dataa. Katso virallinen Redis PING -komennon dokumentaatio.

Nopean diagnostiikan taulukko

1. Toista virhe sovelluksen ulkopuolella

Käytä Redis CLI:tä ennen sovelluskoodin muuttamista. Redisin virallinen CLI-dokumentaatio kertoo, että oletuksena redis-cli muodostaa yhteyden osoitteeseen 127.0.0.1:6379. Voit määrittää kohteen eksplisiittisesti:

redis-cli -h 127.0.0.1 -p 6379 PING

Toimivan paikallisen palvelimen tulisi vastata:

PONG

Jos saat saman yhteyden hylkäysviestin, olet toistanut ongelman siirtokerroksella. Tämä on hyödyllistä, koska se poistaa kehyksesi, ORM:n, välimuistikirjaston ja sovelluskoodin välittömästä tutkimuksesta. Redis CLI hyväksyy myös -h isännälle ja -p portille, kuten Redis CLI -viite kertoo.

Jos PING palauttaa jo PONG:n, siirry vaiheeseen 5. Älä käynnistä terveellistä Redis-instanssia jatkuvasti uudelleen; keskity sovelluksen yhteysmerkkijonoon ja suoritusympäristöön.

2. Varmista, että Redis-palvelin on käynnissä

Linux-järjestelmässä, joka on asennettu pakettienhallinnan kautta, Redis voidaan yleensä hallita järjestelmäpalveluna. Redisin Linux-asennusdokumentaatio näyttää komennot systemctl start ja systemctl stop, ja huomauttaa, että palvelun nimi voi olla redis tai redis-server alustasta riippuen. Tyypillinen Ubuntu/Debian-tarkistus on:

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

Jos jakelusi käyttää palvelun nimenä redis:iä, korvaa nimi sillä. Jos systemd ei hallinnoi Redis-prosessiasi, käytä käynnistysmenetelmää, joka vastaa sitä, miten asensit Redisin, äläkä oleta palvelun olevan olemassa. Nykyinen Redis Linux -opas on saatavilla virallisessa Linux-asennusdokumentaatiossa.

Huomio Windowsista ja WSL:stä

Älä oleta natiivin Windows Redis -palvelun olevan olemassa vain siksi, että sovelluksesi toimii Windowsissa. Redisin nykyinen asennusyleiskatsaus listaa Windowsin Docker-reitin alla, kun taas Redis ylläpitää myös Windows-oppaita WSL:lle ja sen Windows-yhteensopivuuskumppanille. Jos Redis toimii WSL:n sisällä, testaa sitä ensin samasta WSL-ympäristöstä. Jos Redis toimii Docker Desktopissa, käytä seuraavan osion Docker-tarkistuksia. Katso nykyinen Redis Open Source -asennusyleiskatsaus ja Redis Windows/WSL -asennusdokumentaatio.

3. Tarkista portti 6379 ja korjaa Docker-verkkoasetukset

Redis käyttää normaalisti TCP-porttia 6379. Jos Redis on käynnissä, mutta mikään ei kuuntele kyseisessä portissa, tarkista, onko palvelin käynnistetty eri konfiguraatiolla. Linuxissa nopea käyttöjärjestelmätarkistus kuten ss -ltnp voi näyttää kuuntelevat TCP-pistorasiat; Windowsissa PowerShellin Test-NetConnection 127.0.0.1 -Port 6379 voi auttaa erottamaan kuuntelevan portin hylätystä. Ratkaiseva testi on kuitenkin edelleen toimiva Redis-komento kuten PING.

Jos Redis toimii Dockerissa ja sovelluksesi isäntäkoneella

Kontin portti on julkaistava isäntäkoneelle. Redisin Docker-dokumentaatio näyttää isäntä-kontti-kartoituksen portille 6379. Paikalliseen kehitykseen voit sitoa julkaistun portin isäntäkoneen loopback-osoitteeseen:

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

Dockerin oma portin julkaisudokumentaatio selittää, että 127.0.0.1:n määrittäminen tekee julkaistusta portista saavutettavan vain Docker-isännältä, mikä on turvallisempaa paikalliselle kehitysvälimuistille kuin sen julkaiseminen kaikissa rajapinnoissa. Redisin virallinen Docker-pikaopas ja yhteysesimerkit ovat kohdassa Suorita Redis Open Source Dockerissa, ja isäntäosoitteen käyttäytyminen on kuvattu Dockerin portin julkaisudokumentaatiossa.

Jos sovelluksesi toimii myös Dockerissa

Tämä on yleinen sekaannuksen lähde. Kontin sisällä 127.0.0.1 viittaa kyseiseen konttiin itseensä. Jos Redis on erillinen Compose-palvelu, muodosta yhteys Redis-palvelun nimeen, kuten redis:6379, jaetussa Compose-verkossa sen sijaan, että käyttäisit 127.0.0.1:6379:ää. Docker dokumentoi, että Compose-palvelut oletusverkossa ovat löydettävissä palvelun nimellä sen Compose-verkkodokumentaation mukaan.

Jos sovellus on Docker Desktop -kontissa, mutta Redis toimii suoraan isäntäkoneella, Docker suosittelee erityistä isäntänimeä host.docker.internal isäntäpalveluiden saavuttamiseksi. Tämä käyttäytyminen on dokumentoitu Docker Desktop -verkkoasetusten UKK:ssa.

4. Tarkista redis.conf: bind, suojattu tila ja portti

Jos prosessi on käynnissä mutta kuuntelee väärässä rajapinnassa tai portissa, tutki konfiguraatiotiedostoa, jota aktiivinen Redis-prosessi todella käyttää. Kolme asetusta ovat tärkeimpiä tämän virheen kannalta:

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

Virallinen Redis-konfiguraatiopohja käyttää loopback-sidontaa paikalliseen pääsyyn, ottaa suojatun tilan käyttöön oletuksena ja asettaa normaalin TCP-portin arvoon 6379. Se dokumentoi myös, että port 0 poistaa ei-TLS TCP-kuuntelijan käytöstä. Voit tutkia nykyistä pohjaa virallisessa Redis-tietovarastossa.

Samalla isäntäkoneella olevassa kehitysympäristössä loopback-sidonta on asianmukainen. Lailliseen etä- tai moni-isäntäkäyttöönottoon älä ratkaise yhteyttä muuttamalla bind:iä kevyesti kaikkiin rajapintoihin ja kääntämällä protected-mode pois päältä. Redis varoittaa TCP-portin altistamisesta luottamattomille verkostoille. Käytä sen sijaan sopivaa verkkorajapintaa, palomuurikäytäntöä ja Redis-todennusta tai ACL:iä. Tarkista virallinen Redis-turvallisuusopas ennen verkkopääsyn laajentamista.

Konfiguraation muuttamisen jälkeen käynnistä Redis uudelleen käyttämällä samaa palvelunhallintaa, konttikomentoa tai prosessivalvojaa, joka omistaa käynnissä olevan instanssin. Toista sitten:

redis-cli -h 127.0.0.1 -p 6379 PING

5. Jos Redis vastaa, korjaa sovelluksen yhteysasetukset

Kun Redis CLI palauttaa PONG:n samasta suoritusympäristöstä kuin sovelluksesi, alkuperäinen yhteyden hylkäysongelma ei enää ole Redis-kuuntelijaongelma. Vertaa sovelluksen asetuksia onnistuneeseen testiin. Tarkista kaikki nämä arvot:

• Isäntänimi tai IP-osoite
• TCP-portti
• Tietokantanumero, jos sovelluksesi valitsee ei-oletustietokannan
• Käyttäjätunnus ja salasana, kun ACL-todennus on käytössä
• Käyttääkö yhteys tavallista Redis:iä vai TLS:ää
• Toimiiko sovellus isäntäkoneella, WSL:ssä, kontissa vai toisella koneella

Paikallinen, ei-TLS URL näyttää usein tältä:

redis://127.0.0.1:6379/0

Redis CLI tukee myös Redis-URI:ita ja dokumentoi rediss:// TLS:lle. Jos palvelin vaatii todennuksen, käytä asianmukaista käyttäjätunnusta ja salasanaa. CLI-testauksessa Redis suosittelee REDISCLI_AUTH-ympäristömuuttujan käyttöä sen sijaan, että laittaisit salasanan suoraan komentoriville. Katso Redis CLI -yhteysvaihtoehdot.

Älä sekoita todennus- ja TLS-virheitä yhteyden hylkäykseen

Jos viesti muuttuu muodosta Connection refused muotoon NOAUTH, WRONGPASS tai ACL-virhe, se on edistystä: asiakas saavutti Redis-palvelimen ja tarvitsee nyt kelvolliset kirjautumistiedot. Redis suosittelee ACL-pohjaista todennusta nykyaikaisiin käyttöönottoihin; virallinen Redis ACL -dokumentaatio selittää mallin.

Samoin, jos päätepiste vaatii TLS:ää, tavallinen TCP Redis -asiakas voi epäonnistua protokollan asennuksessa, vaikka portti olisi saavutettavissa. Redis CLI tukee --tls:ää, ja Redis-URI:t käyttävät rediss-schemaa TLS-yhteyksille. Palvelinpuolen TLS-tiedoista katso Redis TLS -dokumentaatio.

Ympäristökohtaiset yhteyskohteet

Nopea tarkistuslista

• Suorita redis-cli -h 127.0.0.1 -p 6379 PING.
• Jos hylätty, varmista, että Redis-prosessi tai -palvelu on käynnissä.
• Varmista, että Redis todella kuuntelee portissa 6379, tai päivitä asiakas konfiguroituun porttiin.
• Jos käytät Dockeria, varmista porttikartoitus ja onko asiakas isäntäkoneella vai toisessa kontissa.
• Jos molemmat palvelut ovat Compose:ssa, käytä Redis-palvelun nimeä sen sijaan, että käyttäisit 127.0.0.1:ää.
• Tarkista aktiivinen redis.conf asetuksille bind, protected-mode ja port.
• Pidä Redis pois julkisesta internetistä; älä poista tietoturva-asetuksia käytöstä pelkästään virheen poistamiseksi.
• Kun PING toimii, siirry sovelluksen kirjautumistietoihin, TLS:ään, URL:aan, tietokantanumeroon ja ympäristökohtaisiin verkkoasetuksiin.

Mikä yleensä korjaa tämän virheen?

Kehittäjän koneella yleisin onnistunut polku on yksinkertainen: käynnistä Redis, varmista, että se kuuntelee päätepisteessä, jota sovelluksesi todella käyttää, ja varmista sitten PING:llä. Docker muuttaa "localhostin" merkitystä, joten kontitetut sovellukset tarvitsevat usein palvelun nimen tai host.docker.internal:n sen sijaan, että käyttäisivät 127.0.0.1:ää. Konfiguraatiomuutosten tulisi olla viimeinen keino, ei ensimmäinen.

Tärkeä diagnostinen raja on, voidaanko TCP-yhteys muodostaa. Hylkäys tarkoittaa, että asiakas ei ole saavuttanut käyttökelpoista Redis-kuuntelijaa pyydetyssä päätepisteessä. Redis-virhe kuten NOAUTH tarkoittaa, että se on saavuttanut. Näiden kahden tapauksen käsitteleminen eri tavalla välttää tarpeettomat konfiguraatiomuutokset ja vie sinut todelliseen syytä paljon nopeammin.