WordPress + Cloudflare: correcte configuratie en veelvoorkomende conflicten

Cloudflare voor je WordPress-site zetten is een van de goedkoopste performance- en security-upgrades die je kunt doen. Het is ook een van de makkelijkste dingen om mis te configureren tot een redirect-lus, een kapotte WooCommerce-checkout, een wp-admin waar niemand meer in kan of een site die stilzwijgend de verkeerde gecachete HTML serveert aan de helft van je bezoekers. Het doel van dit artikel is de juiste setup, op volgorde, met de conflicten benoemd op de plek waar ze ontstaan.

Hoe Cloudflare tussen bezoeker en WordPress-server zit

Zodra je een domein aan Cloudflare toevoegt en je nameservers wisselt, gaat geen enkel verzoek meer rechtstreeks naar je hostingprovider. In plaats daarvan komt het verzoek binnen op een Cloudflare-datacenter dicht bij de bezoeker, en bepaalt Cloudflare wat ermee gebeurt: een gecachete response uit de edge serveren, een verse versie van je origin halen, het verzoek blokkeren als bedreiging of het ongewijzigd doorzetten naar je origin server. De origin server is je eigenlijke WordPress-installatie. Cloudflare staat er als reverse proxy voor.

Die ene architectuurwissel is de bron van elk Cloudflare-en-WordPress-probleem en elk Cloudflare-en-WordPress-voordeel. WordPress ziet het IP-adres van de bezoeker niet meer (het ziet een Cloudflare-IP). HTTPS wordt nu beëindigd op Cloudflare en de verbinding tussen Cloudflare en je origin is een aparte. De cache die bepaalt wat bezoekers zien is niet meer je WordPress-pagecache, maar wat Cloudflare aan de edge heeft opgeslagen. Elke misconfiguratie in dit artikel is een variant van een van die drie dingen die fout staat. Voor de cachelagen waar Cloudflare voor zit, zie hoe WordPress caching werkt.

Oranje wolk (proxy) versus grijze wolk (alleen DNS)

Cloudflare's DNS-dashboard laat naast elk record een oranje of grijze wolk zien. Die wolk is geen decoratie. Hij bepaalt of het verkeer voor die hostnaam door Cloudflare wordt geproxyd of dat Cloudflare alleen de DNS-vraag beantwoordt en het verkeer er rechtstreeks naartoe gaat.

• Oranje wolk (proxied): de bezoeker verbindt met Cloudflare. Cloudflare verbindt met je origin. SSL-terminatie, caching, WAF, DDoS-mitigatie en edge-logica gelden allemaal. Dit is wat je wilt voor @, www en elke andere webhostnaam.
• Grijze wolk (DNS only): Cloudflare beantwoordt alleen de DNS-vraag met je echte origin-IP. De bezoeker verbindt rechtstreeks met je server. Niets van Cloudflare's bescherming of caching is van toepassing. Gebruik grijze wolken voor alles wat geen HTTP/HTTPS-webverkeer is en voor elke hostnaam die Cloudflare niet kan proxyen.

Twee categorieën records moeten altijd grijs blijven:

• Mailrecords. MX-records zijn helemaal niet proxybaar (Cloudflare laat de wolk-icon niet eens zien voor MX). Elk A- of AAAA-record dat als mailservernaam fungeert (meestal mail.voorbeeld.nl) moet op DNS Only staan. SMTP-verkeer loopt niet door Cloudflare's HTTP-proxy, dus een oranje mail.-record breekt zonder waarschuwing inkomende en uitgaande mail. Voor SMTP en DNS-records voor WordPress-mail, zie Cloudflare's officiële email DNS-gids.
• FTP, SSH, database en andere niet-HTTP-services. Cloudflare's standaardplannen proxyen alleen HTTP en HTTPS op een vaste lijst poorten. Elke hostnaam die je gebruikt voor SFTP, SSH, MySQL of een andere service moet DNS Only zijn, anders kun je niet meer verbinden.

