Un piccolo toolkit per il debug di redirect e intestazioni HTTP in produzione

Il problema del debug HTTP in produzione

La maggior parte dei problemi HTTP è invisibile nel browser. Una catena di redirect fallisce silenziosamente, un'intestazione di cache è sbagliata di un solo carattere, una policy CORS blocca una richiesta senza spiegazioni. Gli strumenti per sviluppatori del browser mostrano il risultato della conversazione, ma spesso nascondono lo scambio grezzo che ha causato il problema.

Questo conta soprattutto in produzione, dove non puoi aggiungere logging o riavviare servizi per vedere cosa è cambiato. Ti servono strumenti che mostrino la conversazione HTTP effettiva: intestazioni di richiesta, intestazioni di risposta, codici di stato, destinazioni dei redirect, tempi. Ecco i cinque strumenti che svolgono questo lavoro in modo affidabile, più le tecniche del browser che li completano.

curl: la base

curl è il primo strumento da usare perché mostra esattamente ciò che il server ha inviato, senza interpretazioni del browser nel mezzo.

Per vedere le intestazioni di risposta senza il corpo:

curl -I https://example.com

Per seguire i redirect e vedere ogni passaggio:

curl -L -v https://example.com

Il flag -v (verbose) mostra la richiesta e la risposta complete, incluse tutte le intestazioni. Il flag -L segue automaticamente i redirect. Insieme mostrano l'intera catena di redirect, che è il punto in cui si annida la maggior parte dei problemi in produzione.

Per vedere solo le destinazioni dei redirect:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -L https://example.com

È utile quando devi verificare una catena di redirect senza il rumore di tutte le intestazioni. Il flag -w formatta l'output per mostrare solo il codice di stato e l'URL successivo nella catena.

curl consente anche di inviare intestazioni personalizzate, cosa essenziale per testare il comportamento di una CDN, l'autenticazione o gli endpoint API:

curl -H "Authorization: Bearer token" -H "Accept: application/json" https://api.example.com

httpie: curl con impostazioni predefinite migliori

httpie è uno strumento Python che fa ciò che fa curl, ma con una sintassi più facile da ricordare e un output più facile da leggere. Non è un sostituto: curl è più potente e più ampiamente installato, ma per controlli rapidi httpie è più veloce.

Per vedere le intestazioni:

http HEAD https://example.com

Per seguire i redirect:

http --follow --all https://example.com

Il flag --all mostra ogni risposta nella catena di redirect, non solo quella finale. È l'equivalente di curl -L -v, ma l'output è colorato e più facile da scorrere.

Per inviare JSON:

http POST https://api.example.com name=value

httpie assume JSON come impostazione predefinita, risparmiando digitazione quando testi API. Inoltre formatta in modo leggibile la risposta, rendendo più facile individuare intestazioni malformate o valori inattesi.

Browser DevTools: scheda Network

La scheda Network del browser è il punto da cui partire se il problema si verifica solo nel browser. Mostra le stesse informazioni di curl, ma mostra anche l'interpretazione del browser: se ha bloccato una richiesta, come ha gestito la cache, se ha inviato cookie.

Per vedere le intestazioni complete di richiesta e risposta, fai clic su qualsiasi richiesta nella scheda Network, poi guarda la sezione Headers. La vista "Raw" mostra le intestazioni esattamente come sono state inviate, senza formattazione.

Per vedere le catene di redirect, cerca le richieste con codici di stato 3xx. Il browser le raggruppa sotto la richiesta finale, ma puoi espanderle per vedere ogni passaggio. Qui troverai loop di redirect, intestazioni Location mancanti o redirect che puntano al dominio sbagliato.

Per vedere i tempi, guarda la scheda Timing di una richiesta. Mostra quanto tempo il browser ha impiegato per la risoluzione DNS, la connessione TCP, l'handshake TLS e l'attesa del server. Se un redirect è lento, la scheda Timing ti dice se il problema è la latenza di rete o l'elaborazione lato server.

Una limitazione: il browser nasconde alcune intestazioni per motivi di sicurezza. Le intestazioni Set-Cookie sono visibili, ma i valori effettivi dei cookie sono oscurati. Le intestazioni Authorization a volte sono nascoste del tutto. Se devi vederle, usa curl.

mitmproxy: il proxy di intercettazione

mitmproxy è uno strumento Python che si posiziona tra il browser e il server, mostrandoti ogni richiesta e risposta in tempo reale. È più complesso di curl, ma è l'unico strumento che mostra cosa il browser invia davvero, incluse le intestazioni che il browser aggiunge automaticamente.

