Checklist HTTP/2 per Nginx, Apache e Caddy
Nginx Apache Caddy HTTP/2 · test HTTP/2 online · ALPN TLS verifica
Cosa verificare quando abiliti HTTP/2 sui web server più comuni.
Di DN01 Network Team
Cosa verificare quando abiliti HTTP/2 sui web server più comuni. HTTP/2 Tester su /it/http2-tester è pensato per controllare dall'esterno quale protocollo TLS/ALPN viene negoziato da un host pubblico. Non misura tutte le prestazioni del sito e non sostituisce un browser reale, ma risponde a una domanda precisa: il server offre h2 oppure cade su HTTP/1.1? Una configurazione apparentemente corretta può fallire su SNI, TLS o listener sbagliato.
Per usare la guida in modo operativo, apri /it/http2-tester, inserisci il dominio o l'URL HTTPS e salva il risultato insieme a una verifica con /it/ssl-certificate-checker e /it/http-header-checker. Il collegamento tra protocollo, certificato e intestazioni evita diagnosi parziali: un certificato valido non garantisce HTTP/2, e HTTP/2 attivo non corregge cache o security header sbagliati.
Questa pagina fa parte del cluster HTTP/2 di DN01. Dopo la lettura passa anche a /it/articles/debug-errori-http2 per una checklist correlata e torna alla pagina strumento quando devi confrontare staging, produzione, CDN e origin.
Quando il test HTTP/2 è utile
Il test è utile dopo una migrazione CDN, un cambio di reverse proxy, un aggiornamento Nginx/Apache/Caddy o l'attivazione di TLS su un nuovo hostname. Molti incidenti nascono perché staging e produzione non negoziano lo stesso protocollo, oppure perché un proxy termina TLS prima dell'applicazione e modifica ALPN.
Usalo anche nelle revisioni SEO e Core Web Vitals: HTTP/2 non rende automaticamente veloce una pagina, ma permette multiplexing, compressione header HPACK e uso più efficiente di una singola connessione TLS. Se il risultato mostra HTTP/1.1, vale la pena controllare configurazione TLS, CDN e certificato.
Per API pubbliche, il risultato aiuta supporto e partner a capire se i client moderni possono usare h2. Documenta sempre host, ora del test e protocollo negoziato: sono dati più affidabili di uno screenshot generico del browser.
Come interpretare ALPN, TLS e protocollo
ALPN è l'estensione TLS con cui client e server scelgono il protocollo applicativo prima di inviare richieste HTTP. Se il server pubblica h2 e il client lo propone, il risultato dovrebbe indicare protocollo negoziato h2. Se manca ALPN, molti client useranno HTTP/1.1 anche con certificato valido.
Controlla anche la versione TLS e la suite cifrata. HTTP/2 nei browser richiede in pratica TLS moderno; configurazioni obsolete, intermediari o terminazioni mal allineate possono impedire la negoziazione. Il tester mostra un singolo percorso dal backend DN01, quindi ripeti dopo modifiche DNS o purge CDN.
Se vedi HTTP/1.1, non concludere subito che l'applicazione è lenta. Prima verifica se il CDN supporta h2 sul piano attivo, se il virtual host include la direttiva corretta e se la catena certificato corrisponde all'hostname testato.
Flusso consigliato con gli altri strumenti DN01
Inizia con /it/dns-checker o /it/dig per verificare che l'hostname punti al proxy o origin previsto. Poi usa /it/ssl-certificate-checker per confermare SAN, scadenza e catena. Solo dopo il livello TLS esegui HTTP/2 Tester, perché ALPN dipende da quella connessione.
Completa il controllo con /it/http-header-checker: HTTP/2 spiega il trasporto, mentre Cache-Control, HSTS, CSP e redirect spiegano il comportamento HTTP visibile agli utenti. In un ticket di rilascio, incolla i tre risultati in ordine: DNS, TLS/HTTP2, header.
Per automazione, registra l'accesso API su /it/api-register-access e usa l'endpoint /site-api/tools/http2 nelle verifiche ricorrenti. Mantieni soglie semplici: h2 atteso in produzione, host non risolvibile o fallback HTTP/1.1 come warning da indagare.
Errori comuni
Il più comune è testare l'origin diretto mentre gli utenti passano dal CDN: i due percorsi possono avere protocolli diversi. Un altro errore è controllare http:// invece di HTTPS; HTTP/2 pubblico viene negoziato quasi sempre dentro TLS.
Alcuni load balancer annunciano h2 solo su listener specifici o solo per certi SNI. Se un wildcard certificate è valido ma il virtual host sbagliato risponde, il tester può mostrare un protocollo diverso da quello atteso. Verifica sempre il nome host esatto.
Non usare HTTP/2 come unica metrica di performance. Compressione immagini, cache, render blocking e TTFB restano separati. Questo strumento conferma la capacità del trasporto, non sostituisce Lighthouse, RUM o tracing applicativo.
| Campo | Perché conta | Azione |
|---|---|---|
| supportsHttp2 | Indica se ALPN ha negoziato h2 | Deve essere true sugli host moderni |
| negotiatedProtocol | Mostra h2, http/1.1 o assenza ALPN | Confronta con configurazione proxy |
| tlsVersion | Rende visibile il livello TLS usato | Aggiorna se vedi versioni legacy |
| durationMs | Tempo della negoziazione dal backend DN01 | Usalo come segnale, non benchmark globale |
Domande frequenti
- HTTP/2 Tester scarica la pagina?
No. Verifica la negoziazione TLS/ALPN e restituisce protocollo, TLS e metadati principali; non esegue JavaScript e non misura l'intera pagina.
- Perché il browser mostra HTTP/2 ma il tester no?
Potresti usare un percorso CDN diverso, DNS geolocalizzato, cache o SNI differente. Ripeti il test sullo stesso hostname e confronta DNS e certificato.
- Posso usarlo in CI?
Sì. L'endpoint /site-api/tools/http2 accetta host o URL HTTPS e può essere usato dopo registrazione token API.