Todos los productos
Search
Centro de documentos

CDN:Configurar el intercambio de recursos de origen cruzado

Última actualización: Sep 11, 2026

Después de agregar su servicio a Alibaba Cloud CDN, puede habilitar el acceso de origen cruzado si configura los encabezados de respuesta HTTP en los POP.

¿Qué es el intercambio de recursos de origen cruzado?

El intercambio de recursos de origen cruzado (CORS) es un mecanismo estándar que permite a una página web acceder a recursos de un origen distinto al propio (dominio, protocolo o puerto). Este mecanismo proporciona una forma segura de habilitar las transferencias de datos entre orígenes. Para obtener más información, consulte Cross-Origin Resource Sharing (CORS).

Nota

De forma predeterminada, CDN no habilita el intercambio de recursos de origen cruzado (CORS). Sin esta configuración, los navegadores aplican la política del mismo origen y bloquean las solicitudes de origen cruzado, lo que impide que otros sitios web carguen sus recursos.

¿Por qué configurar el intercambio de recursos de origen cruzado?

Debido a las restricciones de seguridad, los navegadores suelen aplicar la política del mismo origen. Esta política restringe las solicitudes para cargar y acceder a recursos de distintos dominios, subdominios, protocolos o puertos. Por ejemplo, example.com no puede acceder a los recursos de example.org. Al configurar el intercambio de recursos de origen cruzado (CORS), usted establece los encabezados de respuesta correspondientes en el servidor CDNDCDN. Si una solicitud incluye encabezados que cumplen con las reglas permitidas, el servidor devuelve los encabezados de respuesta HTTP correspondientes. Esto permite cargar y acceder a los recursos de origen cruzado.

Cómo funciona

CORS configurado en el servidor de origen

image

Con CORS configurado en CDN

image

Notas de uso

  • Si utiliza un bucket de OSS como servidor de origen, la configuración de CORS en la consola CDNDCDN anula la configuración de CORS en la consola de OSS. Para obtener más información sobre cómo configurar CORS en la consola de OSS, consulte Set CORS rules.

  • Si utiliza un servidor local o una instancia de ECS como servidor de origen, se recomienda separar el contenido estático del dinámico. Además, utilice CDNDCDN para acelerar la entrega de archivos estáticos. La función de CORS configurada en la consola CDNDCDN se aplica únicamente a los archivos estáticos.

