Solución de problemas de puntos de conexión de Azure Content Delivery Network que devuelven un código de estado 404

Importante

Azure CDN Estándar de Microsoft (clásico) se retirará el 30 de septiembre de 2027. Para evitar interrupciones del servicio, es importante que migre los perfiles de Azure CDN Estándar de Microsoft (clásico) a los nivel Estándar o Prémium de Azure Front Door antes del 30 de septiembre de 2027. Para más información, consulte Retirada de Azure CDN Estándar de Microsoft (clásico).

Azure CDN de Edgio se retirará el 15 de enero de 2025. Debe migrar la carga de trabajo a Azure Front Door antes de esta fecha para evitar interrupciones del servicio. Para más información, consulte Azure CDN de Edgio retirada P+F.

Este artículo le permite solucionar problemas con los puntos de conexión de Azure Content Delivery Network que devuelven códigos de estado de respuesta HTTP 404.

Si necesita más ayuda en cualquier momento con este artículo, puede ponerse en contacto con los expertos de Azure en los foros de MSDN Azure y de desbordamiento de pila. Como alternativa, también puede registrar un incidente de soporte técnico de Azure. Vaya al sitio de soporte técnico de Azure y seleccione Soporte técnico.

Síntoma

Ha creado un perfil de red de entrega de contenido y un punto de conexión, pero el contenido no parece estar disponible en la red de entrega de contenido. Los usuarios que intentan acceder a su contenido a través de la dirección URL de red de entrega de contenido reciben un código de estado HTTP 404.

Causa

Hay varias causas posibles, por nombrar algunas:

• El origen del archivo no es visible para la red de entrega de contenido.
• El punto de conexión está mal configurado, lo que hace que la red de entrega de contenido tenga un aspecto incorrecto.
• El host rechaza el encabezado de host de la red de entrega de contenido.
• El punto de conexión no ha tenido tiempo de propagarse a través de la red de entrega de contenido.

Pasos para solucionar problemas

Importante

Después de crear un punto de conexión de red de entrega de contenido, no estará disponible inmediatamente para su uso, ya que el registro tarda tiempo en propagarse a través de la red de entrega de contenido:

• En los perfiles Azure CDN Estándar de Microsoft, la propagación se completa normalmente en diez minutos.
• En los perfiles Azure CDN Estándar de Edgio y Azure CDN Premium de Edgio, la propagación se completa normalmente en 90 minutos.

Si realiza los pasos detallados en este documento y sigue obteniendo errores 404, espere unas horas para probar nuevamente antes de abrir una incidencia de soporte técnico.

Comprobación del archivo de origen

En primer lugar, compruebe que el archivo para almacenar en caché está disponible en el servidor de origen y es accesible públicamente en Internet. La forma más rápida de hacerlo es abrir un explorador en una sesión en modo privado o incógnito y buscar directamente el archivo. Escriba o pegue la dirección URL en el cuadro de dirección y vea si esto da como resultado el archivo esperado. Por ejemplo, supongamos que tiene un archivo en una cuenta de Azure Storage, accesible en HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt. Si el contenido de este archivo se puede cargar correctamente, pasa la prueba.

Advertencia

Aunque esta es la manera más rápida y sencilla de comprobar que el archivo está disponible públicamente, algunas configuraciones de red de su organización podrían dar la impresión de que este archivo está disponible públicamente cuando, en realidad, solo está visible para los usuarios de la red (incluso si está hospedado en Azure). Para asegurarse de que este no es el caso, pruebe el archivo con un explorador externo, por ejemplo, un dispositivo móvil que no esté conectado a la red de su organización o una máquina virtual en Azure.

Comprobación de la configuración de origen

Ahora que hemos comprobado que el archivo está disponible públicamente en Internet, compruebe la configuración de origen. En el Azure Portal, vaya al perfil de red de entrega de contenido y seleccione el punto de conexión que está solucionando. En la página resultante Punto de conexión, seleccione el origen.

Aparece la página Origen.

Tipo de origen y nombre del host

Compruebe que los valores de Tipo de origen y Nombre de host de origen sean correctos. En este ejemplo, HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt, la parte del nombre de host de la dirección URL es cdndocdemo.blob.core.windows.net, que es correcta. Dado que los orígenes de Azure Storage, Web App y Cloud Service usan un valor de lista desplegable para el campo nombre de host de origen, los ortografías incorrectas no son un problema. Sin embargo, si usa un origen personalizado, asegúrese de escribir correctamente el nombre de host.

Puertos HTTP y HTTPS

