NGINX vs Caddy: ce reverse proxy alegi pentru serverul firmei

Ai o aplicație pe serverul firmei: un CRM, o platformă de documente, un portal pentru clienți. Browserul nu vorbește direct cu ea. Între browser și aplicație stă un program care primește cererile, le trimite mai departe și răspunde pentru HTTPS. Acel program este reverse proxy-ul, iar în practică alegerea se face între două nume: NGINX și Caddy.

Întrebarea apare de obicei la prima instalare sau la primul certificat expirat. Cineva a configurat NGINX acum doi ani, certificatul nu s-a reînnoit, iar aplicația afișează un avertisment roșu de securitate exact când un client vrea să intre. Sau invers: ai citit că Caddy „face totul singur” și vrei să știi ce pierzi dacă nu alegi standardul.

Pentru o firmă mică, cu două-trei aplicații pe un server Linux și fără un administrator care să se ocupe zilnic de el, Caddy este alegerea implicită. NGINX rămâne alegerea corectă când echipa îl cunoaște deja, când ai nevoie de module sau integrări pe care Caddy nu le are sau când serverul este Windows. Restul articolului explică de ce și cum verifici în ce situație ești.

Ce face reverse proxy-ul și de ce contează alegerea

Reverse proxy-ul are patru roluri în fața unei aplicații de business:

• Termină HTTPS. El deține certificatul TLS, criptează traficul cu browserul și vorbește necriptat, în rețeaua internă, cu aplicația.
• Rutează. crm.firma-ta.ro merge la un container, documente.firma-ta.ro la altul, pe același server și aceeași adresă IP.
• Protejează. Adaugă antetele de securitate, limitează numărul de cereri pe minut, respinge ce nu are ce căuta.
• Jurnalizează. Vezi cine a accesat ce, independent de aplicație.

Aplicațiile moderne livrate prin Docker, inclusiv cele pe care le instalăm noi la clienți, presupun că există un asemenea strat în față. Ce diferă între NGINX și Caddy nu este ce fac, ci cât efort cere fiecare ca să facă lucrurile corect și să rămână corecte peste un an.

NGINX: standardul pe care îl știe toată lumea

NGINX este scris în C, publicat sub licență BSD cu două clauze și dezvoltat astăzi de F5, care vinde și varianta comercială NGINX Plus. Conform W3Techs, la 9 octombrie 2026 rulează pe aproximativ 30% dintre site-urile cu server identificabil. Este serverul pe care îl găsești în orice tutorial, în orice imagine Docker a unei aplicații web și în CV-ul oricărui administrator Linux.

Puterea lui vine din maturitate și din ecosistem. Modulele acoperă orice: cache, compresie, geolocalizare, autentificare, streaming. Configurația este un fișier text cu blocuri server și location, iar reîncărcarea ei cu nginx -s reload nu întrerupe conexiunile existente: procesul principal verifică sintaxa, pornește procese noi și le închide pe cele vechi după ce termină cererile în curs.

Slăbiciunea lui, pentru o firmă mică, este tot ce stă în jurul lui. NGINX nu obține singur certificate HTTPS. Ai nevoie de un program separat, de regulă certbot, de un cron care îl rulează și de cineva care observă când cronul nu mai merge. HTTP/3, protocolul pe care îl folosesc browserele moderne pe conexiuni mobile, este marcat experimental și nu este inclus în compilarea standard. Iar un fișier de configurare pentru trei aplicații cu HTTPS, redirectare și antete de securitate ajunge ușor la o sută de rânduri pe care, peste un an, nimeni nu-și mai amintește de ce arată așa.

Caddy: HTTPS din prima clipă, fără pași suplimentari

Caddy este scris în Go, publicat sub licență Apache 2.0 și livrat ca un singur fișier executabil, fără dependențe. Versiunea curentă, 2.11.7, a apărut pe 3 octombrie 2026. Cota de piață măsurată de același W3Techs este de aproximativ 1%, deci îl vei găsi rar în tutoriale și în imaginile Docker ale altora.

Ce îl face interesant este un singur lucru, făcut complet: HTTPS automat. Când scrii în configurație un nume de domeniu public, Caddy obține certificatul de la Let's Encrypt sau ZeroSSL, îl reînnoiește în fundal înainte să expire și redirectează singur HTTP către HTTPS. Nu există certbot, nu există cron, nu există certificat expirat pentru că a uitat cineva. Pentru localhost și adrese IP emite certificate autosemnate, utile la teste.

Pe deasupra, HTTP/1.1, HTTP/2 și HTTP/3 sunt activate implicit, configurația se scrie într-un format numit Caddyfile, în care o aplicație întreagă încape în trei rânduri, iar caddy reload aplică modificările fără întrerupere. Comanda caddy validate încarcă efectiv configurația, nu doar îi verifică sintaxa, deci prinde erori pe care un simplu test de sintaxă le-ar lăsa să treacă.

Limita structurală: modulele suplimentare, de exemplu pentru validare DNS la un anumit furnizor, se compilează în executabil cu unealta xcaddy. Nu se încarcă la rulare, ca la NGINX pe distribuțiile Linux. Pentru majoritatea instalărilor nu ai nevoie de niciun modul suplimentar, dar când ai, pasul de compilare trebuie repetat la fiecare actualizare.

