Cauze de bază și soluții pentru eroarea „Prea multe redirecționări”

Eroarea "Too Many Redirects" — afișată în browsere ca ERR_TOO_MANY_REDIRECTS și corespunzând unei bucle de redirecționare HTTP — apare atunci când un server web și un client intră într-un lanț circular de redirecționări care nu se rezolvă niciodată la o destinație finală. Browserul abandonează cererea după depășirea pragului de redirecționare (de obicei 20 de salturi în Chrome) și afișează această eroare în loc să încarce pagina.

Aceasta nu este o eroare vagă de rețea. Este o defecțiune deterministă cauzată de o configurare greșită specifică în regulile serverului, setările SSL, valorile din baza de date CMS, configurația CDN sau datele de redirecționare din cache. Fiecare instanță are o cauză rădăcină trasabilă, iar fiecare cauză rădăcină are o soluție precisă. Acest ghid le parcurge pe toate cu profunzimea tehnică necesară pentru a rezolva problema permanent — indiferent dacă rulați un site WordPress, o aplicație personalizată sau un stack de server brut pe un mediu de VPS Hosting.

Ce se întâmplă de fapt în timpul unei bucle de redirecționare

Când un browser solicită un URL, serverul poate răspunde cu un cod de stare 301 Moved Permanently, 302 Found sau 307 Temporary Redirect care indică o nouă locație. Browserul urmează acel antet de locație, face o altă cerere și se așteaptă la un răspuns 200 OK la un moment dat în lanț.

O buclă de redirecționare se formează când:

• URL A redirecționează către URL B, iar URL B redirecționează înapoi către URL A (buclă cu două salturi)
• URL A redirecționează către URL B, care redirecționează către URL C, care redirecționează înapoi către URL A (buclă cu mai multe salturi)
• Un singur URL se redirecționează către el însuși (buclă auto-referențială)

Browserele nu se repetă la infinit. Chrome și Firefox se opresc ambele după aproximativ 20 de redirecționări și afișează ERR_TOO_MANY_REDIRECTS. Safari afișează "Safari Can't Open the Page." Comportamentul HTTP de bază este identic în toate.

Cauze rădăcină și soluții precise

1. Reguli de redirecționare configurate greșit în .htaccess sau Nginx

Cea mai frecventă cauză tehnică sunt regulile de rescriere conflictuale sau circulare în stratul de configurare al serverului.

Exemplu Apache .htaccess de buclă defectă:

RewriteEngine On
RewriteRule ^page$ /page [R=301,L]

Această regulă redirecționează /page către /page — o buclă auto-referențială. Similar, două reguli care redirecționează între /old-url și /new-url în direcții opuse vor cauza același eșec.

Cum se diagnostichează:

Deschideți fișierul .htaccess și urmăriți manual fiecare directivă RewriteRule și Redirect. Căutați orice regulă în care modelul țintă poate corespunde sursei altei reguli.

grep -n "Redirect|RewriteRule|RewriteCond" /var/www/html/.htaccess

Pentru Nginx, problema echivalentă apare în blocurile server sau location:

# Broken example — loop between two location blocks
location /old {
    return 301 /new;
}
location /new {
    return 301 /old;
}

Auditați configurația Nginx cu:

nginx -T | grep -A3 "return 301|rewrite"

Soluție: Asigurați-vă că fiecare regulă de redirecționare are o sursă și o destinație unice, fără suprapuneri. Folosiți indicatorul [L] în Apache pentru a opri procesarea regulilor odată ce o potrivire este găsită. În Nginx, preferați return 301 față de rewrite pentru claritate și pentru a evita înlănțuirea neintențională.

2. Configurare greșită a redirecționării HTTP către HTTPS

Aceasta este cea mai frecventă cauză în mediile de hosting moderne, în special după adăugarea unui Certificat SSL fără actualizarea configurației la nivelul aplicației.

Modelul de eșec arată astfel:

• Serverul web forțează tot traficul HTTP către HTTPS prin .htaccess sau configurația Nginx
• Aplicația (de ex., WordPress) are opțiunea siteurl sau home setată la http:// în baza de date
• Aplicația redirecționează apoi cererile HTTPS înapoi la HTTP
• Bucla este: HTTP → HTTPS (server) → HTTP (app) → HTTPS (server) → ...

