Comparteix a través de

Solución de problemas comunes de Azure Front Door

  • Article

En este artículo se describe cómo solucionar problemas comunes de enrutamiento que pueden surgir con la configuración de Azure Front Door.

Otros encabezados HTTP de depuración

Puedes solicitar a Azure Front Door que devuelva más encabezados de respuesta HTTP de depuración. Para más información, consulte Encabezados de respuesta opcionales.

Respuesta 503 o 504 de Azure Front Door después de unos segundos

Síntoma

  • Las solicitudes normales enviadas al back-end sin pasar a través de Azure Front Door son correctas. Pasar por Azure Front Door da como resultado respuestas de error 503 o 504.
  • El error de Azure Front Door suele aparecer después de unos 30 segundos.
  • Aparecen errores intermitentes 503 con "ErrorInfo: OriginInvalidResponse".

Causa

La causa de este problema puede ser una de tres cosas:

  • El origen tarda más que el tiempo de expiración configurado en recibir la solicitud de Azure Front Door. El tiempo de expiración predeterminado es de 30 segundos.
  • El tiempo que se tarda en enviar una respuesta a la solicitud desde Azure Front Door es mayor que el valor de tiempo de expiración.
  • El cliente envió una solicitud de intervalo de bytes con un encabezado Accept-Encoding, lo que significa que la compresión está habilitada.

Pasos para solucionar problemas

  • Enviar la solicitud a su origen directamente sin pasar por Azure Front Door. Ver cuánto tarda normalmente el origen en responder.

  • Enviar la solicitud a través de Azure Front Door y ver si recibes alguna respuesta 503. Si no es así, es posible que no se trate de un problema de tiempo de expiración. Crear una solicitud de soporte para seguir solucionando la incidencia.

  • Si las solicitudes que pasan por Azure Front Door dan como resultado un código de respuesta de error 503, configura el tiempo de espera de respuesta de origen para Azure Front Door. Puedes aumentar el tiempo de espera predeterminado hasta 4 minutos (240 segundos). Para configurar el valor, vaya a la página de información general del perfil de Front Door. Seleccione Origin response timeout (Tiempo de espera de respuesta de origen) y escriba un valor entre 16 y 240 segundos.

    Nota:

    La capacidad de configurar el tiempo de espera de respuesta de Origen solo está disponible en Azure Front Door Estándar/Premium.

    Screenshot of the origin timeout settings on the overview page of the Azure Front Door profile.

  • Si aumentar tiempo de espera no resuelve la incidencia, usa una herramienta como Fiddler o la herramienta para desarrolladores del explorador para comprobar si el cliente envía solicitudes de intervalo de bytes con encabezados Accept-Encoding. El uso de esta opción lleva al origen a responder con distintas longitudes de contenido.

    Si el cliente envía solicitudes de intervalo de bytes con encabezados Accept-Encoding, tiene dos opciones. La primera opción es deshabilitar la compresión en el origen o Azure Front Door. La segunda opción es crear una regla de conjunto de reglas para quitar Accept-Encoding de la solicitud de intervalo de bytes.

    Screenshot that shows the Accept-Encoding rule in a rule set.

Respuestas de 503 de Azure Front Door solo para HTTPS

Síntoma

  • Las respuestas 503 solo las devuelven los puntos de conexión habilitados para HTTPS de Azure Front Door.
  • Las solicitudes normales enviadas al back-end sin pasar a través de Azure Front Door son correctas. Al pasar a través de Azure Front Door, se producen respuestas de error 503.
  • Aparecen errores intermitentes 503 con "ErrorInfo: OriginInvalidResponse".

Causa

La causa de este problema puede ser una de estas tres:

  • El grupo de back-end es una dirección IP.
  • El servidor back-end devuelve un certificado que no coincide con el FQDN del grupo de back-end de Azure Front Door.
  • El grupo de back-end es un servidor de aplicaciones web de Azure.

Pasos para solucionar problemas

  • El grupo de back-end es una dirección IP.

    EnforceCertificateNameCheck debe deshabilitarse.

    Azure Front Door tiene un modificador denominado EnforceCertificateNameCheck. Esta opción está habilitada de manera predeterminada. Cuando se habilita, Azure Front Door comprueba que el FQDN del nombre de host del grupo de back-end coincide con el nombre del certificado del servidor back-end o una de las entradas de la extensión de nombres alternativos del sujeto.

    • Cómo deshabilitar EnforceCertificateNameCheck desde Azure Portal:

      En el portal, use un botón de alternancia para activar o desactivar esta configuración en el panel de Diseño de Azure Front Door (clásico)

      Screenshot that shows the toggle button.

      Para Azure Front Door Estándar y Premium, esta configuración se puede encontrar en la configuración de origen al agregar un origen a un grupo de origen o configurar una ruta.

      Screenshot of the certificate subject name validation checkbox.

  • El servidor back-end devuelve un certificado que no coincide con el FQDN del grupo de back-end de Azure Front Door. Tiene dos opciones para resolver este problema:

    • El certificado devuelto debe coincidir con el FQDN.
    • EnforceCertificateNameCheck debe deshabilitarse.

  • El grupo de back-end es un servidor de aplicaciones web de Azure:

    • Compruebe si la aplicación web de Azure está configurada con SSL basado en IP en lugar de basado en SNI. Si la aplicación web está configurada como basada en IP, debe cambiarse a SNI.
    • Si el back-end es incorrecto debido a un error de certificado, se devuelve un mensaje de error 503. Puede comprobar el estado de los back-end en los puertos 80 y 443. Si solo el puerto 443 es incorrecto, probablemente se trate de una incidencia con SSL. Dado que el back-end está configurado para usar el FQDN, sabemos que está enviando SNI.

    Use OPENSSL para comprobar el certificado que se va a devolver. Para ello, conéctese al back-end mediante -servername. Debe devolver el SNI que tiene que coincidir con el FQDN del grupo de back-end.

    openssl s_client -connect backendvm.contoso.com:443 -servername backendvm.contoso.com

