Condividi tramite

Codici di risposta HTTP nel gateway delle applicazioni

Riassunto

Questo articolo illustra perché il gateway applicazione di Azure restituisce codici di risposta HTTP specifici. Fornisce cause comuni e passaggi di risoluzione dei problemi che consentono di determinare la causa radice di un codice di risposta HTTP di errore. Il gateway applicativo può restituire codici di risposta HTTP a una richiesta client, indipendentemente dal fatto che avvii o meno una connessione con un back-end di destinazione.

Annotazioni

Se una connessione client ha esito negativo prima che il gateway applicazione restituisca una risposta HTTP, è probabile che si verifichi un errore di handshake Transport Layer Security (TLS). Le cause comuni includono le mancate corrispondenze della versione TLS (ad esempio, il client usa TLS 1.0 o 1.1 mentre il gateway richiede TLS 1.2 o versione successiva) e i pacchetti di crittografia non supportati. A partire dal 31 agosto 2025, il gateway applicazione di Azure interrompe il supporto per TLS 1.0 e 1.1. Per ulteriori informazioni, vedere Panoramica dei criteri TLS del gateway applicazione e Configurazione delle versioni dei criteri TLS e dei pacchetti di crittografia.

Codici di risposta 3XX (reindirizzamento)

Il gateway applicativo restituisce risposte da 300 a 399 quando una richiesta client corrisponde a una regola del gateway applicativo con reindirizzamenti configurati. È possibile configurare i reindirizzamenti in una regola as-is o tramite una regola della mappa del percorso. Per altre informazioni sui reindirizzamenti, vedere Panoramica sui reindirizzamenti di Application Gateway.

301 Reindirizzamento permanente

Il gateway applicativo restituisce risposte HTTP 301 quando si specifica una regola di reindirizzamento con il valore Permanent.

302 - Trovato

Il gateway applicazioni restituisce risposte HTTP 302 quando si specifica una regola di reindirizzamento con il valore Found.

303 Vedi altro

Application Gateway restituisce risposte HTTP 303 quando si specifica una regola di reindirizzamento con il valore See Other.

307 Reindirizzamento temporaneo

Il Gateway applicativo restituisce risposte HTTP 307 quando si specifica una regola di reindirizzamento con il valore Temporaneo.

Codici di risposta 4XX (errore del client)

I codici di risposta 400-499 indicano un problema avviato dal client. Questi problemi possono variare dal cliente che avvia richieste a un nome host non corrispondente, dal timeout della richiesta, dalla richiesta non autenticata, dalla richiesta dannosa e altro ancora.

Il gateway Application Gateway raccoglie metriche che acquisiscono la distribuzione dei codici di stato 4xx/5xx e ha un meccanismo di registrazione che acquisisce informazioni come l'indirizzo IP del client e l'URI insieme al codice di risposta. Le metriche e la registrazione contribuiscono ulteriormente alla risoluzione dei problemi. I client possono anche ricevere risposte di errore 4xx da altri proxy tra il dispositivo client e l'Application Gateway. Ad esempio, rete CDN (rete per la distribuzione di contenuti) e altri provider di autenticazione. Vedi gli articoli seguenti per altre informazioni.

400 - Richiesta non valida

I codici di risposta HTTP 400 vengono comunemente visualizzati quando:

  • Avviate traffico non HTTP né HTTPS verso un gateway applicativo con un listener HTTP o HTTPS.
  • Si avvia il traffico HTTP a un listener con HTTPS, senza reindirizzamento configurato.
  • È possibile configurare l'autenticazione reciproca, ma Application Gateway non riesce a negoziare correttamente.
  • La richiesta non è conforme a RFC.

Alcuni motivi comuni per cui la richiesta non è conforme a RFC sono:

Categoria Esempi
Host non valido nella riga della richiesta L'host contiene due punti (example.com:8090:8080)
Intestazione host mancante La richiesta non include l'intestazione host
Presenza di caratteri non validi o non ammessi I caratteri riservati sono &,!.. Per ovviare alla limitazione, è possibile codificarli come percentuale. ad esempio %&
Versione HTTP non valida Richiedi /content.css HTTP/0.3
Caratteri non ASCII nel nome del campo di intestazione e nell'URI GET /«úü¡»¿.doc HTTP/1.1
Intestazione Content-Length mancante per la richiesta POST Facilmente comprensibile
Metodo HTTP non valido GET123 /index.html HTTP/1.1
Intestazioni duplicate Authorization:<contenuto con codifica Base64 >, Authorization:<contenuto con codifica Base64>
Valore non valido per Content-Length Lunghezza del contenuto: abc, Lunghezza del contenuto: -10

