:Add a website configuration

Périmètre

• Une instance Anti-DDoS Proxy (Chinese Mainland) ou Anti-DDoS Proxy (Outside Chinese Mainland) a été achetée. Pour plus d'informations, consultez Acheter une instance Anti-DDoS Proxy.

• Pour ajouter votre service de site web à une instance Anti-DDoS Proxy (Chinese Mainland), le nom de domaine du site doit déjà disposer d'un dépôt ICP. Pour plus d'informations, consultez Dépôt ICP.

  Remarque

  Les sites web ajoutés aux instances Anti-DDoS Proxy (Outside Chinese Mainland) ne sont pas soumis aux exigences de dépôt ICP.

Procédure

1. Connectez-vous à la page Website Config dans la console Anti-DDoS Proxy.

2. Dans la barre de navigation supérieure, sélectionnez la région de votre instance.

   • Anti-DDoS Proxy (Chinese Mainland) : choisissez la région Chinese Mainland.

   • Anti-DDoS Proxy (Outside Chinese Mainland) : choisissez la région Outside Chinese Mainland.

3. Sur la page Website Config, cliquez sur Add Website.

   Remarque

   Vous pouvez également cliquer sur Batch Import en bas de la page pour importer plusieurs configurations de site web simultanément. Les configurations de site web sont importées au format XML. Pour plus d'informations sur le format de fichier, consultez Autres opérations.

