Ghid nginx ca reverse proxy
Pe această pagină
Un reverse proxy stă în fața aplicațiilor tale și le transmite cererile vizitatorilor. Cu nginx în față, o aplicație Node.js, un container Docker sau un dashboard care rulează pe un port oarecare devine https://app.example.com, cu HTTPS, headere corecte și un singur loc din care gestionezi totul.
Acest ghid configurează nginx ca reverse proxy pe Ubuntu, pas cu pas: blocul server, headerele, WebSockets, HTTPS gratuit și erorile pe care le vei întâlni cel mai probabil.
Ce face un reverse proxy
- Un singur punct de intrare public. nginx ascultă pe porturile 80 și 443 și trimite fiecare domeniu sau cale către aplicația potrivită, astfel încât aplicațiile nu sunt niciodată expuse direct pe internet.
- HTTPS într-un singur loc. nginx se ocupă de certificate; aplicațiile din spatele lui pot folosi HTTP simplu pe localhost.
- Mai multe aplicații pe un singur server.
app.example.com,api.example.comșiexample.com/blogpot duce fiecare la alt serviciu. - Extra: compresie, cache, limite de upload și reguli de acces, fără să atingi aplicația.
Pasul 1: Instalează nginx
sudo apt update sudo apt install nginx
Deschide http://your-server-ip și ar trebui să vezi pagina de bun venit nginx. Dacă folosești ufw, permite traficul web cu sudo ufw allow 'Nginx Full'.
Asigură-te că aplicația rulează și răspunde pe server, de exemplu cu curl http://127.0.0.1:3000. Dacă asta eșuează, va eșua și nginx.
Rulează nginx și aplicațiile tale cu acces root complet: planurile HytHost KVM VPS pornesc de la €2.92/lună.
Vezi planurile VPSPasul 2: Creează blocul server pentru proxy
Pe Ubuntu, fiecare site are un fișier în /etc/nginx/sites-available/, activat printr-un link în sites-enabled. Creează /etc/nginx/sites-available/app.example.com:
server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Activează-l, testează configurația și reîncarcă:
sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx
Îndreaptă înregistrarea A a domeniului spre serverul tău, iar http://app.example.com îți afișează acum aplicația. Rulează mereu nginx -t înainte de reîncărcare: prinde greșelile de scriere înainte să-ți pice site-ul.
Headerele și slash-ul de la final
Hosttransmite domeniul cerut de vizitator. Fără el, nginx trimite adresa dinproxy_pass, iar aplicațiile care construiesc linkuri pe baza hostului nu mai funcționează corect.X-Real-IPșiX-Forwarded-Fortransmit adresa IP a vizitatorului. Fără ele, fiecare cerere pare să vină de la127.0.0.1.X-Forwarded-Protoîi spune aplicației dacă vizitatorul a folosit HTTPS, ca să nu intre într-o buclă de redirecționări.
Pachetul nginx din Ubuntu include aceste linii în /etc/nginx/proxy_params, așa că include proxy_params; e o scurtătură.
Slash-ul de la final contează. Pentru o aplicație aflată sub o cale:
location /app/ {
proxy_pass http://127.0.0.1:3000/;
}
Cu slash după port, /app/login ajunge la aplicație ca /login. Fără el, aplicația primește calea completă /app/login.
WebSockets
Aplicațiile de chat, dashboardurile live și multe panouri de administrare folosesc WebSockets, care au nevoie de două headere în plus. Adaugă acest map o singură dată, în blocul http, de exemplu într-un fișier nou /etc/nginx/conf.d/websocket.conf:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
Apoi, în location:
proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_read_timeout 1h;
nginx închide o conexiune proxy prin care nu trece nimic timp de 60 de secunde; un proxy_read_timeout mai lung ține deschise WebSocket-urile inactive. proxy_http_version 1.1 e implicit abia de la nginx 1.29.7, iar Ubuntu 24.04 vine cu 1.24, deci păstrează linia.
Pasul 3: HTTPS gratuit cu Certbot
sudo snap install --classic certbot sudo ln -s /snap/bin/certbot /usr/local/bin/certbot sudo certbot --nginx -d app.example.com
Certbot obține un certificat Let's Encrypt gratuit, adaugă setările HTTPS în blocul server și poate redirecționa HTTP spre HTTPS. Reînnoiește certificatul automat; verifică cu sudo certbot renew --dry-run. Mai multe despre certificate în cum obții un certificat SSL gratuit.
Cum rezolvi erorile 502, 504 și 413
| Eroare | Cauza obișnuită | Soluție |
|---|---|---|
| 502 Bad Gateway | nginx nu poate ajunge la aplicație: e oprită, s-a blocat sau ascultă pe alt port ori altă adresă | Pornește aplicația, verifică portul cu curl http://127.0.0.1:PORT, citește /var/log/nginx/error.log |
| 504 Gateway Timeout | Aplicația a avut nevoie de mai mult de 60 de secunde ca să răspundă | Accelerează cererea sau mărește proxy_read_timeout pentru acel location |
| 413 Request Entity Too Large | Un upload depășește limita implicită nginx de 1 MB | Setează client_max_body_size 50m; în blocul server |
| Buclă de redirecționare | Aplicația nu știe că vizitatorul a folosit HTTPS | Transmite X-Forwarded-Proto și spune-i aplicației că rulează în spatele unui proxy |
După fiecare modificare: sudo nginx -t, apoi sudo systemctl reload nginx.
Rulează-l pe un VPS HytHost
Un reverse proxy are nevoie de un server pe care controlezi porturile 80 și 443. Planurile VPS HytHost rulează pe KVM cu acces root complet, stocare SSD și protecție DDoS; alege Ubuntu 24.04 și urmează pașii de mai sus. Îți rulezi aplicațiile în containere? Instalează mai întâi Docker cu cum instalezi Docker pe Ubuntu și leagă porturile containerelor de 127.0.0.1, ca doar nginx să ajungă la ele.
Întrebări frecvente
Un reverse proxy transmite cererile către una sau mai multe aplicații din spatele lui. Un load balancer este un reverse proxy care distribuie cererile între mai multe copii ale aceleiași aplicații. nginx le poate face pe amândouă, cu un bloc upstream care listează copiile.
nginx nu poate ajunge la aplicația din spatele lui. Verifică dacă aplicația rulează și ascultă pe adresa și portul din proxy_pass și citește /var/log/nginx/error.log pentru motivul exact.
Nu, dacă aplicația rulează pe același server. nginx se ocupă de HTTPS pentru vizitatori și comunică cu aplicația prin HTTP simplu pe 127.0.0.1, care nu părăsește niciodată mașina.
Dă fiecărei aplicații propriul bloc server cu propriul server_name, de exemplu app.example.com și api.example.com, fiecare cu un proxy_pass către alt port.
Da. Publică portul fiecărui container doar pe 127.0.0.1 și îndreaptă proxy_pass spre el. Așa containerele rămân în afara internetului public, lucru important pentru că porturile publicate de Docker ocolesc ufw.
Găzduiește-ți aplicațiile în spatele nginx
Planurile HytHost KVM VPS cu acces root complet, stocare SSD și protecție DDoS pornesc de la €2.92/lună.
Live chat 8 AM – 11 PM (Chișinău time) · tickets answered during business hoursȚi-a fost util acest ghid?