De ce pun totul în spatele CloudflareDe ce pun totul în spatele CloudflareDe ce pun totul în spatele Cloudflare

Fiecare site pe care îl lansez trece în spatele Cloudflare înainte de orice altceva. Nu pentru că e la modă. Pentru că nivelul gratuit singur îți dă o CDN globală, un adevărat web application firewall, mitigare DDoS, SSL la edge și DNS autoritar rapid. Aceasta este multă infrastructură pe care nu trebuie s-o operezi tu. Pe deasupra, Cloudflare injectează un header cu țara vizitatorului la fiecare cerere în parte, iar acel header este coloana vertebrală a detectării limbii bazate pe geolocație pe acest site.

Nivelul gratuit face mai mult decât crezi

Majoritatea oamenilor cunosc Cloudflare ca CDN. Pune în cache activele statice la noduri edge aproape de vizitator, astfel încât răspunsul nu trebuie să călătorească înapoi la serverul de origine din Nürnberg pentru fiecare cerere. Asta singură reduce latența percepută pentru vizitatorii europeni și americani cu o marjă reală. Dar CDN-ul este cea mai puțin interesantă parte.

WAF-ul este mai interesant. Planul gratuit include setul de reguli gestionat de Cloudflare. Blochează tiparele de atac comune: SQL injection, cross-site scripting, directory traversal, payload-uri de exploit cunoscute. Am văzut cum blochează traficul de scanere automate înainte să ajungă la originea mea. Pe un VPS self-hosted, acel trafic consumă oricum lățime de bandă și CPU dacă îl lași să treacă. Cloudflare îl absoarbe la edge.

Protecția DDoS la nivelul gratuit nu este o jucărie. Atacurile volumetrice L3/L4 sunt absorbite automat. Atacurile L7 la nivel de aplicație pot fi gestionate cu reguli de rate-limiting și comutatorul Bot Fight Mode. Nu a trebuit niciodată să intervin manual în timpul unui atac. Dashboard-ul arată vârful de trafic, mitigarea intră în acțiune și VPS-ul meu nu îl vede niciodată.

Header-ul de țară care alimentează rutarea geo

Aceasta este funcționalitatea care contează cel mai mult pentru acest stack specific. Cloudflare adaugă un header cf-ipcountry la fiecare cerere proxată. Valoarea este codul de țară ISO 3166-1 alpha-2 pentru IP-ul vizitatorului: DE pentru Germania, AT pentru Austria, IT pentru Italia și așa mai departe. Middleware-ul meu Next.js citește acest header și decide ce locale să servească.

Cazul interesant este Tirolul de Sud. Tirolul de Sud este o provincie din nordul Italiei unde aproximativ 70 la sută din populație vorbește germana ca primă limbă. Un vizitator din Tirolul de Sud primește IT din codul de țară. Dacă aș face rutarea doar pe baza codului de țară, ar primi locala italiană. Este greșit. Middleware-ul meu verifică header-ul accept-language alături de cf-ipcountry: dacă țara este IT dar preferința de limbă a browserului este de, site-ul servește germana. Cloudflare furnizează semnalul brut. Codul meu furnizează inteligența.

Fără Cloudflare poți face în continuare rutare geo, dar ai nevoie de un serviciu separat de geolocalizare IP sau de o bază de date. Baza de date GeoIP2 a MaxMind este precisă, dar este o altă dependență de actualizat și întreținut. cf-ipcountry este gratuit, mereu actualizat și deja în cerere. Nu există niciun motiv întemeiat să o faci altfel.

Un VPS, toată lumea

Originea mea este un singur Hetzner CPX31 în Nürnberg. Nürnberg este bine pentru Germania și regiunea DACH. Pentru un utilizator din New York sau Singapore, accesarea directă a acelei mașini adaugă latență. Cu Cloudflare în față, răspunsurile din cache sunt servite de cel mai aproape din cele 300-plus noduri edge ale lor. Paginile statice, postările de blog, imaginile și output-ul Next.js compilat sunt toate cacheable. Originea vede în principal apeluri API, trimiteri de formulare și render-uri SSR dinamice care nu pot fi puse în cache.

Regulile de cache îți permit să fii explicit despre ce se pune în cache și pentru cât timp. Postări de blog: o zi. Active statice în /_next/static/: treizeci de zile. Rute API: bypass. Configurezi asta o dată în dashboard-ul Cloudflare sau prin API-ul lor și uiți de ea. Caddy sau nginx de pe serverul de origine nu trebuie să se gândească deloc la cache. Cloudflare îl gestionează la edge.

• CDN global: 300-plus locații edge, conținut static servit aproape de vizitator
• WAF: seturile de reguli gestionate blochează tiparele de atac OWASP Top 10 la nivelul gratuit
• Protecție DDoS: L3/L4 mereu activă, L7 configurabilă cu rate limiting
• SSL la edge: Cloudflare termină TLS, deci originea ta are nevoie doar de un certificat self-signed sau Let's Encrypt
• Bot Fight Mode: blochează boții malițioși cunoscuți la edge, gratuit
• Analytics: numărul de cereri, raporturi cache/non-cache, lățime de bandă economisită
• Header cf-ipcountry: țara vizitatorului injectată la fiecare cerere, niciun serviciu suplimentar necesar

Acordarea încrederii IP-urilor Cloudflare pe origine

Un pas de configurare ușor de ratat: serverul tău de origine trebuie să aibă încredere în IP-urile proxy ale Cloudflare și să blocheze conexiunile directe. Dacă omiți asta, oricine descoperă IP-ul originii tale poate ocoli complet WAF-ul. Securizezi asta în două moduri. În primul rând, configurezi reverse proxy-ul să aibă încredere în IP-urile reale ale vizitatorilor doar când cererea vine dintr-un range de IP Cloudflare cunoscut. Cloudflare publică aceste range-uri la cloudflare.com/ips. În al doilea rând, pe Hetzner, adaugi o regulă de firewall care permite doar portul 443 inbound din range-urile de IP Cloudflare, astfel încât VPS-ul să nu fie accesibil direct.

