Compartir a través de

Códigos de respuesta HTTP en Application Gateway

Resumen

En este artículo se explica por qué Azure Application Gateway devuelve códigos de respuesta HTTP específicos. Proporciona causas comunes y pasos de solución de problemas que le ayudarán a determinar la causa principal de un código de respuesta HTTP de error. Application Gateway puede devolver códigos de respuesta HTTP a una solicitud de cliente si inicia o no una conexión a un destino de back-end.

Nota:

Si se produce un error en una conexión de cliente antes de que Application Gateway devuelva cualquier respuesta HTTP, probablemente se deba a un fallo de seguridad de la capa de transporte (TLS). Entre las causas comunes se incluyen los errores de coincidencia de versiones de TLS (por ejemplo, el cliente usa TLS 1.0 o 1.1, mientras que la puerta de enlace requiere TLS 1.2 o superior) y conjuntos de cifrado no admitidos. A partir del 31 de agosto de 2025, Azure Application Gateway deja de admitir TLS 1.0 y 1.1. Para más información, consulte Introducción a la directiva TLS de Application Gateway y Configuración de versiones de directivas TLS y conjuntos de cifrado.

Códigos de respuesta 3XX (redireccionamiento)

El Application Gateway devuelve respuestas de 300 a 399 cuando una solicitud de cliente coincide con una regla del Application Gateway configurada para redirigir. Puede configurar redirecciones en una regla tal cual o a través de una regla de mapa de rutas. Para más información acerca de los redireccionamientos, consulte Introducción a la redirección de Application Gateway.

Redireccionamiento permanente 301

Application Gateway devuelve respuestas HTTP 301 al especificar una regla de redirección con el valor Permanente .

302 Encontrado

Application Gateway devuelve respuestas HTTP 302 al especificar una regla de redirección con el valor Encontrado .

303 Ver otros

Application Gateway devuelve respuestas HTTP 303 al especificar una regla de redirección con el valor Ver otro .

307 Redirección temporal

Application Gateway devuelve respuestas HTTP 307 al especificar una regla de redirección con el valor temporal .

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

Los códigos de respuesta 400-499 indican un problema que inicia 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 códigos de estado 4xx/5xx y tienen 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 respuestas 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.

400 : solicitud incorrecta

Normalmente, verá códigos de respuesta HTTP 400 cuando:

  • Inicias tráfico no HTTP o HTTPS hacia una puerta de enlace de aplicaciones con un agente de escucha HTTP o HTTPS.
  • Usted inicia el tráfico HTTP hacia un escucha con HTTPS, sin redireccionamiento configurado.
  • Configuras la autenticación mutua, pero Application Gateway 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

Al configurar la autenticación mutua, varios escenarios pueden provocar que se devuelva una respuesta HTTP 400 al cliente, entre las que se incluyen:

  • Habilite la autenticación mutua, pero no se presentó el certificado de cliente.
  • Habilite la validación de nombre distintivo (DN) 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.
  • Habilitas la verificación de revocación de cliente del Protocolo de Estado de Certificado en Línea (OCSP) y el certificado se revoca.
  • Usted habilita la comprobación de revocación del cliente OCSP, pero el Application Gateway no puede contactar con el respondedor OCSP.
  • Habilita la verificación de revocación del cliente OCSP, pero el respondedor OCSP no está incluido 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

Application Gateway devuelve una respuesta http 401 no autorizada al cliente si el cliente no está autorizado para acceder al recurso. Existen varias razones para que se devuelva 401. En la lista siguiente se proporcionan 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.

Application Gateway puede devolver una respuesta HTTP 401 no autorizada a la solicitud de sondear de AppGW si se configura el grupo de back-end con autenticación NTLM. En este escenario, Application Gateway marca el backend como saludable. Resuelva este problema mediante uno de los métodos siguientes:

  • 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 esta solución no nos indica si el sitio real detrás de la puerta de enlace 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

Application Gateway presenta HTTP 403 Prohibido (Forbidden) cuando se usan SKU de WAF (Firewall de aplicaciones web) y se ha configurado WAF en modo de prevención. Si los conjuntos de reglas waf habilitados o las reglas waf de denegación personalizadas coinciden con las características de una solicitud entrante, Application Gateway presenta una respuesta 403 prohibida al cliente.

