Códigos de respuesta HTTP en Application Gateway

Resumen

En este artículo se proporcionan motivos por los que Azure Application Gateway devuelve códigos de respuesta HTTP específicos. Se proporcionan las causas comunes y los pasos de solución de problemas para ayudarle a determinar la causa principal del código de respuesta HTTP de error. Los códigos de respuesta HTTP se pueden devolver a una solicitud de cliente tanto si se haya iniciado una conexión a un destino de backend o no.

Códigos de respuesta 3XX (redireccionamiento)

Las respuestas 300-399 se presentan cuando una solicitud de cliente coincide con una regla de puerta de enlace de aplicación que tiene redireccionamientos configurados. Los redireccionamientos se pueden configurar en una regla tal cual o por medio de una regla de asignación de ruta de acceso. Para más información acerca de los redireccionamientos, consulte Introducción a la redirección de Application Gateway.

301 (redirección permanente)

Las respuestas HTTP 301 se presentan cuando se especifica una regla de redireccionamiento con el valor Permanente.

302 Encontrado

Las respuestas HTTP 302 se presentan cuando se especifica una regla de redireccionamiento con el valor Encontrado.

303 Ver Otros

Las respuestas HTTP 302 se presentan cuando se especifica una regla de redireccionamiento con el valor Ver otro.

307 (redirección temporal)

Las respuestas HTTP 307 se presentan cuando se especifica una regla de redireccionamiento con el valor Temporal.

Códigos de respuesta 4XX (error de cliente)

Los códigos de respuesta 400-499 indican un problema que se inicia desde el cliente. Estos problemas pueden variar desde el cliente que inicia solicitudes a un nombre de host no coincidente, tiempo de espera de solicitud, solicitud no autenticada, solicitud malintencionada, etc.

Application Gateway recopila métricas que capturan la distribución de los códigos de estado 4xx/5xx y tiene un mecanismo de registro que captura información como la dirección IP del cliente URI con el código de respuesta. Las métricas y el registro permiten solucionar más problemas. Los clientes también pueden recibir una respuesta 4xx de otros servidores proxy entre el dispositivo cliente y Application Gateway. Por ejemplo, CDN (Content Delivery Network) y otros proveedores de autenticación. Para obtener más información, consulta los siguientes artículos.

• Métricas compatibles con la SKU V2 de Application Gateway
• Registro de diagnóstico

400: Solicitud incorrecta

Los códigos de respuesta HTTP 400 se suelen observar cuando:

• El tráfico no HTTP/HTTPS se inicia en una puerta de enlace de aplicaciones con un cliente de escucha HTTP o HTTPS.
• El tráfico HTTP se inicia en un cliente de escucha con HTTPS, sin redireccionamiento configurado.
• La autenticación mutua está configurada y no puede negociar correctamente.
• La solicitud no es compatible con RFC.

Algunas razones comunes para que la solicitud no sea compatible con RFC son:

Categoría	Examples
Host no válido en la línea de solicitud	Host que contiene dos puntos (ejemplo.com:8090:8080)
Falta el encabezado host	La solicitud no tiene encabezado host
Presencia de caracteres malformados o no válidos	Los caracteres reservados son &,!. La solución alternativa consiste en codificarla como porcentaje. Por ejemplo: %&
Versión HTTP no válida	Obtener /content.css HTTP/0.3
El nombre del campo de encabezado y el URI contienen caracteres no ASCII	GET /«úü¡»¿.doc HTTP/1.1
Falta el encabezado Content-Length en la solicitud POST.	Se explica por sí solo.
Método HTTP no válido	GET123 /index.html HTTP/1.1
Encabezados duplicados	Autorización:contenido codificado en base64, Autorización: contenido codificado en base64
Valor no válido en Content-Length	Longitud del contenido: abc, Longitud del contenido: -10

En los casos en los que se configura la autenticación mutua, varios escenarios pueden dar lugar a que se devuelva una respuesta HTTP 400 al cliente, como:

