Codici di risposta HTTP in gateway applicazione

  • Articolo

Questo articolo illustra i motivi per cui app Azure lication Gateway restituisce codici di risposta HTTP specifici. Vengono fornite cause comuni e procedure di risoluzione dei problemi per determinare la causa radice del codice di risposta HTTP di errore. I codici di risposta HTTP possono essere restituiti a una richiesta client indipendentemente dal fatto che sia stata avviata una connessione a una destinazione back-end.

Codici di risposta 3XX (reindirizzamento)

Le risposte da 300 a 399 vengono presentate quando una richiesta client corrisponde a una regola del gateway applicazione con reindirizzamenti configurati. I reindirizzamenti possono essere configurati in una regola così come sono o tramite una regola della mappa del percorso. Per altre informazioni sui reindirizzamenti, vedere gateway applicazione panoramica del reindirizzamento.

301 - Reindirizzamento permanente

Le risposte HTTP 301 vengono presentate quando viene specificata una regola di reindirizzamento con il valore Permanente .

302 - Trovato

Le risposte HTTP 302 vengono presentate quando viene specificata una regola di reindirizzamento con il valore Trovato .

303 - Vedi altri

Le risposte HTTP 302 vengono presentate quando viene specificata una regola di reindirizzamento con il valore See Other .

307 - Reindirizzamento temporaneo

Le risposte HTTP 307 vengono visualizzate quando viene specificata 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 dall'avvio delle richieste al nome host non corrispondente, dal timeout della richiesta, da una richiesta non autenticata, da una richiesta dannosa e altro ancora.

gateway applicazione raccoglie le metriche che acquisisce la distribuzione dei codici di stato 4xx/5xx ha un meccanismo di registrazione che acquisisce informazioni come l'indirizzo IP del client URI con il codice di risposta. Le metriche e la registrazione consentono un'ulteriore risoluzione dei problemi. I client possono anche ricevere una risposta 4xx da altri proxy tra il dispositivo client e gateway applicazione. Ad esempio, rete CDN e altri provider di autenticazione. Vedi gli articoli seguenti per altre informazioni.

Metriche supportate dai log di diagnostica dello SKUV2 gateway applicazione

400 - Richiesta non valida

I codici di risposta HTTP 400 vengono comunemente osservati quando:

  • Il traffico non HTTP/HTTPS viene avviato in un gateway applicazione con un listener HTTP o HTTPS.
  • Il traffico HTTP viene avviato in un listener con HTTPS, senza reindirizzamento configurato.
  • L'autenticazione reciproca è configurata e non è in grado di negoziare correttamente.
  • La richiesta non è conforme a RFC.

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

Category Esempi
Host non valido nella riga di richiesta Host contenente due due punti (example.com:8090:8080)
Intestazione host mancante La richiesta non ha intestazione host
Presenza di caratteri non validi o non validi I caratteri riservati sono &,!. La soluzione alternativa consiste nel codificarla come percentuale. Ad esempio: %&
Versione HTTP non valida Ottenere /content.css HTTP/0.3
Il nome del campo di intestazione e l'URI contengono caratteri non ASCII GET /«úü¡»^.doc HTTP/1.1
Intestazione Lunghezza contenuto mancante per la richiesta POST Evidente
Metodo HTTP non valido GET123 /index.html HTTP/1.1
Intestazioni duplicate Authorization:<base64 encoded content>, Authorization: <base64 encoded content>
Valore non valido in Content-Length Content-Length: abc,Content-Length: -10

Nei casi in cui è configurata l'autenticazione reciproca, diversi scenari possono causare la restituzione di una risposta HTTP 400 al client, ad esempio:

  • Il certificato client non viene presentato, ma l'autenticazione reciproca è abilitata.
  • La convalida DN è abilitata e il nome DN del certificato client non corrisponde al DN della catena di certificati specificata.
  • La catena di certificati client non corrisponde alla catena di certificati configurata nei criteri SSL definiti.
  • Il certificato client è scaduto.
  • Il controllo di revoca del client OCSP è abilitato e il certificato viene revocato.
  • Il controllo di revoca del client OCSP è abilitato, ma non è possibile contattare.
  • Il controllo di revoca del client OCSP è abilitato, 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 al codice di errore.

