Se besøgendes rigtige IP-adresser bag Cloudflare

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å Apache med mod_remoteip, på Nginx med real_ip-modulet og på LiteSpeed med indstillingen „Use Client IP in Header“. Gør det på serverniveau, ikke i hvert enkelt plugin – og stol kun på headeren, når requesten kommer fra Cloudflares egne IP-områder.

Fagligt gennemgået: 2. oktober 2026

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 er, at serveren tror, at al trafik kommer fra en håndfuld Cloudflare-adresser.

Guiden viser, hvorfor det sker, hvordan du tjekker det på to minutter, hvordan rettelsen ser ud på de tre almindelige webservere – og hvordan du undgår at åbne et nyt sikkerhedshul, mens du retter det gamle.

Før du ændrer noget: Tag en kopi af den webserverkonfiguration, du ændrer, og test syntaksen, før du genindlæser (apachectl configtest eller nginx -t). På delt hosting har du normalt ikke adgang til serverkonfigurationen – så er det hostingudbyderens opgave, og du skal blot bede om, at Cloudflare-IP-gendannelse bliver slået til.

1. Sådan opstår problemet

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 med i headere, som Cloudflare selv tilføjer. Alt, der skal bruge besøgerens identitet – logs, rate limiting, landeblokering, statistik og loginbeskyttelse – skal lære at læse dem.

Header	Indhold	Brug
CF-Connecting-IP	Præcis én adresse: den besøgende, som Cloudflare så den	Den anbefalede kilde bag Cloudflare
X-Forwarded-For	En kæde af adresser, hvis requesten har passeret flere proxyer	Kun med en korrekt liste over betroede proxyer
REMOTE_ADDR (PHP)	Den adresse, der faktisk har forbindelsen til serveren	Viser Cloudflare, indtil serveren er sat op

Med grå sky (DNS only) går trafikken direkte til serveren, og så er REMOTE_ADDR allerede den rigtige adresse. Problemet findes altså kun på hostnavne, der er proxied – læs mere om forskellen i guiden om orange og grå sky.

2. Tjek, hvad serveren ser

Hurtigtest uden at installere noget: kig i et sikkerhedsplugins log over seneste logins eller i kommentarernes IP-felt. Går de fleste poster igen med adresser fra de samme få områder, er det Cloudflare-adresser, du ser. Har du adgang til accessloggen, er billedet endnu tydeligere: mange forskellige besøg, men kun et fåtal af afsenderadresser.

Vil du være helt sikker, kan du lægge en midlertidig testfil i webroden, åbne den i browseren og sammenligne med din egen offentlige IP-adresse. Slet filen igen, så snart du har set resultatet – den viser intet hemmeligt, men den skal ikke ligge permanent.

<?php
header('Content-Type: text/plain');
echo 'REMOTE_ADDR: ' . $_SERVER['REMOTE_ADDR'] . "\n";
echo 'CF-Connecting-IP: ' . ($_SERVER['HTTP_CF_CONNECTING_IP'] ?? '-') . "\n";

Viser REMOTE_ADDR en anden adresse end din egen, mens CF-Connecting-IP viser din rigtige, mangler gendannelsen. Viser begge din egen adresse, er serveren allerede sat korrekt op.

3. Gendan IP’en på serverniveau

Den rigtige løsning laves én gang på serveren. Så får logs, PHP og alle plugins den korrekte adresse automatisk, og du skal ikke huske indstillingen i hvert enkelt plugin. Cloudflare dokumenterer selv metoderne for de almindelige webservere.

Apache: mod_remoteip

Det gamle mod_cloudflare er udfaset; brug mod_remoteip, som følger med Apache. Modulet aktiveres, og du angiver, hvilken header der indeholder klientens IP, og hvilke proxyer der må sætte den:

LoadModule remoteip_module modules/mod_remoteip.so
RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
# ... tilføj resten af Cloudflares aktuelle IPv4- og IPv6-områder

Husk også logformatet: Apaches accesslog skal bruge %a (klientens IP) i stedet for %h, ellers står Cloudflare-adressen stadig i loggen, selvom PHP har fået den rigtige.

Nginx: real_ip-modulet

set_real_ip_from 173.245.48.0/20;
# ... tilføj resten af Cloudflares aktuelle IPv4- og IPv6-områder
real_ip_header CF-Connecting-IP;

Direktiverne lægges typisk i http-blokken, så de gælder alle sites på serveren. Test med nginx -t, og genindlæs derefter.

LiteSpeed

LiteSpeed Web Server har en indbygget indstilling, „Use Client IP in Header“, i serverens konfiguration. Når den er slået til, omskriver serveren klient-IP’en i accessloggen og giver applikationen den rigtige adresse. På hosting med LiteSpeed er det serveradministratorens indstilling – spørg din udbyder, hvis du er i tvivl om, hvorvidt den er aktiv.

Eksempeladressen ovenfor er et af Cloudflares områder, men listen er længere og ændrer sig. Hent altid den aktuelle liste fra Cloudflares officielle side over IP-områder (cloudflare.com/ips), og kopiér den aldrig fra en gammel artikel eller et forum.

4. Plugin-niveau som nødløsning

