Cloudflare voor Magento: caching, echte IP-adressen en wat je niet cachet

Zet je Cloudflare voor een Magento-shop zonder verdere aanpassingen, dan zie je de volgende dag twee dingen. Alle bezoekers lijken van een handvol Cloudflare-IP's te komen. En je vraagt je af waarom de shop niet sneller is geworden.

Beide hebben een reden. Dit artikel legt uit hoe je de echte IP-adressen terugkrijgt, wat Cloudflare standaard wel en niet cachet, en hoe je voorkomt dat je klant de winkelwagen van een ander ziet. Voor de eerste setup: Cloudflare Pro instellen.

Probleem 1: je server ziet Cloudflare, niet de bezoeker

Met de proxy actief verbindt Cloudflare met je server. In je serverlogs staat dus het IP-adres van Cloudflare. Dat heeft gevolgen:

• Je IP-beperking op de Magento-admin werkt niet meer zoals bedoeld.
• Fail2ban of een andere tool kan Cloudflare zelf bannen en daarmee al je bezoekers.
• Rate limiting op serverniveau telt per Cloudflare-IP.
• Je analyse- en fraudecontroles zien verkeerde locaties.

Cloudflare geeft het echte IP mee in een header, CF-Connecting-IP. Je server moet die header vertrouwen, maar alléén als het verzoek van Cloudflare komt.

Zo los je het op in nginx

Met de ngx_http_realip_module zeg je welke adressen proxy's zijn (de Cloudflare-ranges) en welke header het echte IP bevat. In grote lijnen:

set_real_ip_from <Cloudflare IP-range>;
# ... herhaal voor elke range
real_ip_header CF-Connecting-IP;

De actuele IP-ranges staan op de Cloudflare-website onder "IPs". Ze veranderen soms, dus neem ze niet blind over uit een oud artikel en automatiseer de update. Gebruik je een managed hosting, vraag dan je hostingpartij hoe zij Cloudflare ondersteunen. Vaak is het al ingericht.

Staat er een Varnish of andere proxy tussen? Dan moet het echte IP ook daar goed doorgegeven worden. Zie Varnish configureren voor Magento.

Voor Laravel

In Laravel stel je de trusted proxies in, zodat de applicatie de juiste client-IP en het juiste schema (HTTPS) ziet. Zonder dat krijg je verkeerde IP's in je logs en rate limiters.

Probleem 2: wat cachet Cloudflare eigenlijk?

Volgens de Cloudflare-documentatie cachet de CDN standaard op basis van bestandsextensie. Denk aan afbeeldingen, CSS, JavaScript, fonts en documenten. HTML en JSON cachet Cloudflare standaard níet.

Daarnaast respecteert Cloudflare de cache-headers van je server. Een response wordt niet gecachet als:

• Cache-Control private, no-store, no-cache of max-age=0 bevat.
• Er een Set-Cookie-header in zit.
• De methode niet GET is.

Magento zet op veel pagina's cookies. Dat is wat HTML-caching op de edge lastig maakt. Het goede nieuws: voor de statische bestanden hoef je niets te doen. Je winst zit in afbeeldingen, JavaScript, CSS en fonts.

Moet je HTML door Cloudflare laten cachen?

Meestal niet. De HTML van een Magento-shop wordt al door Varnish of de ingebouwde full page cache geserveerd. Zie Magento full page cache configureren. Een extra HTML-cache op de edge levert winst op, maar brengt risico:

• Een winkelwagen, accountpagina of prijs voor een klantgroep kan bij een verkeerde klant belanden.
• Een gecachete pagina met een CSRF-token of formulier-key kan formulieren laten falen.

Wil je het toch? Doe het dan met Cache Rules en sluit uit wat gebruikersspecifiek is. Op Pro heb je 25 Cache Rules.

Wat je nooit cachet

Alles wat persoonlijk is, hoort buiten de cache. Test eerst met twee verschillende browsers en accounts.

Geen Rocket Loader zonder testen