Redirecționare HTTPS corectă în Apache .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Redirecționare HTTPS corectă în Nginx:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Capcană critică: Dacă vă aflați în spatele unui load balancer sau proxy invers (inclusiv Cloudflare), serverul backend poate să nu vadă HTTPS direct. Proxy-ul termină SSL și transmite cererea ca HTTP către originea dvs. Serverul dvs. vede apoi %{HTTPS} = off și redirecționează din nou către HTTPS — creând o buclă.

Soluția este să verificați în schimb antetul X-Forwarded-Proto:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

3. Nepotrivire mod SSL Cloudflare și CDN

Dacă utilizați Cloudflare sau un alt CDN în fața serverului dvs. de origine, modul de criptare SSL/TLS trebuie să corespundă stării reale a certificatului originii dvs.

Cel mai frecvent scenariu de buclă Cloudflare: Modul SSL este setat la Flexible, iar serverul de origine are o regulă .htaccess care forțează HTTP la HTTPS. Cloudflare trimite HTTP la origine, originea redirecționează la HTTPS, Cloudflare primește acea redirecționare, trimite din nou HTTP — buclă infinită.

Soluție: Setați modul SSL Cloudflare la Full (Strict) și asigurați-vă că originea dvs. are un certificat valid. Alternativ, dacă trebuie să utilizați Flexible, eliminați complet redirecționarea HTTP→HTTPS de pe serverul dvs. de origine și lăsați Cloudflare să o gestioneze printr-o regulă de pagină sau comutatorul "Always Use HTTPS".

De asemenea, dezactivați Automatic HTTPS Rewrites în Cloudflare dacă originea dvs. gestionează deja redirecționările — a le avea pe ambele active dublează logica de redirecționare.

4. Nepotrivire setări URL WordPress

WordPress stochează URL-urile sale canonice în două câmpuri din baza de date: siteurl (URL-ul instalării de bază WordPress) și home (URL-ul public). Când aceste valori intră în conflict cu regulile de redirecționare ale serverului sau între ele, o buclă este aproape inevitabilă.

Verificați valorile curente prin WP-CLI:

wp option get siteurl
wp option get home

Sau interogați direct baza de date:

mysql -u dbuser -p dbname -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"

