Moldova · Proxy_Hosting · 27-10-2026
Un reverse proxy stă între vizitator și aplicația ta: primește cererea HTTP, o transmite către serverul intern care chiar generează pagina și returnează răspunsul. Pe un shared hosting ieftin de la providerii locali (de la 25–40 de lei pe lună pentru un plan de bază) de obicei nu ai acces la această configurație, dar pe un VPS de la 250–400 de lei pe lună, unde ai root, devine o unealtă zilnică. Motivul cel mai frecvent pentru care se apelează la el nu e securitatea, ci faptul că pe același IP rulează mai multe site-uri și certificate, iar traficul trebuie direcționat corect.
În practică, un web proxy bine pus la punct rezolvă trei lucruri simultan: ascunde portul real al aplicației, termină conexiunea TLS într-un singur loc și permite mutarea backendului pe alt server fără să schimbi DNS-ul. Pentru un magazin online cu sediul în Chișinău care ține aplicația pe un VPS în România și vrea domeniul .md gestionat local, asta înseamnă că poți schimba furnizorul din spate într-o noapte, fără downtime vizibil.
nginx e alegerea standard când ai multe conexiuni simultane și conținut static: consumă puțină memorie și duce lejer câteva mii de cereri pe secundă pe un VPS de 2 GB RAM. Apache rămâne relevant când ai aplicații vechi cu fișiere .htaccess pe care nu vrei să le rescrii. O combinație des întâlnită la noi este nginx în față și Apache în spate, exact pentru a păstra regulile vechi funcționale.
Pentru un subdomeniu nou, configurația clasică presupune un bloc de server separat și un proxy_pass către portul aplicației. Dacă vrei să faci nginx reverse proxy subdomain către alt domeniu — de exemplu api.site.md care trimite către un serviciu găzduit pe alt provider — folosești directivul proxy_set_header Host pentru ca backendul să știe ce domeniu a fost cerut. Fără el, aplicația va genera linkuri greșite și vei pierde sesiuni.
Cea mai frecventă eroare pe care o vezi în loguri este 504 Gateway Timeout. Cauza nu e aproape niciodată rețeaua, ci un backend lent: o interogare SQL neoptimizată, un script PHP care așteaptă un API extern sau un cron care blochează tabela. Directivele de tip proxy_connect_timeout controlează cât așteaptă nginx după conectarea la backend, nu după răspunsul complet — confuzia dintre ele duce la ore pierdute.
Dacă rulezi Kubernetes cu ingress-nginx, aceleași principii se aplică prin adnotări. Adnotarea nginx.ingress.kubernetes.io/proxy-connect-timeout se setează în secunde și trebuie corelată cu proxy-read-timeout, altfel conexiunea se închide în timp ce aplicația încă procesează. Valoarea implicită de 60 de secunde e prea mică pentru rapoarte sau exporturi mari, dar prea mare dacă o lași așa pentru toate rutele.
Măsoară timpul real al backendului cu curl direct pe portul intern, ocolind proxy-ul. Dacă răspunsul vine în 200 ms local și în 8 secunde prin proxy, problema e în configurație, nu în aplicație. Verifică apoi dacă backendul rezolvă corect numele: un DNS intern greșit produce întârzieri de câteva secunde la fiecare cerere, mai ales când resolverul providerului e lent.
Nu în ultimul rând, ține cont de certificate. Când termini TLS la proxy, backendul primește trafic HTTP simplu, iar aplicația poate genera linkuri http:// care declanșează avertismente în browser. Trimiterea headerului X-Forwarded-Proto rezolvă problema, dar trebuie configurată și în aplicație, nu doar în nginx.
O altă utilizare frecventă în rândul cititorilor din Moldova este proxy-ul ca instrument de acces. Un web proxy gratuit sau un server proxy free pare comod, dar în practică majoritatea sunt lente, pline de reclame și îți văd tot traficul. Pentru verificarea modului în care un site se încarcă dintr-o altă țară — de exemplu cum arată o pagină din România față de una servită din Serbia — un proxy plătit de 3–5 dolari pe lună e mai previzibil decât zece variante gratuite.
În dezvoltare, setarea unui proxy în Postman sau în Python prin urllib.request proxy este o operațiune de rutină pentru testarea API-urilor cu restricții geografice. Aici greșeala tipică e să uiți să excluzi localhost din regulile de proxy, iar cererile către serverul tău de test pleacă în exterior și se blochează. În Windows, setările se fac fie la nivel de sistem, fie per aplicație, iar comenzile din linia de comandă ignoră adesea setările din interfață.
Un detaliu care prinde des pe administratorii din regiune: proxy-ul rezidențial static e mult mai scump decât cel datacenter, dar are altă rată de blocare. Pentru scraping ocazional nu merită; pentru monitorizarea prețurilor la comercianți locali, diferența se simte în numărul de captcha-uri rezolvate manual.
Prima greșeală este să muți tot traficul deodată. Testează pe un subdomeniu cu trafic real redus, compară logurile o săptămână și abia apoi mută domeniul principal. A doua: uitarea fișierelor statice mari — dacă proxy-ul are limită de dimensiune a cererii, upload-urile de imagini sau fișiere de backup eșuează cu 413 fără un mesaj clar în browser.
A treia greșeală ține de cache. Un proxy care cache-uiește agresiv pagini dinamice servește conținut vechi utilizatorilor autentificați. Exclude cookie-urile de sesiune din cache și verifică rezultatul cu un cont de test, nu doar în modul incognito. Pe un site de anunțuri cu mii de vizitatori zilnic, o astfel de eroare înseamnă că un utilizator vede anunțurile altuia — și o reclamație justificată.
În final, documentează configurația. Un fișier scurt cu ce porturi ascultă backendul, ce headere se trimit și ce limite sunt setate economisește ore întregi când colegul preia serverul sau când providerul din Moldova îți schimbă planul și trebuie să migrezi în altă parte.