Cloudflare peut tenir, sur un même domaine, le DNS, le cache, le filtrage, la répartition entre serveurs, le stockage des fichiers et la vidéo. Le piège est d'activer le proxy orange partout sans décider ce qui se cache, ce qui reste dynamique, et où partent les médias. Voici la chaîne que nous montons, et l'ordre dans lequel la configurer depuis le tableau de bord.
Ce que chaque brique fait
- DNS autoritaire, en anycast. Chaque nom est soit proxied (nuage orange : le trafic HTTP passe par Cloudflare), soit DNS only (nuage gris : Cloudflare ne fait que répondre à la requête DNS).
- CDN sert ce qui est en cache depuis le point de présence le plus proche. Le visiteur ne voit pas l'adresse du serveur d'origine.
- Load Balancing choisit un pool d'origines sain. En mode proxy, il travaille en HTTP. En mode DNS only, il se contente de renvoyer une adresse, avec un basculement plus lent.
- R2 est le stockage objet, avec une API compatible S3. Les fichiers publics sortent par un domaine du CDN, pas par le disque du VPS.
- Stream encode la vidéo, la découpe en HLS et DASH, et la livre depuis le réseau edge, avec un lecteur et des URL signées pour les contenus privés.
1. Le DNS et le nuage orange
On ajoute le domaine, on importe les enregistrements, on relit les MX, SPF, DKIM et TXT avant de changer les serveurs de noms chez le registrar. Le courrier ne doit pas être proxifié : un MX qui passerait par le proxy HTTP casse la réception.
Le site, lui, passe en orange. Cloudflare termine le TLS du visiteur, applique le cache et le WAF, puis rappelle l'origine en HTTPS. L'origine n'a plus besoin d'être joignable par le monde entier : on la limite aux plages IP de Cloudflare, ou on exige un en-tête secret que seul le proxy ajoute.
Le mode gris reste utile pour ce qui n'est pas de l'HTTP : un VPN, un serveur de jeu, parfois SSH si l'on assume d'en publier l'adresse. SSH public avec mot de passe est précisément le genre d'entrée qu'il ne faut pas laisser nue. On y revient dans l'article CrowdSec.
2. Le cache
Le gain se joue sur les règles de cache, pas sur le fait d'activer le proxy.
- Cache long sur les fichiers versionnés : CSS, JavaScript, images, polices.
- Pas de cache sur
/admin/, le compte, le panier, les webhooks et toute réponse qui dépend d'un cookie de session. Cache-Controlexplicite côté Django. Une consigne absente se fait interpréter, une consigne écrite se respecte.- Niveau de TLS moderne vers les visiteurs, et HTTPS strict vers l'origine, certificat vérifié.
Une page de compte mise en cache est servie au visiteur suivant. On le vérifie avec deux navigateurs avant d'annoncer la mise en production.
3. Le load balancer
Un load balancer est un nom DNS (app.exemple.com) qui distribue vers des pools. Un pool est un groupe d'origines. Un moniteur interroge chaque origine (souvent un HTTP 200 sur un chemin /health/) et retire celles qui échouent. Un pool de repli reçoit le trafic quand les pools par défaut sont tous malades.
La politique de routage dit comment choisir parmi les pools sains :
- Off : ordre de secours. Le premier pool sain prend tout.
- Aléatoire, avec des poids : on répartit, par exemple 70 % sur le pool principal et 30 % sur le second.
- Géo ou proximité : le visiteur va vers la région la plus proche.
- Latence dynamique : le pool dont le temps d'aller-retour est le plus bas.
En proxy orange, le visiteur ne voit jamais l'IP des origines. Le cache, le WAF et l'affinité de session (cookie) sont disponibles. En DNS only, Cloudflare renvoie une IP saine, mais cette IP reste publique, le basculement attend que les résolveurs respectent un TTL court, et il n'y a ni cache ni WAF sur ce nom. Pour un site web, on reste en orange.
L'affinité de session ne sert que si l'application garde un état local sur un nœud. Une application Django dont la session et le cache sont dans une base partagée n'en a pas besoin.
4. R2 pour les fichiers
On crée un bucket, par exemple media-prod. L'accès d'écriture passe par une clé API limitée à ce bucket, jamais par une clé de compte collée dans le dépôt. La lecture publique passe par un domaine personnalisé rattaché au bucket, du type cdn.exemple.com, donc par le CDN.
Django envoie les images, PDF et exports vers R2. Le HTML ne change que le domaine des URLs. Le disque du conteneur applicatif redevient petit, et une réinstallation du VPS n'emporte plus les médias.
5. Stream pour la vidéo
Un MP4 servi par Gunicorn ou par Nginx sature la bande passante et coupe la lecture dès que le réseau du visiteur change. Stream télécharge le fichier (depuis R2, par une URL, ou par envoi direct), l'encode en plusieurs débits, puis le sert en HLS et en DASH.
- Créer le jeton API Stream, séparé de la clé R2.
- Envoyer la vidéo, ou demander à Stream de la copier depuis l'URL du fichier dans R2.
- Attendre
readyToStream. L'encodage prend de quelques secondes à quelques minutes selon la durée. - Intégrer le lecteur avec l'identifiant de la vidéo.
- Signer les URL si la vidéo n'est pas publique. Un lien expiré ne se partage plus.
Le direct suit le même principe avec Stream Live : ingestion, enregistrement, lecture ensuite. Ce n'est pas le même produit que la visioconférence temps réel.
Ordre de mise en place
- Zone DNS, import des enregistrements, relecture du courrier, changement des serveurs de noms.
- Proxy orange sur le seul nom du site. Origine en HTTPS. Pare-feu d'origine limité à Cloudflare.
- Règles de cache, puis contrôle avec une page publique et une page de compte.
- Bucket R2 et domaine des médias. Bascule des URLs.
- Load balancer, moniteurs, pool de repli, politique de routage. On casse volontairement une origine pour voir le basculement.
- Stream, à part, dès qu'il y a de la vidéo.
- Lecture des analytiques : taux de cache, erreurs origine, santé des pools. L'ancien accès direct au serveur ne saute qu'après ça.
Ce qui ne se cache pas
- les réponses qui lisent un cookie de session ou un jeton ;
- les pages de paiement et les webhooks ;
- l'administration ;
- tout HTML personnalisé (nom, panier, solde).
Le HTML public d'un article, les images, les polices et les feuilles de style se cachent. C'est là que le temps de réponse baisse.
Sécurité minimale
- Origine joignable uniquement en HTTPS, certificat vérifié.
- Le port du site n'est pas ouvert au monde : seules les plages Cloudflare, ou un tunnel, y accèdent.
- Clés R2 et jetons API hors du dépôt Git, dans les variables d'environnement.
- WAF sur le nom proxifié. Les règles gérées couvrent les signatures courantes ; elles ne remplacent pas un correctif applicatif.
- Vidéos privées en URL signées, fichiers sensibles du bucket sans lecture anonyme.
Le détail des pools et des politiques est dans la documentation Load Balancing. R2 et Stream ont leurs guides : R2 et Stream. La configuration du domaine se fait dans le tableau de bord Cloudflare.
Akamasoft pose cette chaîne devant l'application : DNS, proxy, règles de cache, pools, bucket des médias et bibliothèque vidéo. Le serveur applicatif ne sert plus ni les fichiers statiques, ni la vidéo, ni le premier filtrage.
