Kort svar: Bag Cloudflare ser serveren Cloudflares IP-adresser som afsender – den besøgendes rigtige IP ligger i headeren
CF-Connecting-IP. Skal logs, sikkerhedsplugins og landeblokering virke korrekt, skal serveren sættes til at bruge den header – på LiteSpeed/Apache typisk via mod_remoteip eller serverens Cloudflare-integration. Gør det på serverniveau, ikke i hvert enkelt plugin – og stol kun på headeren fra Cloudflares egne IP-områder.
Symptomet dukker op de mærkeligste steder: sikkerhedspluginnet banner “samme bruger” igen og igen, statistikken viser få besøgende med enorm aktivitet, kommentarspam kan ikke blokeres på IP, og fail2ban rammer pludselig alle på én gang. Fællesnævneren: serveren tror, at al trafik kommer fra en håndfuld Cloudflare-adresser.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplet er genskabt med anonymiserede adresser – det er ikke data fra hostious.io.
Med orange sky går al trafik gennem Cloudflares proxy: den besøgende taler med Cloudflare, og Cloudflare taler med din server. På netværksniveau er afsenderen derfor en Cloudflare-adresse – og det er den, serverens logs og PHP’s REMOTE_ADDR ser. Den rigtige IP sendes trofast med i to headere: CF-Connecting-IP (Cloudflares egen) og X-Forwarded-For. Alt, der skal bruge besøgerens identitet – logs, rate limiting, landeblokering, statistik – skal lære at læse dem.
Hurtigtest i WordPress: installer intet – kig i stedet i et vilkårligt plugins “seneste login”-log eller i kommentarers IP-felt. Går de fleste poster igen med adresser fra samme få områder, er det Cloudflare-adresser, du ser.
Én vigtig detalje: headere kan forfalskes af enhver, der taler direkte med serveren. Derfor må serveren kun stole på CF-Connecting-IP, når requesten faktisk kommer fra Cloudflares offentliggjorte IP-områder – det er præcis, hvad mod_remoteip/LiteSpeed-opsætningen håndhæver med en liste over betroede proxyer. Og allerbedst: lad kun Cloudflare kunne nå serveren overhovedet (firewall på Cloudflares IP-områder), så ingen kan gå uden om proxyen og forfalske noget som helst.
Rettelsen sidder, når nye linjer i accessloggen viser forskellige, virkelige besøger-adresser (besøg selv sitet fra mobilnet og find din egen), når sikkerhedspluginnets hændelser bærer rigtige IP-adresser, og når landeblokering og rate limiting opfører sig fornuftigt igen. Tjek også baglæns: gamle bans udstedt mod Cloudflare-adresser skal ryddes, ellers rammer de tilfældig trafik. Og gør verifikationen igen efter serverflytninger – opsætningen følger serveren, ikke domænet.
Det bryder ikke sitet, men det gør sikkerhedsarbejde blindt: bans rammer proxyen i stedet for angriberen, og retsgyldig dokumentation af hændelser bliver værdiløs. Få IP-gendannelsen på plads før næste hændelse.
Fordi det ser én Cloudflare-adresse stå bag mange fejllogins og banner den – og så rammes alle besøgende bag samme proxy-adresse. Det stopper, så snart pluginnet får de rigtige IP-adresser.
Bag Cloudflare: CF-Connecting-IP – den indeholder præcis én adresse og sættes af Cloudflare selv. X-Forwarded-For kan indeholde en kæde af adresser og er lettere at manipulere, hvis serveren også kan nås uden om proxyen.