Dit is veruit de meest gemaakte fout bij het toevoegen van een WordPress-site aan Cloudflare: iemand proxyt het mail-record samen met de rest, een uur later werkt mail niet meer en het verband tussen die twee gebeurtenissen is niet meteen te zien.

SSL/TLS-modus: waarom Full (Strict) de enige veilige optie is

Cloudflare biedt vijf SSL/TLS-modi voor de verbinding tussen Cloudflare en je origin. Eentje is correct voor een WordPress-site met een geldig certificaat op de origin, en een van de andere is verantwoordelijk voor meer redirect-loops dan welke andere Cloudflare-instelling dan ook.

Cloudflare's eigen documentatie raadt expliciet Full of Full (Strict) aan "whenever feasible" en waarschuwt dat Flexible niet gebruikt moet worden bij sites met gevoelige data, en daar valt alles met een login onder. WordPress heeft een login. Gebruik Full (Strict).

Waarom Flexible-modus redirect-lussen veroorzaakt

Flexible-modus oogt aantrekkelijk omdat de origin geen certificaat nodig heeft, dus je kunt de Let's Encrypt-stap overslaan. Elke WordPress-site die ik heb gezien die voor Flexible koos "om het simpel te houden" liep uiteindelijk tegen dezelfde lus aan:

1. Een bezoeker vraagt https://jouwsite.nl op.
2. Cloudflare Flexible-modus stuurt een HTTP-verzoek naar je origin (poort 80, geen versleuteling).
3. Je nginx- of Apache-config heeft een return 301 https://...-regel, of WordPress heeft FORCE_SSL_ADMIN aanstaan, of een security-plugin dwingt HTTPS af. De origin stuurt een 301-redirect terug naar https://jouwsite.nl/wat-dan-ook.
4. Cloudflare ontvangt de HTTPS-redirect, stuurt opnieuw een HTTP-verzoek naar de origin.
5. Stap 3 herhaalt zich. De browser laat ERR_TOO_MANY_REDIRECTS zien.

Dit is de meest voorkomende oorzaak van de Too Many Redirects-fout in WordPress. Cloudflare's eigen troubleshootingpagina zegt dat de fix is om te wisselen naar Full (Strict) en een geldig origin-certificaat te installeren. Doe dat.

Als je nog geen certificaat op de origin kunt installeren: Cloudflare's gratis Origin CA-certificaat is door Cloudflare ondertekend en wordt automatisch vertrouwd zolang het verkeer door Cloudflare's proxy loopt. Je genereert het vanuit het SSL/TLS-dashboard, installeert het op je origin en vanaf dat moment is de verbinding tussen Cloudflare en je origin versleuteld en gevalideerd. Belangrijke kanttekening: een Origin CA-certificaat wordt niet rechtstreeks door browsers vertrouwd. Zet je ooit de oranje wolk uit en hitten bezoekers je origin zonder Cloudflare ervoor, dan zien ze SSL-fouten. Dat is de trade-off, en in de praktijk is dat zelden een probleem zolang je het maar onthoudt.

Cloudflare opzetten voor WordPress: de juiste volgorde

De volgorde is belangrijk. Wissel je eerst DNS en daarna SSL, dan is je site tussen die twee stappen kapot. Zet je Always Use HTTPS aan voordat Cloudflare's certificaat is uitgegeven, dan gebeurt hetzelfde. Dit is de volgorde die ik aanhoud:

