Risolvere il Loop "Too Many Redirects" su WordPress in Docker dietro Reverse Proxy [2026]

// Riconoscimento HTTPS delegato dal Reverse Proxy
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
    $_SERVER['HTTPS'] = 'on';
}
define('WP_HOME', 'https://tuodominio.it');
define('WP_SITEURL', 'https://tuodominio.it');
define('FORCE_SSL_ADMIN', true);

1. Anatomia del Problema: Perché si Crea il Loop 301?

Quando esegui WordPress all'interno di un container Docker (usando l'immagine ufficiale wordpress:latest o versioni basate su Apache/FPM), l'architettura tipica di produzione prevede un Reverse Proxy (Nginx Proxy Manager, Traefik, Caddy o Cloudflare) posto a monte.

Il flusso delle richieste avviene in questo modo:

1. Il browser dell'utente richiede la pagina su https://tuodominio.it (porta 443 cifrata con certificato SSL Let's Encrypt).
2. Il Reverse Proxy riceve la richiesta, effettua la SSL Termination (decifra il pacchetto) e inoltra la richiesta al container WordPress tramite la rete Docker interna in HTTP sulla porta 80.
3. Il server web del container (Apache/PHP) esamina le variabili d'ambiente $_SERVER. Poiché la connessione diretta con il proxy è in chiaro, la variabile $_SERVER['HTTPS'] è vuota o off.
4. WordPress verifica che l'URL configurato nel database richiede HTTPS, nota che $_SERVER['HTTPS'] != 'on' e genera un redirect HTTP 301: "Ehi browser, vai su https://tuodominio.it!".
5. Il browser riceve il 301 e ripete la richiesta su HTTPS, ricominciando il ciclo da capo fino al blocco di sicurezza del browser (ERR_TOO_MANY_REDIRECTS).

2. La Configurazione Corretta di Nginx Reverse Proxy

Affinché WordPress sappia che la connessione originale dell'utente era in HTTPS, il reverse proxy deve trasmettere l'header X-Forwarded-Proto. Se utilizzi Nginx nativo o un file di configurazione custom, assicurati che la direttiva contenga:

server {
    listen 443 ssl http2;
    server_name tuodominio.it;

    ssl_certificate /etc/letsencrypt/live/tuodominio.it/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/tuodominio.it/privkey.pem;

    location / {
        proxy_pass http://wordpress_container:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port $server_port;

        # Ottimizzazioni buffer per evitare troncamento risposte
        proxy_buffer_size 128k;
        proxy_buffers 4 256k;
        proxy_busy_buffers_size 256k;
    }
}

Se utilizzi Nginx Proxy Manager (NPM), basta entrare nella scheda del tuo Proxy Host e verificare che:

• Lo Scheme verso il container sia http e la porta sia 80.
• Nel tab SSL siano spuntate le opzioni Force SSL e HTTP/2 Support.

3. La Patch Chirurgica in wp-config.php

Accedi alla cartella montata come volume sul tuo host per WordPress (o usa docker exec -it wordpress_container bash) e apri il file wp-config.php.

⚠️ ATTENZIONE ALL'ORDINE: PHP esegue il codice in maniera sequenziale. Se inserisci le direttive in fondo al file dopo require_once ABSPATH . 'wp-settings.php';, le costanti non avranno alcun effetto sul caricamento del core di WordPress.

<?php
/**
 * Inserire subito dopo i parametri del database (DB_NAME, DB_USER, ecc.)
 */

// Istruisce WordPress ad accettare l'header inoltrato dal Reverse Proxy
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
    $_SERVER['HTTPS'] = 'on';
}

// Forza gli indirizzi canonici senza dipendere dalle query al database MariaDB
define('WP_HOME', 'https://tuodominio.it');
define('WP_SITEURL', 'https://tuodominio.it');

// Obbliga la cifratura SSL per l'accesso e la gestione della dashboard di amministrazione
define('FORCE_SSL_ADMIN', true);

// Previene problemi di mix-content sui cookie di sessione
define('COOKIE_SSL', true);

4. Il Tranello di Cloudflare: "Flexible" vs "Full (Strict)"

Se il tuo dominio transita attraverso il proxy arancione di Cloudflare, esiste un'ulteriore trappola nota:

• Se imposti la crittografia SSL/TLS di Cloudflare su Flexible, Cloudflare interroga il tuo server sempre in HTTP porta 80. Con le regole precedenti attive, WordPress si aspetta solo chiamate sicure e il loop si ripresenta all'infinito tra i datacenter di Cloudflare e il tuo server.
• Soluzione: Imposta Cloudflare su Full (se il tuo reverse proxy ha un certificato auto-firmato) oppure su Full (Strict) (consigliato, se utilizzi un certificato Let's Encrypt valido sul reverse proxy).

5. Script di Diagnostica con cURL

Per accertarti che il loop sia debellato al 100% senza interferenze della cache locale del browser, esegui questo comando dal tuo terminale:

curl -ILs -o /dev/null -w "%{http_code} -> %{url_effective}\n" https://tuodominio.it

L'output corretto deve mostrare un unico salto oppure la risposta diretta:

200 -> https://tuodominio.it/

Se vedi una sfilza di 301 -> https://tuodominio.it/ ripetuti per 20 volte, significa che una delle tre variabili sopra descritte non è stata caricata prima del bootstrap del framework.