Quando si configura l'autenticazione reciproca, diversi scenari possono causare la restituzione di una risposta HTTP 400, tra cui:

  • Si abilita l'autenticazione reciproca, ma il certificato client non è stato presentato.
  • Si abilita la convalida del DN (Distinguished Name) e il DN del certificato client non corrisponde al DN della catena di certificati specificata.
  • La catena di certificati client non corrisponde a quella configurata nei criteri SSL definiti.
  • Il certificato client è scaduto.
  • Si abilita il controllo di revoca client OCSP (Online Certificate Status Protocol) e il certificato viene revocato.
  • Si abilita il controllo di revoca del client OCSP, ma il gateway delle applicazioni non può contattare il server OCSP.
  • Si abilita il controllo di revoca del client OCSP, ma il risponditore OCSP non viene fornito nel certificato.

Per altre informazioni sulla risoluzione dei problemi relativi all'autenticazione reciproca, vedere Risoluzione dei problemi relativi ai codici errore.

401 - Non autorizzato

Il gateway applicativo restituisce una risposta HTTP 401 non autorizzato al client se il client non è autorizzato ad accedere alla risorsa. Esistono diversi motivi per cui restituire 401. L'elenco seguente fornisce alcuni motivi con possibili correzioni.

  • Se il client ha accesso, potrebbe avere una cache del browser obsoleta. Svuotare la cache del browser e riprovare ad accedere all'applicazione.

Il gateway applicativo può restituire una risposta HTTP 401 non autorizzata a una richiesta di probe di AppGW se si configura il pool back-end con l'autenticazione NTLM. In questo scenario, Application Gateway contrassegna il back-end come sano. Risolvere questo problema usando uno dei metodi seguenti:

  • Consentire l'accesso anonimo nel backend pool.
  • Configurare il probe per inviare la richiesta a un altro sito "falso" che non richiede NTLM.
  • Non consigliato, perché questa soluzione non indica se il sito reale dietro il gateway applicativo è attivo o meno.
  • Configurare il gateway applicazione per consentire risposte 401 come valide per i probe: Condizioni di corrispondenza dei probe.

403 - Accesso negato

Il Application Gateway presenta HTTP 403 Vietato quando si usano SKU WAF (Web Application Firewall) e il WAF è configurato in Modalità Prevenzione. Se i set di regole WAF abilitati o le regole WAF di negazione personalizzate corrispondono alle caratteristiche di una richiesta in ingresso, il gateway applicazione presenta una risposta 403 non consentita al client.

Per risolvere i problemi relativi ai falsi positivi WAF (richieste legittime bloccate dalle regole WAF):

  1. Abilitare i log di diagnostica WAF ed esaminare il ruleId_s campo per identificare quale regola blocca la richiesta.
  2. Passare temporaneamente il WAF alla modalità rilevamento per registrare le regole di corrispondenza senza bloccare il traffico. Questo approccio consente di confermare i falsi positivi prima di apportare modifiche alle regole. Per ulteriori informazioni, consultare le Impostazioni dei criteri WAF.
  3. Creare esclusioni WAF per attributi di richiesta specifici (intestazioni, cookie o argomenti) che generano falsi positivi.
  4. Se una regola gestita causa falsi positivi in modo coerente e le esclusioni non sono sufficienti, disabilitare la singola regola nei criteri WAF.

Per indicazioni dettagliate, vedere Risoluzione dei problemi di WAF per il Gateway dell'Applicazione e pratiche ottimali per WAF.

Altri motivi per cui i client ricevono risposte 403 - Accesso negato:

  • Tentativi di aggiornamento del protocollo h2c: il gateway applicazione restituisce errori 403 quando i client tentano di eseguire l'aggiornamento da HTTP/1.1 a HTTP/2.0 usando il protocollo h2c (HTTP/2 Cleartext). Il gateway applicativo supporta HTTP/2 solo su TLS (listener HTTPS). Non supporta gli aggiornamenti del protocollo h2c sui listener HTTP. Questo comportamento si verifica indipendentemente dalla modalità WAF. I client devono usare connessioni HTTP/2 native tramite HTTPS o rimanere su HTTP/1.1 senza tentativi di aggiornamento.
  • Stai usando App Service come back-end e lo hai configurato per consentire l'accesso solo dall'Application Gateway. Questa configurazione può causare un errore 403 da App Services. Questo errore si verifica in genere a causa di reindirizzamenti o collegamenti href che puntano direttamente a App Services anziché all'indirizzo IP del Application Gateway.
  • Se si accede a un BLOB di archiviazione e l'endpoint di archiviazione e il gateway applicativo si trovano in aree diverse, viene restituito un errore 403 se l'indirizzo IP pubblico del gateway applicativo non è nella lista di autorizzazione. Vedere Concedere l'accesso da un intervallo IP Internet.

404 - Pagina non trovata

Quando si effettua una richiesta a Application Gateway (SKU V2) con un hostname che non corrisponde a nessuno dei listener multisito configurati e non è presente alcun listener Basic, viene generata una risposta HTTP 404. Per altre informazioni, vedere Tipi di listener.

408 - Timeout della richiesta

È possibile osservare una risposta HTTP 408 quando le richieste client al listener front-end del gateway dell'applicazione non rispondono entro 60 secondi. È possibile osservare questo errore a causa della congestione del traffico tra reti locali e Azure, quando l'appliance virtuale controlla il traffico o il client stesso diventa sovraccarico.

413 - Entità richiesta troppo grande

