Moldova · Proxy_Hosting · 27-10-2026
Un server Nginx pus în fața aplicației rezolvă simultan trei probleme care apar la orice proiect serios găzduit în Moldova: terminarea TLS, distribuția cererilor către procesele din spate și ascunderea portului real al aplicației. Când închiriezi un VPS de la un furnizor local precum un host din Chișinău sau Bălți, primești de obicei un singur IP public. Toate serviciile — site-ul, API-ul, panoul de administrare — trebuie să împartă acel IP, iar proxy-ul invers este singurul mod curat de a face asta.
Configurarea de bază stă într-un fișier din /etc/nginx/sites-available/ și conține un bloc server cu listen 443 ssl, certificatele Let's Encrypt și un location / care trimite totul către proxy_pass http://127.0.0.1:3000. Din acel moment, aplicația nu mai ascultă pe IP-ul public și nu mai are nevoie de certificat propriu. Un detaliu pe care mulți îl ratează: fără proxy_set_header Host $host și X-Forwarded-For, aplicația va vedea doar adresa 127.0.0.1 și va genera linkuri greșite în emailuri sau în redirect-uri.
Blocul pentru portul 80 trebuie să conțină doar return 301 https://$host$request_uri. Este cea mai simplă și mai rapidă variantă, mult mai bună decât un rewrite cu expresii regulate. O greșeală frecventă la proiectele care stau în spatele unui CDN sau al unui alt proxy: Nginx primește deja trafic HTTPS de la echipamentul din față, iar regula de redirecționare creează o buclă infinită. Soluția este să verifici antetul X-Forwarded-Proto și să redirecționezi doar când acesta lipsește sau are valoarea http.
Pe un server modest cu 2 GB RAM, testat cu trafic de test din rețeaua locală, o astfel de configurare ține lejer câteva sute de conexiuni simultane. Consumul de memorie rămâne sub 40 MB pentru procesele worker, ceea ce contează când mai rulezi și o bază de date pe același VPS.
Aplicațiile moderne — chat-uri, panouri cu actualizări în timp real, notificări — folosesc WebSocket. Fără configurare specială, conexiunea cade imediat după handshake, iar în consola browserului apare un 400 sau un timeout. Motivul: protocolul necesită actualizarea conexiunii de la HTTP la WebSocket, iar Nginx nu face asta implicit.
În blocul location dedicat endpoint-ului WebSocket adaugi proxy_http_version 1.1, proxy_set_header Upgrade $http_upgrade, proxy_set_header Connection "upgrade" și mărești proxy_read_timeout la 3600 de secunde. Ultimul parametru este crucial: valoarea implicită de 60 de secunde închide conexiunile inactive, iar utilizatorul vede că mesajele nu mai ajung deși pagina pare încărcată.
Un scenariu tipic la o echipă din Chișinău care lucra la un panou de monitorizare: ping-ul către server era bun, dar graficul se oprea la fiecare minut. Cauza nu era rețeaua, ci timeout-ul implicit. După ajustare, conexiunea a rezistat zile întregi fără întreruperi.
Dacă frontend-ul este servit de un server de dezvoltare pe portul 5173, iar API-ul pe 8000, folosești două blocuri location: unul pentru /api/ cu proxy_pass http://127.0.0.1:8000/ și altul pentru restul. Atenție la slash-ul final din proxy_pass — el decide dacă prefixul este păstrat sau eliminat, iar diferența produce erori 404 greu de diagnosticat.
Când apare „proxy not working”, ordinea verificărilor economisește ore. Întâi rulezi nginx -t pentru sintaxă, apoi systemctl status nginx și abia după aceea te uiți în /var/log/nginx/error.log. În nouă cazuri din zece, răspunsul este acolo: un certificat expirat, un upstream care nu răspunde sau o permisiune refuzată la fișierul socket.
Al doilea pas este să testezi direct upstream-ul, ocolind Nginx: curl -I http://127.0.0.1:3000. Dacă răspunde, problema e în configurația proxy-ului; dacă nu, aplicația nu a pornit. Folosește curl -v pentru a vedea antetele complete și pentru a confirma dacă redirecționarea HTTPS se produce o singură dată sau intră în buclă.
Un caz concret întâlnit des la proiectele găzduite pe VPS-uri moldovenești: furnizorul blochează portul 80 la nivel de firewall, iar validarea certificatului Let's Encrypt eșuează. Verificarea se face cu ufw status sau cu panoul furnizorului, nu cu presupuneri.
Adaugă un format de log care include $upstream_response_time și $request_time. Diferența dintre ele arată dacă întârzierea vine din aplicație sau din rețea. Dacă upstream-ul răspunde în 50 de milisecunde, dar clientul așteaptă două secunde, problema este banda sau latența către vizitatori, nu codul.
Pentru proiectele cu trafic din afara țării, un proxy de caching în față reduce timpii de răspuns vizibil. Merită configurat proxy_cache pentru fișierele statice, cu o durată de 7 zile, și dezactivat pentru API. Astfel, un articol sau o imagine se încarcă din memoria serverului, nu din aplicație.
În final, păstrează configurația în Git. Fiecare modificare făcută direct pe server fără urmă în istoric se pierde la prima reinstalare și transformă o simplă actualizare într-o noapte pierdută.