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.

Skrytá origin IP, která vlastně skrytá není

Oranžový mrak slibuje, že útočník tvou origin IP neuvidí, takže musí jít přes Cloudflare a tam ho zastaví WAF a DDoS ochrana. Slib platí jen tehdy, když IP opravdu nikde neuteče. A ona obvykle uteče.

Nejčastější vzorec: www je za proxy (oranžové), ale apex @ zůstane šedý a míří na stejný origin. dig firma.cz vrátí origin IP jako na talíři. Útočník Cloudflare obejde a praští přímo na server, kde žádný WAF není. A IP uteče i jinudy. DNS historií, hlavičkami odchozích mailů, starými zapomenutými subdoménami, záznamy v logu Certificate Transparency. Doložený případ je hlášení HackerOne #1536299, kde výzkumník našel origin IP služby SMTP2GO a obešel její Cloudflare WAF.

Náprava není „dát za proxy i apex" a hotovo. Origin IP, která už unikla, zůstane v historii. Musíš ji vyměnit a na firewallu originu pustit dovnitř jen rozsahy Cloudflare IP. Pak je jedno, že někdo IP zná. Přímé spojení server odmítne. Bez tohohle kroku je oranžový mrak jen pocit bezpečí.

Dvě nohy jednoho spojení

TLS módy v Cloudflare dávají smysl jedině přes jeden mentální obraz. Spojení od návštěvníka k tvému serveru není jedna trubka, jsou to dvě nezávislé nohy: prohlížeč↔Cloudflare a Cloudflare↔origin. TLS mód říká, co se děje na druhé noze. Zámeček v prohlížeči ti o ní neřekne nic.

Flexible. První noha šifrovaná, druhá noha nešifrované HTTP. Návštěvník vidí zámeček a má dojem bezpečí, ale půlka cesty od Cloudflare k serveru jede otevřeně. Kdokoli mezi nimi čte i mění provoz. Historicky nejčastěji omylem zvolený mód, protože „funguje hned a nemusím nic na originu". Nedávej ho.

Full. Obě nohy šifrované, ale Cloudflare origin certifikát neověřuje. Stačí self-signed nebo expirovaný. Chrání před pasivním odposlechem, ne před aktivním útočníkem s podvrženým certifikátem.

Full (strict). Obě nohy šifrované a Cloudflare origin certifikát ověřuje. Musí být platný a sedět na doménu. Vystavíš si zdarma Cloudflare Origin CA certifikát (platí roky, vidí ho jen Cloudflare) nebo dáš veřejný od Let's Encrypt. Tohle je výchozí volba. Když máš volit, vol tohle.

Flexible navíc rád vyrobí nekonečnou smyčku. Skoro každý moderní server sám přesměrovává HTTP na HTTPS. Při Flexible posílá Cloudflare na origin HTTP, origin vrátí redirect na HTTPS, Cloudflare zase pošle HTTP, a tak pořád dokola, až prohlížeč spadne na ERR_TOO_MANY_REDIRECTS. Oprava je přepnout na Full nebo Full (strict). Když nechceš vybírat ručně, Cloudflare má od roku 2024 Automatic SSL/TLS, který mód sám detekuje a nastaví.

Obecné vydávání a obnovu certifikátů (ACME, Let's Encrypt, 90 dní) řeší hosting a CDN. Tady jen volíš, jak se Cloudflare chová k té druhé noze.

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.

Zdroje

• Cloudflare docs, StackHarbor — proxied (orange) vs. DNS only (grey), reverse proxy, HTTP/HTTPS-only proxying, výpadek pošty z mail. omylem daného za proxy.
• EastonDev, Cloudflare docs, HackerOne #1536299 (SMTP2GO) — únik origin IP vedle www za proxy, únik přes DNS historii a cert transparency, rotace IP a firewall na Cloudflare rozsahy.
• Cloudflare SSL/TLS docs, ViVIO KB, StackHarbor — Flexible / Full / Full (strict), validace origin certu, Origin CA cert, Automatic SSL/TLS (2024).
• Cloudflare docs — ERR_TOO_MANY_REDIRECTS z Flexible + origin redirect, fix přepnutím na Full.
• Cloudflare cache docs, EastonDev — default necachuje HTML (rozhoduje přípona), Cache Rule „Cache Everything", cache tags / purge.
• ppc.land, Cloudflare Rules migration docs — Page Rules deprecated 6. 1. 2025, limit 125/zóna, migrace do Cache/Configuration/Redirect Rules.
• Cloudflare Workers docs, blog, Just After Midnight — Workers Static Assets, „nové projekty na Workers", Pages legacy-friendly, Pages Functions vs. Durable Objects/cron/queues.

Cloudflare je konkrétní nástrojová vrstva nad DNS (proxy status, flattening) a nad hostingem a CDN (edge, cache, TLS módy). Volba runtime navazuje na renderování a deploy na git a CI/CD. Edge cache, komprese a Always Use HTTPS zlepšují výkon a Core Web Vitals, přepnutí proxy a vyčištění cache patří do spuštění a migrace. Doručovat statiku z vlastní domény místo z cizí CDN má i právní rozměr: podklad třetí strany posílá IP návštěvníka jinam, což hlídá právo, soukromí a souhlas. Pojmy doména, DNS, hosting a CDN sjednocuje slovník.