1. Zorg dat je origin een geldig HTTPS-certificaat heeft. Let's Encrypt via je hostingpaneel is de makkelijkste route. Heeft je host die niet, genereer dan in stap 7 een Cloudflare Origin CA-certificaat vanuit het Cloudflare-dashboard en installeer dat.
2. Voeg het domein toe aan Cloudflare via het dashboard. Cloudflare scant je bestaande DNS-records en importeert ze. Controleer of alle records goed zijn meegekomen. Let met name op MX, mail., webmail., imap., smtp., cpanel. en alle subdomeinen voor niet-web services.
3. Zet de wolk-icon goed op elk record. Webhostnamen (@, www) krijgen oranje wolken. Alles wat met mail te maken heeft krijgt grijze wolken. Alles wat geen HTTP is krijgt grijze wolken. Controleer dit nog een keer voordat je nameservers wisselt.
4. Wissel je nameservers bij je domeinregistrar naar de twee Cloudflare-nameservers die Cloudflare aan je zone toewijst. Wacht tot Cloudflare's statuspagina voor de zone "Active" toont voordat je verdergaat. Dit duurt meestal minuten, soms uren.
5. Zet SSL/TLS-modus op Full (Strict). Dashboard: SSL/TLS, Overview, encryption mode op Full (strict). Controleer in een privévenster of de site op HTTPS laadt. Krijg je hier ERR_TOO_MANY_REDIRECTS, ga dan terug naar de redirect-loop sectie hierboven.
6. Schakel Always Use HTTPS in. Dashboard: SSL/TLS, Edge Certificates, Always Use HTTPS. Hierdoor 301-redirect Cloudflare elk plain HTTP-verzoek aan de edge naar HTTPS, voordat het verzoek je origin überhaupt bereikt. Met Full (Strict) plus Always Use HTTPS kun je veilig de HTTP-naar-HTTPS-redirect uit je nginx- of Apache-config halen (als je die hebt). Eén redirect is genoeg.
7. Installeer de Cloudflare WordPress-plugin. Zoek in de plugindirectory op "Cloudflare", installeer versie 4.14.2 of nieuwer (uitgegeven december 2025) en koppel hem aan je Cloudflare-account met een scoped API token. De plugin maakt APO mogelijk als je dat aanzet, purged automatisch de Cloudflare-cache als je content publiceert of bijwerkt en biedt een paar Cloudflare-instellingen binnen wp-admin.
8. Configureer cache rules zoals beschreven in de cache rules-sectie hieronder. Zonder expliciete cache rules cachet Cloudflare wel je statische assets, maar niet je HTML. Het grootste deel van de snelheidswinst van Cloudflare op een WordPress-site komt juist uit het cachen van HTML aan de edge.
9. Verifieer de proxy header-truc in wp-config.php als WordPress nog steeds denkt dat de verbinding HTTP is. Zie de sectie "X-Forwarded-Proto en reverse proxy detectie".

Na stap 6 hoort de site te werken: HTTPS aan de voorkant, geldig certificaat, geen redirect-lussen, mail loopt nog. Stap 7 tot en met 9 maken van Cloudflare niet alleen een security- en basis-CDN-laag, maar een volwaardige edge cache voor WordPress.

Page Rules zijn deprecated: gebruik het nieuwe Rules-systeem

Lees je oudere Cloudflare-en-WordPress-artikelen, dan staat bijna elk cache- of redirectrecept daarin als Page Rule. Page Rules zijn niet meer de manier om Cloudflare te configureren. Volgens Cloudflare's Page Rules migration guide kan sinds 6 januari 2025 geen Cloudflare-account op welk plan dan ook nog nieuwe Page Rules aanmaken. Bestaande Page Rules blijven werken en Cloudflare migreert ze automatisch naar het nieuwe systeem, maar voor nieuwe configuratie moet je de vervangers gebruiken.

Het gedragsverschil dat mensen verrast: de nieuwe Rules zijn stapelbaar. Meerdere rules kunnen op één verzoek matchen en gelden allemaal. Page Rules werkten met first-match-wins, waarbij maar één rule per verzoek werd toegepast. Migreer je oude configuraties met de hand, ga er dan niet vanuit dat een Page Rule één-op-één in een Cache Rule kopiëren hetzelfde effect geeft, zeker niet als meerdere rules op dezelfde URL kunnen matchen.

