REMOTE_ADDR vs CF-Connecting-IP: Die echte Besucher-IP hinter Cloudflare ermitteln

Wenn ein WordPress-Sicherheits-Plugin dich vor den "IP-Erkennungseinstellungen" warnt oder deine PHP-Anwendung plötzlich für jeden Besucher dieselbe Handvoll IPs protokolliert, ist die Ursache fast immer dieselbe: Ein Reverse Proxy wie Cloudflare sitzt zwischen deinen Besuchern und deinem Server. Kurz gesagt — behalte REMOTE_ADDR als Standard bei, vertraue niemals blind HTTP_CLIENT_IP und lies CF-Connecting-IP nur dann, wenn du bestätigt hast, dass die Anfrage wirklich über Cloudflare kam. Hier kommt das Warum hinter jedem dieser Punkte.

Was jeder Wert tatsächlich bedeutet

In PHP kommen diese als $_SERVER-Einträge an. Sie sind nicht austauschbar — sie stammen aus völlig unterschiedlichen Quellen, und genau dieser Unterschied ist der Kern der Sache:

• REMOTE_ADDR — die IP-Adresse desjenigen, der die TCP-Verbindung zu deinem Server geöffnet hat. Der Webserver trägt diese aus dem Socket selbst ein, sodass ein Client sie nicht fälschen kann. Das ist der eine vertrauenswürdige Wert.
• HTTP_CLIENT_IP und HTTP_X_FORWARDED_FOR — gewöhnliche HTTP-Request-Header. Jeder HTTP_*-Eintrag in $_SERVER ist einfach ein vom Client gesendeter Header, was bedeutet, dass ihn jeder mit einer einzigen Zeile curl auf einen beliebigen Wert setzen kann.
• HTTP_CF_CONNECTING_IP — der CF-Connecting-IP-Header, den Cloudflare hinzufügt und der die echte Besucher-IP enthält. Vertrauenswürdig nur dann, wenn du garantieren kannst, dass die Anfrage über Cloudflare lief.

Warum REMOTE_ADDR hinter Cloudflare "falsch" ist

Wenn Cloudflare deine Domain proxyt, verbinden sich deine Besucher mit Cloudflares Edge, und Cloudflare öffnet eine neue Verbindung zu deinem Origin-Server. Aus Sicht deines Servers ist der Besucher Cloudflare — also ist REMOTE_ADDR eine Cloudflare-Edge-IP, dieselbe für Tausende verschiedener Personen. Nichts ist kaputt; der Proxy macht einfach seine Arbeit.

Um dir den ursprünglichen Besucher zu übergeben, hängt Cloudflare den CF-Connecting-IP-Header an jede Anfrage. Hinter Cloudflare ist die korrekte Quelle also $_SERVER['HTTP_CF_CONNECTING_IP'], mit Rückfall auf REMOTE_ADDR, wenn dieser Header fehlt.

Die Sicherheitsfalle: warum du dem Header nicht einfach vertrauen darfst

Es ist verlockend zu schreiben "lies HTTP_CLIENT_IP oder X-Forwarded-For, sonst REMOTE_ADDR" und weiterzumachen. Genau dieses Muster bringt Websites dazu, kompromittiert zu werden. Weil das vom Client gelieferte Header sind, kann ein Angreifer Folgendes senden:

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

Wenn deine Login-Drosselung, deine Firewall oder dein Audit-Log diese Header liest, kann der Angreifer bei jeder Anfrage eine gefälschte IP rotieren lassen — und damit Rate-Limits aushebeln, IP-Sperren umgehen und deine Logs vergiften. Deshalb warnt dich ein gutes Sicherheits-Plugin, bevor es die Erkennungsmethode ändert: Die "bequemere" Einstellung ist oft die unsichere.

CF-Connecting-IP ist davor nur aufgrund einer zusätzlichen Bedingung sicher: Dein Origin muss Traffic ausschließlich von Cloudflare akzeptieren. Wenn dein Server auch direkt über seine öffentliche IP erreichbar ist, kann ein Angreifer Cloudflare umgehen und CF-Connecting-IP selbst fälschen. Sperre den Origin ab mit Authenticated Origin Pulls oder einer Firewall, die nur Cloudflares IP-Bereiche zulässt, und der Header wird vertrauenswürdig.

Die richtige Einstellung, einfach erklärt

• Einfacher Server, kein Proxy: verwende REMOTE_ADDR. Fertig.
• Hinter Cloudflare: verwende CF-Connecting-IP (HTTP_CF_CONNECTING_IP) und beschränke deinen Origin auf Cloudflare, damit der Header nicht gefälscht werden kann.
• Hinter einem anderen Proxy/CDN oder einem Load Balancer: verwende den Header, den dieser Proxy dokumentiert (oft X-Forwarded-For, wobei du den am weitesten rechts stehenden vertrauenswürdigen Hop nimmst), und stelle erneut sicher, dass der Origin nur Traffic von diesem Proxy akzeptiert.

In WordPress-Sicherheits-Plugins wie All-In-One Security steuert genau diese Wahl die Einstellung "IP-Erkennung". Belasse sie auf REMOTE_ADDR, es sei denn, du bist hinter Cloudflare — dann stelle sie auf CF-Connecting-IP um.

Wie du überprüfst, ob es stimmt

Der schnellste Plausibilitätscheck ist, das, was dein Server erkennt, mit deiner echten öffentlichen IP zu vergleichen. Öffne whatsmy.fyi vom selben Rechner aus: Es zeigt genau die öffentliche IP, als die dich die Außenwelt sieht. Wenn die IP, die dein Plugin oder deine App für deinen eigenen Besuch protokolliert, damit übereinstimmt, funktioniert die Erkennung. (whatsmy.fyi läuft selbst auf Cloudflare, liest deine Adresse also aus CF-Connecting-IP auf dieselbe Weise wie ein korrekt konfigurierter Origin — und speichert nichts.)

Wenn du programmatisch debuggst, liefert der schlüssellose Endpunkt denselben Wert für Skripte:

curl https://whatsmy.fyi/ip
# → deine echte öffentliche IP, wie am Edge gesehen

Zwei übereinstimmende IPs bedeuten, dass deine Erkennung korrekt ist. Wenn dein Server eine Cloudflare-IP protokolliert, während whatsmy.fyi deine echte zeigt, liest du hinter dem Proxy immer noch REMOTE_ADDR — wechsle zu CF-Connecting-IP. Wenn sie sich auf andere Weise unterscheiden, ist ein VPN, eine IPv4/IPv6-Aufteilung oder ein zweiter Proxy im Pfad — unser Hinweis dazu, warum eine IP den falschen Standort anzeigen kann deckt diese Fälle ab.

Das Fazit in einem Satz

REMOTE_ADDR ist die Wahrheit, über die dein Server nicht belogen werden kann; HTTP_CLIENT_IP ist eine Behauptung, die jeder aufstellen kann. Hinter Cloudflare bevorzuge CF-Connecting-IP und sperre deinen Origin ab, damit er vertrauenswürdig bleibt — und bestätige dann das Ergebnis gegen deine echte Adresse bei whatsmy.fyi.