Comment configurer un proxy inverse Cloudflare (tutoriel)

Un proxy inverse Cloudflare se place devant votre propre serveur web : lorsque vous définissez un enregistrement DNS sur Proxied, les requêtes des visiteurs arrivent d’abord sur le réseau de périphérie (edge) de Cloudflare, qui les transmet ensuite à votre origine. Ce tutoriel présente les étapes exactes pour transformer Cloudflare en proxy inverse pour un site que vous hébergez, des enregistrements DNS proxifiés et des modes SSL/TLS à la mise en cache, aux règles d’origine, aux tests avec curl et aux erreurs 522 et 525 les plus courantes.

Pour comprendre le principe général et la différence avec un proxy direct, consultez notre explication sur proxy inverse vs proxy direct. Ici, nous restons ciblés et ne couvrons que les spécificités de Cloudflare.

DataImpulse est un fournisseur de proxies éthiques proposant plus de 90 millions d’adresses IP résidentielles, mobiles et de datacenter dans 195 pays. Il propose un paiement à l’usage à partir de 1 dollar par Go, avec un trafic sans expiration. Ces proxies sont adaptés au web scraping, à la vérification des publicités, à la surveillance des prix, aux études de marché et à la gestion de plusieurs comptes.

De quoi avez-vous besoin avant de commencer ?

Vous avez besoin d’un domaine, d’un compte Cloudflare et d’un serveur web avec une IP publique qui héberge déjà votre site. Un proxy inverse est un serveur qui reçoit les requêtes des clients et les transmet à un ou plusieurs serveurs d’origine, Cloudflare assume ce rôle à son edge dès que votre domaine utilise les serveurs de noms de Cloudflare.

Pour suivre la configuration, rassemblez d’abord ces éléments :

• Une origine active : un site accessible via une adresse IP publique (par exemple 203.0.113.10) en HTTP ou HTTPS.
• Les serveurs de noms de Cloudflare : votre bureau d’enregistrement doit pointer vers les deux serveurs de noms que Cloudflare attribue lors de l’ajout du site.
• Un certificat TLS sur l’origine : un certificat valide (Let’s Encrypt ou un Cloudflare Origin Certificate gratuit) afin d’utiliser un mode SSL sécurisé.

Il est utile de visualiser le flux du trafic. Le parcours d’une requête via le proxy inverse Cloudflare suit cinq étapes : DNS -> edge -> cache -> WAF -> origine. Une requête est résolue vers une IP de l’edge Cloudflare, inspectée et, si nécessaire, servie depuis le cache. Elle passe ensuite par le Web Application Firewall et n’atteint votre origine qu’en dernier lieu. Identifier l’étape où elle se trouve facilite grandement les corrections ultérieures.

Comment configurer un proxy inverse Cloudflare étape par étape ?

Ajoutez votre site à Cloudflare, définissez l’enregistrement DNS sur Proxied et choisissez un mode SSL strict. Le nuage orange sur un enregistrement DNS est l’interrupteur qui transforme Cloudflare en proxy inverse pour ce nom d’hôte ; un nuage gris signifie DNS seul et contourne entièrement l’edge.

Faites pointer le DNS vers votre origine et activez le nuage orange. Dans l’onglet DNS, créez des enregistrements A (ou AAAA) pour le domaine racine et www qui pointent vers l’IP de votre origine, avec le statut de proxy défini sur Proxied :

Type   Name   Content        Proxy status
A      @      203.0.113.10   Proxied (orange cloud)
A      www    203.0.113.10   Proxied (orange cloud)

Choisissez un mode de chiffrement SSL/TLS. Dans SSL/TLS, le mode contrôle la manière dont Cloudflare communique avec votre origine. Utilisez Full (strict) dès que l’origine dispose d’un certificat valide :

SSL/TLS encryption mode
  Off            no HTTPS, do not use
  Flexible       browser-to-Cloudflare only, origin unencrypted (avoid)
  Full           encrypts to origin, accepts any certificate
  Full (strict)  encrypts to origin, requires a valid certificate

Ajoutez une règle de cache ou d’origine. Les règles vous permettent de contrôler ce que l’edge met en cache ou comment il atteint l’origine. Une Cache Rule simple marque un chemin statique comme pouvant être mis en cache afin que Cloudflare le serve sans solliciter votre serveur :

# Rules > Caching > Create rule
When incoming requests match:
  (http.request.uri.path contains "/static/")
Then:
  Cache eligibility = Eligible for cache
  Edge TTL = 1 day

Les Origin Rules permettent de remplacer l’en-tête host ou le port de connexion de Cloudflare, ce qui est utile lorsque votre backend écoute sur un port non standard. Une fois ces réglages enregistrés, Cloudflare agit comme un proxy inverse devant votre origine.

Comment vérifier que le proxy inverse fonctionne ?

Envoyez une requête à votre domaine et confirmez que la réponse passe bien par Cloudflare. La vérification la plus rapide est une requête HEAD avec curl, en vérifiant la présence des en-têtes server et cf-ray ajoutés par Cloudflare :

curl -I https://example.com

# Expected headers when proxied:
#   server: cloudflare
#   cf-ray: 8a1b2c3d4e5f6789-FRA
#   cf-cache-status: HIT | MISS | DYNAMIC