Het free plan biedt tien Cache Rules en tien Redirect Rules, wat genoeg is voor een normale WordPress-site. De vier cache rules hieronder laten er nog zes over voor andere dingen.

Cache rules: wat cachen, wat bypassen

Cloudflare cachet HTML niet standaard. Out of the box cachet de oranje wolk je statische assets (CSS, JS, afbeeldingen) en beschermt hij je, maar elk paginaverzoek komt nog steeds bij je origin terecht en draait PHP en doet databasequeries. Wil je de echte edge-cachewinst op WordPress, dan moet je Cloudflare expliciet vertellen om HTML te cachen en de verzoeken te bypassen die niet gecachet mogen worden. Een verkeerde bypass-lijst is hoe je een wp-admin-pagina van een ingelogde admin serveert aan een willekeurige anonieme bezoeker.

De minimum veilige ruleset voor WordPress, op volgorde:

Rule 1: bypass voor ingelogde gebruikers en admin-paden.

• When incoming requests match: Cookie name contains wordpress_logged_in_ OR URI Path starts with /wp-admin/ OR URI Path equals /wp-login.php OR URI Path starts with /wp-json/
• Then: Bypass cache

Dit beschermt het hele admin-pad en de REST API tegen caching. De wordpress_logged_in_-cookie wordt gezet zodra iemand is ingelogd, ongeacht zijn rol. De /wp-json/-bypass voorkomt dat Gutenberg en de block editor verouderde data te zien krijgen.

Rule 2: bypass voor WooCommerce-sessies en cart-cookies.

• When incoming requests match: Cookie name contains woocommerce_items_in_cart OR woocommerce_cart_hash OR wp_woocommerce_session_
• Then: Bypass cache

De wp_woocommerce_session_-cookieprefix bevat het sessie-ID van de bezoeker voor zijn winkelmandje. Cache je pagina's met deze cookies erin, dan kunnen twee bezoekers elkaars cart te zien krijgen. Deze rule voorkomt dat.

Rule 3: bypass voor WooCommerce path-prefixes.

• When incoming requests match: URI Path starts with /cart/ OR /checkout/ OR /my-account/
• Then: Bypass cache

Dit is de defense in depth voor WooCommerce: de cookie-rule hierboven is de primaire bescherming, maar als de cookie ergens mist, houdt de path-rule de cart-, checkout- en accountpagina's nog steeds buiten de cache. Cloudflare's WooCommerce-cachinggids hanteert dezelfde uitsluitingen.

Rule 4: cache HTML voor de rest.

• When incoming requests match: All incoming requests (of, voorzichtiger, URI Path starts not with /wp-admin/ and Hostname equals jouw domein)
• Then: Eligible for cache; Edge TTL: respect existing headers (aanbevolen) of 4 uur; Browser TTL: respect existing headers

Dit is degene die Cloudflare daadwerkelijk HTML aan de edge laat cachen. Zonder deze rule volgt Cloudflare zijn defaultgedrag, en dat is alleen de statische asset-extensies cachen die het kent. Met "respect existing headers" bepaalt WordPress (of je caching-plugin) de TTL via Cache-Control-headers, en dat is de veiligste default als je al een WordPress-pagecacheplugin hebt draaien.

Een opmerking over het free plan: Cloudflare's edge cache TTL plan limits zetten de minimum edge TTL op het free plan op twee uur. Dat betekent dat zelfs als WordPress Cache-Control: max-age=300 meestuurt, Cloudflare op het free plan de pagina minstens twee uur aan de edge vasthoudt. Publiceer of update je een post, dan heb je de Cloudflare WordPress-plugin nodig om automatisch een cache purge uit te voeren. Anders zien bezoekers tot twee uur lang een verouderde pagina.

APO: wat het doet en wanneer het helpt

Automatic Platform Optimization is Cloudflare's naam voor het cachen van complete HTML-pagina's aan de edge via Cloudflare Workers, met WordPress-bewuste logica die automatisch bypassed voor ingelogde gebruikers en WooCommerce-sessies. APO ging live op 2 oktober 2020, tijdens Cloudflare's Birthday Week. Cloudflare's launch-post rapporteerde 72% reductie in TTFB op het 90e percentiel op testsites.

