Cerca qualsiasi codice di stato HTTP: scopri cosa significa, quando viene inviato dai server e quale specifica lo definisce. Cerca per numero o parola chiave, filtra per classe e crea un link diretto al codice.
Il server ha ricevuto le intestazioni della richiesta e il client può inviare il corpo. Si verifica quando un client invia «Expect: 100-continue» prima di caricare un corpo di grandi dimensioni.
Il server accetta di passare al protocollo richiesto dal client nell'intestazione Upgrade. Si verifica quando una connessione viene aggiornata a WebSocket.
Il server ha accettato una richiesta WebDAV, ma non l'ha ancora completata. È stato rimosso dalle specifiche WebDAV successive e oggi si usa raramente.
Viene inviato prima della risposta finale, così il browser può iniziare a precaricare le risorse indicate nelle intestazioni Link. CDN e server lo usano per velocizzare il caricamento delle pagine.
La richiesta è riuscita e ha creato una nuova risorsa, solitamente identificata dall'intestazione Location. Tipico dopo un POST riuscito che crea un record.
La richiesta è stata accettata per l'elaborazione, ma non è ancora stata completata. Si usa nelle API che mettono le attività in coda, ad esempio esportazioni o processi batch.
La richiesta è riuscita e non c'è contenuto da restituire. È comune per le richieste DELETE e per il salvataggio dei dati quando il client non ha bisogno di un corpo della risposta.
Il server restituisce solo l'intervallo di byte richiesto dal client. Si verifica durante lo streaming di video, la ripresa di download o quando un client invia un'intestazione Range.
La risorsa è stata spostata in modo permanente all'URL indicato nell'intestazione Location. Browser e motori di ricerca aggiornano i link; alcuni client trasformano POST in GET quando seguono il reindirizzamento.
La risorsa si trova temporaneamente a un altro URL, indicato nell'intestazione Location. È comune dopo gli accessi e per i reindirizzamenti a breve termine; di solito i browser lo seguono con GET.
Il client dovrebbe recuperare il risultato da un altro URL con GET. Si usa dopo un POST di un modulo per reindirizzare a una pagina di conferma (schema Post/Redirect/Get).
La copia memorizzata nella cache è ancora valida, quindi il server non invia un corpo. Si verifica quando un browser verifica nuovamente un file in cache con If-None-Match o If-Modified-Since.
La risorsa si trova temporaneamente a un altro URL e il client deve ripetere la richiesta con lo stesso metodo e lo stesso corpo. Viene usato anche dai browser per i reindirizzamenti HSTS interni verso HTTPS.
La risorsa è stata spostata in modo permanente e il client deve usare lo stesso metodo e lo stesso corpo sul nuovo URL. È l’equivalente permanente di 307, sicuro per reindirizzare le richieste POST.
Il server non può elaborare la richiesta perché è malformata, ad esempio contiene JSON non valido, un parametro di query errato o un cookie danneggiato.
La richiesta non include credenziali di autenticazione valide. Nonostante il nome, significa “non autenticato”; il server invia un header WWW-Authenticate che indica come accedere.
Il server ha compreso la richiesta, ma la rifiuta; effettuare di nuovo l’accesso non servirà. Si verifica quando mancano i permessi, la visualizzazione dell’elenco di una directory è disattivata o un firewall blocca il client.
Il server non riesce a trovare la risorsa richiesta. Di solito il link è scritto in modo errato o non è aggiornato, la pagina è stata eliminata oppure la route dell’API non è corretta.
La risorsa esiste, ma non supporta il metodo HTTP usato, ad esempio POST su un URL di sola lettura. La risposta elenca i metodi consentiti nell’header Allow.
Il server ha esaurito il tempo di attesa mentre aspettava che il client finisse di inviare la richiesta. Si verifica con connessioni lente o interrotte.
La richiesta è in conflitto con lo stato attuale della risorsa, ad esempio per un conflitto durante una modifica o perché si sta cercando di creare qualcosa che esiste già.
La risorsa è stata rimossa definitivamente e non tornerà disponibile. A differenza di 404, indica ai motori di ricerca di rimuovere l’URL più rapidamente.
Una condizione negli header della richiesta, come If-Match, non è stata soddisfatta. Si usa per evitare di sovrascrivere una risorsa modificata dall’ultima volta che il client l’ha letta.
Il corpo della richiesta supera le dimensioni accettate dal server. Si verifica quando si carica un file che supera un limite come client_max_body_size di nginx.
L’URL è troppo lungo perché il server possa elaborarlo. Di solito accade quando un modulo invia troppi dati con GET o quando un ciclo di reindirizzamenti continua ad aggiungere parametri.
Uno scherzo del primo aprile tratto dal protocollo Hyper Text Coffee Pot Control Protocol del 1998: una teiera che si rifiuta di preparare il caffè. HTTP riserva il codice come non utilizzato, ma alcuni server lo restituiscono come Easter egg o per rifiutare bot indesiderati.
La richiesta è arrivata a un server che non può fornire una risposta per questo host, ad esempio quando una connessione HTTP/2 viene riutilizzata per un dominio diverso.
La richiesta è ben formata, ma il suo contenuto non è valido, ad esempio un modulo che non supera i controlli di convalida. È ampiamente usato dalle API per gli errori di convalida.
Il client ha inviato troppe richieste in un determinato intervallo di tempo. Le API lo usano per limitare le richieste e spesso includono un header Retry-After che indica quando riprovare.
Non è un codice standard. nginx lo usa internamente per chiudere la connessione senza inviare alcuna risposta, spesso per bloccare traffico indesiderato; i client non lo ricevono mai.
La risorsa non è disponibile per motivi legali, ad esempio a causa di un’ordinanza del tribunale o della censura governativa. Il numero rimanda al romanzo Fahrenheit 451.
Non è un codice standard. nginx lo registra quando il client chiude la connessione prima che il server risponda, ad esempio se un utente annulla il caricamento di una pagina lenta o si verifica un timeout sul client.
Il server ha riscontrato un errore imprevisto e non ha potuto completare la richiesta. È un errore generico causato da un bug, un arresto anomalo o una configurazione errata; i dettagli sono nei log del server.
Un gateway o un proxy ha ricevuto una risposta non valida dal server upstream. Si verifica spesso quando l’applicazione dietro nginx o un bilanciatore di carico è arrestata in modo anomalo o si sta riavviando.
Il server non è temporaneamente in grado di gestire la richiesta perché è sovraccarico o fuori servizio per manutenzione. Un header Retry-After può indicare quando riprovare.
Un gateway o un proxy non ha ricevuto in tempo una risposta dal server a monte. Si verifica quando una richiesta al backend è troppo lenta, ad esempio a causa di una query al database di lunga durata.
Non è un codice standard. Cloudflare lo restituisce quando il server di origine rifiuta la connessione, di solito perché il server web è inattivo o blocca gli indirizzi IP di Cloudflare.
Non è un codice standard. Cloudflare lo restituisce quando non riesce a raggiungere il server di origine, ad esempio per un problema di DNS o di routing.
Non è un codice standard. Cloudflare lo restituisce quando si connette al server di origine ma non riceve una risposta HTTP entro il timeout (100 secondi per impostazione predefinita).
Non è un codice standard. Cloudflare lo restituisce quando il certificato SSL del server di origine non è valido e la modalità SSL Full (strict) è attiva.
Definito in Cloudflare
Come si usa
Inserisci il numero di un codice (ad esempio 404 o semplicemente 5 per tutti gli errori del server) oppure una parola chiave come «reindirizzamento» o «timeout».
Restringi l'elenco con il filtro per classe: informativo, successo, reindirizzamento, errore del client o errore del server.
Usa «Copia link» su un codice per condividerne il collegamento diretto, ad esempio in una segnalazione di bug.
Come funziona
Ogni risposta HTTP inizia con un codice di stato di tre cifre. La prima cifra indica la classe: risposte informative 1xx, successo 2xx, reindirizzamenti 3xx, errori causati dalla richiesta 4xx ed errori lato server 5xx. I client che non riconoscono un codice specifico lo trattano come il codice x00 della stessa classe, quindi un codice 4xx sconosciuto viene gestito come 400.
I codici principali sono definiti nell’RFC 9110 (HTTP Semantics, 2022), che ha sostituito il precedente RFC 7231. Altri provengono da estensioni: WebDAV (RFC 4918), RFC 6585 per 428, 429, 431 e 511, RFC 7725 per 451 e RFC 8470 per 425. L’RFC 9110 ha anche rinominato due codici: 413 ora è “Content Too Large” e 422 “Unprocessable Content”. Potresti ancora trovarli con i vecchi nomi “Payload Too Large” e “Unprocessable Entity”.
Alcuni codici presenti nei log non fanno parte di alcuno standard. nginx usa internamente i codici 444 e 494–499 (499 indica che il client ha smesso di attendere) e Cloudflare restituisce i codici 520–526 quando non riesce a ottenere una risposta valida dal server di origine. Nell’elenco sono contrassegnati come “Non-standard”. Le frasi descrittive (come “Not Found”) sono riportate in inglese, come nelle specifiche; HTTP/2 e HTTP/3 trasmettono solo il numero.
Esempi
301 o 308 per spostare un sito
Entrambi sono permanenti. Usa 301 per i normali spostamenti di pagina; usa 308 quando i client devono ripetere le richieste POST o PUT al nuovo URL, perché alcuni client trasformano POST in GET dopo un 301.
401 e 403 a confronto
Un’API restituisce 401 quando non viene inviato alcun token o quando il token è scaduto: il client deve quindi accedere. Restituisce 403 quando il token è valido ma l’utente non dispone dell’autorizzazione necessaria, quindi accedere di nuovo non servirà.
Diagnosticare un 502 dietro nginx
Un errore 502 Bad Gateway di nginx indica che l’applicazione a cui fa da tramite non ha risposto correttamente. Controlla se il processo dell’app è in esecuzione e cosa è stato registrato nei log; 504 indica invece che la risposta è arrivata troppo tardi.
Domande frequenti
Qual è la differenza tra 404 e 410?
404 significa che il server non riesce a trovare la risorsa e non dice nulla sul futuro. 410 indica che la risorsa è stata rimossa intenzionalmente e non verrà ripristinata; questo aiuta i motori di ricerca a rimuovere prima l’URL.
Un errore di convalida dovrebbe restituire 400 o 422?
Si usano entrambi. 400 è adatto alle richieste che il server non riesce a interpretare, per esempio un JSON non valido. 422 è adatto alle richieste interpretate correttamente ma con valori non validi, per esempio un campo email senza @.
418 I'm a teapot è un vero codice di stato?
Deriva da una RFC per il pesce d'aprile del 1998. La RFC 9110 riserva il codice 418 come non utilizzato, così da evitare che venga assegnato ad altro. Alcuni server lo restituiscono per scherzo, ma non ha un significato standard.
Da dove deriva il codice 499?
499 è specifico di nginx. Compare nei log di nginx quando il client chiude la connessione prima che il server invii una risposta. Il client non riceve mai un 499: di solito indica risposte lente o timeout lato client.
I motori di ricerca trattano un 302 come un 301?
Un 302 segnala uno spostamento temporaneo, quindi inizialmente i motori di ricerca mantengono di solito nell'indice l'URL originale. Se un 302 resta in vigore a lungo, Google potrebbe considerarlo un reindirizzamento permanente. Per gli spostamenti permanenti, usa 301 o 308.
Privacy
L'elenco è incluso nella pagina. Le ricerche e i filtri vengono applicati nel browser; i termini cercati non vengono inviati né inclusi nelle statistiche.