Loading...

Aide CDN.com.tr

Connexion à l'origine : l'IP réelle du visiteur, verrouiller votre origine, WebSocket et délais d'attente

Les serveurs de périphérie transmettent l'adresse IP du visiteur dans l'en-tête X-CDN-Client-IP. N'ouvrez votre origine qu'au CDN, à l'aide d'un en-tête secret que vous ajoutez à chaque règle. Configurez WebSocket et les requêtes longues par règle.

Connexion à l'origine : l'IP réelle du visiteur, verrouiller votre origine, WebSocket et délais d'attente

Les serveurs de périphérie transmettent l'adresse IP du visiteur dans l'en-tête X-CDN-Client-IP. N'ouvrez votre origine qu'au CDN, à l'aide d'un en-tête secret que vous ajoutez à chaque règle. Configurez WebSocket et les requêtes longues par règle.

Cas d'usage

Une équipe exploite une application web avec authentification sur son propre serveur et place le CDN et le WAF devant elle. Elle veut l'IP réelle du visiteur dans ses journaux, rejeter les requêtes qui ne passent pas par le CDN, et garder les connexions WebSocket fonctionnelles.

Workflow

  1. Faites en sorte que votre application lise l'IP réelle du visiteur depuis l'en-tête X-CDN-Client-IP.
  2. Générez une valeur longue et aléatoire. Écrivez la même ligne dans le champ En-têtes envoyés à votre origine de chaque règle de diffusion de votre compte, par exemple X-CDN-Auth <valeur>.
  3. Une fois l'en-tête actif dans toutes les règles et votre domaine pointé vers le CDN, rejetez sur votre origine les requêtes qui ne portent pas cet en-tête.
  4. Pour les chemins qui utilisent WebSocket, créez une règle séparée et activez Autoriser les connexions WebSocket. Pour les requêtes longues, augmentez la valeur Délai de réponse de l'origine (secondes).
  5. Si votre API utilise PUT, PATCH ou DELETE, ajoutez ces méthodes à la liste WAF : Méthodes HTTP autorisées.

Verifications

  • L'IP réelle du visiteur arrive dans l'en-tête X-CDN-Client-IP. Il contient une seule valeur et le serveur de périphérie le réécrit à chaque requête ; un en-tête du même nom envoyé par le visiteur n'est pas utilisé. La valeur peut aussi être une adresse IPv6.
  • Les serveurs de périphérie envoient aussi X-Real-IP et X-Forwarded-For. Si vous utilisez X-Forwarded-For, prenez la valeur la plus à droite, et non la première ; le visiteur peut écrire les valeurs situées à gauche.
  • En-têtes envoyés à votre origine se configurent par règle : un en-tête par ligne, au format Header-Name value. Quand vous ajoutez une nouvelle règle, ajoutez-y aussi l'en-tête secret ; sinon votre origine rejette les requêtes de cette règle.
  • Faites de la valeur de l'en-tête secret une valeur aléatoire d'au moins 32 caractères, lettres et chiffres uniquement. Sur les règles qui se connectent à votre origine en HTTPS, l'en-tête circule chiffré.
  • Fiez-vous à l'en-tête secret plutôt qu'à un verrouillage de votre origine par simple liste d'IP. Nous vous communiquons sur demande les adresses actuelles des serveurs de périphérie liés à votre compte.
  • Sur une règle où Autoriser les connexions WebSocket est activé, les connexions atteignent votre origine et restent ouvertes tant que des données circulent ; les réponses sur ce chemin ne sont pas mises en cache. WebSocket ne peut pas être activé dans une règle qui optimise les images ; créez donc une règle séparée pour le chemin WebSocket.
  • Le délai de réponse de l'origine est de 60 secondes par défaut : si votre origine n'envoie aucune donnée pendant 60 secondes, la requête se termine par une erreur 504 et une connexion WebSocket inactive se ferme. Vous pouvez régler cette valeur par règle entre 1 et 3 600 secondes. Tant que des données circulent, il n'y a pas de limite sur la durée totale d'une connexion.
  • Sur le domaine de vos applications Managed Container, WebSocket est activé par défaut et le délai est de 300 secondes, sauf si la règle définit une autre valeur.
  • Avec le WAF activé, GET, HEAD, POST et OPTIONS sont autorisés par défaut. Le challenge JavaScript ne s'applique qu'aux requêtes de page provenant de navigateurs et n'affecte pas les requêtes d'API.

Questions frequentes

Comment vérifier l'en-tête secret dans Apache ou nginx ?

Dans Apache, ajoutez les lignes RewriteEngine On, RewriteCond %{HTTP:X-CDN-Auth} !=<valeur> et RewriteRule ^ - [F] tout en haut du fichier .htaccess. Dans nginx, ajoutez if ($http_x_cdn_auth != "<valeur>") { return 403; } dans le bloc server. Activez la vérification en dernier : l'en-tête doit d'abord être actif dans toutes les règles et votre domaine doit pointer vers le CDN.

WebSocket est-il pris en charge ?

Oui. Créez une règle pour le chemin qui utilise WebSocket et activez Autoriser les connexions WebSocket. La connexion atteint votre origine et reste ouverte tant que des données circulent ; aucune mise en cache n'est utilisée sur ce chemin.

Combien de temps une requête peut-elle rester ouverte ?

Tant que des données circulent, il n'y a pas de limite sur la durée totale. La limite porte sur le temps d'attente de l'edge sans circulation de données : 60 secondes par défaut. Vous pouvez l'augmenter jusqu'à 3 600 secondes dans le champ Délai de réponse de l'origine (secondes) de la règle.

Où puis-je lire l'IP réelle du visiteur ?

Dans l'en-tête X-CDN-Client-IP. Le serveur de périphérie écrit lui-même cet en-tête à chaque requête et n'utilise pas un en-tête du même nom envoyé par le visiteur. Si vous utilisez X-Forwarded-For, prenez la valeur la plus à droite.

Pages associees

Gérer les enregistrements DNS

Ajoutez, mettez à jour, supprimez, importez, exportez et déplacez les enregistrements éligibles vers le DNS cloud.

HTTP/3 et IPv6 sur l’edge

Depuis septembre 2026, l’edge CDN.com.tr sert chaque hostname en HTTP/3 (QUIC) et en IPv6, en plus de HTTP/2 et IPv4. Les navigateurs basculent d’eux-mêmes ; il n’y a aucun réglage par compte et votre origine peut rester en IPv4 seul.