Compruebe sus puertos HTTP y HTTPS. En la mayoría de los casos, los puertos 80 y 443 son correctos y no se requiere ningún cambio. Sin embargo, si el servidor de origen está escuchando en un puerto diferente, este debe estar representado aquí. Si no está seguro, vea la dirección URL del archivo de origen. Las especificaciones de HTTP y HTTPS usan los puertos 80 y 443 como valores predeterminados. En la dirección URL de ejemplo, HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt, no se especifica un puerto, por lo que se supone que el valor predeterminado es 443 y la configuración es correcta.

Sin embargo, supongamos que la dirección URL para el archivo de origen que ha comprobado anteriormente es HTTP://www.contoso.com:8080/file.txt.. Observe la parte : 8080 al final del segmento de nombre de host. Ese número indica al explorador que use el puerto 8080 para conectarse al servidor web en www.contoso.com, por lo tanto, debe escribir 8080 en el campo Puerto HTTP. Es importante tener en cuenta que esta configuración de puerto solo afecta al puerto que usa el punto de conexión para recupera información del origen.

Comprobación de la configuración del punto de conexión

En la página Punto de conexión, seleccione el botón Configurar.

Aparece la página Configurar del punto de conexión de red de entrega de contenido.

Protocolos

En Protocolos, compruebe que está seleccionado el protocolo utilizado por los clientes. Como el mismo protocolo utilizado por el cliente es el que se usa para acceder al origen, es importante tener configurados correctamente los puertos de origen en la sección anterior. El punto de conexión de red de entrega de contenido solo escucha en los puertos HTTP y HTTPS predeterminados (80 y 443), independientemente de los puertos de origen.

Volvamos a nuestro ejemplo hipotético con HTTP://www.contoso.com:8080/file.txt.. Como recuerda, Contoso especificó 8080 como puerto HTTP, pero supongamos también que se especificó 44300 como puerto HTTPS. Si crearon un punto de conexión llamado contoso, el nombre de host de su punto de conexión de red de entrega de contenido sería contoso.azureedge.net. Una solicitud para HTTP://Contoso.azureedge.net/file.txt es una solicitud HTTP, por lo que el punto de conexión utilizará HTTP en el puerto 8080 para recuperar el archivo del origen. Una solicitud segura a través de HTTPS, HTTPS://Contoso.azureedge.net/file.txt, hará que el punto de conexión use HTTPS en el puerto 44300 al recuperar el archivo del origen.

Encabezado del host de origen

El encabezado de host de origen es el valor del encabezado del host que se envía al origen con cada solicitud. En la mayoría de los casos, este valor debe ser el mismo que el nombre de host de origen que se comprobó anteriormente. Un valor incorrecto en este campo normalmente no causa errores 404, pero puede provocar otros errores 4xx, dependiendo de lo que el origen espera.

Ruta de acceso de origen

Por último, debemos comprobar la ruta de acceso de origen. De manera predeterminada esta ruta de acceso está en blanco. Solo debe usar este campo si quiere restringir el ámbito de los recursos hospedados en el origen que desea que estén disponibles en la red de entrega de contenido.

En el punto de conexión de ejemplo, queremos que todos los recursos de la cuenta de almacenamiento estén disponibles, por lo que la ruta de acceso de origen se dejó en blanco. Por lo tanto, una solicitud a HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt da como resultado una conexión desde el punto de conexión a cdndocdemo.core.windows.net que solicita /publicblob/lorem.txt. De la misma forma, una solicitud para HTTPS://cdndocdemo.azureedge.net/donotcache/status.png genera que el punto de conexión solicite /donotcache/status.png del origen.

Pero, ¿qué ocurre si no desea usar la red de entrega de contenido para cada ruta de acceso del origen? Supongamos que solo quisiera exponer la ruta de acceso public blob. Si escribimos /publicblob en el campo Ruta de acceso de origen, el punto de conexión inserta /publicblob antes de realizar cada solicitud al origen. Por lo que la solicitud para HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt toma la parte de la solicitud de la dirección URL, /publicblob/lorem.txt, y anexa /publicblob al principio. El resultado es una solicitud a /publicblob/publicblob/lorem.txt desde el origen. Si no se puede resolver esa ruta de acceso en un archivo real, el origen devuelve un estado 404. La dirección URL correcta para recuperar lorem.txt en este ejemplo sería realmente HTTPS://cdndocdemo.azureedge.net/lorem.txt. No se incluye la ruta de acceso /publicblob, ya que la parte de la solicitud de la dirección URL es /lorem.txt y el punto de conexión agrega /publicblob, lo que da lugar a que /publicblob/lorem.txt sea la solicitud que se pasa al origen.