Comparația pe criteriile care contează la o firmă mică

Coloana „Windows” merită o explicație. Dacă serverul firmei este Windows și nu vrei un strat Linux sau Docker, NGINX pentru Windows este considerat beta de producătorul lui, cu un singur proces care lucrează efectiv și fără suport pentru QUIC. Caddy rulează pe Windows ca pe Linux, inclusiv ca serviciu.

Aceeași aplicație, în ambele configurații

Presupunem un CRM care ascultă intern pe portul 8080 și trebuie publicat la crm.firma-ta.ro. În Caddy, fișierul complet este:

crm.firma-ta.ro {
    reverse_proxy localhost:8080
}

Certificatul, reînnoirea, redirectarea de pe HTTP și HTTP/3 sunt incluse. În NGINX, după ce ai obținut separat certificatul cu certbot, blocul minim arată așa:

server {
    listen 80;
    server_name crm.firma-ta.ro;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl;
    http2 on;
    server_name crm.firma-ta.ro;
    ssl_certificate     /etc/letsencrypt/live/crm.firma-ta.ro/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/crm.firma-ta.ro/privkey.pem;
    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Nu este greu. Dar sunt douăzeci de rânduri în loc de trei, plus certbot, plus cronul de reînnoire, plus antetele X-Forwarded-* pe care Caddy le pune singur. Fiecare rând în plus este un loc în care se poate greși și un lucru de explicat celui care preia serverul.

Cum alegi

1. Numără aplicațiile și oamenii. Două-trei aplicații, un server, nimeni plătit să-l administreze zilnic: Caddy. Zeci de site-uri, trafic mare, echipă care face asta de meserie: NGINX, pentru că ecosistemul și experiența echipei valorează mai mult decât confortul.
2. Verifică ce știe deja echipa. Dacă administratorul vostru, intern sau externalizat, lucrează de ani de zile cu NGINX, păstrează-l. Un instrument cunoscut și bine întreținut bate unul nou și neglijat.
3. Verifică cerințele aplicației. Unele aplicații vin cu configurație NGINX gata scrisă sau cer module pe care Caddy nu le are. Citește documentația de instalare înainte să alegi.
4. Verifică sistemul de operare. Server Windows fără Docker: Caddy. Linux: oricare.
5. Întreabă cum se expune serverul pe internet. Dacă aplicația stă în spatele unui tunel Cloudflare, certificatul public este gestionat de Cloudflare, iar avantajul principal al lui Caddy contează mai puțin. Reverse proxy-ul rămâne necesar pentru rutare și antete, dar alegerea devine o chestiune de preferință.

Unde nu se potrivește

Caddy nu este răspunsul universal, iar limitele lui trebuie știute înainte:

• Comunitate mică. La o problemă neobișnuită, vei găsi de zece ori mai puține răspunsuri decât pentru NGINX. Forumul oficial este activ, dar nu are volumul Stack Overflow pentru NGINX.
• Module compilate. Orice extensie în afara celor standard înseamnă xcaddy build și o procedură proprie de actualizare, ceea ce anulează o parte din simplitate.
• Limitele Let's Encrypt. Automatizarea cere un domeniu public cu DNS corect și porturile 80 și 443 accesibile. Let's Encrypt permite maximum 50 de certificate pe domeniu înregistrat la 7 zile și 5 pentru același set de nume; cine testează la nesfârșit pe același domeniu se blochează.
• Fără suport comercial. NGINX Plus există pentru firmele care au nevoie de un contract de suport cu producătorul. Pentru Caddy, suportul vine de la comunitate sau de la partenerul IT.

Și NGINX are situații în care nu este alegerea bună: pe Windows, cum am arătat, și la firma unde nimeni nu se uită la server între două incidente. Un NGINX configurat corect acum doi ani și neatins de atunci este exact serverul la care certificatul expiră într-o sâmbătă.

Niciunul dintre ele nu înlocuiește igiena de bază: actualizări, parole bune, backup, firewall. Reverse proxy-ul este stratul din față, nu toată apărarea.

Cum procedăm noi

La instalările produselor noastre pe serverul clientului, de exemplu Brio CRM prin Docker Compose, aplicația nu este niciodată expusă direct: în față stă un reverse proxy care termină HTTPS și rutează către containere. Alegerea lui urmează regula de mai sus. La firmele fără administrator propriu propunem Caddy, pentru că reduce la zero lista de lucruri care expiră. La firmele care au deja NGINX și o echipă care îl stăpânește, îl păstrăm și documentăm configurația, în loc să schimbăm un instrument care funcționează.

Pentru clienții cu management IT externalizat, reverse proxy-ul intră în monitorizare ca orice altă componentă: versiune, certificat, jurnal de erori.

Dacă ai un server cu aplicații în spatele unui NGINX sau Caddy și nu știi când expiră certificatul sau cine îl reînnoiește, trimite-ne configurația. Îți spunem în câteva minute ce lipsește și dacă merită schimbat ceva.