Iată cum fac asta cu Caddy. Directiva trusted_proxies îi spune lui Caddy căror IP-uri upstream să le acorde încredere pentru headere precum X-Forwarded-For și cf-ipcountry. Linia header_up transmite codul de țară către aplicația Node ca X-Visitor-Country.

# Caddyfile — trust Cloudflare IPs, read cf-ipcountry header
{
  servers {
    trusted_proxies static 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22
      104.16.0.0/13 104.24.0.0/14 108.162.192.0/18 131.0.72.0/22
      141.101.64.0/18 162.158.0.0/15 172.64.0.0/13 173.245.48.0/20
      188.114.96.0/20 190.93.240.0/20 197.234.240.0/22 198.41.128.0/17
  }
}

:443 {
  tls {
    dns cloudflare YOUR_API_TOKEN
  }

  # Pass the geo country header downstream so your app can read it
  header_up X-Visitor-Country '{http.request.header.Cf-Ipcountry}'

  reverse_proxy localhost:3000
}

Păstrarea configurației zonei într-un fișier markdown de memorie

Folosesc Claude Code ca agent de coding pe toate proiectele mele. Când un agent ajută cu infrastructura, are nevoie de context care să supraviețuiască unei singure sesiuni. Setările zonei Cloudflare, ce headere să fie de încredere, logica regulilor de cache, locația token-ului API: nimic din toate acestea nu ar trebui re-explicat de fiecare dată. Soluția mea este un fișier CLOUDFLARE.md inclus în repository la rădăcina proiectului.

Fișierul nu este documentație. Este un cheat sheet de operații pe care agentul îl citește la începutul oricărei sesiuni care atinge rețelistică sau deployment. Când se schimbă o setare, îi spun agentului să actualizeze fișierul. Devine memoria persistentă care supraviețuiește reset-urilor ferestrei de context.

Iată un exemplu reprezentativ al cum arată acel fișier. Ținut factual și scurt. Fără proză. Doar lucrurile de care un agent ar avea nevoie pentru a acționa corect.

# Cloudflare Ops Memory

## Zone settings (applied in Cloudflare dashboard)
- SSL/TLS mode: Full (strict)
- Always Use HTTPS: on
- Min TLS Version: 1.2
- HSTS: enabled, max-age 31536000, includeSubDomains

## Trusted proxy IPs
Cloudflare publishes its IP ranges at https://www.cloudflare.com/ips/
Update the Caddy/nginx trusted_proxies list whenever Cloudflare rotates ranges.

## Headers we rely on
- cf-ipcountry: ISO 3166-1 alpha-2 country code for the visitor
  Used for: South Tyrol (IT) => route to German (de) locale
- cf-ray: Cloudflare request ID, useful in error logs
- cf-connecting-ip: real visitor IP after CF proxy

## Cache rules (Page Rules or Cache Rules)
- /blog/*   TTL 1 day, cache everything
- /api/*    Bypass cache
- /_next/static/*  TTL 30 days, cache everything

## WAF
- OWASP Core Ruleset: enabled, sensitivity medium
- Bot Fight Mode: on

## Notes for agent
- DNS A record for jumpinotech.com => Hetzner VPS IP, proxied (orange cloud)
- When changing origin IP: update Hetzner server, then update DNS A record in CF dashboard
- CF_ZONE_ID and CF_API_TOKEN stored in 1Password under "Cloudflare jumpinotech"

Cu acest fișier în repository, o nouă sesiune pornește cu context. Agentul știe ce headere să transmită, ce mod SSL este setat, unde se află token-ul API și care este strategia de caching. Nu halucinează setări și nu pune întrebări de clarificare despre lucruri care ar trebui să fie fapte cunoscute. Fișierul este suficient de scurt pentru a fi lipit integral ca instrucțiune și suficient de specific pentru a fi acționabil imediat.

Când aș sări Cloudflare

Cloudflare este implicit-ul corect pentru aproape orice proiect. Dar există cazuri limită oneste. Dacă originea ta se află deja pe o platformă distribuită cu propria rețea edge, adăugarea Cloudflare în față adaugă un hop fără prea mult beneficiu. Dacă ai nevoie de TLS strict end-to-end cu propriul lanț de certificate și niciun proxy intermediar care să atingă traficul, poziția Cloudflare în mijloc este o problemă. Unele industrii reglementate au cerințe privind unde se rezolvă DNS-ul și cine proxiază traficul care fac din Cloudflare un risc de conformitate în loc de un atu.

Pentru un stack self-hosted pe un singur VPS, niciuna din aceste excepții nu se aplică. Nivelul gratuit face muncă reală. WAF-ul, CDN-ul, absorbția DDoS, header-ul de țară, analytics: ar trebui să cheltuiești timp real de inginerie construind o acoperire echivalentă singur. Cloudflare ți-o dă la costul redirecționării nameserverelor. Este o decizie ușoară.

Cazul de rutare al Tirolului de Sud este o bună ilustrare. Fără cf-ipcountry, aș avea nevoie de o bază de date de geolocalizare, un cron job pentru a o ține actualizată și o căutare suplimentară la fiecare cerere. Cu Cloudflare este un header. Site-ul servește limba corectă pentru Tirolul de Sud trilingv pentru că Cloudflare spune unde se află vizitatorul, iar middleware-ul are logica să facă alegerea corectă de acolo.