401 - Non autorizzato

Al client viene restituita una risposta HTTP 401 non autorizzata se il client non è autorizzato ad accedere alla risorsa. Ci sono diversi motivi per cui 401 deve essere restituito. Di seguito sono riportati 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.

È possibile restituire una risposta HTTP 401 non autorizzata alla richiesta di probe AppGW se il pool back-end è configurato con l'autenticazione NTLM . In questo scenario, il back-end viene contrassegnato come integro. Esistono diversi modi per risolvere questo problema:

  • Consentire l'accesso anonimo nel pool back-end.
  • Configurare il probe per inviare la richiesta a un altro sito "falso" che non richiede NTLM.
  • Non consigliato, perché questo non indica se il sito effettivo dietro il gateway applicazione è attivo o meno.
  • Configurare il gateway applicazione per consentire 401 risposte come valide per i probe: condizioni di corrispondenza del probe.

403 - Accesso negato

HTTP 403 Non consentito viene presentato quando i clienti usano SKU WAF e hanno 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 client viene presentata una risposta 403 non consentita.

Altri motivi per i client che ricevono risposte 403 includono:

  • Si sta usando servizio app come back-end ed è configurato per consentire l'accesso solo da gateway applicazione. Questo può restituire un errore 403 per servizio app. Ciò si verifica in genere a causa di reindirizzamenti/collegamenti href che puntano direttamente alle servizio app anziché puntare all'indirizzo IP del gateway applicazione.
  • Se si accede a un blog di archiviazione e l'endpoint di archiviazione e gateway applicazione si trova in un'area diversa, viene restituito un errore 403 se l'indirizzo IP pubblico del gateway applicazione non è consentito. Vedere Concedere l'accesso da un intervallo di indirizzi IP Internet.

404 - Pagina non trovata

È possibile restituire una risposta HTTP 404 se una richiesta viene inviata a un gateway applicazione:

408 - Timeout richiesta

Una risposta HTTP 408 può essere osservata quando le richieste client al listener front-end del gateway applicazione non rispondono entro 60 secondi. Questo errore può essere osservato 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 - Richiedere un'entità troppo grande

Una risposta HTTP 413 può essere osservata quando si usa Web Application Firewall di Azure in gateway applicazione e le dimensioni della richiesta 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 altre informazioni, vedere Limiti delle dimensioni delle richieste di 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 abbia terminato la risposta. Questo errore può essere osservato in 2 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 risposta di grandi dimensioni. 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 un codice di risposta HTTP 0 per il client che chiude la connessione prima che il server abbia terminato di rispondere.

Codici di risposta 5XX (errore del server)

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

500 - Errore interno del server

Gateway applicazione di Azure non dovrebbe presentare 500 codici di risposta. 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 supporto tecnico di Azure.

502 - Gateway non valido

Gli errori HTTP 502 possono avere diverse cause radice, ad esempio:

  • Il gruppo di sicurezza di rete, la route definita dall'utente o il DNS personalizzato blocca l'accesso ai membri del pool back-end.
  • Le macchine virtuali back-end o le istanze dei set di scalabilità di macchine virtuali non rispondono al probe di integrità predefinito.
  • Configurazione dei probe di integrità personalizzati non valida o inappropriata.
  • app Azure pool back-end del gateway non è configurato o vuoto.
  • Nessuna delle macchine virtuali o delle istanze nel set di scalabilità di macchine virtuali è integra.
  • Timeout della richiesta o problemi di connettività con lo SKU V1 del gateway applicazione azure V1 ha inviato errori HTTP 502 se il tempo di risposta back-end supera il valore di timeout configurato nell'impostazione back-end.

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

504 - Timeout del gateway

Lo SKU V2 del gateway applicazione di Azure ha inviato errori HTTP 504 se il tempo di risposta back-end supera il valore di timeout configurato nell'impostazione back-end.

IIS

Se il server back-end è IIS, consultare la sezione 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 è un controller di ingresso nginx o nginx e se dispone di server upstream, verificare che il valore di nginx:proxy_read_timeout corrisponde o non superi il timeout impostato nell'impostazione back-end.

Passaggi successivi

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