Edge Security Acceleration:Personnaliser le Host d'origine

Host d'origine ESA par défaut

L'en-tête de requête Host indique le nom de domaine du serveur sollicité. Lorsqu'un point de présence (POP) ESA demande des ressources à un serveur d'origine, le Host par défaut est déterminé selon les règles suivantes :

• Si la Record Value correspond à une adresse IPv4, une adresse IPv6, un nom de domaine, un Server Load Balancer ou un pool d'origines : le paramètre par défaut de Origin Host est Match Requested Domain Name. Le Host provenant de la requête client est alors utilisé comme Host d'origine.

• Si la Record Value est de type OSS/S3 Compatible : le paramètre par défaut de Origin Host est Match Origin's Domain Name. Le nom de domaine du serveur d'origine sert alors de Host d'origine.

Le serveur d'origine utilise le champ Host de la requête pour restituer les ressources du site correspondant, par exemple www.example.com. Lorsque plusieurs sites sont hébergés sur votre serveur d'origine (comme dans un scénario d'hébergement virtuel), le serveur valide le champ Host afin de fournir les ressources appropriées.

Hébergement virtuel

L'hébergement virtuel permet d'héberger plusieurs sites web sur un seul serveur web. Ce dernier distingue les sites grâce à différents noms de domaine ou noms d'hôte. Lorsqu'un client sollicite un nom de domaine ou d'hôte spécifique, le serveur dirige la requête vers le site virtuel correspondant pour délivrer le contenu adéquat.

server {
    listen      80;
    server_name example.org www.example.org;
    ...
}

server {
    listen      80;
    server_name example.net www.example.net;
    ...
}

server {
    listen      80;
    server_name example.com www.example.com;
    ...
}

Origine Function Compute (FC)

Si le nom de domaine accéléré ESA diffère du nom de domaine personnalisé associé à votre instance Function Compute (FC), les requêtes d'origine peuvent échouer avec une erreur DomainNameNotFound. Pour résoudre ce problème, créez une règle de Host d'origine :

• Définissez la condition de correspondance du nom d'hôte sur le nom de domaine accéléré ESA.

• Définissez le Origin Host sur le nom de domaine personnalisé réellement associé à votre instance FC.

Cette configuration garantit que l'instance FC route les requêtes entrantes vers la fonction appropriée en se basant sur l'en-tête Host.

Origine CNAME GA ou WAF

Si votre serveur d'origine est une adresse CNAME Global Accelerator (GA) ou Web Application Firewall (WAF) et que le service backend nécessite un en-tête Host spécifique pour identifier les requêtes, vous devez configurer explicitement le Origin Host et le Origin SNI dans la règle d'origine. Attribuez à ces deux valeurs le nom de domaine effectivement lié à l'instance GA ou WAF, et non le nom de domaine accéléré ESA ni l'adresse CNAME elle-même.

Origine OSS

ESA prend en charge les types de domaines Alibaba Cloud Object Storage Service (OSS) suivants comme origine :

• Endpoint public OSS (domaine réseau externe)

• Domaine d'accélération de transfert OSS

Les domaines de réseau interne OSS ne sont pas pris en charge. Si une erreur HostForbidden survient après l'activation d'ESA, l'origine est probablement configurée avec la valeur d'enregistrement CNAME d'un domaine personnalisé OSS plutôt qu'avec un domaine d'accès OSS valide. Mettez à jour l'origine pour utiliser l'endpoint public OSS ou le domaine d'accélération de transfert.

Origine multi-sites ou hébergement virtuel

Si votre serveur d'origine héberge plusieurs sites web (par exemple via un hébergement virtuel Nginx comme illustré ci-dessus), configurez manuellement le Origin Host et le Origin SNI pour assurer un routage correct vers le site virtuel approprié. En conservant le paramètre par défaut (suivre le Host de la requête client), les nœuds ESA risquent de retourner le contenu d'un site incorrect ou de générer une erreur 404.

Pourquoi l'accès au domaine accéléré redirige-t-il vers un autre domaine ou affiche-t-il un contenu inattendu ?

Ce problème peut survenir pour les raisons suivantes :

Redirection par le serveur d'origine

Si la barre d'adresse du navigateur bascule vers un autre domaine après l'accès au domaine accéléré (passage d'une URL boutique à une URL administrateur, par exemple), le serveur d'origine a probablement une redirection 301 HTTP-vers-HTTPS ou une redirection applicative configurée. Pour diagnostiquer le problème :

• Examinez et désactivez les redirections superflues sur le serveur d'origine.

• Dans la règle d'origine, configurez le Origin Host et le Origin SNI pour cibler le domaine d'origine correct.

Adresse du serveur d'origine configurée comme nom de domaine

Si l'adresse du serveur d'origine est configurée sous forme de nom de domaine (par exemple shop.example.com) au lieu d'une adresse IP, le serveur d'origine peut interpréter les requêtes entrantes comme des requêtes directes pour ce domaine et déclencher une redirection. Pour y remédier, configurez le serveur d'origine avec une adresse IP et utilisez le champ Origin Host pour spécifier le nom de domaine correspondant.

Désalignement entre le Host d'origine et le SNI

Si le nom de domaine accéléré ESA diffère du nom de domaine attendu par le serveur d'origine, configurez le Origin Host et le Origin SNI dans la règle d'origine afin qu'ils correspondent au nom de domaine effectivement lié au serveur d'origine. Après la mise à jour de la configuration, purgez le cache pour garantir la prise en compte des modifications.

Puis-je utiliser un autre domaine accéléré ESA ou un alias CDN comme serveur d'origine ?

L'accélération circulaire ou imbriquée n'est pas prise en charge

ESA ne permet pas d'utiliser un autre domaine accéléré ESA comme serveur d'origine. Une telle configuration entraîne des erreurs de résolution ou des boucles de requêtes infinies. Vous devez configurer l'adresse d'origine réelle située derrière le domaine accéléré, telle qu'un nom de domaine OSS ou une adresse IP de serveur.

Utilisation de DCDN ou CDN comme origine

ESA prend en charge le routage des requêtes d'origine via un alias DCDN ou CDN. Pour éviter une double mise en cache, nous vous recommandons de désactiver la mise en cache côté DCDN ou CDN et de laisser ESA gérer l'ensemble du cache.

Utilisation de Cloudflare R2 comme origine

Lorsque vous utilisez Cloudflare R2 comme origine, configurez l'adresse d'origine avec l'adresse d'accès direct du bucket R2 (par exemple xxx.r2.cloudflarestorage.com) plutôt qu'avec le domaine proxy Cloudflare. Cela évite le double proxy et réduit la latence.

Puis-je saisir une adresse IP dans le champ de domaine d'une règle d'origine ?

Non. Le champ de domaine d'une règle d'origine n'accepte pas les adresses IP. Les serveurs web tels que Nginx utilisent le nom de domaine présent dans l'en-tête Host pour identifier et router les requêtes vers le bon site virtuel. Saisir une adresse IP dans ce champ peut provoquer des échecs de routage.

Si vous devez router des requêtes vers une adresse IP spécifique, configurez cette adresse IP dans les paramètres du serveur d'origine et utilisez le champ Origin Host pour spécifier le nom de domaine correspondant.

Comment vérifier que les modifications de configuration d'origine ont pris effet et résoudre les problèmes liés aux fonctionnalités d'origine ?

Vérifier l'IP d'origine ou les changements de configuration

Après avoir mis à jour la configuration d'origine, accédez à votre site web et vérifiez que le contenu retourné provient bien du nouveau serveur d'origine. Consultez également les journaux d'accès du serveur d'origine pour confirmer que les requêtes proviennent des nœuds ESA.

Résoudre les défaillances de fonctionnalités d'origine (par exemple, changement de langue)

Si une fonctionnalité du site (telle que le changement de langue) cesse de fonctionner après l'activation d'ESA, suivez ces étapes :

1. Ajoutez une entrée hosts locale mappant l'adresse IP du serveur d'origine au domaine de test. Accédez au site via cette connexion directe, en contournant ESA, afin de déterminer si le problème provient du serveur d'origine lui-même.

2. Videz le cache du navigateur et réessayez.