Las solicitudes enviadas al dominio personalizado devuelven el código de estado 400

Síntoma

  • Creó una instancia de Azure Front Door, pero una solicitud al dominio o el host de front-end devuelve un código de estado HTTP 400.
  • Creó una asignación de DNS para un dominio personalizado para el host de front-end que configuró. El envío de una solicitud al nombre de host de dominio personalizado devuelve un código de estado HTTP 400. No parece enrutarse al back-end que configuró.

Causa

El problema se produce si no configuró una regla de enrutamiento para el dominio personalizado que se agregó como host de front-end. Es necesario agregar explícitamente una regla de enrutamiento para ese host de front-end. Debes crear la regla incluso si ya se configuró una regla de enrutamiento para el host front-end en el subdominio de Azure Front Door, que es *.azurefd.net.

Paso de solución de problemas

Agregue una regla de enrutamiento para que el dominio personalizado dirija el tráfico al grupo de origen seleccionado.

Azure Front Door no redirige HTTP a HTTPS

Síntoma

Azure Front Door tiene una regla de enrutamiento que redirige HTTP a HTTPS, pero el acceso al dominio sigue manteniendo HTTP como protocolo.

Causa

Este comportamiento puede producirse si no configuró correctamente las reglas de enrutamiento para Azure Front Door. La configuración actual no se ha especificado y puede tener reglas en conflicto.

Pasos para solucionar problemas

La solicitud al nombre de host de front-end devuelve el código de estado 411

Síntoma

Creó una instancia de Azure Front Door Estándar o Premium y ha configurado:

  • Un host de front-end.
  • Un grupo de origen con al menos un origen.
  • Una regla de enrutamiento que conecta el host de front-end al grupo de origen.

El contenido parece no estar disponible cuando una solicitud se dirige al host de front-end configurado, ya que se devuelve un código de estado HTTP 411.

Las respuestas a estas solicitudes también pueden contener una página de error HTML en el cuerpo de la respuesta que incluya una declaración explicativa. Un ejemplo es "Error HTTP 411. La solicitud debe estar fragmentada o tener una longitud de contenido".

Causa

Hay varias causas posibles para este síntoma. El motivo general es que la solicitud HTTP no es totalmente compatible con RFC.

Un ejemplo de incumplimiento es una POSTsolicitud enviada sin un encabezado Content-Length o Transfer-Encoding. Un ejemplo sería usar curl -X POST https://example-front-door.domain.com. Esta solicitud no cumple los requisitos establecidos en RFC 7230. Azure Front Door la bloqueará con una respuesta HTTP 411. Estas solicitudes no se registran.

Este comportamiento es independiente de la funcionalidad de firewall de aplicaciones web (WAF) de Azure Front Door. Actualmente, no hay ninguna manera de deshabilitar este comportamiento. Todas las solicitudes HTTP deben cumplir los requisitos, incluso si la funcionalidad WAF no está en uso.

Pasos para solucionar problemas

  • Compruebe que las solicitudes cumplen los requisitos establecidos en las normativas RFC exigidas.
  • Tome nota de cualquier cuerpo de mensaje HTML que se devuelva en respuesta a su solicitud. Un cuerpo de mensaje suele explicar exactamente cómo la solicitud no es conforme.

Mi origen está configurado como una dirección IP.

Síntoma

El origen se configura como una dirección IP. El origen es correcto, pero rechaza las solicitudes de Azure Front Door.

Causa

Durante el protocolo de enlace SSL, Azure Front Door usa el nombre de host de origen como encabezado SNI. Dado que el origen está configurado como una dirección IP, el error puede deberse a uno de los siguientes motivos:

  • La comprobación de nombres de certificado está habilitada en la configuración de origen de Front Door. Se recomienda dejar esta configuración habilitada. La comprobación del nombre del certificado requiere que el nombre de host de origen coincida con el nombre del certificado o una de las entradas de la extensión de nombres alternativos del firmante.
  • Si la comprobación del nombre del certificado está deshabilitada, es probable que la causa se deba a que la lógica del certificado de origen rechace las solicitudes que no tengan un encabezado de host válido en la solicitud que coincida con el certificado.

Pasos para solucionar problemas

Cambie el origen de una dirección IP a un FQDN al que se emite un certificado válido que coincida con el certificado de origen.

Pasos siguientes