Partekatu honen bidez:

Códigos de respuesta HTTP en Application Gateway

  • Artikulua

En este artículo se indican los 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 inició una conexión a un destino de back-end 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 como está o a través 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 otras)

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 ir desde el cliente que inicia solicitudes a un nombre de host no coincidente, tiempo de espera de la 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 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 GatewayRegistros 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:

Category Ejemplos
Host no válido en la línea de solicitud Host que contiene el signo de los dos puntos (ejemplo.com:8090:8080)
Falta el encabezado host La solicitud no tiene encabezado host
Presencia de caracteres incorrectos 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 Get /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 Authorization:<base64 encoded content>, Authorization: <base64 encoded content>
Valor no válido en Content-Length Content-Length: abc,Content-Length: -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:

  • No se presenta el certificado de cliente, pero la autenticación mutua está habilitada.
  • La validación de DN 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 de cliente OCSP está habilitada y se revoca el certificado.
  • La comprobación de revocación de cliente OCSP está habilitada, pero no se puede contactar con ella.
  • La comprobación de revocación de cliente OCSP está habilitada, pero el respondedor OCSP no consta 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 una 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 se marca como correcto. Hay varias formas de solucionar este problema:

  • Permitir el acceso anónimo en el grupo de 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 real detrás de la puerta de enlace de aplicación está activo o no.
  • Configure la puerta de enlace de aplicación para que permita las respuestas 401 como válidas para los sondeos: condiciones de coincidencia de sondeo.

403 - Prohibido

El error HTTP 403 Forbidden se presenta cuando los clientes usan sku de WAF y lo tienen configurado en modo de 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.

Entre otros motivos para los clientes que reciben respuestas 403 se incluyen:

  • Está usando App Service como back-end y está configurado para permitir el acceso solo desde Application Gateway. Esto puede devolver un error 403 por App Services. 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 Concesión de acceso desde un intervalo IP de Internet.

404: Página no encontrada

Puede que se devuelva una respuesta HTTP 404 si se envía una solicitud a una puerta de enlace de aplicaciones:

408: Tiempo de espera de solicitud

Se puede observar una respuesta HTTP 408 cuando las solicitudes de cliente al cliente de escucha de front-end de la puerta de enlace de aplicación no responden en un plazo de 60 segundos. Este error se puede observar 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: Entidad de solicitud demasiado larga

Se 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 más información consulte Límites de tamaño de solicitud del firewall de aplicaciones web.

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 se produce 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 debería 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, vea el artículo Creación de una solicitud de Soporte técnico de Azure.

502: Puerta de enlace incorrecta

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

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

La SKU V2 de Azure Application Gateway envía errores HTTP 504 si el tiempo de respuesta de back-end supera el valor de tiempo de espera configurado en la configuración de back-end.

IIS

Si el servidor back-end es IIS, consulte Límites predeterminados para 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 es igual o no superior al tiempo de espera establecido en la configuración del back-end.

nginx

Si el servidor back-end es nginx o el controlador de entrada de nginx, y si tiene servidores ascendentes, asegúrese de que el valor de nginx:proxy_read_timeout coincide o no supera el tiempo de espera establecido en la configuración de back-end.

Pasos siguientes

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