Külastate oma veebisaiti ja tuttava lehe asemel näitab brauser teadet „ERR_TOO_MANY_REDIRECTS". Sait ei lae, administraatori paneel pole ligipääsetav ja külastajad näevad viga. Paanika? Ei, see on parandatav.

Tehniliselt tähendab see viga, et brauser jäi lõpmatusse ümbersuunamistsüklisse: leht A saadab teid lehele B, mis saadab teid tagasi lehele A ja nii edasi, kuni brauser annab alla. WordPressis juhtub seda olukorda sagedamini, kui sooviksite, ja peaaegu alati pole süüdlaseks häkkerid, vaid süütu seadistuse muutmine.

Allpool on kuus tõestatud viisi oma saidi taas töökorda saamiseks. Alates kiireimast (brauseri vahemälu tühjendamine) kuni serveritasemeni (HTTPS-i ümbersuunamiste kontrollimine). Minge need järjekorras läbi ja üks neist lahendab probleemi.

💡 Kiire ülevaade:

• Tühjendage brauseri vahemälu ja küpsised: välistage lokaalne põhjus
• Kontrollige saidi URL-i WordPressi seadetes ja failis wp-config.php: vastuolulised WP_HOME/WP_SITEURL lõhuvad ümbersuunamised
• Tühjendage WP pistikprogrammide (WP Super Cache, WP Rocket, W3 Total Cache) ja CDN-i vahemälu: vahemälu salvestab vanu reegleid
• Looge uuesti .htaccess: rikutud fail tekitab sageli lisaümbersuunamisi
• Keelake pistikprogrammid ja leidke konfliktne: eriti need, mis haldavad ümbersuunamisi või SSL-i
• Kontrollige HTTPS-i seadeid: valesti seadistatud sunnitud HTTP-lt-HTTPS-le ümbersuunamine tekitab liikluse tsükli

1. Tühjendage brauseri vahemälu ja küpsised

Alustage põhitõdedest. Brauserid salvestavad vahemällu ümbersuunamisi ja kui teie sait ajutiselt tõrkus, võib vana vahemälu teid ringiratast saata ka pärast seda, kui serveripoolne probleem on lahendatud.

Chrome'is: kolm punkti paremas ülanurgas → „Settings" → „Privacy and security" → „Clear browsing data". Märkige „Cookies" ja „Cached images", seadke ajavahemikuks „All time" ja klõpsake „Delete data".

Firefoxis: kolm joont → „Settings" → „Privacy & Security" → „Cookies and Site Data" jaotis → „Clear Data". Märkige mõlemad kastid ja kinnitage.