Mange sikkerheds- og statistikplugins har en indstilling for „bag proxy“ eller „Cloudflare“, hvor de selv læser CF-Connecting-IP eller X-Forwarded-For. Det virker, men løsningen skal huskes i hvert plugin – og glemmes altid i det næste. Der findes også plugins, der gendanner IP’en for WordPress alene, hvilket kan være en mulighed på delt hosting uden adgang til serverkonfigurationen.

Pas på én faldgrube: Et plugin, der blindt læser X-Forwarded-For uden at tjekke, hvem der sendte requesten, kan snydes af enhver, der skriver en falsk header. Vælg den indstilling, der læser Cloudflares header, og kun når requesten kommer fra Cloudflare – eller endnu bedre: lad serveren gøre arbejdet, og sæt pluginnet til at bruge REMOTE_ADDR.

5. Sikkerheden i det

Headere kan forfalskes af alle, 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 listen over betroede proxyer i mod_remoteip, real_ip-modulet og LiteSpeed-opsætningen håndhæver.

Allerbedst er det at lade kun Cloudflare nå serveren overhovedet: en firewall, der kun tillader web-trafik fra Cloudflares IP-områder, gør det umuligt at gå uden om proxyen. Det kræver til gengæld, at listen holdes opdateret, og at du har en plan for adgang, hvis Cloudflare en dag skal slås fra.

• IPv6: Cloudflare har også IPv6-områder. Mangler de på listen over betroede proxyer, får besøgende via IPv6 stadig en forkert adresse.
• Pseudo IPv4: Cloudflare kan omsætte IPv6-adresser til pseudo-IPv4-adresser for ældre systemer. Står indstillingen til at overskrive headerne, ændres indholdet af CF-Connecting-IP og X-Forwarded-For – tjek indstillingen, hvis du ser uventede adresser.
• Origin-IP: Del aldrig serverens egen IP-adresse i offentlige skærmbilleder eller supportfora; den er nøglen til at gå uden om Cloudflare.

6. Ryd op efter rettelsen

Når IP-gendannelsen virker, ligger der ofte rester fra perioden uden den. Gamle bans udstedt mod Cloudflare-adresser skal fjernes fra sikkerhedspluginnet, fail2ban eller serverens firewall – ellers rammer de tilfældige besøgende, der tilfældigvis kommer via samme Cloudflare-knudepunkt. Tjek også rate limiting-regler og landeblokering, som kan være blevet slækket for at „få det til at virke“, og stram dem igen.

Statistik fra perioden kan ikke rettes bagud. Notér datoen for rettelsen, så du ikke senere sammenligner besøgstal og unikke brugere på tværs af den.

7. Verifikation

Rettelsen sidder, når nye linjer i accessloggen viser forskellige, virkelige besøgsadresser. Besøg selv sitet fra mobilnettet og find din egen adresse i loggen. Sikkerhedspluginnets hændelser skal bære rigtige IP-adresser, og landeblokering og rate limiting skal opføre sig fornuftigt igen.

• Testfilen fra trin 2 viser din egen IP i REMOTE_ADDR – og er slettet igen bagefter.
• Accessloggen viser varierede klientadresser, ikke kun Cloudflare-områder.
• Et fejllogin fra din egen forbindelse dukker op med din adresse i sikkerhedspluginnet.
• Gamle bans mod Cloudflare-adresser er ryddet.

Gentag verifikationen efter serverflytninger og større opdateringer – opsætningen følger serveren, ikke domænet.

Hvornår skal hostingudbyderen hjælpe?

På delt hosting og administreret WordPress-hosting ligger webserverens konfiguration hos udbyderen. Send en kort sag med domænet, at sitet er bag Cloudflare med orange sky, og resultatet af testfilen. Så er det tydeligt, hvad der mangler, og udbyderen kan slå gendannelsen til centralt for alle sites på serveren.

Læs også

• Hub: Cloudflare til WordPress
• Orange eller grå sky i DNS
• Cloudflare Error 1020: find WAF-reglen
• Beskyt WordPress-login mod brute force
• Loglæsning for ikke-teknikere
• WordPress hosting hos Hostious – LiteSpeed-hosting med dansk support døgnet rundt

Ofte stillede spørgsmål om rigtige IP-adresser bag Cloudflare

Er det farligt, at logs viser Cloudflare-IP’er?

Det bryder ikke sitet, men det gør sikkerhedsarbejde blindt: bans rammer proxyen i stedet for angriberen, og dokumentation af hændelser bliver værdiløs. Få IP-gendannelsen på plads før næste hændelse.

Hvorfor banner mit sikkerhedsplugin alle på én gang?

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.

Skal jeg bruge X-Forwarded-For eller CF-Connecting-IP?

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.

Hvor finder jeg Cloudflares IP-områder?

Cloudflare offentliggør de aktuelle IPv4- og IPv6-områder på sin officielle side over IP-adresser. Hent listen derfra, tag både IPv4 og IPv6 med, og tjek den jævnligt – listen kan ændre sig.

Har jeg problemet, hvis skyen er grå?

Nej. Med grå sky (DNS only) går trafikken direkte til serveren, så den ser allerede den rigtige adresse. Problemet opstår kun på hostnavne, hvor trafikken går gennem Cloudflares proxy.