Per avviarlo:

mitmproxy

Poi configura il browser per usare localhost:8080 come proxy HTTP. mitmproxy mostrerà ogni richiesta in un'interfaccia da terminale. Puoi ispezionare le intestazioni, modificare le richieste prima che vengano inviate o ripetere richieste con parametri diversi.

È utile per fare debug di problemi che si verificano solo nel browser: richieste preflight CORS, gestione dei cookie o richieste che falliscono quando sono presenti determinate intestazioni. È utile anche per testare come si comporta il sito dietro un proxy aziendale o una VPN, perché mitmproxy può simulare questi ambienti.

Lo svantaggio è la complessità della configurazione. Devi installare un certificato radice affinché mitmproxy possa intercettare traffico HTTPS, e devi configurare il browser per usare il proxy. Per controlli rapidi, curl è più veloce. Per debug approfondito, mitmproxy vale il tempo di configurazione.

webpagetest: prospettiva di produzione

WebPageTest è un servizio gratuito che carica la tua pagina da browser reali in località diverse e ti mostra la conversazione HTTP completa. È più lento di curl, ma mostra ciò che sperimentano gli utenti reali, incluso il comportamento della CDN, la risoluzione DNS e la negoziazione TLS.

Le viste "Request Headers" e "Response Headers" mostrano esattamente ciò che il browser ha inviato e ricevuto. La vista "Waterfall" mostra i tempi di ogni richiesta, inclusi i redirect. Qui troverai problemi che si verificano solo in determinate regioni o su determinate reti.

WebPageTest mostra anche la catena di redirect del documento principale, che è il punto in cui si trova la maggior parte dei problemi di redirect. Se il tuo sito reindirizza da http:// a https://, poi da www. a non-www., poi da / a /en/, WebPageTest mostra tutti e tre i passaggi e quanto tempo ha richiesto ciascuno.

Per strumenti che aiutano a validare e ottimizzare questi fondamentali HTTP, Wux Webtools offre diverse utilità che funzionano interamente nel browser, inclusi analizzatori di intestazioni e controllori di redirect che rispettano la tua privacy elaborando tutto lato client.

Quando le intestazioni mentono

I problemi HTTP più difficili sono quelli in cui il server invia intestazioni contraddittorie. Un'intestazione Cache-Control dice no-cache, ma un'intestazione Expires dice che la risorsa è valida per un anno. Un'intestazione Location punta a un URL relativo, ma l'intestazione Content-Location punta altrove. Il browser deve indovinare di quale fidarsi, e browser diversi indovinano in modo diverso.

Quando succede, devi vedere le intestazioni grezze nell'ordine in cui il server le ha inviate. curl -v lo fa. Anche mitmproxy lo fa. I DevTools del browser a volte riordinano le intestazioni per leggibilità, nascondendo il problema.

Un altro problema comune: intestazioni aggiunte da una CDN o da un load balancer, non dalla tua applicazione. Se stai facendo debug di un problema di cache, devi sapere se l'intestazione Cache-Control arriva dalla tua app o dalla CDN. curl mostra il risultato finale, ma non ti dice da dove proviene ogni intestazione. Per questo devi bypassare la CDN (raggiungendo direttamente il server di origine) e confrontare le intestazioni.

Il problema dei loop di redirect

I loop di redirect sono il problema HTTP più comune in produzione. Si verificano quando due server non concordano su dove debba puntare un URL: la CDN reindirizza all'origine, l'origine reindirizza di nuovo alla CDN. Oppure il load balancer reindirizza HTTP a HTTPS, ma l'app reindirizza HTTPS di nuovo a HTTP perché non vede l'intestazione X-Forwarded-Proto.

Per fare debug, devi vedere la catena completa di redirect, inclusa l'intestazione Location a ogni passaggio. curl -L -v lo fa, ma si ferma dopo 50 redirect per evitare loop infiniti. Se raggiungi quel limite, hai un loop di redirect.

La correzione di solito è una modifica di configurazione: dire all'app di fidarsi dell'intestazione X-Forwarded-Proto, oppure dire alla CDN di smettere di reindirizzare richieste che sono già HTTPS. Ma non puoi correggerlo finché non vedi il loop, e il browser non ti mostrerà più di pochi redirect prima di arrendersi.

Cosa controllare per primo

Quando qualcosa si rompe in produzione, controlla questi elementi in ordine:

1. Codice di stato: è quello che ti aspettavi? Un 301 è permanente, un 302 è temporaneo, un 307 preserva il metodo HTTP. Se vedi il codice sbagliato, il problema è nella configurazione dei redirect.