APO is een add-on van $5 per maand op het free plan en gratis inbegrepen op Pro, Business en Enterprise. Om het te gebruiken heb je ook de Cloudflare WordPress-plugin nodig, want die plugin handelt de cache-purge-bij-publish-logica af. Zonder de plugin cachet APO nog steeds HTML, maar met een vaste 30 minuten TTL en zonder slimme purges, en dat is zelden wat je wilt.

De eerlijke vergelijking tussen APO en handmatige Cache Rules:

Kies APO als je de minste moeite wilt en op een Pro plan zit (waar het gratis is) of de $5 geen issue is. Kies handmatige Cache Rules als je op het free plan zit en geen maandlasten wilt, en je het prima vindt om de bypass-lijst zelf te onderhouden. Beide aanpakken geven je HTML-caching aan de edge. Er is geen derde optie die wezenlijk beter is.

In 2024 en 2025 was er enige verwarring of APO werd gedeprecateerd. Dat was niet zo. Cloudflare bracht de Cloudflare WordPress-plugin tussen augustus 2024 en oktober 2025 niet uit, en dat leidde tot speculatie in de community, maar de plugin-development is eind 2025 hervat en de huidige versie (4.14.2 per 22 december 2025) wordt actief onderhouden en is getest tot WordPress 6.9. APO zelf is al die tijd een actief product gebleven.

De Cloudflare WordPress-plugin

De officiële Cloudflare-plugin op wordpress.org staat op versie 4.14.2 per 22 december 2025, heeft meer dan 200.000 actieve installaties en is getest tot WordPress 6.9. Hij vereist PHP 7.4 of nieuwer en WordPress 5.0 of nieuwer.

Wat de plugin daadwerkelijk doet:

• Cache purge bij contentwijzigingen. Als je een post of pagina publiceert, bijwerkt of verwijdert, doet de plugin een Cloudflare API-call om de edge cache te purgen voor de gewijzigde URL's. Dit is de feature die APO bruikbaar maakt, en hij is ook nuttig met handmatige Cache Rules.
• Handmatige cache purge vanuit wp-admin. Een knop om de complete Cloudflare-cache voor de zone te purgen, zonder WordPress te verlaten. Handig als je net een sitewide change hebt gedaan (theme update, CSS-wijziging) en niet wilt wachten tot losse URL's verlopen.
• Cloudflare-instellingen toggelen vanuit wp-admin. Security level, Always Online, Image Optimization. Niets hiervan is functionaliteit die je niet ook in het Cloudflare-dashboard zelf kunt vinden, maar het scheelt context-switchen.
• APO-control. Aanzetten, uitzetten en configureren van APO vanuit wp-admin als je een APO-abonnement op de zone hebt.

Je koppelt de plugin aan Cloudflare met een scoped API token, niet met de oude global API key. Genereer het token vanuit je Cloudflare-account: My Profile, API Tokens, Create Token, gebruik de "WordPress"-template. Het token heeft alleen de rechten die de plugin nodig heeft, wat de blast radius beperkt mocht het ooit lekken.

X-Forwarded-Proto en reverse proxy-detectie

Als Cloudflare een verzoek doorzet naar je origin, is de verbinding van de bezoeker naar Cloudflare HTTPS, maar de verbinding tussen Cloudflare en de origin kan HTTP of HTTPS zijn, afhankelijk van je SSL-modus. Ziet je origin een HTTP-verzoek, dan is PHP's $_SERVER['HTTPS'] leeg en denkt WordPress dat de bezoeker op plain HTTP zit. Dat breekt is_ssl(), breekt elke HTTPS-bewuste redirect-logica en draagt bij aan mixed content waarschuwingen aan de voorkant. Voor de voorkant zelf, zie mixed content waarschuwingen in WordPress.