Cloudflare biedt optimalisaties voor JavaScript en minificatie. Bij een Magento- of Hyvä-thema kunnen die scripts van volgorde of uitvoering veranderen. Zet zulke opties alleen aan na uitgebreid testen, en controleer je checkout.

Controle na uitrol

• IP's in de serverlogs. Zie je echte bezoekers-IP's?
• Cache-status. Kijk in de response-header cf-cache-status op een afbeelding. HIT betekent dat hij uit de cache komt.
• Winkelwagen en inloggen. Test met twee accounts tegelijk.
• Checkout en betaling.
• Core Web Vitals. Meet vooraf en achteraf in plaats van te raden. Zie CDN-configuratie voor e-commerce.

Een veilige uitrolvolgorde

Cache-fouten zijn lastig omdat ze er soms pas uren later uit zien. Rol caching daarom stap voor stap uit.

1. Herstel eerst het echte IP-adres (zie hierboven) en controleer dat je logs en beperkingen kloppen.
2. Laat Cloudflare standaard doen wat het doet: statische bestanden cachen. Controleer cf-cache-status voor je afbeeldingen, CSS en JavaScript.
3. Schrijf expliciet wat nooit gecachet wordt, als Cache Rule met "Bypass cache", voor paden zoals checkout, account en admin.
4. Overweeg pas daarna caching van HTML, en alleen voor pagina's die voor iedereen gelijk zijn.
5. Test als ingelogde klant én als anonieme bezoeker, in twee browsers.

Test op het gevaarlijkste scenario

Het ergste dat caching kan doen, is persoonlijke gegevens aan de verkeerde persoon tonen. Test dat actief:

• Log in met account A in browser 1 en bekijk de accountpagina.
• Open dezelfde URL als anonieme bezoeker in browser 2.
• Controleer dat browser 2 niet de gegevens van account A ziet.
• Herhaal het met de winkelwagen: voeg in browser 1 een product toe, controleer dat browser 2 een lege winkelwagen heeft.

Zie je iets anders, zet dan de HTML-cache direct uit en zoek de oorzaak. Eén gecachte accountpagina is een datalek.

Wat de cache-header je vertelt

Bij elke respons kun je kijken naar de header cf-cache-status. De gangbare waarden:

Een pagina die je wilt cachen en die steeds DYNAMIC toont, heeft vaak een Set-Cookie-header of een cache-instructie die caching tegenhoudt. Dat is bij Magento normaal voor pagina's met sessiegegevens.

Samenwerking met Varnish en Full Page Cache

Magento heeft een eigen Full Page Cache, vaak met Varnish. Dat is een hele andere laag dan Cloudflare: de FPC bewaart de gerenderde pagina op de server, Cloudflare bewaart kopieën op een locatie dichter bij de bezoeker. Ze kunnen samenwerken, maar voorkom dubbel werk en inconsistentie:

• Bepaal welke laag de baas is over HTML. Meestal is dat de eigen server, omdat die weet wanneer iets wijzigt.
• Als je HTML op de edge cachet, heb je een manier nodig om die cache te legen bij een wijziging van product, prijs of voorraad.
• Test wijzigingen: pas een prijs aan en kijk hoelang het duurt voor bezoekers de nieuwe prijs zien.

Voor de meeste shops levert het cachen van statische bestanden op de edge het grootste deel van de winst met het kleinste risico. Wil je ook de snelheid serieus aanpakken, dan lees je meer bij Magento performance.

Rocket Loader en andere optimalisaties

Optimalisaties die JavaScript herschikken of uitstellen kunnen scripts van je checkout of betaalmodules breken. Zet ze niet in één keer voor de hele site aan. Test op een kopie, of beperk ze via regels tot paden waar het veilig is. Controleer na elke wijziging het volledige koopproces met een testbestelling.

Waar dit in de beveiliging past

Caching en echte IP-adressen lijken een performance-onderwerp, maar ze raken je beveiliging direct. Een rate limit op een verkeerd IP-adres blokkeert alle bezoekers of niemand. Een gecachte accountpagina lekt data. Meer over de samenhang vind je op webshop security.