REMOTE_ADDR vs CF-Connecting-IP : obtenir la vraie IP du visiteur derrière Cloudflare

Si un plugin de sécurité WordPress vous avertit à propos des "paramètres de détection d'IP," ou si votre application PHP se met soudain à journaliser la même poignée d'IP pour chaque visiteur, la cause est presque toujours la même : un reverse proxy comme Cloudflare s'intercale entre vos visiteurs et votre serveur. En résumé — gardez REMOTE_ADDR par défaut, ne faites jamais aveuglément confiance à HTTP_CLIENT_IP, et ne lisez CF-Connecting-IP que lorsque vous avez confirmé que la requête est réellement passée par Cloudflare. Voici le pourquoi de chacun de ces points.

Ce que chaque valeur signifie réellement

En PHP, ces valeurs arrivent sous forme d'entrées $_SERVER. Elles ne sont pas interchangeables — elles proviennent d'endroits complètement différents, et cette différence est toute l'histoire :

• REMOTE_ADDR — l'adresse IP de celui qui a ouvert la connexion TCP vers votre serveur. Le serveur web la renseigne directement depuis la socket, si bien qu'un client ne peut pas la falsifier. C'est la seule valeur digne de confiance.
• HTTP_CLIENT_IP et HTTP_X_FORWARDED_FOR — de simples en-têtes de requête HTTP. Toute entrée HTTP_* dans $_SERVER n'est qu'un en-tête envoyé par le client, ce qui signifie que n'importe qui peut lui donner n'importe quelle valeur avec une seule ligne de curl.
• HTTP_CF_CONNECTING_IP — l'en-tête CF-Connecting-IP ajouté par Cloudflare, qui contient la véritable IP du visiteur. Digne de confiance uniquement lorsque vous pouvez garantir que la requête est passée par Cloudflare.

Pourquoi derrière Cloudflare REMOTE_ADDR est "faux"

Quand Cloudflare met votre domaine en proxy, vos visiteurs se connectent à l'edge de Cloudflare, et Cloudflare ouvre une nouvelle connexion vers votre serveur d'origine. Du point de vue de votre serveur, le visiteur est Cloudflare — donc REMOTE_ADDR est une IP de l'edge Cloudflare, la même pour des milliers de personnes différentes. Rien n'est cassé ; le proxy fait simplement son travail.

Pour vous transmettre le visiteur d'origine, Cloudflare attache l'en-tête CF-Connecting-IP à chaque requête. Donc derrière Cloudflare, la source correcte est $_SERVER['HTTP_CF_CONNECTING_IP'], avec un repli sur REMOTE_ADDR lorsque cet en-tête est absent.

Le piège de sécurité : pourquoi vous ne pouvez pas simplement faire confiance à l'en-tête

Il est tentant d'écrire "lis HTTP_CLIENT_IP ou X-Forwarded-For, sinon REMOTE_ADDR" et de passer à autre chose. C'est exactement le schéma qui compromet les sites. Comme ce sont des en-têtes fournis par le client, un attaquant peut envoyer :

curl https://your-site.example/wp-login.php \
  -H "X-Forwarded-For: 8.8.8.8" \
  -H "Client-IP: 1.1.1.1"

Si votre limitation de connexions, votre pare-feu ou votre journal d'audit lisent ces en-têtes, l'attaquant peut faire tourner une fausse IP à chaque requête — contournant les limites de débit, échappant aux bannissements d'IP et empoisonnant vos journaux. C'est pourquoi un bon plugin de sécurité vous avertit avant de changer la méthode de détection : le réglage "plus pratique" est souvent celui qui est le moins sûr.

CF-Connecting-IP n'est à l'abri de cela que grâce à une condition supplémentaire : votre origine ne doit accepter du trafic que de Cloudflare. Si votre serveur est aussi joignable directement sur son IP publique, un attaquant peut contourner Cloudflare et falsifier lui-même CF-Connecting-IP. Verrouillez l'origine avec Authenticated Origin Pulls ou un pare-feu qui n'autorise que les plages d'IP de Cloudflare, et l'en-tête devient digne de confiance.

Le bon réglage, en termes simples

• Serveur classique, sans proxy : utilisez REMOTE_ADDR. Terminé.
• Derrière Cloudflare : utilisez CF-Connecting-IP (HTTP_CF_CONNECTING_IP), et restreignez votre origine à Cloudflare pour que l'en-tête ne puisse pas être usurpé.
• Derrière un autre proxy/CDN ou un répartiteur de charge : utilisez l'en-tête documenté par ce proxy (souvent X-Forwarded-For, en prenant le saut de confiance le plus à droite), et là encore, assurez-vous que l'origine n'accepte du trafic que de ce proxy.

Dans les plugins de sécurité WordPress comme All-In-One Security, c'est précisément le choix que contrôle le paramètre "IP detection". Laissez-le sur REMOTE_ADDR sauf si vous êtes derrière Cloudflare, auquel cas basculez-le sur CF-Connecting-IP.

Comment vérifier que vous avez bien fait

Le contrôle le plus rapide consiste à comparer ce que votre serveur détecte avec votre véritable IP publique. Ouvrez whatsmy.fyi depuis la même machine : il affiche l'IP publique exacte sous laquelle le monde extérieur vous voit. Si l'IP que votre plugin ou votre application journalise pour votre propre visite correspond à celle-ci, la détection fonctionne. (whatsmy.fyi tourne lui-même sur Cloudflare, il lit donc votre adresse depuis CF-Connecting-IP exactement comme le ferait une origine correctement configurée — et il ne stocke rien.)

Si vous déboguez de manière programmatique, le endpoint sans clé renvoie la même valeur pour les scripts :

curl https://whatsmy.fyi/ip
# → your real public IP, as seen at the edge

Deux IP qui correspondent signifient que votre détection est correcte. Si votre serveur journalise une IP Cloudflare alors que whatsmy.fyi affiche votre véritable IP, c'est que vous lisez encore REMOTE_ADDR derrière le proxy — basculez sur CF-Connecting-IP. Si elles diffèrent d'une autre manière, c'est qu'un VPN, une séparation IPv4/IPv6 ou un second proxy se trouve sur le chemin — notre note sur pourquoi une IP peut afficher la mauvaise localisation couvre ces cas.

À retenir en une ligne

REMOTE_ADDR est la vérité sur laquelle votre serveur ne peut pas être trompé ; HTTP_CLIENT_IP est une affirmation que n'importe qui peut faire. Derrière Cloudflare, préférez CF-Connecting-IP et verrouillez votre origine pour qu'elle reste digne de confiance — puis confirmez le résultat avec votre véritable adresse sur whatsmy.fyi.