Moldova · Proxy_Hosting · 27-10-2026
Un tipar care apare des la administratorii de hosting din Moldova: aplicația rulează pe Apache cu module vechi (.htaccess, mod_rewrite, PHP în modul prefork), dar traficul vine prea lent sub concurență. Soluția clasică nu este să rescrii aplicația, ci să pui nginx în față ca proxy invers și să lași Apache pe un port intern, de regulă 8080. Nginx servește fișierele statice direct și preia conexiunile lente, iar Apache primește doar cererile dinamice.
Pe un VPS de la un furnizor local cu 2 vCPU și 4 GB RAM, diferența se simte la circa 300–400 de vizitatori simultani: fără nginx, Apache umple coada de conexiuni și începe să răspundă în 3–5 secunde; cu nginx în față, timpul rămâne sub o secundă, pentru că legăturile keep-alive sunt ținute de nginx, nu de procesele Apache.
Configurația minimă cere trei lucruri: un bloc server care ascultă pe 443, un location / cu proxy_pass http://127.0.0.1:8080 și headerele Host, X-Real-IP și X-Forwarded-For. Fără ultimele două, logurile Apache arată doar adresa 127.0.0.1, iar orice limitare pe IP devine inutilă.
Cel mai frecvent simptom după activarea proxy-ului este eroarea 500, deși aplicația funcționa perfect înainte. În nouă cazuri din zece, cauza nu este codul, ci un detaliu de configurare. Verifică întâi error_log al nginx: dacă apare mesajul „upstream sent too big header", problema vine de la headerele lungi trimise de Apache, iar soluția este să crești bufferele — proxy_buffer_size 16k și proxy_buffers 4 16k.
A doua sursă tipică este limita de dimensiune a corpului cererii. Formularele cu fișiere, importurile CSV sau panourile de administrare care trimit loturi mari lovesc implicit limita de 1 MB. Directiva proxy-body-size trebuie setată explicit, de exemplu la 25m, altfel nginx returnează 413 sau, dacă aplicația nu tratează corect răspunsul, ajungi tot la o pagină 500.
Nu în ultimul rând, verifică dacă Apache ascultă într-adevăr pe 127.0.0.1:8080 și nu pe 80. După ce schimbi portul în ports.conf și în virtual host, repornește serviciul și testează cu curl -I http://127.0.0.1:8080 înainte să dai drumul la trafic. Un detaliu de cinci minute economisește o noapte de panică.
Aplicațiile moderne — chat-uri, panouri de monitorizare, notificări în timp real — folosesc WebSocket. Proxy-ul invers nu îl tratează la fel ca pe HTTP obișnuit, pentru că cererea cere un upgrade de protocol. Fără headerele Upgrade și Connection setate corect, conexiunea cade imediat după handshake, iar utilizatorul vede un mesaj de tipul „disconnected" în interfață.
Blocul corect arată astfel: în location /ws/ adaugi proxy_http_version 1.1, proxy_set_header Upgrade $http_upgrade și proxy_set_header Connection "upgrade". Pentru SSL, certificatul stă pe nginx, nu pe Apache — Apache rămâne pe HTTP simplu în rețeaua internă. Această separare simplifică reînnoirea certificatelor: un singur loc de actualizat, indiferent câte virtual hosturi ai.
Un timeout prea scurt omoară conexiunile inactive. Setează proxy_read_timeout 3600s dacă aplicația ține socketul deschis, altfel nginx îl închide după 60 de secunde și clientul se reconectează în buclă, consumând resurse degeaba.
Când ai nevoie nu de acces spre aplicație, ci de control asupra traficului care iese din rețea, Squid rămâne cea mai matură soluție. Configurarea pas cu pas pornește de la fișierul /etc/squid/squid.conf: definești portul, apoi ACL-urile pentru rețeaua locală, de exemplu acl retea src 192.168.1.0/24, și permiți doar rețeaua respectivă cu http_access allow retea. Orice altceva rămâne blocat, ceea ce împiedică transformarea serverului într-un proxy deschis.
Pe un server dintr-un centru de date din Chișinău, un Squid bine configurat cu cache de 2–4 GB reduce consumul de trafic extern cu 20–30% la rețelele mici care accesează aceleași pagini. Adaugă autentificare basic pentru utilizatorii din afara rețelei și loghează accesul separat, ca să poți identifica rapid un post care descarcă necontrolat.
Ordinea de pornire contează: nginx trebuie să pornească după Apache, altfel la reboot primești 502 până când backend-ul urcă. Folosește systemd cu dependențe explicite sau un health check simplu care reîncarcă nginx dacă upstream-ul nu răspunde.
Pentru aplicațiile Java care ies prin proxy, clientul HTTP trebuie să primească explicit gazda și portul, altfel conexiunea merge direct și regulile tale sunt ocolite. Iar dacă lucrezi cu un furnizor de hosting local, întreabă din start dacă permite proxy invers pe portul 443 și dacă blocarea portului 25 sau a celui de ieșire afectează traficul tău.
Monitorizează cele trei cifre care contează: numărul de conexiuni active către upstream, timpul de răspuns al lui Apache și frecvența erorilor 5xx. Când prima crește și a doua scade, ai găsit un backend lent; când a treia sare peste 1%, problema e în configurație, nu în trafic.