Habilitar el intercambio de recursos de origen cruzado

  1. Inicie sesión en la consola de CDN.

  2. En el panel de navegación izquierdo, haga clic en Domain Names.

  3. En la página Domains, busque el dominio que desea gestionar y haga clic en Actions dentro de la columna Manage.

  4. Haga clic en Cache, seleccione la pestaña Modify Outgoing Response Header y establezca los orígenes y métodos permitidos para las solicitudes de origen cruzado.

    • Establecer el origen para las solicitudes de origen cruzado

      Haga clic en Customize, configure los parámetros según la siguiente tabla y luego haga clic en OK.

      Parámetro

      Descripción

      Ejemplo

      Operation

      Establezca este parámetro en Add para habilitar la función de validación de CORS.

      Add

      Response Header

      Debe establecer Access-Control-Allow-Origin para usar la función de validación de origen cruzado.

      Access-Control-Allow-Origin

      Header Value

      Si la validación de CORS está deshabilitada: Solo puede especificar un comodín o un único origen.

      • Comodín *: Permite que cualquier origen acceda al recurso.

      • Origen único: Permite acceder a los recursos únicamente desde un origen específico (nombre de dominio).

      Si la validación de CORS está habilitada: Puede especificar un comodín, un origen único, varios orígenes o un dominio con comodín.

      • Comodín *: Permite que cualquier origen acceda al recurso.

      • Origen único: Permite acceder a los recursos únicamente desde un origen específico (nombre de dominio).

      • Varios orígenes especificados: Configure varios orígenes específicos (nombres de dominio) separados por una coma , para permitirles el acceso al recurso.

        Importante

        Cuando especifique varios orígenes, debe separarlos con comas (,). Si utiliza puntos y comas (;) en su lugar, la configuración de CORS no surtirá efecto. La consola seguirá mostrando la configuración como exitosa, pero CDN tratará toda la cadena separada por puntos y comas como un solo origen. Este origen no coincidirá con ningún dominio individual de la solicitud, por lo que CORS no funcionará.

      • Dominio con comodín: Especifique un dominio con comodín para permitir el acceso desde todos los orígenes que coincidan con el patrón.

      • *

      • http://www.aliyun.com

      • https://aliyun.com,http://www.aliyun.com

      • http://*.aliyun.com

      Allow Duplicates

      • Sí: Se conservan los encabezados del servidor de origen y el nuevo encabezado con el mismo nombre también se agrega a la respuesta.

      • No: El nuevo encabezado reemplaza cualquier encabezado del servidor de origen que tenga el mismo nombre.

      Importante

      Las configuraciones de Allow Duplicates y CORS Validation son mutuamente excluyentes. Si establece Allow Duplicates en Yes, la validación de CORS se deshabilita.

      No

      CORS

      • CORS solo se puede configurar cuando Operation se establece en Add y Response Header se establece en "Access-Control-Allow-Origin".

      • CORS se puede establecer en Disable o Enable. El valor predeterminado es Disable.

        • Disable: Los POP de CDN no validan el encabezado Origin en las solicitudes entrantes y siempre devuelven el valor configurado de Access-Control-Allow-Origin.

        • Enable: Los POP de CDN validan las solicitudes de origen cruzado según las siguientes reglas y responden con el valor de Access-Control-Allow-Origin en consecuencia.

          • Response Header: Si Response Header se establece en , el POP siempre devuelve Access-Control-Allow-Origin:, sin importar si la solicitud del usuario contiene un encabezado Origin o cuál sea su valor.

          • Response Header: Response Header se establece en uno o más orígenes específicos, separados por comas (,).

            • Si el valor del encabezado Origin en la solicitud del usuario coincide exactamente con uno de los orígenes configurados, el POP responde con ese origen como valor del encabezado Access-Control-Allow-Origin.

            • Si no se encuentra ninguna coincidencia, el POP no agrega el encabezado de CORS a la respuesta.

          • Response Header: Si Response Header se establece en un dominio con comodín, el POP comprueba si el encabezado Origin de la solicitud coincide con el patrón del comodín.

        • Si establece Enable en Header Value y el nombre de dominio en el campo Header Value contiene un guion (-), debe escaparlo y reemplazar - por %-. Ejemplo:

          • Valor original del encabezado: http://doc.aliyun-example.com.

          • Valor del encabezado escapado: http://doc.aliyun%-example.com.

      Enable

    • Establecer los métodos para las solicitudes de origen cruzado

      Haga clic en Customize, configure los parámetros según la siguiente tabla y luego haga clic en OK.

      Parámetro

      Descripción

      Ejemplo

      Operation

      Establezca este parámetro en Add.

      Add

      Response Header

      Debe establecerse en Access-Control-Allow-Methods

      Access-Control-Allow-Methods

      Header Value

      Es compatible con los métodos de solicitud GET, POST, and PUT. Si necesita agregar GET, POST, and PUT al mismo tiempo, sepárelos con una coma ,.

      GET

      Allow Duplicates

      • Sí: Se conservan los encabezados del servidor de origen y el nuevo encabezado con el mismo nombre también se agrega a la respuesta.

      • No: El nuevo encabezado reemplaza cualquier encabezado del servidor de origen que tenga el mismo nombre.

      No

Ejemplos de configuración

Ejemplo 1

Si el valor del encabezado de respuesta para CORS se establece en uno o más orígenes específicos separados por comas (,):

  • Si el valor del encabezado Origin en la solicitud del usuario coincide exactamente con uno de los orígenes especificados, el POP de CDNDCDN responde con el encabezado de CORS correspondiente.

  • Si no se encuentra ninguna coincidencia exacta, el encabezado de CORS no se incluye en la respuesta.

En CDN/DCDN, establezca: Access-Control-Allow-Origin: http://example.com,https://aliyundoc.com.

  • El encabezado Origin de la solicitud del usuario es http://example.com, y el punto de presencia (POP) de CDNDCDN responde con Access-Control-Allow-Origin: http://example.com.

  • El encabezado Origin de la solicitud del usuario es https://aliyundoc.com, y el nodo de CDNDCDN responde con Access-Control-Allow-Origin: https://aliyundoc.com.

  • El nodo de CDNDCDN no responderá a una solicitud de usuario con el encabezado Origin http://aliyundoc.com (debido a una discrepancia de protocolo: la solicitud del usuario usa HTTP, mientras que CDNDCDN está configurado para HTTPS).

  • Si el encabezado Origin de una solicitud es http://aliyun.com, el POP de CDNDCDN no responderá (discrepancia de dominio).

Ejemplo 2

Si el valor del encabezado de respuesta para CORS se establece en un dominio con comodín, el POP comprueba si el valor de Origin en el encabezado de la solicitud coincide con el patrón del comodín.