• La autenticación mutua está habilitada, pero no se presentó el certificado de cliente.
• La validación de DN (nombre distintivo) está habilitada y el DN del certificado de cliente no coincide con el DN de la cadena de certificados especificada.
• La cadena de certificados de cliente no coincide con la cadena de certificados configurada en la directiva SSL definida.
• El certificado de cliente ha caducado.
• La comprobación de revocación del cliente OCSP (Protocolo de estado de certificados en línea) está habilitada y el certificado se ha revocado.
• La comprobación de revocación de cliente de OCSP (Protocolo de estado de certificados en línea) está habilitada, pero no se puede ponerse en contacto con él.
• La comprobación de revocación del cliente de OCSP (Protocolo de estado de certificados en línea) está habilitada, pero el respondedor OCSP no se proporciona en el certificado.

Para obtener más información sobre cómo solucionar problemas de autenticación mutua, consulte Solución de problemas de código de error.

401 - No autorizado

Se devuelve una respuesta HTTP 401 no autorizada al cliente si el cliente no está autorizado para acceder al recurso. Hay varias razones para que se devuelva un código de respuesta 401. A continuación se muestran algunas razones con posibles correcciones.

• Si el cliente tiene acceso, es posible que tenga una caché de explorador obsoleta. Borre la memoria caché del explorador e intente volver a acceder a la aplicación.

Se puede devolver una respuesta HTTP 401 no autorizada a la solicitud de sondeo de AppGW si el grupo de back-end está configurado con la autenticación NTLM. En este escenario, el backend está marcado como saludable. Hay varias formas de solucionar este problema:

• Permitir el acceso anónimo en el grupo de servidores backend.
• Configure el sondeo para enviar la solicitud a otro sitio "falso" que no requiera NTLM.
• No se recomienda, ya que esto no nos indicará si el sitio efectivo detrás del gateway de aplicaciones está activo o no.
• Configure la puerta de enlace de la aplicación para que permita las respuestas 401 como válidas para los sondeos: Condiciones de Coincidencia de Sondeo.

403 - Prohibido

HTTP 403 Prohibido se presenta cuando los clientes utilizan skus de WAF (Web Application Firewall) y tienen WAF configurado en modo Prevención. Si los conjuntos de reglas de WAF habilitados o las reglas de WAF de denegación personalizadas coinciden con las características de una solicitud entrante, el cliente presenta una respuesta 403 prohibida.

Otros motivos por los cuales los clientes reciben respuestas 403 incluyen:

• Intentos de actualización del protocolo h2c: Application Gateway devuelve 403 errores cuando los clientes intentan actualizar de HTTP/1.1 a HTTP/2.0 mediante el protocolo h2c (HTTP/2 Cleartext). Application Gateway solo admite HTTP/2 a través de TLS (agentes de escucha HTTPS); No se admiten las actualizaciones del protocolo h2c a través de agentes de escucha HTTP. Este comportamiento se produce independientemente del modo WAF. Los clientes deben usar conexiones HTTP/2 nativas a través de HTTPS o permanecer en HTTP/1.1 sin intentos de actualización.
• Está usando App Service como back-end y está configurado para permitir el acceso solo desde Application Gateway. Esto puede devolver un error 403 causado por los servicios de aplicaciones. Esto suele ocurrir debido a los vínculos de redirección/href que apuntan directamente a App Services en lugar de apuntar a la dirección IP de Application Gateway.
• Si tiene acceso a un blog de almacenamiento y el punto de conexión de almacenamiento y Application Gateway se encuentra en otra región, se devuelve un error 403 si la dirección IP pública de Application Gateway no aparece en la lista de permitidos. Consulte Conceder acceso desde un rango de IP de Internet.

404: Página no encontrada

Se genera una respuesta HTTP 404 cuando se realiza una solicitud a Application Gateway (SKU V2) con un nombre de host que no corresponde a ninguno de los agentes de escucha multisitio configurados y no hay ningún agente de escucha básico presente. Obtenga más información sobre los tipos de agentes de escucha.

408: Tiempo de espera de solicitud

Se puede observar una respuesta HTTP 408 cuando las solicitudes del cliente al escucha del frontend de la puerta de enlace de aplicaciones no reciben respuesta dentro de 60 segundos. Este error se puede observar debido a la congestión del tráfico entre redes locales y Azure, cuando la aplicación virtual inspecciona el tráfico o el propio cliente se sobrecarga.

413: Entidad de solicitud demasiado grande