De fix is om de X-Forwarded-Proto-header die Cloudflare altijd zet te lezen en WordPress te vertellen dat de verbinding veilig is wanneer de header https aangeeft. Voeg dit toe aan wp-config.php, boven de regel require_once ABSPATH . 'wp-settings.php':

// Vertrouw Cloudflare's X-Forwarded-Proto-header.
// Alleen veilig wanneer de origin niet rechtstreeks bereikbaar is zonder
// Cloudflare, dus als het origin-IP gefirewalled is op Cloudflare's IP-ranges.
if (
    isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
    && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO']
) {
    $_SERVER['HTTPS'] = 'on';
}

De security-kanttekening is niet onderhandelbaar. Is je origin op een publiek IP bereikbaar zonder dat het verkeer eerst door Cloudflare loopt, dan kan een aanvaller rechtstreeks verbinden en een nep X-Forwarded-Proto: https-header meesturen, en WordPress gelooft dat. De X-Forwarded-Proto-header in het snippet hierboven is alleen te vertrouwen als niets anders hem kan schrijven, en dat betekent dat je je origin firewallt tot alleen Cloudflare's IP-ranges poorten 80 en 443 kunnen bereiken. Cloudflare publiceert de lijst met IPv4- en IPv6-ranges. Je hostingprovider hoort een gids te hebben voor het beperken van de firewall tot die lijst.

Hetzelfde principe geldt voor het terugvinden van bezoeker-IP's in WordPress-logs, in comment spam-heuristieken en in rate-limiting plugins. Cloudflare zet het echte IP van de bezoeker in de CF-Connecting-IP-header. Plugins zoals Wordfence hebben ingebouwde modi om die te lezen. Webservers kun je hetzelfde laten doen: nginx met ngx_http_realip_module, Apache met mod_remoteip. Doe je dat niet, dan is elk IP in je WordPress access logs een Cloudflare-IP, en dan zijn country-blocking en abuse-forensics waardeloos.

Voor het correct laten werken van HTTPS in WordPress achter een proxy, zie HTTPS afdwingen in WordPress zonder redirect-lus.

Cloudflare-cache purgen na contentwijzigingen