È possibile osservare una risposta HTTP 413 quando si utilizza il Web Application Firewall di Azure su Application Gateway e le dimensioni della richiesta del client superano il limite massimo di dimensioni del corpo della richiesta. Il campo dimensione massima del corpo della richiesta controlla il limite complessivo delle dimensioni della richiesta, escludendo qualsiasi caricamento di file. Il valore predefinito per le dimensioni del corpo della richiesta è 128 kB. Per ulteriori informazioni, vedere limiti di dimensione delle richieste del Web Application Firewall.

499 - Il client ha chiuso la connessione

Viene visualizzata una risposta HTTP 499 se una richiesta client inviata ai gateway applicazione tramite SKU v2 viene chiusa prima che il server finisca di rispondere. È possibile osservare questo errore in due scenari. Il primo scenario è quando viene restituita una risposta di grandi dimensioni al client e il client potrebbe aver chiuso o aggiornato l'applicazione prima che il server abbia completato l'invio di una tale risposta. Il secondo scenario è quando il timeout sul lato client è basso e non attende abbastanza a lungo per ricevere la risposta dal server. In questo caso, è preferibile aumentare il timeout nel client. Nei gateway applicazione che usano lo SKU v1, potrebbe essere generato anche un codice di risposta HTTP 0 per il client che chiude la connessione prima che il server finisca di rispondere.

Codici di risposta 5XX (errore del server)

I codici di risposta 500-599 indicano un problema con il gateway applicazione o il server back-end durante l'esecuzione della richiesta.

500 - Errore interno del server

Il Application Gateway di Azure non dovrebbe restituire codici di risposta 500. Aprire una richiesta di supporto se viene visualizzato questo codice, perché questo problema è un errore interno al servizio. Per informazioni su come aprire un caso di supporto, vedere Creare una richiesta di Azure support.

502 - Gateway non valido

Gli errori HTTP 502 possono avere diverse cause radice, tra cui:

Per informazioni sugli scenari in cui si verificano errori 502 e su come risolverli, vedere Risolvere gli errori di tipo Gateway non valido.

503 - Servizio non disponibile

Le risposte HTTP 503 indicano che il gateway applicazione o un server back-end non è temporaneamente in grado di gestire la richiesta. Cause comuni includono:

  • Tutti i membri del pool back-end non sono integri come determinato dai probe di integrità e non è disponibile alcun server integro per elaborare le richieste.
  • Il server back-end è sovraccarico o in fase di manutenzione e restituisce 503 direttamente al gateway applicazione.
  • La scalabilità automatica del gateway applicazione V2 è in corso e le nuove istanze non sono ancora pronte per gestire il traffico.
  • I limiti delle connessioni vengono raggiunti su Application Gateway o sul server backend.

Per risolvere gli errori 503:

  1. Controllare il riquadro Integrità back-end nel portale di Azure per verificare lo stato dei membri del pool back-end.
  2. Esaminare la configurazione delle sonde di integrità per assicurarsi che le sonde non contrassegnino erroneamente i back-end sani come non sani. Per ulteriori informazioni, vedere Panoramica della sonda di salute.
  3. Verificare che l'applicazione back-end sia operativa accedendovi direttamente, bypassando il Gateway dell'applicazione.
  4. Controllare le metriche del gateway applicativo per il conteggio delle connessioni e l'utilizzo delle unità di capacità in Azure Monitor.
  5. Per gli SKU V2, esaminare le impostazioni di scalabilità automatica per garantire un numero minimo di istanze sufficiente durante i picchi di traffico.

Per altre informazioni, vedere Risolvere i problemi di stato del backend.

504 - Timeout del gateway

Lo SKU V2 del gateway di applicazione Azure invia errori HTTP 504 se il tempo di risposta del back-end supera il timeout configurato nelle impostazioni del back-end.

IIS (il server web di servizi di informazione Internet)

Se il server back-end è IIS, vedere Limiti predefiniti per siti Web per impostare il valore di timeout. Per informazioni dettagliate, vedere l'attributo connectionTimeout. Verificare che il timeout della connessione in IIS corrisponda o non superi il timeout impostato nell'impostazione back-end.

Nginx

Se il server back-end è Nginx o Nginx Ingress Controller e se dispone di server upstream, verificare che il valore del nginx:proxy_read_timeout corrisponda o non superi il timeout impostato nelle impostazioni del back-end.

Scenari di risoluzione dei problemi

Errore "ERRORINFO_INVALID_HEADER" nei log di accesso

Problema: il log di accesso mostra un errore "ERRORINFO_INVALID_HEADER" per una richiesta, anche se il codice di risposta back-end (serverStatus) è 200. In altri casi, il server back-end restituisce 500.

Causa: il client invia un'intestazione che contiene caratteri CR LF.

Soluzione: Sostituire i caratteri CR LF con uno spazio e inviare nuovamente la richiesta all'Application Gateway.

Passaggi successivi

Se le informazioni contenute in questo articolo non consentono di risolvere il problema, inviare un ticket di supporto.

  • Last updated on