Para resolver falsos positivos de WAF (solicitudes legítimas bloqueadas por las reglas de WAF):

  1. Habilite los registros de diagnóstico de WAF y revise el ruleId_s campo para identificar qué regla está bloqueando la solicitud.
  2. Cambie temporalmente el waf al modo de detección para registrar reglas de coincidencia sin bloquear el tráfico. Este enfoque le ayuda a confirmar falsos positivos antes de realizar cambios en las reglas. Para obtener más información, consulte la configuración de directivas de WAF.
  3. Cree exclusiones de WAF para atributos de solicitud específicos (como encabezados, cookies o argumentos) que produzcan falsos positivos.
  4. Si una regla administrada provoca constantemente falsos positivos y las exclusiones no son suficientes, deshabilite la regla individual en la directiva WAF.

Para obtener instrucciones detalladas, consulte Solución de problemas de WAF para Application Gateway y procedimientos recomendados de WAF.

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

  • Intentos de actualización del protocolo h2c: Application Gateway devuelve errores 403 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 admite 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 lo configuró para permitir el acceso solo desde Application Gateway. Esta configuración puede devolver un error 403 por App Services. Este error suele producirse debido a redirecciones o vínculos href que apuntan directamente a App Services en lugar de apuntar a la dirección IP de Application Gateway.
  • Si tiene acceso a un blob de almacenamiento y el punto de conexión de Almacenamiento y Application Gateway están en regiones diferentes, 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 se corresponde con ninguno de los agentes de escucha multisitio configurados y no hay ningún agente de escucha básico presente. Para más información, consulte tipos de agentes de escucha.

408: tiempo de espera de la solicitud

Puede observar una respuesta HTTP 408 cuando las solicitudes de cliente al agente de escucha de front-end de Application Gateway no responden en un plazo de 60 segundos. Es posible que observe este error debido a la congestión del tráfico entre las redes locales y Azure, cuando la aplicación virtual inspecciona el tráfico o el propio cliente se sobrecarga.

413: solicitud de entidad demasiado grande

Puede observar una respuesta HTTP 413 cuando se usa 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 enviada a los gateways de aplicaciones con la SKU v2 antes de que el servidor termine de responder. Puede observar este error en dos 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 la SKU v1, se podría generar un código de respuesta HTTP 0 para que el cliente cierre la conexión antes de que el servidor termine de responder también.

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

Los códigos de respuesta 500-599 indican un problema con la puerta de enlace de aplicaciones o el servidor back-end mientras realiza la solicitud.

500: error interno del servidor

Azure Application Gateway no debe devolver 500 códigos de respuesta. 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 Azure support.

502: puerta de enlace incorrecta

Los errores HTTP 502 pueden tener varias causas principales, entre las que se incluyen:

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.

503: servicio no disponible

Las respuestas HTTP 503 indican que Application Gateway o un servidor back-end no pueden controlar temporalmente la solicitud. Las causas más comunes son:

  • Todos los miembros del grupo de back-end no son saludables según lo determinan las comprobaciones de salud y no hay ningún servidor saludable disponible para procesar las solicitudes.
  • El servidor back-end se sobrecarga o está realizando un mantenimiento y devuelve 503 directamente a Application Gateway.
  • El escalado automático de Application Gateway V2 está en curso y las nuevas instancias aún no están listas para atender el tráfico.
  • Se alcanzan los límites de conexión en Application Gateway o en el servidor back-end.

Para solucionar los errores 503:

  1. Compruebe el panel Estado del backend en el portal de Azure para verificar el estado del miembro del grupo de backend.
  2. Revise la configuración del sondeo de salud para asegurarse de que los sondeos no marcan incorrectamente los backends saludables como no saludables. Para obtener más información, consulte Vista general del sondeo de salud.
  3. Compruebe que la aplicación back-end está operativa accediendo directamente a ella y omitiendo Application Gateway.
  4. Compruebe las métricas de Application Gateway para ver el recuento de conexiones y el uso de unidades de capacidad en Azure Monitor.
  5. En las SKU V2, revise la configuración de escalado automático para garantizar instancias mínimas suficientes durante los picos de tráfico.

Para más información, consulte Solución de problemas de mantenimiento del back-end.

504: Tiempo de espera agotado para la puerta de enlace

La SKU V2 de Azure Application Gateway envía errores HTTP 504 si el tiempo de respuesta del backend supera el valor de tiempo de espera que configura 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 connectionTimeout 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 upstream, asegúrese de que el valor de nginx:proxy_read_timeout coincida con o no supere el tiempo de espera establecido en la configuración de back-end.

Escenarios de solución de problemas

Error de "ERRORINFO_INVALID_HEADER" en los registros de acceso

Problema: el registro de acceso muestra un error de "ERRORINFO_INVALID_HEADER" para una solicitud, aunque el código de respuesta back-end (serverStatus) sea 200. En otros casos, el servidor back-end devuelve 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.

  • Last updated on