Met Cache Rules of APO die HTML aan de edge cachen, is elke gepubliceerde post tegelijk twee caches: de WordPress-pagecache (of APO's edge cache) op de ene laag, en Cloudflare's edge nodes op de andere. Een post in wp-admin bijwerken klaart de WordPress-kant op, maar doet niets aan de Cloudflare-kant tenzij iets Cloudflare expliciet vertelt om te purgen.

De Cloudflare WordPress-plugin regelt dit automatisch voor posts en pagina's: als je een gepubliceerde post opslaat, doet hij een POST /zones/{zone_id}/purge_cache-call naar de Cloudflare API voor de betrokken URL's. APO-abonnees krijgen hetzelfde gedrag, plus extra logica die ook archief-, categorie- en homepagina's meeneemt. Zonder de plugin moet je handmatig purgen vanuit het Cloudflare-dashboard, of je eigen purge-logica met de API schrijven.

De WordPress page cache plugin die je al hebt (LiteSpeed Cache, WP Rocket, W3 Total Cache, FlyingPress) heeft vaak zijn eigen Cloudflare-integratie die hetzelfde werk doet. Kies er één. Twee plugins die allebei de Cloudflare-cache willen managen geeft onvoorspelbare purge-timing en af en toe gemiste invalidaties. Ga je voor de officiële Cloudflare-plugin, zet dan de Cloudflare-integratie in je page cache plugin uit. Ga je voor de Cloudflare-integratie van je page cache plugin, dan heb je de Cloudflare-plugin niet nodig voor purges, maar wil je hem misschien toch nog voor APO.

Veelvoorkomende conflicten en hoe je ze herkent

Conflict 1: redirect-lus na het inschakelen van Cloudflare

Symptoom: de site die gisteren prima werkte, geeft nu in elke browser meteen ERR_TOO_MANY_REDIRECTS, voordat er content laadt.

Oorzaak: SSL/TLS-modus staat op Flexible (of Off) en de origin heeft zelf een HTTP-naar-HTTPS-redirect.

Fix: zet SSL/TLS-modus op Full (Strict) en installeer een geldig origin-certificaat (Let's Encrypt of Cloudflare Origin CA). Kun je dat niet meteen doen, haal dan de origin-redirect weg en vertrouw op Cloudflare's "Always Use HTTPS". Beide fixes doorbreken de lus.

Verifieer: open de site in een privévenster. De pagina hoort op https:// te laden zonder fouten. Run vanaf een terminal curl -I https://jouwsite.nl en bevestig dat de response HTTP/2 200 is, niet een keten van 301's.

Conflict 2: WooCommerce-checkout toont andermans winkelmandje

Symptoom: klanten melden dat ze items in hun mandje zien die ze niet hebben toegevoegd, of het verkeerde totaalbedrag in de checkout, of een ingelogde account-header van iemand anders.

Oorzaak: Cloudflare cachet pagina's met WooCommerce-sessiecookies en serveert diezelfde cachepagina aan meerdere bezoekers. Of de bypass voor woocommerce_*-cookies ontbreekt, of de path-bypass voor /cart/, /checkout/ en /my-account/ ontbreekt, of allebei.

Fix: voeg de cookie-bypass-rule en de path-bypass-rule uit de cache rules-sectie hierboven toe. Purg na het toevoegen de complete Cloudflare-cache (Caching, Configuration, Purge Everything) zodat de vervuilde entries verdwijnen.

Verifieer: voeg een product toe aan je winkelmandje, log uit, open een privévenster en bezoek dezelfde URL. Het privévenster hoort een leeg mandje te tonen, niet dat van jou.

Conflict 3: wp-admin laadt verouderde pagina's of inloggen werkt niet

Symptoom: wijzigingen die je in wp-admin maakt zijn na een reload niet zichtbaar, of je wordt onverwacht uitgelogd, of de Customizer toont verkeerde content.

Oorzaak: Cloudflare cachet wp-admin-pagina's, de REST API, of de wordpress_logged_in_-cookies staan niet in de bypass-lijst. Cloudflare Rocket Loader (een JavaScript-optimalisatie) kan ook wp-admin-scripts breken.

Fix: controleer dat Cache Rule 1 zowel wordpress_logged_in_ als /wp-admin/ als /wp-json/ bevat. Ga in Cloudflare naar Speed, Optimization en zet Rocket Loader globaal uit, of zet hem uit voor /wp-admin/* met een Configuration Rule. Purge na het wijzigen van rules alles.

Verifieer: log in een privévenster in op wp-admin. Maak een contentwijziging. Reload meteen de publieke site. De wijziging hoort zichtbaar te zijn.

Conflict 4: mail werkt niet meer na onboarding

Symptoom: uitgaande mail vanuit contactformulieren wordt niet meer afgeleverd, of inkomende mail naar je domein bounct, een uur of twee nadat je nameservers zijn gewisseld naar Cloudflare.

Oorzaak: het MX-record wijst naar een hostnaam zoals mail.jouwsite.nl en het A-record van die hostnaam is tijdens de onboarding oranje gewolkt. Cloudflare proxyt geen SMTP, dus mailverkeer komt niet meer aan op je echte mailserver.

Fix: zoek in Cloudflare DNS elk A- en AAAA-record voor mail, smtp, imap, pop, webmail of een andere mail-gerelateerde hostnaam, en klik op de oranje wolk om hem grijs te maken. MX-records zijn standaard niet proxybaar en hoef je niet aan te raken.

Verifieer: stuur een testmail vanuit een contactformulier op de site, en stuur een mail vanaf een externe account naar je domein. Beide horen binnen een minuut aan te komen. Controleer je DNS-records met dig mail.jouwsite.nl A +short en bevestig dat het antwoord je echte mailserver-IP is, niet een Cloudflare-IP (Cloudflare-IP's beginnen meestal met 104.16., 104.17., 172.64. of vergelijkbaar).

Conflict 5: bezoeker-IP's in WordPress-logs zijn allemaal Cloudflare

Symptoom: Wordfence, Limit Login Attempts of een analytics-plugin laat zien dat elke bezoeker vanaf een Cloudflare-IP komt, country-blocking werkt niet en spam-heuristieken slaan de plank mis.

Oorzaak: WordPress en de webserver lezen het directe verbindings-IP, en dat is Cloudflare. Het echte bezoeker-IP zit in de CF-Connecting-IP-header.

Fix: zet je webserver zo in dat hij het echte client-IP herstelt vanuit CF-Connecting-IP. Op nginx gebruik je ngx_http_realip_module met set_real_ip_from-regels voor Cloudflare's IP-ranges. Op Apache gebruik je mod_remoteip. Plugins zoals Wordfence hebben onder Tools, Diagnostics, Other Tests een instelling voor de IP-bron. Kies de optie die CF-Connecting-IP gebruikt.

Verifieer: laad je site, en kijk daarna in de access log op de origin of in Wordfence's recente bezoekerslijst. De IP's horen nu te matchen met je echte publieke IP, niet met dat van Cloudflare.

Wanneer je hulp moet vragen

Heb je de stappen hierboven gevolgd en is de site nog steeds kapot, blijft de lus zich voordoen of serveert de cache nog steeds verkeerde content aan verkeerde mensen, verzamel dan dit voordat je hulp inschakelt:

• Cloudflare-zonenaam en het plan waar je op zit (Free, Pro, Business, Enterprise)
• SSL/TLS-modus zoals nu ingesteld (screenshot van de SSL/TLS Overview-pagina)
• Cache Rules en Configuration Rules die actief zijn (screenshots, op volgorde)
• Output van curl -I https://jouwsite.nl vanaf buiten Cloudflare
• Output van curl -I -H "Host: jouwsite.nl" https://je-origin-ip/ als je de origin nog rechtstreeks kunt bereiken (alleen relevant als je de origin nog niet hebt gefirewalled tot Cloudflare)
• WordPress-versie, PHP-versie, page-cache-plugin met versie, Cloudflare WordPress-pluginversie
• Browser console errors en de network tab waterfall voor de pagina die mis gaat
• Een duidelijke beschrijving van wat je al geprobeerd hebt, inclusief eventuele cache purges

Met dit setje informatie kan elke Cloudflare-bewuste support engineer of hostingprovider het probleem in één keer reproduceren. Zonder ben je een paar uur kwijt aan heen-en-weer berichten voordat iemand je iets nuttigs kan vertellen.

Hoe voorkom je dat het terugkomt

Een beetje discipline houdt Cloudflare er meestal van af om dingen twee keer te breken:

• Documenteer de SSL-modus, cache rules en bypass rules op een plek die personeelswisselingen overleeft. Cloudflare-configuratie is onzichtbaar vanuit het WordPress-dashboard, dus een toekomstige beheerder die alleen naar WordPress kijkt snapt niet waarom de cache zich gedraagt zoals hij zich gedraagt.
• Audit DNS-records na elke onboarding. Controleer dat elk mail-record grijs is, elk web-record oranje en dat er niets is gemist in de import.
• Houd één bron van cache-invalidatie aan. Of de officiële Cloudflare-plugin handelt purges af, of de Cloudflare-integratie van je page cache plugin doet het, nooit allebei tegelijk.
• Firewall de origin tot Cloudflare's IP-ranges als je X-Forwarded-Proto vertrouwt. Zonder die firewall is de proxy header-truc een security hole.
• Test in een privévenster na elke wijziging. De cache die je raakt is bijna altijd degene die je ingelogde browser voor je verbergt.