Tous les produits
Search
Centre de documentation

CDN:Origin fetch FAQ

Dernière mise à jour :Aug 31, 2026

Cette rubrique répond aux questions d’ordre général sur la fonctionnalité de récupération depuis l’origine. Pour les problèmes techniques, consultez le guide de dépannage de la récupération depuis l’origine.

Comment vérifier que les en-têtes de réponse tels que Access-Control-Allow-Origin sont correctement configurés sur mon serveur d'origine ?

La méthode de vérification dépend du type de votre serveur d'origine :

  • Alibaba Cloud ECS comme serveur d'origine : Vérifiez que les en-têtes de réponse CORS, tels que Access-Control-Allow-Origin, sont bien configurés dans les fichiers de configuration du serveur web. Pour Apache, examinez la directive Header set Access-Control-Allow-Origin dans .htaccess ou httpd.conf. Pour Nginx, vérifiez la directive add_header Access-Control-Allow-Origin dans le bloc server. Redémarrez le serveur web après toute modification pour appliquer les changements.

  • Alibaba Cloud OSS comme serveur d'origine : Connectez-vous à la console OSS, cliquez sur le bucket cible dans la liste des buckets, puis choisissez Data Security > Cross-Origin Resource Sharing (CORS) dans le volet de navigation de gauche. Vérifiez que le champ Sources d'une règle CORS inclut le nom de domaine à l'origine de la requête cross-origin (ce champ détermine la valeur de l'en-tête de réponse Access-Control-Allow-Origin), et assurez-vous que les méthodes de requête autorisées ainsi que les autres paramètres sont corrects. Pour plus d'informations sur la configuration CORS d'OSS, consultez CORS.

Une fois la configuration terminée, accédez à la ressource et utilisez l'onglet Network des outils de développement de votre navigateur pour vérifier la présence de l'en-tête Access-Control-Allow-Origin dans la réponse. Vous pouvez également exécuter la commande curl -I pour afficher directement les en-têtes de réponse.

Si je force globalement Content-Type à video/mp4, les autres ressources seront-elles affectées ? Comment configurer cela avec précision ?

Si vous définissez globalement Content-Type sur video/mp4 pour un nom de domaine entier, tous les types de ressources hébergés sous ce domaine seront affectés, y compris les images et les fichiers CSS et JS. Pour éviter d'impacter d'autres fichiers, appliquez les méthodes suivantes pour une configuration précise :

  1. Correspondance par chemin : Lorsque vous ajoutez une règle sur la page Modify incoming response headers, associez la Rule Condition à une règle qui correspond aux chemins vidéo (par exemple, /vod-cd20e3/ ou le suffixe .mp4), afin que la configuration ne s'applique qu'aux chemins vidéo. Pour ajouter et gérer les conditions de règle, consultez Rules engine.

  2. Utilisation de la correspondance conditionnelle : La console CDN vous permet de configurer les en-têtes de réponse en fonction du suffixe de la requête ou des conditions d'en-tête. Vous pouvez limiter la configuration de sorte que Content-Type: video/mp4 soit renvoyé uniquement pour les fichiers .mp4.

Grâce à ces méthodes, vous modifiez Content-Type uniquement pour les fichiers vidéo, sans interférer avec d'autres types de ressources comme les images.

La fonctionnalité Modify incoming response headers prend-elle en charge les paramètres uniquement pour les fichiers JS ? Le paramètre affecte-t-il d'autres types de fichiers ?

Oui. Vous pouvez utiliser Modify incoming response headers pour définir Content-Type sur application/javascript uniquement pour les fichiers JS, sans affecter les autres types de fichiers.

Méthode : Lors de la configuration de la règle, utilisez une condition de règle pour cibler le suffixe .js afin que la règle de modification de l'en-tête de réponse ne s'applique qu'aux fichiers JS. Cela garantit que le type MIME des fichiers JS est correct, sans interférer avec d'autres types de ressources tels que les fichiers CSS et les images.

La configuration Modify incoming response headers peut-elle être utilisée pour vérifier les fichiers manquants ou l'état de synchronisation dans le CDN ?

Non. Modify incoming response headers sert à corriger ou à forcer le type MIME de certains types de fichiers, afin de résoudre les problèmes de mise en cache causés par le renvoi initial d'un type incorrect par le serveur d'origine. Cette fonctionnalité ne détecte pas les fichiers manquants dans le CDN et ne détermine pas l'état de synchronisation des fichiers.

Pour vérifier si un fichier existe dans le CDN ou si son état de synchronisation est anormal, utilisez les méthodes suivantes :

  • Utilisez la fonctionnalité Refresh and Prefetch dans la console CDN pour actualiser (actualisation d'URL) le fichier cible, ce qui force le nœud CDN à récupérer à nouveau le fichier depuis l'origine. Accédez ensuite à nouveau au fichier et déterminez sa présence sur l'origine en fonction du code d'état renvoyé. Par exemple, une réponse 404 indique que le fichier n'existe pas sur l'origine.

  • Vérifiez que le fichier côté origine est accessible normalement.

  • Consultez les journaux CDN pour vérifier que les codes d'état de récupération depuis l'origine sont normaux.