Vai al contenuto 
Vi spiegherò in modo conciso e chiaro come potete creare una Loop di reindirizzamento WordPress e analizzarli e risolverli in modo affidabile. Vi mostrerò soluzioni immediatamente realizzabili per conflitti SSL, regole .htaccess errate, URL del sito non corretti, cache/cookies, problemi di plugin e impostazioni del server, compresi test e prevenzione.
Punti centrali
L'elenco che segue riassume i passaggi più importanti prima di illustrarli nel dettaglio.
- Causa restringere rapidamente il campo: SSL, .htaccess, URL, plugin, cache
- Standard-Controllo delle regole: .htaccess e wp-config.php
- HTTPS impostato correttamente: Certificato, Contenuto misto, HSTS
- Plugins Spegnimento su base di prova: tramite dashboard o FTP
- Prevenzione stabilire: Backup, documentazione, monitoraggio
Che cosa significa un ciclo di reindirizzamento?
A Anello di inoltro si verifica quando l'URL A salta all'URL B e B torna ad A, oppure quando diversi salti riportano all'indirizzo iniziale alla fine. Il browser si annulla con ERR_TOO_MANY_REDIRECTS e blocca la chiamata. Spesso riconosco il loop dal fatto che il login carica nuovamente il modulo di accesso dopo l'inserimento corretto. Per i visitatori questo sembra un ciclo infinito, per i motori di ricerca un errore tecnico. Questo costa fiducia, impedisce l'accesso al backend e consuma preziosi budget per il crawling.
Principali cause di loop in WordPress
Trovo che i fattori scatenanti più frequenti siano falso URL di WordPress, regole .htaccess aggressive, doppio SSL o reindirizzamenti caotici dei plugin. Anche i vecchi cookie e le cache del browser inviano le richieste fuori strada. Dopo i cambi di dominio o le conversioni HTTPS, gli errori si verificano più frequentemente perché http e https sono mescolati. Nei temi con reindirizzamenti propri o nei plugin di sicurezza, le regole possono bloccarsi a vicenda. In rari casi, il malware imposta deliberatamente i reindirizzamenti per bloccare gli amministratori.
Test rapidi nel browser: Cookie e cache
Inizio con un Cliente-controllo, perché porta chiarezza in pochi minuti. Elimino i cookie e l'intera cache per il dominio interessato. Una finestra privata aiuta a escludere le vecchie sessioni. Se il login funziona, il problema è dovuto ai dati locali e non al server. Se l'errore continua a verificarsi, passo al livello del server e di WordPress.
Controllare .htaccess e ripristinare le impostazioni predefinite
Assicuro il .htaccess e li reimposto allo standard di WordPress come test. In questo modo rimuovo i reindirizzamenti in conflitto con precedenti esperimenti o regole SEO.
# INIZIA WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# FINE WordPress
Una volta che tutto è pronto e funzionante, aggiungerò ulteriori reindirizzamenti passo dopo passo. Per le condizioni pulite faccio riferimento a reindirizzamenti htaccess con esempi pratici. Importante: non forzare mai l'http→https due volte; una volta a livello di server è sufficiente.
Personalizzare gli URL di WordPress nelle impostazioni e in wp-config.php
Scostamenti tra WP_HOME e WP_SITEURL spesso innescano loop infiniti, soprattutto dopo il trasferimento di un dominio. Per prima cosa controllo Impostazioni > Generale. Se il backend non è accessibile, imposto brevemente i valori in wp-config.php:
define( 'WP_HOME', 'https://deinedomain.de' );
define( 'WP_SITEURL', 'https://deinedomain.de' );
In caso di problemi di SSL dell'amministratore, sblocco temporaneamente l'accesso:
define('FORCE_SSL_ADMIN', false);
Non appena sono nella dashboard, imposto gli URL corretti e rimuovo nuovamente le costanti. Gli indirizzi standardizzati evitano cicli ripetuti.
Risolvere in modo pulito i conflitti HTTPS/SSL
I conflitti sorgono quando SSL viene applicato sul lato server e un plugin imposta anche i reindirizzamenti. Per prima cosa verifico se il certificato è valido e se le intestazioni HSTS o proxy interferiscono con il riconoscimento. Poi mi assicuro che ci sia una posizione chiara che imponga l'https, preferibilmente a livello di server. Elimino costantemente gli errori di contenuto misto e le catene di inoltro errate. Per il passaggio effettivo, queste istruzioni mi aiutano a Conversione HTTPS in WordPress.
Limitazione di plugin e temi come fonte di errori
Accendo il sospetto Plugins In particolare gli strumenti di reindirizzamento, SEO e sicurezza. Se non riesco ad accedere al backend, rinomino la cartella wp-content/plugins in plugins.old tramite FTP. Quindi attivo ogni singolo plugin nella dashboard finché l'errore non ricompare. Anche il passaggio a un tema standard come Twenty Twenty-Four mostra se il tema contribuisce alle regole. Questo mi consente di individuare rapidamente la causa e di creare una configurazione priva di conflitti.
Fine dei cicli di login: Cookie, sessioni, sicurezza
Se il login non riesce nonostante la corretta Dati salta di nuovo, controllo il dominio del cookie, il percorso e il flag https. Cancello le cache a tutti i livelli: Browser, cache di WordPress, cache degli oggetti, CDN. Per i plugin di sicurezza, controllo le regole che reindirizzano gli URL degli amministratori o limitano i login. Imposto temporaneamente i valori predefiniti per la diagnostica e poi ricostruisco la sicurezza un po' alla volta. Obiettivo: una sessione stabile senza reindirizzamenti doppi.
Impostazione corretta di reverse proxy, CDN e intestazione del server
Dietro un Proxy Le applicazioni confondono facilmente http e https se l'intestazione Forwarded o X-Forwarded-Proto manca o arriva in modo errato. Controllo le configurazioni di Nginx/Apache, le impostazioni del bilanciatore di carico e l'inoltro del CDN. È importante che WordPress riconosca correttamente l'URL effettivo del client. Per le configurazioni con un proxy upstream, questa guida mi aiuta a Impostare il reverse proxy. In questo modo si evitano regole contraddittorie tra server, CDN e plugin.
Il malware come ultima fonte di sospetto
Se il loop può ancora essere chiuso nonostante tutte le correzioni non Esamino l'installazione alla ricerca di codice dannoso. Confronto i file principali con gli originali, controllo gli amministratori più recenti e i cron job. Espongo i reindirizzamenti nelle intestazioni, nei file dei modelli o tramite JavaScript, cercando window.location, meta refresh o oscure stringhe Base64. Dopo la pulizia, resetto le password e faccio un nuovo backup. La sicurezza contro le reinfezioni fa risparmiare molto tempo in seguito.
Profilassi e monitoraggio nella vita quotidiana
Prevengo i loop Cambiamenti gestisco centralmente i reindirizzamenti e li collaudo in un ambiente di staging prima delle implementazioni live. Creo automaticamente i backup e mantengo aggiornati i plugin e i temi. Dopo le modifiche al dominio, controllo gli URL del sito, l'SSL e le catene di reindirizzamento. Un piccolo sistema di monitoraggio mi segnala tempestivamente i cambiamenti di codice di stato. La seguente tabella è utile per una rapida diagnostica durante il funzionamento.
| Sintomo | Possibile causa | Misura diretta | Strumento di prova |
|---|---|---|---|
| ERRE_TROPPO_REDIRECTS | Doppia applicazione di https | Utilizzate una sola posizione per i reindirizzamenti | Controllo intestazione HTTP, Curl |
| Il login salta indietro | Conflitto tra cookie e sessione | Cancellare i cookie, svuotare la cache | Finestra privata, DevTools |
| La pagina iniziale non viene caricata | Ciclo .htaccess | Attivare .htaccess standard | Registri del server, diff |
| Difettoso solo in caso di delega | Intestazione Proto non corretta | Impostare correttamente X-Forwarded-Proto | Configurazione proxy, tracciamento delle intestazioni |
| Improvvisamente dalla classifica | Catene di reindirizzamento | Ridurre le catene, 301 corretto | Gattonatore, Rana urlante |
Tracciamento preciso dei reindirizzamenti: Tracciamento dell'intestazione e curl
Prima di passare alle configurazioni, disegno il catena esatta a. In DevTools (scheda Network) è possibile vedere ogni salto con il codice di stato e l'intestazione della posizione. Spesso è sufficiente la shell:
curl -IL https://deinedomain.de
# o dettagliato con la visualizzazione di ogni reindirizzamento
curl -IL --max-redirs 20 https://deinedomain.de
Cerco schemi come http→https→http (avanti e indietro) o www↔non-www. Anche un 302 che segue un 301 è sospetto. Se anche la prima richiesta reindirizza a /wp-login.php, la causa è di solito nel plugin/tema o nei cookie; se accade globalmente, spesso è .htaccess o il server.
Uso mirato dei log del server e di WordPress
I log risparmiano ore. Attivo il log di debug in wp-config.php senza visualizzarlo ai visitatori:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Poi controllo /wp-content/debug.log alla ricerca di indicazioni (ad esempio "Impossibile modificare le informazioni di intestazione" prima di un reindirizzamento). Allo stesso tempo, controllo i log del server web. Per Apache: access.log ed error.log, per Nginx: access.log con lo stato 301/302. Un'occhiata all'user agent aiuta a determinare se sono interessati solo i bot o tutti gli utenti.
WP-CLI: salvataggio rapido tramite console
Se il cruscotto non è accessibile, risolvo molte cose tramite WP-CLI:
# Controllare e impostare gli URL
opzione wp get home
wp opzione get siteurl
wp option aggiorna la home 'https://deinedomain.de'
opzione wp aggiorna siteurl 'https://deinedomain.de'
# "Salva attraverso" i permalink una sola volta
wp rewrite flush --hard
# Svuotare la cache
wp cache flush
wp cancellazione transitoria --all
# Disattivare / testare i plugin in massa
wp plugin disattivare --tutti
plugin wp attivare classic-editor
In questo modo posso tornare al sistema senza rischi, trovare i colpevoli e attivare solo ciò che è veramente necessario.
www, slash e canonizzazione senza loop
I loop sono spesso creati da piccole incongruenzewww vs. non-www, slash mancante/aggiuntivo o proto misto. Decido a favore di una sola variante e imposto solo a Catena di regole. Esempio non-www→www in Apache (senza doppio https):
RewriteEngine On
# Inoltra solo se l'host non è già www
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [L,R=301]
Con Nginx, ho impostato un chiaro blocco del server per l'inoltro ed evito regole miste in PHP/plugins. Importante: prima la canonicalizzazione (www/slash), poi https - e solo per a Posizione.
Pulizia dietro proxy/CDN: riconoscere correttamente HTTPS
Se WordPress si trova dietro un bilanciatore di carico o un CDN, il backend spesso riceve solo http, anche se il client utilizza https. WordPress riconosce quindi is_ssl() in modo errato e genera dei loop. Correggo le variabili del server in anticipo nel file wp-config.php:
se (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
Ho anche impostato le intestazioni X-Forwarded-Proto e Forwarded clean sul proxy. Uso HSTS con parsimonia: Se HSTS è attivo, può nessuno percorso http, altrimenti il browser si blocca. Uso il preload solo quando tutti i sottodomini funzionano stabilmente su https.
Disinnescare le trappole per login e cookie
Una fonte comune è l'impostazione errata dei cookie. Di solito imposto nessuno COOKIE_DOMAIN. Se è stato definito una volta, lo cambio come prova:
definire('COOKIE_DOMAIN', false);
Verifico anche che il flag del cookie di amministrazione "Secure" sia impostato su https e che il percorso sia impostato su "/". In caso di problemi persistenti, cancello le sessioni lato server (ad esempio riavviando php-fpm) e svuoto la cache degli oggetti/redis in modo che i vecchi nonces non abbiano più effetto.
Caratteristiche speciali della mappatura multisito e del dominio
All'indirizzo Multisito-impostazioni, mappature diverse portano rapidamente a un loop: Modalità sottodominio o directory, protocolli diversi o un vecchio plugin di mappatura dei domini con i propri reindirizzamenti. Controllo le tabelle del blog e del sito, sincronizzo i protocolli e gli host e disattivo brevemente i reindirizzamenti automatici per il cambio di lingua. Un login "Super Admin" nel blog principale aiuta a vedere i reindirizzamenti di rete in modo centralizzato. Importante: solo un'istanza decide il dominio canonico.
WooCommerce, multilinguismo e "Nascondi login
I negozi e i siti multilingue hanno logiche di reindirizzamento aggiuntive: pagine SSL forzate (checkout/account), reindirizzamento della lingua su Accept-Language o funzioni "Hide Login" nei plugin di sicurezza. Per la diagnosi, disattivo il reindirizzamento automatico della lingua e permetto temporaneamente /wp-login.php senza una deviazione. In WooCommerce, imposto "Solo queste pagine su SSL" in modo pulito sul lato server o completamente a livello di sistema, in modo che non si verifichino stati misti.
Cache degli oggetti coordinati, cache degli opcode e dei bordi
Diversi livelli di cache possono l'un l'altro amplify: opcode PHP (OPcache), object cache (Redis/Memcached), page cache dei plugin e CDN edge. Le svuoto in sequenza ordinata, in modo che nessun livello restituisca vecchi reindirizzamenti. Dopo le modifiche alle regole, invalido completamente la cache edge. Solo a questo punto il test è significativo.
Tipiche trappole di Nginx
Con Nginx, i loop si verificano quando i blocchi di posizione vengono riscritti due volte o /index.php vive internamente ed esternamente. Uso un'unica configurazione pulita: prima il blocco di inoltro del server (www/https), poi un try_files chiaro su /index.php. Evito sempre di mischiare add_header refresh e 301/302.
Lista di controllo: trovare la causa in 10 minuti
- Cancellare i cookie/cache localmente, testare in modalità incognito
- eseguire curl -IL e visualizzare la catena
- Ripristinare .htaccess/Nginx al percorso predefinito
- Sincronizzare WP_HOME/WP_SITEURL (se necessario, tramite WP-CLI).
- Solo un'istanza applica https (server preferito)
- Disattivare i plugin/temi, attivarli passo dopo passo
- Impostare correttamente l'intestazione proxy, controllare is_ssl()
- Cache vuota di oggetti/pagine/bordi
- Controllare i registri: debug.log, access/error.log
- Caratteristiche speciali: Multisito, Woo, Lingue, Hide-Login
Modelli di errore che vanno oltre i classici loop
Non tutti i 301/302 sono un vero e proprio loop - ma Instradamento errato anche i costi. Un 301 a 404 segnala ai motori di ricerca "questa risorsa è qui per sempre", ma consegna il vuoto. Oppure un 302 al posto del 301 impedisce il consolidamento permanente dei segnali. Mantengo la catena a un massimo di uno o due livelli, imposto 301 per i casi permanenti, 302 per quelli temporanei ed evito perdite di stringhe di query passando correttamente i flag o gli argomenti QSA.
Distribuzioni stabili e documentazione
Per evitare che i loop si verifichino in primo luogo, documento ogni regolaChi instrada cosa verso dove - e perché? Uso un ambiente di staging, vi riproduco le modifiche alle regole, registro intestazioni e tempi e poi distribuisco le stesse impostazioni di server e plugin nella produzione. Un breve controllo successivo alla distribuzione (pagina iniziale, login, checkout, lingua) previene gli errori.
Conclusione in breve
Sto rilasciando un Anello di inoltro Sistematico: controllare i cookie, ripristinare .htaccess ai valori predefiniti, personalizzare gli URL di WP, impostare correttamente l'SSL, isolare i plugin/temi e fornire correttamente le intestazioni del server. Questi passaggi di solito chiudono il cerchio in breve tempo. Quindi proteggo l'installazione, documento i reindirizzamenti e mantengo gli aggiornamenti aggiornati. In questo modo il login rimane accessibile, i visitatori arrivano sulle pagine giuste e i motori di ricerca effettuano il crawling senza perdere tempo. Un approccio strutturato evita le ripetizioni e risparmia i nervi.