Se puede observar una respuesta HTTP 413 al usar Azure Web Application Firewall en Application Gateway y el tamaño de la solicitud de cliente supera el límite máximo de tamaño del cuerpo de la solicitud. El campo del tamaño máximo del cuerpo de la solicitud controla el límite de tamaño de la solicitud general, y se excluye cualquier carga de archivo. El valor predeterminado para el tamaño del cuerpo de la solicitud es de 128 KB. Para obtener más información, consulte Web Application Firewall límites de tamaño de solicitud.

499: El cliente cerró la conexión

Se presenta una respuesta HTTP 499 si se cierra una solicitud de cliente que se envía a las puertas de enlace de aplicaciones mediante SKU v2 antes de que el servidor termine de responder. Este error se puede observar en 2 escenarios. El primer escenario es cuando se devuelve una respuesta grande al cliente y es posible que este haya cerrado o actualizado la aplicación antes de que el servidor termine de enviar una respuesta grande. El segundo escenario es cuando el tiempo de espera en el lado cliente es bajo y no espera lo suficiente para recibir la respuesta del servidor. En este caso, es mejor aumentar el tiempo de espera en el cliente. En las puertas de enlace de aplicaciones que usan sku v1, se puede generar un código de respuesta HTTP 0 para que el cliente cierre la conexión antes de que el servidor también haya terminado de responder.

Códigos de respuesta 5XX (error del servidor)

Los códigos de respuesta 500-599 indican que se ha producido un problema con la puerta de enlace de aplicación o el servidor back-end al realizar la solicitud.

500: Error interno del servidor

Azure Application Gateway no debe presentar códigos de respuesta 500. Si ve este código, abra una solicitud de soporte técnico, ya que este problema es un error interno del servicio. Para obtener información sobre cómo abrir un caso de soporte técnico, consulte Crear una solicitud de Soporte técnico de Azure.

502: Puerta de enlace incorrecta

Los errores HTTP 502 pueden tener varias causas principales, por ejemplo:

• NSG (grupo de seguridad de red), UDR (ruta definida por el usuario) o DNS personalizado bloquea el acceso a los miembros del grupo de back-end.
• Las máquinas virtuales de back-end o las instancias de los conjuntos de escalado de máquinas virtuales no responden al sondeo de estado predeterminado.
• Configuración no válida o adecuada de las sondas de estado personalizadas.
• Azure Application Gateway grupo de backend no está configurado o está vacío.
• Ninguna de las máquinas virtuales o instancias del conjunto de escalado de máquina virtual está en buen estado.
• Problemas de tiempo de espera o conectividad con las solicitudes de usuario: el SKU V1 de Azure Application Gateway envió errores HTTP 502 si el tiempo de respuesta del back-end supera el valor de tiempo de espera configurado en la configuración del back-end.

Para obtener información sobre escenarios en los que se producen errores 502 y cómo solucionarlos, vea el artículo Solución de errores de puerta de enlace incorrecta.

504: Tiempo de espera agotado para la puerta de enlace

Azure SKU V2 de Application Gateway de Azure envió errores HTTP 504 si el tiempo de respuesta del backend supera el valor de tiempo de espera configurado en la Configuración del backend.

IIS (servidor web de Internet Information Services)

Si el servidor back-end es IIS, consulte Límites predeterminados de sitios web para establecer el valor de tiempo de espera. Consulte el atributo para más información. Asegúrese de que el tiempo de espera de conexión en IIS coincide o no supera el tiempo de espera establecido en la configuración de back-end.

Nginx

Si el servidor back-end es Nginx o Nginx Ingress Controller, y si tiene servidores ascendentes, asegúrese de que el valor de coincide o no supere con el tiempo de espera establecido en la configuración de back-end.

Escenarios de solución de problemas

Error "ERRORINFO_INVALID_HEADER" en los registros de acceso

Problema: el registro de acceso muestra un error de "ERRORINFO_INVALID_HEADER" para una solicitud, a pesar de que el código de respuesta de back-end (serverStatus) sea 200. En otros casos, el servidor back-end podría devolver 500.

Causa: el cliente envía un encabezado que contiene caracteres CR LF.

Solución: reemplace los caracteres cr LF por SP (espacio en blanco) y vuelva a enviar la solicitud a Application Gateway.

Pasos siguientes

Si la información de este artículo no ayuda a resolver el problema, envíe una incidencia de soporte técnico.