1. Intestazione Location: punta al posto giusto? È un URL assoluto o relativo? Gli URL relativi vengono risolti rispetto all'URL corrente, il che può produrre risultati inattesi se l'URL di base non è quello che pensi.

1. Intestazioni di cache: il browser sta memorizzando in cache il redirect? Un redirect 301 viene memorizzato in cache per impostazione predefinita, il che significa che un redirect configurato male può rompere il sito per ore anche dopo che lo hai corretto. Controlla le intestazioni Cache-Control e Expires per vedere per quanto tempo il browser ricorderà il redirect.

1. Intestazioni CORS: se la richiesta è cross-origin, il server invia l'intestazione Access-Control-Allow-Origin corretta? In caso contrario, il browser bloccherà la richiesta e vedrai un errore CORS nella console. Le intestazioni di risposta del server sono l'unico punto in cui correggerlo: non puoi aggirarlo nel browser.

1. Tempi: quanto ha impiegato la richiesta? Se è lenta, si tratta di latenza di rete o di elaborazione lato server? I DevTools del browser e WebPageTest mostrano entrambi scomposizioni dei tempi che ti dicono dove è finito il tempo.

Per uno sguardo più approfondito a come il comportamento dei browser sia cambiato rispetto a privacy e intestazioni, vedi cosa è cambiato per i cookie nel 2026 e cosa fare al riguardo, che copre le implicazioni su intestazioni e consenso dei recenti aggiornamenti dei browser.

Punti chiave

• curl -L -v mostra la catena completa di redirect e tutte le intestazioni, senza interpretazione del browser
• La scheda Network del browser mostra cosa il browser ha fatto con la risposta, incluse le decisioni su cache e CORS
• mitmproxy mostra cosa il browser ha inviato, incluse le intestazioni che il browser aggiunge automaticamente
• WebPageTest mostra ciò che sperimentano gli utenti reali, incluso il comportamento della CDN e le differenze regionali
• I loop di redirect e le intestazioni contraddittorie sono i problemi più comuni in produzione, e sono invisibili senza ispezione HTTP grezza

FAQ

Q: Perché curl mostra intestazioni diverse dal browser?

A: Perché il browser aggiunge automaticamente intestazioni (User-Agent, Accept, Cookie) e segue le proprie regole per cache e CORS. curl invia solo ciò che gli dici di inviare. Per vedere cosa invia davvero il browser, usa mitmproxy o i DevTools del browser.

Q: Come faccio a fare debug di un redirect che si verifica solo per alcuni utenti?

A: Controlla se il redirect dipende dalle intestazioni inviate dall'utente: User-Agent, Accept-Language, Cookie o indirizzo IP (tramite X-Forwarded-For). Usa curl per inviare le stesse intestazioni inviate dall'utente, oppure usa WebPageTest per caricare la pagina dalla località dell'utente.

Q: Qual è la differenza tra redirect 301 e 302?

A: Un 301 è permanente e dice al browser di memorizzare in cache il redirect (a volte per sempre). Un 302 è temporaneo e dice al browser di non memorizzarlo in cache. Se non sei sicuro di quale usare, usa 302: puoi sempre cambiarlo in 301 in seguito.

Q: Perché il mio redirect funziona in curl ma non nel browser?

A: Probabilmente perché il browser sta memorizzando in cache un vecchio redirect, oppure perché il browser sta bloccando il redirect a causa delle regole CORS o di contenuto misto. Controlla la console dei DevTools del browser per gli errori e controlla le intestazioni Cache-Control per vedere se il browser sta usando una risposta in cache.

Q: Come faccio a vedere le intestazioni aggiunte da una CDN?

A: Usa curl per raggiungere l'URL della CDN, poi usa di nuovo curl per raggiungere direttamente il server di origine (bypassando la CDN). Confronta le intestazioni. Quelle che compaiono solo nella prima risposta provengono dalla CDN.

<!-- tool-cta:start -->

💡 Prova questo: Quando indaghi su problemi di reindirizzamento, Redirect Checker traccia l’intera catena e mostra i codici di stato e le intestazioni a ogni hop.

<!-- tool-cta:end -->

Fonti

• curl documentation — Riferimento ufficiale per le opzioni da riga di comando e il comportamento di curl
• HTTPie documentation — Guida alla sintassi e alle funzionalità di httpie
• MDN Web Docs: HTTP redirections — Spiegazione completa dei codici di stato e del comportamento dei redirect HTTP
• WebPageTest documentation — Come interpretare i risultati e le intestazioni di WebPageTest