Si vous voyez server: cloudflare et une valeur cf-ray, le trafic transite bien par l’edge. Un cf-cache-status à HIT indique qu’une règle de cache sert le contenu depuis Cloudflare plutôt que depuis votre origine. Pour confirmer que le DNS se résout vers une IP de l’edge plutôt que vers votre origine brute, exécutez dig example.com +short et vérifiez que l’adresse renvoyée appartient à une plage Cloudflare, et non à 203.0.113.10.

Comment résoudre les erreurs 522 et 525 ?

La plupart des échecs du proxy inverse Cloudflare se produisent côté origine et correspondent à une étape précise du chemin de requête. Une erreur 5xx affichant une page Cloudflare signifie que l’edge a atteint l’étape de votre origine, mais que celle-ci n’a pas répondu correctement.

• Erreur 522 (connection timed out) : Cloudflare n’a pas pu ouvrir de connexion TCP vers l’origine. Vérifiez que votre pare-feu autorise les plages d’IP de Cloudflare, que le serveur web fonctionne bien et que l’enregistrement DNS contient la bonne IP d’origine.
• Erreur 525 (SSL handshake failed) : l’origine a refusé la négociation TLS. Cela signifie généralement que Full (strict) est activé mais que le certificat de l’origine est absent, expiré ou auto-signé ; installez un certificat valide ou un Cloudflare Origin Certificate.
• Boucles de redirection : le mode SSL Flexible combiné à un serveur qui force HTTPS crée une boucle infinie ; passez à Full ou Full (strict).

Comme le chemin de requête est DNS -> edge -> cache -> WAF -> origine, une erreur 522 ou 525 pointe toujours vers le dernier saut, commencez donc le débogage par l’origine et son certificat.

Quel type de proxy correspond réellement à votre besoin ?

Utilisez un proxy inverse Cloudflare pour protéger et accélérer un serveur que vous possédez ; utilisez un proxy direct lorsque vous devez envoyer des requêtes sortantes depuis de nombreuses IP différentes. Ce sont des outils opposés, et les confondre est l’erreur la plus courante chez les lecteurs de ce sujet.

Un proxy inverse se place devant votre serveur et le représente auprès d’internet. Un proxy direct se place devant les clients et les représente vis-à-vis du reste d’internet. Le tableau ci-dessous illustre clairement le sens du trafic :

Voici un point essentiel pour bien comprendre cette comparaison : un proxy inverse Cloudflare se place devant votre site et ne permet pas de faire passer des requêtes sortantes par de nombreuses IP différentes. Si votre tâche consiste à collecter des données, exécuter des tests localisés ou vérifier des publicités depuis différents emplacements, c’est un proxy direct qu’il vous faut, un outil différent. Pour cela, DataImpulse propose des proxies résidentiels et des proxies datacenter rotatifs dans 195 pays. Cloudflare n’est pas un produit DataImpulse : ces deux solutions répondent à des besoins opposés.

Utilisez cette matrice de décision :

• Utilisez un proxy inverse Cloudflare lorsque vous hébergez un site web ou une API et souhaitez du cache, du TLS, une protection DDoS et masquer l’IP de l’origine.
• Vous avez en réalité besoin d’un proxy direct lorsque vous devez émettre des requêtes sortantes depuis des IP variées pour le scraping, la surveillance des prix ou la vérification publicitaire, comme expliqué dans comment scraper un site sans se faire bloquer.
• Évitez un proxy inverse Cloudflare lorsque l’objectif est l’anonymat de votre propre trafic sortant, car un proxy inverse protège une destination, pas un demandeur.

Quelles sont les limites et les risques ?

Un proxy inverse Cloudflare est puissant pour protéger un site que vous possédez, mais ce n’est pas un outil réseau universel. Comprenez ces limites avant d’en dépendre.

• Il ne rend pas votre trafic sortant anonyme : le proxy inverse masque votre origine aux visiteurs, et non vos requêtes auprès de tiers.
• Une IP d’origine exposée l’annule : si des attaquants découvrent l’IP d’origine brute (via d’anciens enregistrements DNS ou des en-têtes d’e-mail), ils peuvent contourner l’edge ; gardez le pare-feu de l’origine restreint aux plages Cloudflare.
• Le SSL Flexible n’est pas sûr : il laisse le tronçon Cloudflare-origine non chiffré, préférez donc Full (strict).
• Exactitude du cache : des règles de cache trop larges peuvent servir du contenu obsolète ou privé ; limitez les règles aux chemins statiques.

DataImpulse est un fournisseur de proxies éthiques et ne vend pas de proxies ISP statiques, n’est pas une API de scraping administrée, ni un service de proxy web gratuit. Si vous découvrez la terminologie des proxies, notre guide sur qu’est-ce qu’un proxy web présente les bases avant de choisir un outil.

Questions fréquentes

Guides connexes

• Proxy inverse NGINX
• Proxy inverse Docker
• Proxy direct NGINX

Besoin d’IP sortantes plutôt que d’un proxy inverse ?

Si vous devez collecter des données ou vérifier des résultats depuis de nombreux emplacements plutôt que protéger votre propre site, un proxy direct est l’outil qu’il vous faut. DataImpulse propose des proxies résidentiels rotatifs à partir de 1 dollar par Go, avec un paiement à l’usage et un trafic sans expiration, dans 195 pays. Créez un compte pour commencer.