Pärast tühjendamist avage sait inkognito režiimis (Ctrl+Shift+N Chrome'is). Kas toimis? Siis oli probleem lokaalne. Kui mitte, liikuge edasi. Muide, kui teil on vaja vahemälu erinevates brauserites täielikult lähtestada, on meil eraldi juhend brauseri vahemälu tühjendamise kohta; otsige seda saidilt.

2. Kontrollige saidi URL-i WordPressi seadetes

Vastuolu saidi aadressi ja WordPressi aadressi vahel on üks levinumaid ümbersuunamistsüklite põhjuseid. Minge administraatori paneeli: „Settings" → „General". Väljad „WordPress Address (URL)" ja „Site Address (URL)" peaksid kattuma (või olema teadlikult erinevad, kui WordPress on alamkaustas).

Veenduge, et:

• Protokoll on igal pool sama: kas igal pool https:// või igal pool http://
• www on mõlemas väljas kas olemas või mõlemast puudu
• Domeen on õigesti kirjutatud, ilma trükivigade või lõpu-kaldkriipsudeta

Klõpsasite „Save", kuid viga püsib? Või administraatori paneel ei avane ümbersuunamiste tõttu üldse? Siis muutke wp-config.php kaudu.

Looge serveriga ühendus FTP/SFTP või oma hostinguteenuse failihalduri kaudu. Leidke saidi juurkaustast fail wp-config.php ja lisage kaks rida (kohe pärast <?php või enne /* That's all, stop editing! */):

1
define('WP_HOME', 'https://your-site.com');
2
define('WP_SITEURL', 'https://your-site.com');

Asendage your-site.com oma tegeliku domeeniga, õige protokolliga ja ilma www-ta, kui teie sait avaneb ilma selleta. Salvestage, laadige serverisse tagasi ja kontrollige saiti. Ümbersuunamised kaovad sageli kohe pärast seda sammu.

3. Tühjendage WordPressi ja CDN-i vahemälu

Kui teie saidil on vahemäluplugin, võib see olla meelde jätnud „katkised" ümbersuunamised ja jätkab nende serveerimist ka pärast seda, kui allikas on parandatud.

Minge administraatoripaneeli ja leidke vahemälu haldamise leht:

• WP Super Cache: „Settings" → „WP Super Cache" → „Delete Cache"
• W3 Total Cache: „Performance" → „Purge All Caches"
• WP Rocket: „Settings" → „WP Rocket" → „Clear Cache"

Kasutate Cloudflare'i või mõnda muud CDN-i? Minge CDN-i paneeli ja tühjendage seal vahemälu. Pärast tühjendamist peatage ajutiselt CDN („Development Mode" või „Bypass Cache" režiimis) ja kontrollige saiti. Mõnikord põhjustab CDN ise ümbersuunamistsükleid HTTP/HTTPS mittevastavuse tõttu puhverserveri tasemel.

4. Taasloo.htaccess-fail

.htaccess on tekstifail saidi juurkataloogis, mille kaudu Apache haldab ümbersuunamisi. Üks lisarida, vigane plugin või käsitsi muutmine ja sait hakkab tsüklisse minema.

Looge serveriga ühendus FTP/SFTP kaudu, leidke .htaccess ja nimetage see ümber .htaccess_old-iks. See keelab kõik kohandatud reeglid, kuid säilitab koopia juhuks, kui seal oli midagi olulist.

Nüüd peate looma uue puhta .htaccess-faili WordPressi vaikereeglitega. Kui administraatoripaneel on ligipääsetav: „Settings" → „Permalinks" → klõpsake lihtsalt „Save Changes" (midagi muutmata). WordPress taasloob .htaccess-i automaatselt.

Administraatoripaneel pole ligipääsetav? Looge fail käsitsi ja kopeerige sinna see:

1
<IfModule mod_rewrite.c>
2
RewriteEngine On
3
RewriteBase /
4
RewriteRule ^index\.php$ - [L]
5
RewriteCond %{REQUEST_FILENAME} !-f
6
RewriteCond %{REQUEST_FILENAME} !-d
7
RewriteRule . /index.php [L]
8
</IfModule>

Salvestage, laadige üles saidi juurkataloogi ja kontrollige. Kui kasutate Nginx-i, lähevad reeglid serveri konfiguratsiooni ja .htaccess-il ei ole mingit mõju; Nginx-i konfiguratsiooni muutmiseks vajate juurdepääsu kaustale /etc/nginx/sites-available/.

5. Leidke konflikti põhjustav plugin

Ümbersuunamispluginad, SSL-pluginad (Really Simple SSL, WP Force SSL) ja isegi mõned vahemälupluginad on ERR_TOO_MANY_REDIRECTS vea sagedased põhjustajad. Eriti pärast WordPressi või plugina uuendust.

Kui administraatoripaneel töötab: keelake KÕIK pluginad korraga („Plugins" → valige kõik → „Deactivate" → „Apply"). Kontrollige saiti. Kas viga kadus? Lubage pluginaid ükshaaval ja kontrollige pärast igaüht, et leida süüdlane.

Administraatoripaneel ei lae ümbersuunamiste tõttu? Looge serveriga ühendus FTP kaudu, navigeerige kausta wp-content/ ja nimetage plugins kaust ümber plugins_disabled-iks. WordPress tuvastab, et plugins kaust on puudu, ja deaktiveerib automaatselt kõik pluginad.

Kas sait avanes ilma veata? Taastage pluginaid ükshaaval: nimetage konkreetse plugina kaust tagasi (näiteks plugins_disabled/wordpress-seo → plugins/wordpress-seo), kontrollige saiti, korrake. Plugin, mille järel viga uuesti ilmneb, on probleemi allikas. Kustutage see või leidke alternatiiv.

6. Parandage HTTPS-i ümbersuunamise seaded

Viga ilmneb sageli pärast SSL-sertifikaadi paigaldamist, kui sait hakkab sunniviisiliselt HTTP-d HTTPS-ile ümber suunama, kuid seadistus on vale.

Kui kasutate Apache'it, avage .htaccess ja kontrollige, kas seal on dubleerivaid või vastuolulisi ümbersuunamisreegleid. Korrektne HTTP-lt HTTPS-ile ümbersuunamine Apache'i jaoks näeb välja selline:

1
RewriteEngine On
2
RewriteCond %{HTTPS} off
3
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginxi puhul käib reegel serveri seadistuses:

1
server {
2
    listen 80;
3
    server_name your-site.com www.your-site.com;
4
    return 301 https://your-site.com$request_uri;
5
}

Levinud lõks: sait on Cloudflare'i või mõne muu puhverserveri taga, SSL on seadistatud puhverserveri tasemel, kuid WordPress üritab ise HTTPS-ile ümber suunata. See tekitab topelt ümbersuunamise ja põhjustab tsükli. Lahendus: Cloudflare'is lubage SSL/TLS-i jaotises režiim „Full (strict)" ja seadistage serverile sertifikaat (võite kasutada Cloudflare'i lähtesertifikaati). WordPressi poolel eemaldage sunnitud HTTPS-i pluginad; puhverserveri seadetest piisab.

⁉️🤔 Korduma kippuvad küsimused

Miks ilmub viga äkki, kui ma midagi ei muutnud?

Enamasti automaatsete uuenduste tõttu. WordPress uuendas ennast, mõni plugin tõmbas uue versiooni või majutusteenus muutis PHP seadeid või lubas sunnitud HTTPS-i. Pealtnäha „ma ei puutunud midagi", kuid sisemiselt on muutused. Kontrolli halduspaneelist uuenduste ajalugu; süüdlane on tavaliselt ilmselge.

Kas ma saan probleemi lahendada ilma WordPressi halduspaneeli ligipääsuta?

Jah, enamik selles juhendis kirjeldatud samme tehakse ilma halduspaneelita: redigeerid wp-config.php ja .htaccess faili FTP/SFTP kaudu ning muudad plugins kausta nime. Ainult plugina vahemälu tühjendamine nõuab halduspaneeli sisse logimist, kuid ka ilma selleta saad lihtsalt vahemälu plugina kausta ümber nimetada, mis selle deaktiveerib.

Kas brauseri või seadme vahetamine aitab?

Ajutiselt jah, kuid see ei lahenda serveripoolset probleemi. Viga ilmub brauserist sõltumata, kui algpõhjus on serveris. Brauseri vahetamine ainult kinnitab, et probleem ei ole kohalikus vahemälus, ja seejärel pead jätkama sammudega 2-6.

Mida teha, kui ükski kuuest meetodist ei töötanud?

Kontrolli ümbersuunamiste ahelat sellise tööriistaga nagu Redirect-Checker.org; see näitab, millised URL-id on tsüklis. Võta ühendust oma majutusteenuse toega: mõnikord on probleem serveri seadetes (nginx konfiguratsioon, koormuse jagaja), millele sul pole ligipääsu. Samuti luba igaks juhuks WP_DEBUG failis wp-config.php; logid võivad paljastada konkreetse vea põhjustava plugina või teema.

Kas WordPressi teema võib seda viga põhjustada?

Võib küll, kuigi harvemini kui pluginad. Mõned teemad lisavad failis functions.php oma ümbersuunamise reegleid, näiteks sunnitud HTTPS-i või sisselogimisjärgsete ümbersuunamiste jaoks. Kui pluginade keelamine ei aidanud, lülitu ajutiselt vaiketeemale (Twenty Twenty-Five), muutes oma teema kausta nime kataloogis wp-content/themes/.

Viga parandatud. Mis edasi?

ERR_TOO_MANY_REDIRECTS tundub hirmutav, kuid on parandatav 10-15 minutiga, kui järgid samme. Üheksal juhul kümnest on süüdlaseks kas URL-i seaded (2. samm), katkine .htaccess (4. samm) või SSL-i ümbersuunamine (6. samm). Alusta neist ja tõenäoliselt ei pea sa kaugemale minema.

Ja kui su sait jälle töötab, tee kohe varukoopia. Päriselt. wp-config.php, .htaccess ja kogu wp-content kaust: salvesta need kuhugi turvalisse kohta. Järgmine viga (ja see tuleb, WordPress on WordPress) leiab su täielikult valmistununa.

Ja kui sa pole veel artikli alguses olevat videot vaadanud, mine tagasi selle juurde. See demonstreerib visuaalselt kogu parandusprotsessi töötaval saidil. Töötab iga kord.