En CDN/DCDN, establezca: Access-Control-Allow-Origin: http://*.aliyundoc.com.

  • La solicitud del usuario contiene el encabezado Origin http://demo.aliyundoc.com, y el POP de CDNDCDN responde con Access-Control-Allow-Origin: http://demo.aliyundoc.com.

  • Si el encabezado Origin de una solicitud es http://demo.example.com, el POP de CDNDCDN no responderá porque el nombre de dominio no coincide.

  • El nodo de CDNDCDN no responde a una solicitud de usuario con el encabezado Origin https://demo.aliyundoc.com porque la solicitud usa el protocolo HTTPS, pero CDNDCDN está configurado con el protocolo HTTP.

Comprobar que la configuración entre dominios sea efectiva

  1. El nuevo encabezado de respuesta entre dominios no se aplica automáticamente a los recursos almacenados previamente en la caché, ya que CDN almacena en caché la respuesta HTTP completa. Para aplicar la nueva configuración de Access-Control-Allow-Origin, debe purgar los recursos correspondientes de la caché de CDN. De lo contrario, los usuarios seguirán recibiendo respuestas de la caché antigua que no incluyen el encabezado.

  2. Use curl para enviar una solicitud GET con un encabezado Origin específico y compruebe el encabezado de respuesta en la salida detallada: curl -svo /dev/null https://accelerated.domain.name/resource/path -H 'origin:https://your-site.example.com'

  3. Compruebe el encabezado Access-Control-Allow-Origin en la respuesta. Si el valor del encabezado es * o coincide con el Origin de la solicitud, la configuración es efectiva.

Notas de uso y límites

Límites de configuración de dominios con comodín

Después de habilitar la validación de CORS, solo puede configurar un único dominio con comodín o varios dominios exactos (sin comodines) separados por comas. No puede separar directamente varios dominios con comodín mediante comas (como https://*.example.com,https://*.example.org).

Diferencias entre archivos de fuentes y archivos de video

Los archivos de fuentes (como .ttf y .woff) siempre están sujetos a la validación obligatoria del encabezado de respuesta de CORS por parte del navegador, sin importar cómo se carguen. Los archivos de video (como MP4 y WebM) que se cargan mediante la etiqueta video no están sujetos a restricciones de CORS de forma predeterminada, a menos que se agregue explícitamente el atributo crossorigin. Por lo tanto, incluso si los videos y las fuentes se alojan en el mismo dominio, acceder a los videos normalmente no genera errores de CORS, pero acceder a los archivos de fuentes sí. Esto lo determinan las especificaciones de los navegadores.

Configuración de CORS cuando CDN acelera OSS

Si desea conservar la configuración de CORS del bucket de OSS de origen, asegúrese de que la primera solicitud incluya un encabezado Origin. De esta manera, CDN puede obtener datos del origen y almacenar en caché el encabezado de respuesta Access-Control-Allow-Origin que devuelve OSS. Sin embargo, el mecanismo de caché puede causar problemas de origen cruzado en solicitudes posteriores que no incluyan un encabezado Origin o que incluyan uno distinto.

Práctica recomendada: Agregue los encabezados de respuesta relacionados con CORS mediante la función Configure an outgoing response header en Cache Settings de la consola de CDN, en lugar de depender de la conservación automática.

Cuando varios dominios de CDN están asociados con el mismo bucket de OSS, no es posible configurar la regla de CORS una sola vez en OSS y dejar que CDN la herede automáticamente. Dado que los POP de CDN almacenan en caché los encabezados de respuesta y este comportamiento depende de si la primera solicitud incluye un encabezado Origin, debe configurar las reglas de CORS por separado para cada dominio de CDN en la consola de CDN.

Manejar respuestas 403 en solicitudes preflight OPTIONS

Cuando Alibaba Cloud CDN acelera OSS y un navegador envía una solicitud preflight OPTIONS, CDN devuelve 403 de forma predeterminada. Puede usar una política personalizada de EdgeScript para interceptar las solicitudes OPTIONS y devolver 204 directamente, de modo que las solicitudes preflight no se rechacen.

  1. Inicie sesión en la consola de Alibaba Cloud CDN y vaya a Domain Management.

  2. Seleccione el nombre de dominio acelerado de destino.

  3. En la página de configuración del dominio, haga clic en EdgeScript custom policy.

  4. En la pestaña staging environment, haga clic en Add rule y agregue la siguiente regla:

    if eq($request_method, 'OPTIONS') { exit(204) }
  5. Establezca Priority en 0 y guarde la regla. Después de comprobar en el staging environment que la solicitud OPTIONS devuelve 204, publique la regla en el production environment.

Nota

Las cadenas de EdgeScript deben usar comillas simples. Las comillas dobles no son compatibles.

Para saber cómo solucionar los casos en los que los errores de CORS persisten después de configurar Access-Control-Allow-Origin, consulte Cache troubleshooting.