Ambele valori trebuie să utilizeze același protocol (https://) și același format de domeniu (cu sau fără www) pe care îl impune configurația serverului dvs.

Soluție prin WP-CLI:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Soluție prin wp-config.php (suprascrie valorile din baza de date, util când nu puteți accesa panoul de administrare):

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Conflicte de plugin-uri: Plugin-urile de gestionare a redirecționărilor (Redirection, Simple 301 Redirects, modulul de redirecționare Yoast SEO) pot crea reguli de redirecționare stocate în baza de date care intră în conflict cu regulile la nivel de server. Redenumiți temporar directorul de plugin-uri pentru a izola problema:

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

Reactivați plugin-urile unul câte unul după ce confirmați că bucla a dispărut.

5. Cache browser și redirecționări 301 în cache

Browserele stochează în cache răspunsurile 301 Moved Permanently în mod agresiv — prin design. Dacă o redirecționare 301 a fost servită anterior pentru un URL și apoi ținta redirecționării a fost schimbată, browserul poate urma în continuare vechea redirecționare din cache, care poate indica o destinație care acum creează o buclă.

Acesta este un scenariu deosebit de înșelător deoarece bucla poate să nu se reproducă pe un browser nou sau pe alt dispozitiv, determinând administratorii să concluzioneze incorect că serverul funcționează bine.

Pași de diagnosticare:

1. Deschideți URL-ul într-o fereastră incognito/privată (fără date în cache)
2. Testați cu curl pentru a ocoli complet cache-ul browserului:

curl -I -L --max-redirs 10 https://example.com

1. Utilizați un instrument online de urmărire a lanțului de redirecționări (de ex., redirect-checker.org sau httpstatus.io) pentru a vedea fiecare salt pe partea serverului

Soluție: Ștergeți cache-ul browserului și cookie-urile pentru domeniul afectat. În Chrome: Setări > Confidențialitate și securitate > Ștergeți datele de navigare > selectați Imagini și fișiere în cache + Cookie-uri.

Pentru cache-ul pe partea serverului (Varnish, Redis, OPcache sau un plugin de cache precum W3 Total Cache):

# Flush Varnish cache
varnishadm ban req.url ~ .

# Flush OPcache via PHP CLI
php -r "opcache_reset();"

6. Conflicte de redirecționare www vs. non-www

O sursă frecvent trecută cu vederea a buclelor de redirecționare este gestionarea inconsistentă a subdomeniului www. Dacă serverul dvs. redirecționează www.example.com către example.com și simultan redirecționează example.com către www.example.com, aveți o buclă.

Verificați configurația DNS și de redirecționare curentă:

curl -sI http://www.example.com | grep -i location
curl -sI http://example.com | grep -i location

Configurație Apache corectă (non-www canonic):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

Asigurați-vă că această regulă nu este asociată cu o altă regulă care redirecționează versiunea non-www înapoi la www.

7. Cookie-uri corupte sau conflictuale

Unele aplicații folosesc cookie-uri pentru a gestiona starea de redirecționare (de ex., redirecționări la autentificare, detectarea localizării, framework-uri de testare A/B). Dacă un cookie stochează o țintă de redirecționare care ea însăși declanșează o altă redirecționare, bucla este condusă de logica aplicației, nu de configurația serverului.

Diagnosticare: Testați URL-ul cu toate cookie-urile șterse pentru acel domeniu. În Chrome DevTools (F12), mergeți la Application > Storage > Cookies, selectați domeniul și ștergeți toate intrările. Reîncărcați pagina.

Dacă eroarea dispare după ștergerea cookie-urilor, problema se află în logica de sesiune sau de redirecționare a aplicației dvs., nu în configurația serverului.

Comparație: Scenarii frecvente de buclă de redirecționare și soluțiile lor

Flux de lucru sistematic pentru diagnosticare

Înainte de a atinge orice fișier de configurare, urmați această secvență pentru a izola cauza:

Pasul 1 — Reproduceți fără cache:

curl -v -L --max-redirs 25 https://example.com 2>&1 | grep -E "Location:|< HTTP"

Aceasta arată fiecare salt de redirecționare și codul de răspuns final. Dacă vedeți aceleași URL-uri repetându-se, ați confirmat bucla și ați identificat URL-urile implicate.

Pasul 2 — Verificați jurnalele de erori ale serverului:

# Apache
tail -100 /var/log/apache2/error.log | grep -i redirect

# Nginx
tail -100 /var/log/nginx/error.log | grep -i rewrite

Pasul 3 — Izolați stratul:

• Dacă bucla dispare când comentați regulile .htaccess, problema se află în configurația Apache
• Dacă dispare când ocoliți Cloudflare (testați prin IP direct), problema se află în setările CDN
• Dacă dispare când redenumiți directorul de plugin-uri, problema se află într-un plugin WordPress
• Dacă dispare în incognito dar nu în modul normal, problema este cache-ul browserului sau cookie-urile

Pasul 4 — Validați legarea certificatului SSL:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "subject|issuer|Verify"

Un certificat invalid sau nepotrivit poate cauza eșecuri de redirecționare HTTPS care se manifestă ca bucle.

Prevenirea buclelor de redirecționare în producție

Odată rezolvate, aceste practici previn recurența:

• Utilizați o singură regulă de redirecționare canonică care gestionează atât HTTP→HTTPS cât și www→non-www într-o singură trecere, nu două reguli separate care pot interacționa
• Testați lanțurile de redirecționare înainte de implementare folosind curl -L sau un verificator online de redirecționări după orice modificare de configurare
• Setați redirecționările 301 doar când sunt permanente — folosiți 302 în timpul testării pentru ca browserele să nu stocheze în cache redirecționarea
• Documentați fiecare regulă de redirecționare în .htaccess sau configurația Nginx cu comentarii inline care explică intenția
• Monitorizați cu instrumente de uptime care urmăresc lanțurile de redirecționare și alertează când numărul de salturi depășește un prag

Pentru echipele care gestionează mai multe site-uri pe un VPS cu cPanel, modulul Redirects din cPanel oferă o interfață vizuală pentru gestionarea regulilor de redirecționare, dar scrie în .htaccess — verificați întotdeauna manual rezultatul după utilizarea interfeței grafice.

Dacă rulați un site cu trafic ridicat sau mai multe domenii, un Server Dedicat vă oferă control deplin asupra configurației Nginx sau Apache la nivel de sistem, eliminând constrângerile mediului partajat care pot complica depanarea redirecționărilor.

Pentru site-urile care utilizează Panouri de control VPS precum Plesk sau DirectAdmin, regulile de redirecționare pot fi gestionate atât prin interfața panoului, cât și direct în fișierele de configurare — verificați ambele locații pentru a vă asigura că nu se contrazic.

Listă de verificare tehnică a punctelor cheie

Folosiți aceasta ca listă de verificare preliminară când diagnosticați ERR_TOO_MANY_REDIRECTS:

• [ ] Rulați curl -v -L --max-redirs 25 pentru a mapa întregul lanț de redirecționare înainte de a atinge orice configurație
• [ ] Confirmați că atât siteurl cât și home în WordPress corespund protocolului și domeniului pe care serverul dvs. îl impune
• [ ] Verificați că modul SSL Cloudflare este Full (Strict) dacă originea dvs. are un certificat valid
• [ ] Verificați că .htaccess sau configurația Nginx folosește X-Forwarded-Proto în loc de %{HTTPS} când se află în spatele unui proxy
• [ ] Asigurați-vă că redirecționările www și non-www sunt unidirecționale — o singură formă canonică
• [ ] Dezactivați temporar toate plugin-urile legate de redirecționare și reactivați-le unul câte unul
• [ ] Ștergeți cache-ul browserului și testați în incognito pentru a exclude răspunsurile 301 în cache
• [ ] Inspectați cookie-urile aplicației pentru starea de redirecționare care poate conduce o buclă
• [ ] Validați că certificatul SSL este valid și corect legat de domeniu
• [ ] După remediere, folosiți temporar 302 înainte de a trece la 301 pentru a preveni stocarea în cache a unei redirecționări defecte

Întrebări frecvente

Care este diferența dintre ERR_TOO_MANY_REDIRECTS și un cod de stare HTTP 310?

ERR_TOO_MANY_REDIRECTS este o eroare de browser pe partea clientului declanșată după ce browserul depășește limita de urmărire a redirecționărilor (de obicei 20). HTTP 310 este un cod de stare rar utilizat care înseamnă "Too Many Redirects" la nivel de protocol. În practică, aproape toate erorile de buclă de redirecționare întâlnite în producție sunt ERR_TOO_MANY_REDIRECTS pe partea browserului — nu un răspuns 310 emis de server.

De ce bucla de redirecționare apare doar pe unele browsere sau dispozitive, dar nu pe altele?

Cel mai frecvent motiv este o redirecționare 301 stocată în cache în browser care indică o destinație acum invalidă. Deoarece răspunsurile 301 sunt stocate în cache pe termen nedefinit în mod implicit, un browser care a vizitat anterior URL-ul poate urma un lanț de redirecționare învechit. Testarea în modul incognito sau pe un dispozitiv nou ocolește acest cache și dezvăluie comportamentul actual al serverului.

Cum remediez o buclă de redirecționare în WordPress când nu pot accesa panoul de administrare?

Adăugați următoarele linii direct în wp-config.php pentru a suprascrie valorile URL din baza de date, apoi accesați panoul de administrare pentru a corecta setările corespunzător:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Alternativ, actualizați valorile direct în baza de date folosind wp-cli sau o interogare MySQL directă împotriva tabelului wp_options.

Poate o buclă de redirecționare afecta pozițiile SEO?

Da. O buclă de redirecționare nu returnează niciun răspuns 200 OK, ceea ce înseamnă că Googlebot nu poate crawla sau indexa URL-ul afectat. Dacă bucla afectează pagina dvs. de start sau paginile cheie de destinație, va duce la dezindexare în timp. În plus, orice echitate de link 301 care trece prin URL-ul cu buclă este efectiv pierdută. Rezolvarea promptă a buclei și verificarea posibilității de crawlare în Google Search Console este esențială.

Cum previn Cloudflare să cauzeze bucle de redirecționare cu configurarea mea SSL?

Setați modul de criptare SSL/TLS al Cloudflare la Full (Strict) în tabloul de bord SSL/TLS. Aceasta asigură că Cloudflare comunică cu originea dvs. prin HTTPS folosind un certificat validat, eliminând bucla HTTP↔HTTPS pe care modul Flexible o creează când serverul de origine impune și el HTTPS. În plus, dezactivați "Automatic HTTPS Rewrites" dacă originea dvs. sau .htaccess gestionează deja redirecționarea HTTP-la-HTTPS pentru a evita logica de dublă redirecționare.