ERR_TOO_MANY_REDIRECTS dietro un CDN: le due impostazioni che fanno loop insieme.
Un CDN che raggiunge l'origin in HTTP semplice e un origin che forza HTTP verso HTTPS vanno bene ciascuno da solo e fanno loop insieme. Come riconoscere la coppia, riprodurla con una sola richiesta e chiudere entrambi i capi.
In questo articolo 4 sezioni
- La coppia da cercare quando un sito dietro un CDN restituisce ERR_TOO_MANY_REDIRECTS: un SSL mode del CDN che raggiunge l'origin in HTTP semplice, e un origin che forza il redirect da HTTP a HTTPS senza controllare cosa il proxy ha già fatto.
- Due difetti, ciascuno innocuo da solo. Molti origin servono HTTP dietro un CDN che termina il TLS, e molti origin forzano HTTPS. Solo i due insieme fanno loop.
- Il loop può non lasciare alcuna riga nell'access log, perché il livello che risponde con il redirect può non loggare le richieste ordinarie. Il silenzio sembra assenza di traffico e indirizza la ricerca dalla parte sbagliata.
- Riproducetelo con una sola richiesta verso l'origin, lungo il percorso che fanno i visitatori, poi correggete entrambi i capi così che il loop non possa formarsi comunque il sito sia esposto.
Abilitare il proxy del CDN davanti a un origin che forza HTTPS basta a far partire il loop. Entrambe le impostazioni sono ragionevoli, e nessuna delle due rompe nulla da sola. Cambiare un'impostazione e testare da un percorso che aggira il CDN sembra una correzione mentre ogni visitatore reale continua a fare loop.
Il meccanismo: due capi, un loop
L'SSL mode del CDN era impostato su "Flexible": il browser parla HTTPS con il CDN, ma il CDN parla HTTP semplice con l'origin. Un'impostazione difendibile da sola. Molti origin servono HTTP dietro un CDN che termina il TLS.
L'edge dell'origin, intanto, forzava il redirect di ogni richiesta HTTP verso HTTPS, senza essere proxy-aware: emetteva il redirect senza controllare l'header che dice che questa richiesta era già HTTPS alla porta d'ingresso. Così il CDN recupera in HTTP, l'origin risponde «vai su HTTPS», la richiesta successiva del browser arriva al CDN come HTTPS, il CDN recupera di nuovo l'origin in HTTP, e l'origin reindirizza di nuovo. Infinito, per costruzione. Flexible da solo va bene. Il redirect forzato da solo va bene. Solo i due insieme fanno loop.
Il bug che non ha loggato nulla
Se il livello che risponde con il redirect non logga le richieste ordinarie, il loop non lascia nulla nell'access log. Il silenzio sembra che non sia arrivato traffico, e l'indagine va ovunque tranne che nel posto giusto. La regola: quando un bug non lascia log, smettete di dare la caccia al silenzio e riproducete il meccanismo.
Riproducete il meccanismo
$ curl -I -H 'X-Forwarded-Proto: https' http://origin.example/
HTTP/1.1 301 Moved Permanently
Location: https://origin.example/
# told the origin the request was already HTTPS. it redirects anyway.Una richiesta riproduce il loop, dal percorso che fanno i visitatori. Un test da qualsiasi altro percorso passa e non dimostra nulla.
Correggete entrambi i capi
| IL CAPO | LA CORREZIONE |
|---|---|
| Il lato CDN | SSL mode portato su "Full (Strict)": il CDN parla HTTPS vero e verificato con l'origin. |
| UNA SOLA CORREZIONE SPEZZA IL LOOP. ENTRAMBE LO RENDONO IMPOSSIBILE.Il lato origin | Il redirect reso proxy-aware: controlla l'header del protocollo inoltrato e non rimbalza mai una richiesta che era già HTTPS alla porta d'ingresso. |
Correggere un solo capo di un'incompatibilità a due capi lascia una configurazione carica in attesa della prossima modifica. Chiudete entrambi i capi e non resta alcuna combinazione che giri in cerchio: mettete in pausa il CDN, cambiate CDN, cambiate l'origin, e il loop non ha più dove formarsi.
“Nessuno dei due capi era rotto. I due insieme lo erano.”
Risposte dirette
Come risolvo ERR_TOO_MANY_REDIRECTS dietro un CDN?+
Controllate la coppia, non una sola impostazione. Se il CDN raggiunge il vostro origin in HTTP semplice (un SSL mode in stile "Flexible") e il vostro origin forza il redirect da HTTP a HTTPS, fanno loop. Portate il CDN su HTTPS pieno e strict verso l'origin, e rendete proxy-aware il redirect dell'origin.
Perché il mio redirect loop non mostra nulla negli access log?+
Il livello che fa loop può non loggare le richieste ordinarie, quindi il loop è invisibile. Non date la caccia al silenzio. Riproducete il meccanismo con una richiesta verso l'origin e leggete cosa fa.
Cosa fa X-Forwarded-Proto?+
Un proxy lo imposta per dire all'origin quale protocollo ha usato davvero il visitatore. Un origin che reindirizza da HTTP a HTTPS deve controllarlo, altrimenti rimbalza richieste che erano già HTTPS al proxy, che è come iniziano i loop.
L'SSL mode Flexible è una cattiva scelta?+
È uno scambio con un lato tagliente: il traffico tra CDN e origin non è cifrato, e combinato con un redirect forzato sull'origin fa loop. Il mode pieno e strict, con un certificato vero sull'origin, elimina entrambi i problemi.
Perché funzionava quando l'ho testato?+
Un test che non passa attraverso il CDN segue un percorso diverso da quello dei vostri visitatori. Riproducete lungo l'esatto percorso che fallisce, header compresi. Quella differenza è dove si nasconde questa classe di bug.
State combattendo un bug che non logga nulla?
Anche il silenzio è un sintomo. Riproduciamo il guasto, leggiamo le fonti primarie e correggiamo entrambi i capi.
Parla con un ingegnereSiete arrivati alla fine.
Mettete la lettura al lavoro
Cosa fate girare?
Raccontateci il carico di lavoro, il traffico e i requisiti di ripristino. Partite dal configuratore di server, oppure discutete i dettagli con un ingegnere.
Scritto dagli ingegneri che costruiscono e gestiscono l'infrastruttura che descrive.Parla con un ingegnere