Cloudflare v praxi

Firma zapnula proxy pro mail.firma.cz. Klikla na oranžový mrak u všech záznamů, protože „čím víc za Cloudflare, tím líp". Pošta přestala chodit. Příchozí i odchozí, naráz, bez chybové hlášky. Cloudflare pouští přes proxy jen HTTP a HTTPS na vybraných portech. SMTP, IMAP a POP3 na záznamu za proxy tiše zahodí. Mail server za oranžovým mrakem zkrátka neexistuje.

To je celá tahle kapitola v jedné nehodě. Oranžový mrak vypadá jako přepínač „zabezpečit", ale dělá něco jiného: přesměruje provoz skrz Cloudflare. Co tudy neteče, to nechrání. Co tudy nesmí téct, to rozbije.

Princip origin, edge a cache vykládá obecně hosting a CDN, proxy status a CNAME flattening zase DNS. Tady jde o jednu věc: jak to vypadá u tohohle poskytovatele, kde se to v administraci zapíná a kde přesně se to láme.

Oranžový mrak: přes proxy, nebo jen DNS

U každého A, AAAA a CNAME záznamu je v Cloudflare ikona mraku. Oranžová znamená proxied, šedá DNS only. Není to kosmetika. Je to volba mezi dvěma úplně jinými cestami provozu.

Šedý mrak (DNS only). Cloudflare jen přeloží jméno na tvou origin IP a vrátí ji klientovi. Ten se připojí přímo na server. Žádná cache, žádný WAF, žádná DDoS ochrana. Tvoje origin IP je veřejně v DNS. Cloudflare je tu obyčejný poskytovatel DNS, nic víc.

Oranžový mrak (proxied). Cloudflare se vloží mezi návštěvníka a server jako reverse proxy. V DNS odpovědi vrátí svou edge IP, ne tvou. Veškerý HTTP a HTTPS provoz teče přes Cloudflare, který po cestě pohlcuje DDoS, zapojuje WAF, cache a ukončuje TLS. Origin IP zůstane skrytá.

Pravidlo zní jednoduše, ale plete se pořád: za proxy dej jen to, co je web. Mail server, cíl MX a ověřovací CNAME (ACME, ověření SaaS služeb) musí zůstat šedé. Mail za proxy položí poštu. Ověřovací CNAME za proxy rozbije ověření, protože Cloudflare odpověď přepíše a původní hodnota se k ověřovateli nedostane.

Cache: ve výchozím stavu žádné HTML

„Mám Cloudflare, web je rychlý." Tenhle mýtus rozebírá principiálně hosting a CDN, tady ho ukážu konkrétně. Cloudflare ve výchozím stavu necachuje HTML. Rozhoduje se podle přípony: .jpg, .png, .css, .js cachuje sám od sebe, HTML a JSON ne. Statické soubory zrychlí hned, samotné stránky ne.

Aby edge cachovala i HTML, musíš to zapnout explicitně. V Cloudflare se to dělá přes Cache Rule s nastavením „Cache Everything" na URL, které chceš cachovat. Teprve pak edge drží i hotové stránky a odlehčí originu.

Pozor, kdo o Page Rules ještě mluví, mluví o mrtvé funkci. Cloudflare ukončil tvorbu nových Page Rules k 6. lednu 2025 a existující během roku migruje do nových Rules: Cache Rules, Configuration Rules, Redirect Rules. Page Rules se spouštěly jen podle vzoru URL, měly limit 125 pravidel na zónu a špatně se ladily. Nová Rules filtrují i podle hlaviček, cookies nebo země a dají se rozumně ladit. Většina starších návodů na webu je v téhle části zastaralá.

Vyčištění cache je jedno volání API. Pro hromadné čištění skupiny objektů existují cache tagy (surrogate keys). Kdy cache čistit při publikaci patří do plánu spuštění, ne až k incidentu.

A ještě jedna past: Always Use HTTPS je přepínač, který přesměrovává HTTP na HTTPS už na edge. Užitečný, ale v kombinaci s Flexible módem (kde přesměrovává i origin) přidává další smyčku do ERR_TOO_MANY_REDIRECTS. Zapínej ho s Full nebo Full (strict), ne s Flexible.

Pages, nebo Workers? Cloudflare už odpověděl

Pro hosting obsahového webu přímo na Cloudflare jsou dvě cesty a od roku 2025 nejsou rovnocenné.

Cloudflare Pages je hosting primárně pro statiku s volitelným SSR přes Pages Functions. Napojí se na Git, dělá CI/CD a ke každé větvi zdarma postaví preview deploy. Pro čistě statický web z SSG je pořád úplně v pohodě.

Workers je runtime pro serverový kód, který umí navíc doručovat statiku — přes Workers Static Assets. Nasadí kód i statické soubory v jedné operaci a statiku automaticky cachuje po celé síti. K tomu má Durable Objects, cron spouštěče, fronty a observability.

A tady je rozhodnutí, které Cloudflare udělal za tebe: pro nové projekty doporučuje Workers, ne Pages. Pages nekončí a dál běží, ale veškeré nové funkce a optimalizace míří do Workers Static Assets a Pages projekty se časem automaticky převedou. Komunita je rozdělená. Pages má jednodušší vývojářskou zkušenost a preview pro každou větev „zadarmo", migrace na Workers má svoje tření. Ale směr je jasný: sjednotit statiku, SSR, Durable Objects a observability pod jednu střechu. Pro nový obsahový web tedy Workers Static Assets, pokud nemáš důvod zůstat na jednoduchosti Pages. Co renderování od runtime vyžaduje (SSG → stačí statika, SSR/ISR → Functions), řeší statický, dynamický, hybridní. Git-based deploy, preview a rollback patří k build a deploy pipeline.

Tři typické záměny

• Oranžový mrak = bezpečno. Je to přesměrování provozu, ne zámek. Chrání jen to, co teče skrz. Mail a validační CNAME za ním nesmí být, origin IP musí být opravdu skrytá včetně firewallu.
• Mám Cloudflare, mám HTTPS, dám Flexible. Flexible je nejnebezpečnější mód (nešifrovaná druhá noha) a typicky vyrobí přesměrovací smyčku. Výchozí volba je Full (strict).
• Cloudflare cachuje web. Ve výchozím stavu necachuje HTML. Bez Cache Rule „Cache Everything" edge stránky vůbec nedrží.

Praktický checklist

• Každý DNS záznam má odůvodněný stav proxy; mail, cíl MX a ověřovací CNAME jsou DNS-only.
• Origin IP je skrytá nejen oranžovým mrakem, ale i firewallem originu (jen rozsahy Cloudflare), a po úniku zrotovaná.
• TLS mód je Full (strict) s Origin CA nebo veřejným certifikátem; Always Use HTTPS není zapnuté spolu s Flexible.
• Pro cache HTML existuje Cache Rule; pravidla jsou v nových Rules, ne v deprecated Page Rules.
• Je zvolené Pages vs. Workers podle renderování a existuje strategie čištění cache pro publikaci.