4. Configurez les informations Website Config, puis cliquez sur Next.

   Configuration de base

   • Function Plan : sélectionnez le plan de fonctionnalités de l'instance Anti-DDoS Proxy que vous souhaitez associer. Options disponibles : Standard et Enhanced.

     Remarque

     Placez le pointeur sur Function Plan (l'icône ) pour consulter les différences de fonctionnalités entre le plan de fonctionnalités Standard et le plan Enhanced. Pour plus d'informations, consultez la rubrique Différences entre les plans de fonctionnalités standard et améliorés.

   • Instance : sélectionnez l'instance Anti-DDoS Proxy à associer.

     Important

     Un nom de domaine de site web peut être associé à un maximum de 8 instances Anti-DDoS Proxy. Ces instances doivent utiliser le même Function Plan.

   • Websites : saisissez le nom de domaine du site web que vous souhaitez protéger. Les noms de domaine exacts (par exemple www.example.com) et les noms de domaine génériques (par exemple *.example.com) sont pris en charge.

     Remarque

     • Si un nom de domaine générique et un nom de domaine exact sont tous deux configurés (par exemple *.aliyundoc.com et www.aliyundoc.com), Anti-DDoS Proxy accorde la priorité aux règles de transfert et aux politiques de protection configurées pour le nom de domaine exact (c'est-à-dire www.aliyundoc.com).

     • Si vous saisissez un nom de domaine de premier niveau, seul ce dernier est protégé. Les sous-domaines, tels que les noms de domaine de deuxième niveau, ne sont pas protégés. Pour protéger un nom de domaine de deuxième niveau, saisissez le nom de domaine de deuxième niveau ou un nom de domaine générique.

     • Seuls les noms de domaine sont pris en charge. Vous ne pouvez pas saisir l'adresse IP d'un site web.

   • Protocol Type : sélectionnez les protocoles pris en charge par votre site web.

     • HTTP / HTTPS : protocoles de base pour les sites web.

       Remarque

       Pour obtenir des informations sur les configurations HTTPS, consultez la description de l'onglet HTTPS configuration.

     • Websocket / Websockets : protocoles de communication en temps réel. Si vous sélectionnez l'un de ces protocoles, HTTP ou HTTPS est automatiquement sélectionné.

   • Server Address : définissez l'adresse du serveur backend (serveur d'origine) vers lequel Anti-DDoS Proxy effectue une requête lors d'une récupération back-to-origin.

     • Origin IP Address : saisissez les adresses IP publiques du serveur d'origine. Vous pouvez saisir plusieurs adresses IP séparées par des virgules (,). Exemples :

       • Serveur d'origine sur Alibaba Cloud : dans la plupart des cas, saisissez l'adresse IP publique de l'instance ECS d'origine. Si une instance SLB est déployée devant l'instance ECS, saisissez l'adresse IP publique de l'instance SLB.

       • Serveur d'origine dans un centre de données hors Alibaba Cloud ou chez un autre fournisseur cloud : utilisez la commande ping domain name pour interroger l'adresse IP publique vers laquelle le nom de domaine résout, puis saisissez l'adresse IP publique obtenue.

     • Origin Domain Name :

       • Scénarios : cette option s'applique lorsqu'un autre service proxy est déployé entre le serveur d'origine et Anti-DDoS Proxy. Exemples :

         • Si le proxy frontal est WAF, vous pouvez saisir l'adresse CNAME de WAF. Pour plus d'informations, consultez la rubrique Protéger un service de site web à l'aide d'Anti-DDoS Proxy et de WAF.

         • Si vous définissez Origin Domain Name sur le endpoint public par défaut d'un bucket Object Storage Service (OSS), un nom de domaine personnalisé doit déjà être lié à ce bucket. Pour plus d'informations, consultez la rubrique Lier un nom de domaine personnalisé.

       • Limites : vous pouvez configurer jusqu'à 10 noms de domaine d'origine. Séparez plusieurs noms de domaine par des sauts de ligne.

   • Server Port : définissez le port sur lequel le serveur d'origine écoute les requêtes de service de site web.

     • HTTP/Websocket : le port par défaut est 80.

     • HTTPS/Websockets : le port par défaut est 443.

     • Port de serveur personnalisé :

       • Plusieurs ports : vous pouvez spécifier plusieurs ports séparés par des virgules (,). Pour l'ensemble des services de site web ajoutés à une instance Anti-DDoS Proxy pour la protection, le nombre total de ports personnalisés (y compris les ports personnalisés pour différents protocoles) ne peut pas dépasser 10.

       • Plage de ports (HTTP/HTTPS) : 80 à 65535

   Configuration HTTPS

   Si vous sélectionnez HTTPS comme protocole pris en charge par votre site web, effectuez la configuration suivante.

   • Configurer le certificat : Pour activer HTTPS, vous devez configurer un certificat SSL correspondant au nom de domaine du site web.

     • Upload : Saisissez un Certificate Name, puis copiez et collez le contenu textuel du fichier de certificat et du fichier de clé privée dans les champs Certificate File et Private Key respectivement.

       Remarque

       • Pour les certificats aux format PEM, CER ou CRT, vous pouvez ouvrir directement le fichier de certificat dans un éditeur de texte et copier son contenu. Pour les certificats dans d'autres formats, tels que PFX et P7B, convertissez d'abord le fichier de certificat au format PEM. Vous pouvez ensuite ouvrir le fichier dans un éditeur de texte et copier le contenu textuel. Pour plus d'informations sur la conversion des formats de certificat, consultez Convertir les formats de certificat ou Convertir les certificats au format PEM.

       • Si le certificat HTTPS comporte plusieurs fichiers de certificat, tels qu'une chaîne de certificats, vous devez fusionner le contenu textuel de la chaîne de certificats et coller le contenu fusionné dans le champ Certificate File.

     • Select Existing Certificate : Vous pouvez sélectionner directement le certificat s'il a été demandé via Alibaba Cloud Certificate Management Service (Original SSL Certificate) ou si vous l'avez téléchargé vers Certificate Management Service.

   • Configurez les TLS Security Settings :

     Remarque

     Pour plus d'informations, consultez Personnaliser la politique de sécurité TLS d'un certificat HTTPS de serveur.

     • TLS Versions for SSL Certificate : Sélectionnez les versions TLS prises en charge par le certificat HTTPS standard international.

       • TLS 1.0 and later. This setting provides the best compatibility but low security. : Prend en charge TLS 1.0, TLS 1.1 et TLS 1.2.

       • TLS 1.1 and later. This setting provides good compatibility and medium security. : Prend en charge TLS 1.1 et TLS 1.2.

       • TLS 1.2 and later. This setting provides good compatibility and high security level. : Prend en charge TLS 1.2.

       • Enable TLS 1.3 Support : Prend en charge TLS 1.3.

     • Cipher Suites for SSL Certificate : Sélectionnez les suites de chiffrement prises en charge par le certificat HTTPS standard international, ou choisissez des suites de chiffrement personnalisées. Placez le pointeur sur l'icône d'une option de suite de chiffrement pour afficher les suites de chiffrement incluses dans cette option.

   • Mutual Authentication :

     • Issued by Alibaba Cloud : Dans la liste déroulante A default CA certificate is required., sélectionnez un certificat CA émis par Alibaba Cloud Certificate Management Service (Original SSL Certificate).

     • Not Issued by Alibaba Cloud :

       • Téléchargez d'abord le certificat CA auto-signé vers Certificate Management Service (Original SSL Certificate). Pour plus d'informations, consultez Télécharger le référentiel de certificats (télécharger un certificat).

       • Dans la liste déroulante A default CA certificate is required., sélectionnez le certificat CA auto-signé que vous avez téléchargé.

   • Enable OCSP Stapling : OCSP signifie Online Certificate Status Protocol. Il envoie une requête à l'autorité de certification (CA) qui a émis le certificat du serveur pour vérifier si le certificat a été révoqué. Lors d'une négociation TLS avec le serveur, le client doit obtenir à la fois le certificat et la réponse OCSP correspondante.

     Important

     Les réponses OCSP sont signées numériquement par la CA et ne peuvent pas être falsifiées. Par conséquent, l'activation de cette fonctionnalité n'introduit aucun risque de sécurité supplémentaire.

     • Disabled (default) : Le client initie une requête OCSP auprès de la CA elle-même lors de la demande de négociation TLS pour vérifier si le certificat est révoqué. Ce processus bloque la connexion et peut entraîner des retards de chargement des pages lorsque le réseau est de mauvaise qualité.

     • Enabled : Anti-DDoS Proxy effectue la requête OCSP et met en cache le résultat pendant 3 600 secondes. Lorsqu'un client initie une demande de négociation TLS vers le serveur, Anti-DDoS Proxy envoie la réponse OCSP mise en cache au client conjointement avec la chaîne de certificats. Cela évite le blocage causé par les requêtes côté client et améliore les performances HTTPS.

   • SM Certificate : Seules les instances Anti-DDoS Proxy (Chinese Mainland) prennent en charge le téléchargement de certificats HTTPS basés sur SM. Seul l'algorithme SM2 est pris en charge.

     • Allow Access Only from SM Certificate-based Clients : Désactivé par défaut.

       • Activé : Traite uniquement les requêtes provenant de clients disposant de certificats SM installés.

         Remarque

         Après avoir activé cette fonctionnalité, les paramètres de suite de chiffrement TLS, d'authentification mutuelle et d'agrafage OCSP (Online Certificate Status Protocol) pour le certificat HTTPS internationalement accepté ne s'appliquent pas.

       • Désactivé : Traite les requêtes provenant de clients disposant soit de certificats SM, soit de certificats internationalement acceptés installés.

     • SM Certificate : Vous devez télécharger le certificat vers Certificate Management Service avant de pouvoir le sélectionner ici.

     • SM Cipher Suites for HTTPS Support : Les suites de chiffrement suivantes sont activées par défaut et ne peuvent pas être modifiées.

       • ECC-SM2-SM4-CBC-SM3

       • ECC-SM2-SM4-GCM-SM3

       • ECDHE-SM2-SM4-CBC-SM3

       • ECDHE-SM2-SM4-GCM-SM3

   Paramètres avancés

   • Enable HTTPS Redirection : ce paramètre s'applique lorsqu'un site web prend en charge à la fois HTTP et HTTPS. Une fois cette option activée, toutes les requêtes HTTP sont converties de force en requêtes HTTPS et redirigées vers le port 443 par défaut.

     Important

     • Vous ne pouvez activer ce paramètre que si les protocoles HTTP et HTTPS sont tous deux sélectionnés et que le protocole Websocket n'est pas sélectionné.

     • Si vous accédez à un site web via un port HTTP non standard (autre que le port 80) et activez la redirection HTTPS forcée, les requêtes d'accès sont redirigées vers le port HTTPS 443 par défaut.

   • HTTP/2 Listener : si vous activez cette option, les clients utilisant HTTP/2,0 peuvent accéder à Anti-DDoS Proxy. Toutefois, Anti-DDoS Proxy continue d'utiliser HTTP/1,1 pour récupérer le contenu depuis le serveur d'origine. Les spécifications HTTP/2,0 sont les suivantes :

     • Spécifications de base :

       • Délai d'inactivité après la fermeture d'une connexion (http2_idle_timeout) : 120 s

       • Nombre maximal de requêtes par connexion (http2_max_requests) : 1 000

       • Nombre maximal de flux simultanés par connexion (http2_max_concurrent_streams) : 4

       • Taille maximale de la liste complète des en-têtes de requête après décompression HPACK (http2_max_header_size) : 256 K

       • Taille maximale d'un champ d'en-tête de requête compressé par HPACK (http2_max_field_size) : 64 K

     • Spécifications configurables : prend en charge Upper Limit for HTTP/2 Streams, qui correspond au nombre maximal de flux simultanés autorisés entre le client et Anti-DDoS Proxy.

   • Set Forward Connection Timeout : délai d'inactivité de la connexion TCP persistante établie entre le client et Anti-DDoS Proxy. Il s'agit du temps d'attente maximal entre deux requêtes client.

     Remarque

     Si aucune nouvelle requête n'arrive dans le délai spécifié, Anti-DDoS Proxy ferme la connexion afin de libérer les ressources.

5. Configurez Forwarding Settings, puis cliquez sur Next.

   Back-to-origin settings

   • Back-to-origin Scheduling Algorithm : si vous configurez plusieurs Origin IP Addresses ou Origin Domain Names, vous pouvez modifier l'algorithme d'équilibrage de charge back-to-origin ou définir des pondérations pour différents serveurs afin de déterminer la répartition du trafic entre les serveurs d'origine.

     Solution	Scénario	Fonctionnement
     Round-robin (par défaut)	Plusieurs serveurs d'origine nécessitant une charge équilibrée.	Toutes les requêtes sont distribuées à tour de rôle à toutes les adresses de serveur. Par défaut, toutes les adresses de serveur ont le même poids. Vous pouvez modifier les pondérations des serveurs. Un poids plus élevé indique une probabilité plus grande de recevoir des requêtes.
     IP hash	Services nécessitant la cohérence des sessions utilisateur. Dans des cas extrêmes, la charge peut être déséquilibrée.	Les requêtes provenant de la même adresse IP client sont toujours dirigées vers le même serveur d'origine afin de garantir la cohérence des sessions. Vous pouvez définir des pondérations pour les serveurs tout en utilisant le hachage IP pour distribuer le trafic en fonction de la capacité de traitement des serveurs et donner la priorité aux serveurs les plus performants.
     Least time	Services très sensibles à la vitesse d'accès et à la latence de réponse, tels que les jeux en ligne et les transactions en ligne.	Utilise la résolution DNS intelligente et l'algorithme back-to-origin Least time pour garantir la latence la plus courte sur l'ensemble du chemin, du nœud de protection au serveur d'origine.

   • Retry Back-to-origin Requests : nombre de sondes de vérification d'état utilisées pour vérifier la disponibilité du serveur d'origine pour la redirection de nom de domaine. La valeur par défaut est 3. Le mécanisme de nouvelle tentative back-to-origin fonctionne comme suit :

     1. La nouvelle tentative back-to-origin est déclenchée uniquement lorsque le trafic de service accède à un nœud Anti-DDoS Proxy. Le nœud relance la requête back-to-origin lorsqu'il détecte que le serveur d'origine du nom de domaine est indisponible.

     2. Si le serveur d'origine reste inaccessible après le nombre maximal de tentatives, il passe à un état silencieux. Pendant cet état, aucun trafic n'est transféré vers le serveur d'origine et aucune sonde n'est envoyée.

     3. Une fois l'état silencieux terminé, la nouvelle tentative back-to-origin est de nouveau déclenchée en fonction du trafic de service. Si la tentative réussit, le serveur d'origine est réactivé.

   • Traffic Marking :

     • Request Header Forwarding Configuration : Anti-DDoS Proxy prend en charge la transmission des en-têtes de requête. Vous pouvez ajouter ou modifier des en-têtes de requête HTTP lors du transfert des requêtes vers votre serveur d'origine. Cela permet d'identifier et de marquer le trafic qui transite par Anti-DDoS Proxy.

       • Insert X-Client-IP to Get Originating IP Address : transmet l'adresse IP d'origine du client.

       • Insert X-True-IP to Forward Client IP : transmet l'adresse IP utilisée par le client pour établir la connexion.

       • Insert Web-Server-Type to Get Service Type : généralement ajouté par le premier proxy. Indique au serveur backend quel serveur web ou proxy frontend a traité la requête.

       • Insert WL-Proxy-Client-IP to Get Connection IP : même fonction que X-Client-IP. En-tête spécifique à Oracle WebLogic Server.

       • X-Forwarded-Proto (Listener Protocol) : protocole utilisé entre le client et le premier proxy.

     • Marqueurs de trafic

       • Marqueurs par défaut

         Remarque

         • JA3 Fingerprint, JA4 Fingerprint, Client TLS Fingerprint et HTTP/2 Fingerprint nécessitent l'assistance de votre gestionnaire de compte pour être configurés.

         • Si votre service utilise des champs personnalisés au lieu des marqueurs par défaut, consultez Custom Header ci-dessous. Après configuration, votre serveur d'origine analyse ce champ à partir des requêtes transférées par Anti-DDoS Proxy. Pour des exemples d'analyse, consultez Obtenir l'adresse IP source réelle après la configuration d'Anti-DDoS Proxy.

         • Originating Port : nom du champ d'en-tête pour le port d'origine du client dans l'en-tête HTTP. Généralement enregistré dans le champ X-Forwarded-ClientSrcPort.

         • Originating IP Address : nom du champ d'en-tête pour l'adresse IP d'origine du client dans l'en-tête HTTP. Généralement enregistré dans le champ X-Forwarded-For.

         • JA3 Fingerprint : nom du champ d'en-tête HTTP contenant le hachage MD5 de l'empreinte JA3 du client. Le champ par défaut est ssl_client_ja3_fingerprinting_md5.

         • JA4 Fingerprint : nom du champ d'en-tête HTTP contenant le hachage MD5 de l'empreinte JA4 du client. Le champ par défaut est ssl_client_ja4_fingerprinting_md5.

         • Client TLS Fingerprint : nom du champ d'en-tête HTTP contenant le hachage MD5 de l'empreinte TLS du client. Le champ par défaut est ssl_client_tls_fingerprinting_md5.

         • HTTP/2 Fingerprint : nom du champ d'en-tête HTTP pour la valeur de hachage MD5 générée à partir de l'empreinte HTTP/2,0 du client. Généralement enregistré dans le champ http2_client_fingerprint_md5.

       • Custom Header : ajoutez un en-tête HTTP personnalisé (incluant le nom du champ et la valeur) pour marquer les requêtes transitant par Anti-DDoS Proxy. Lorsqu'Anti-DDoS Proxy transfère le trafic du site web, il ajoute la valeur de champ configurée aux requêtes envoyées à votre serveur d'origine. Cela aide votre service backend à analyser et suivre le trafic.

         • Restrictions de nommage : pour éviter d'écraser les champs d'en-tête de requête d'origine, n'utilisez pas les noms de champs réservés ou courants suivants pour votre en-tête personnalisé :

           • Champs par défaut d'Anti-DDoS Proxy :

             • X-Forwarded-ClientSrcPort : utilisé par défaut pour obtenir le port client pour l'accès au moteur de couche 7.

             • X-Forwarded-ProxyPort : utilisé par défaut pour obtenir le port d'écoute pour l'accès au moteur de couche 7.

             • X-Forwarded-For : utilisé par défaut pour obtenir l'adresse IP client pour l'accès au moteur de couche 7.

             • ssl_client_ja3_fingerprinting_md5 : utilisé par défaut pour récupérer le hachage MD5 de l'empreinte JA3 du client.

             • ssl_client_ja4_fingerprinting_md5 : utilisé par défaut pour récupérer le hachage MD5 de l'empreinte JA4 du client.

             • ssl_client_tls_fingerprinting_md5 : utilisé par défaut pour récupérer le hachage MD5 de l'empreinte TLS du client.

             • http2_client_fingerprint_md5 : utilisé par défaut pour obtenir la valeur de hachage MD5 de l'empreinte HTTP/2.0 du client.

           • Champs HTTP standard : tels que host, user-agent, connection et upgrade.

           • Champs de proxy courants : tels que x-real-ip, x-true-ip, x-client-ip, web-server-type, wl-proxy-client-ip, eagleeye-rpcid, eagleeye-traceid, x-forwarded-cluster et x-forwarded-proto.

         • Limite de quantité : vous pouvez ajouter jusqu'à cinq étiquettes d'en-tête personnalisées.

         • Recommandations de configuration :

           • Utilisez d'abord les marqueurs par défaut.

           • Vérifiez la configuration des champs d'en-tête dans l'environnement de préproduction avant de l'appliquer à l'environnement de production.

           • Nous vous recommandons de limiter les valeurs des champs à 100 caractères maximum afin d'éviter d'affecter les performances de transfert.

   • CNAME Reuse : sélectionnez si vous souhaitez activer la réutilisation CNAME. Une fois la réutilisation CNAME activée, vous pouvez ajouter plusieurs noms de domaine hébergés sur le même serveur à Anti-DDoS Proxy en pointant leurs enregistrements DNS vers la même adresse CNAME Anti-DDoS Proxy. Vous n'avez pas besoin d'ajouter une configuration de site web distincte pour chaque nom de domaine. Pour plus d'informations, consultez Réutilisation CNAME.

     Important

     Seul Anti-DDoS Proxy (hors Chine continentale) prend en charge ce paramètre.

   Other settings

   • Enable HTTP Redirection of Back-to-origin Requests : si votre site web ne prend pas en charge les requêtes back-to-origin HTTPS, vous devez activer ce paramètre. Une fois activé, toutes les requêtes HTTPS sont transférées vers le serveur d'origine via HTTP, toutes les requêtes Websockets sont transférées via Websocket et le port back-to-origin par défaut est 80.

     Remarque

     Si vous accédez à un site web via un port HTTPS non standard (un port autre que 443) et activez les requêtes back-to-origin HTTP, les requêtes d'accès sont redirigées vers le port HTTP 80 du serveur d'origine par défaut.

   • HTTP/2.0 Origin : une fois les requêtes back-to-origin HTTP/2,0 activées, Anti-DDoS Proxy transfère les requêtes vers le serveur d'origine via HTTP/2,0.

     Avertissement

     • Pour configurer cette fonctionnalité, contactez votre gestionnaire de compte.

     • Si votre serveur d'origine ne prend pas en charge HTTP/2,0, ne configurez pas cette fonctionnalité. Sinon, le site web sera inaccessible.

   • Cookie Settings

     • Delivery Status : activé par défaut. Anti-DDoS Proxy définit un cookie sur le client (tel qu'un navigateur) pour distinguer et compter les différents clients ou pour obtenir des informations sur l'empreinte du client. Pour plus de détails, consultez Configurer la protection contre les inondations HTTP.

       Important

       Si votre application rencontre des plantages de connexion ou une perte de session après avoir été ajoutée à Anti-DDoS Proxy, vous pouvez essayer de désactiver ce commutateur. Notez que certaines fonctionnalités de protection contre les inondations HTTP ne seront plus effectives après sa désactivation.

     • Secure Attribute : désactivé par défaut. Si vous activez ce paramètre, les cookies sont envoyés uniquement via des connexions HTTPS et non via des connexions HTTP. Cela permet de protéger les cookies contre le vol par des attaquants.

       Remarque

       Si votre service de site web prend uniquement en charge les connexions HTTPS, nous vous recommandons d'activer ce paramètre.

   • Configure New Connection Timeout Period : durée pendant laquelle Anti-DDoS Proxy attend l'établissement d'une connexion avec le serveur d'origine.

     Remarque

     Si la connexion n'est pas établie dans ce délai, la tentative est considérée comme échouée.

   • Configure Read Connection Timeout Period : durée maximale pendant laquelle Anti-DDoS Proxy attend que le serveur d'origine renvoie les données de réponse après l'établissement d'une connexion et l'envoi d'une requête de lecture au serveur d'origine.

   • Configure Write Connection Timeout Period : durée pendant laquelle Anti-DDoS Proxy attend après l'envoi des données depuis Anti-DDoS Proxy et avant que le serveur d'origine ne commence à traiter les données.

     Remarque

     Si Anti-DDoS Proxy ne parvient pas à envoyer toutes les données au serveur d'origine, ou si le serveur d'origine ne commence pas à traiter les données dans ce délai, la tentative est considérée comme échouée.

   • Back-to-origin Persistent Connections : une connexion TCP entre un serveur de cache et un serveur d'origine reste active pendant une certaine période au lieu d'être fermée après chaque requête, ce qui gaspille des ressources. Activez Back-to-origin Persistent Connections pour réduire le temps et les ressources consommés par l'établissement de connexions et améliorer l'efficacité et la vitesse du traitement des requêtes.

     • Requests Reusing Persistent Connections : nombre de requêtes HTTP pouvant être envoyées via une seule connexion TCP qu'Anti-DDoS Proxy établit avec le serveur d'origine. Cela réduit la latence et la consommation de ressources causées par l'établissement et la fermeture fréquents des connexions.

       Remarque

       Définissez cette valeur inférieure ou égale au nombre de requêtes par connexion persistante configuré sur le serveur d'origine backend, tel qu'une instance WAF ou SLB. Cela empêche l'inaccessibilité du service due à la terminaison de la connexion.

     • Timeout Period of Idle Persistent Connections : durée maximale pendant laquelle une connexion TCP persistante établie par Anti-DDoS Proxy vers le serveur d'origine reste ouverte dans le pool de connexions d'Anti-DDoS Proxy après qu'aucune donnée n'a été transférée. Si aucune nouvelle requête n'arrive pendant cette période, la connexion est fermée pour libérer les ressources système.

       Remarque

       Définissez cette valeur inférieure ou égale au délai d'expiration configuré sur le serveur d'origine backend, tel qu'une instance WAF ou SLB. Cela empêche l'inaccessibilité du service due à la terminaison de la connexion.

Vérifier et mettre en production

Une fois la configuration du site web terminée, suivez cette liste de contrôle pour vérifier la configuration et mettre en production. Cela vous aidera à éviter les interruptions de service.

• Opérations principales (obligatoires)

  1. Autoriser les adresses IP back-to-origin : dans les politiques de sécurité du serveur d'origine (telles que les pare-feu et les groupes de sécurité), autorisez les blocs CIDR back-to-origin d'Anti-DDoS Proxy en les ajoutant à la liste d'autorisation. Cela empêche le trafic qu'Anti-DDoS Proxy transfère vers le serveur d'origine d'être bloqué par erreur. Pour plus d'informations, consultez Ajouter des adresses IP back-to-origin à la liste d'autorisation.

  2. Vérifier la configuration localement : avant de modifier l'enregistrement DNS, modifiez le fichier hosts local pour vérifier que la configuration de transfert d'Anti-DDoS Proxy fonctionne comme prévu. Cela vous aidera à éviter les interruptions de service. Pour plus d'informations, consultez Valider localement votre configuration de transfert.

  3. Modifier l'enregistrement DNS : après la réussite de la vérification locale, modifiez l'enregistrement DNS du nom de domaine du site web pour le faire pointer vers l'adresse CNAME fournie par Anti-DDoS Proxy. Cela bascule votre trafic de service vers Anti-DDoS Proxy pour la protection. Pour plus d'informations, consultez Pointer un nom de domaine vers Anti-DDoS Proxy.

• Opérations facultatives

  • Modifier l'adresse IP d'origine : si votre serveur d'origine est une instance ECS Alibaba Cloud et que l'adresse IP d'origine est accidentellement exposée, nous vous recommandons de modifier l'adresse IP publique de l'instance ECS. Cela empêche les attaquants de contourner Anti-DDoS Proxy pour attaquer directement le serveur d'origine. Pour plus d'informations, consultez Adresses IP publiques statiques.

  • Configurer des politiques d'atténuation DDoS : en plus des politiques de protection par défaut d'Anti-DDoS Proxy (Anti-DDoS Global Mitigation Policy, Intelligent Protection et Frequency Control), vous pouvez activer davantage de fonctionnalités de protection dans l'onglet Protection for Website Services selon vos besoins. Pour plus d'informations, consultez Protection DDoS des services de site web.

    Important

    L'activation d'une politique de protection contre les inondations HTTP peut définir des cookies sur les clients. Pour plus de détails, consultez Insertion de cookie.

  • Configurer des alertes Cloud Monitor : définissez des règles d'alerte pour les métriques de service courantes d'Anti-DDoS Proxy, telles que le trafic IP et les connexions, ainsi que pour les événements d'attaque, tels que les événements de filtrage blackhole et de nettoyage. Des alertes sont envoyées rapidement en cas d'anomalie sur Anti-DDoS Proxy, ce qui vous aide à réagir rapidement aux événements anormaux. Pour plus d'informations, consultez Alertes Cloud Monitor.

  • Configurer le service de journalisation complète : activez le service de journalisation pour collecter et stocker les journaux d'accès au site web (180 jours par défaut) à des fins d'analyse commerciale et pour répondre aux exigences de conformité en matière de protection classifiée. Pour plus d'informations, consultez Tutoriel.

Quotas et limites

• Un nom de domaine de site web peut être associé à un maximum de 8 instances Anti-DDoS Proxy.

• Pour l'ensemble des configurations de site web sous une instance Anti-DDoS Proxy, le nombre total de ports personnalisés (autres que 80 et 443) ne peut pas dépasser 10.

• Vous pouvez ajouter jusqu'à 5 étiquettes Custom Header.

Références

FAQ

• Pourquoi des erreurs 502 ou 504 se produisent-elles lors de l'accès au site web après la fin de la configuration ?

  Cela est généralement dû à un échec back-to-origin. Dépannez dans l'ordre suivant :

  1. Vérifiez le pare-feu ou le groupe de sécurité du serveur d'origine : assurez-vous que les blocs CIDR back-to-origin d'Anti-DDoS Proxy ont été ajoutés à la liste d'autorisation.

  2. Vérifiez le paramètre « HTTP back-to-origin » : si votre serveur d'origine prend uniquement en charge HTTP (écoute sur le port 80) mais que vous avez configuré HTTPS dans Anti-DDoS Proxy sans activer « HTTP back-to-origin », la requête back-to-origin échoue.

  3. Vérifiez l'état du serveur d'origine : assurez-vous que l'Origin IP Address saisie est correcte et que le serveur d'origine fonctionne correctement.

• Pourquoi le navigateur signale-t-il une erreur de certificat après l'activation de HTTPS ?

  Vérifiez les éléments suivants :

  1. Le certificat ne correspond pas au nom de domaine : assurez-vous que le certificat couvre les noms de domaine que vous avez ajoutés, y compris www et le nom de domaine racine. Par exemple, un certificat émis pour www.example.com ne peut pas être utilisé pour example.com sauf s'il s'agit d'un certificat wildcard ou multi-domaine.

  2. La chaîne de certificats est incomplète : lors du téléchargement d'un certificat, assurez-vous de concaténer et de télécharger la chaîne de certificats complète (certificat serveur + certificat CA intermédiaire).

  3. Le certificat a expiré : vérifiez si le certificat que vous avez téléchargé est toujours valide.

• Comment vérifier que le trafic du site web transite par Anti-DDoS Proxy ?

  1. Requête DNS : dans la ligne de commande, exécutez ping <your domain name> ou dig <your domain name> et vérifiez si l'adresse résolue est l'adresse CNAME d'Anti-DDoS Proxy ou l'adresse IP vers laquelle elle pointe.

  2. Rapports de la console : sur la page des rapports de la console Anti-DDoS Proxy, vérifiez si les données de trafic entrant sont affichées.

  3. Journaux du serveur d'origine : vérifiez les journaux d'accès web de votre serveur d'origine pour confirmer si les adresses IP source des requêtes appartiennent aux blocs CIDR back-to-origin d'Anti-DDoS Proxy.

• Pourquoi mes journaux d'application n'enregistrent-ils que l'adresse IP d'Anti-DDoS Proxy, et comment obtenir l'adresse IP réelle du visiteur ?

  Ceci est normal. En tant que proxy, Anti-DDoS Proxy accède à votre serveur d'origine depuis ses adresses IP back-to-origin. Pour obtenir l'adresse IP réelle du visiteur, configurez votre serveur web (tel que Nginx ou Apache) pour extraire l'adresse IP de l'en-tête de requête X-Forwarded-For. Pour plus d'informations sur la configuration, consultez Obtenir les adresses IP d'origine derrière Anti-DDoS Proxy.

• Les visiteurs peuvent-ils toujours accéder à un site web ajouté à Anti-DDoS Proxy après que l'adresse IP du serveur d'origine soit entrée dans un état blackhole ?

  Pour les sites web disposant déjà d'une configuration de site web sur la page Website Config, le trafic d'accès utilise le transfert back-to-origin basé sur un proxy : le trafic atteint d'abord Anti-DDoS Proxy, qui le transfère ensuite au serveur d'origine. Cela fonctionne comme un proxy inverse. Par conséquent, lorsque l'adresse IP du serveur d'origine entre dans un état blackhole, le trafic d'accès au site web est toujours transféré au serveur d'origine via Anti-DDoS Proxy, et le serveur d'origine répond et renvoie les pages. Cela atténue dans une certaine mesure l'impact du filtrage blackhole sur votre service. De plus, après avoir ajouté votre site web à Anti-DDoS Proxy, vous pouvez demander la désactivation du filtrage blackhole.

• Comment vérifier l'efficacité de la protection d'Anti-DDoS Proxy ?

  Remarque : le filtrage blackhole est un mécanisme de protection que le système déclenche automatiquement lorsqu'une attaque DDoS volumétrique dépasse le seuil d'atténuation. Vous ne pouvez pas le déclencher manuellement. Pour vérifier l'efficacité du nettoyage et du transfert du trafic d'Anti-DDoS Proxy, utilisez les méthodes suivantes :

  1. Ajoutez un service de test (pas un service de production) à Anti-DDoS Proxy. N'utilisez pas de service de production pour les tests.

  2. Utilisez un outil de test de charge pour simuler du trafic DDoS et observer le comportement de nettoyage et de transfert du trafic d'Anti-DDoS Proxy.

  3. Dans la console Anti-DDoS Proxy, consultez les données de protection et les résultats de nettoyage du trafic sur la page Reports.

  4. Vérifiez les journaux d'accès web du serveur d'origine pour confirmer que les adresses IP source des requêtes appartiennent aux blocs CIDR back-to-origin d'Anti-DDoS Proxy.