Nginxi seadistamine reverse proxy'ks

20 Jan 2026 Autor: Inga Vītola

Nginxil põhinev reverse proxy võtab vastu päringud portidel 80 ja 443 ning suunab need rakendusele kohalikul pordil (näiteks 127.0.0.1:3000), lisades vajalikud päised. Nii saate ühtse sisenemispunkti, HTTPS-i ja koormuse jaotamise. Allpool on töötav konfiguratsioon proksimise, päiste, TLS-i ja WebSocketiga.

Mida reverse proxy teeb

  • Võtab vastu välised HTTP/HTTPS-päringud ja annab need edasi rakendusele (Node.js, Python, PHP-FPM jne).
  • Lõpetab TLS-i: rakendus töötab HTTP kaudu, krüptimise võtab enda peale Nginx.
  • Peidab rakenduste sisemise ülesehituse ja pordid ühe domeeni taha.
  • Võimaldab jaotada koormust mitme rakendusserveri vahel.

Samm 1. Paigaldage Nginx

sudo apt update
sudo apt install nginx
sudo systemctl enable --now nginx

Samm 2. Looge saidi konfiguratsioon

Looge virtuaalhosti fail:

sudo nano /etc/nginx/sites-available/app.conf

Lihtne reverse proxy rakendusele pordil 3000:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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;
    }
}

Milleks need päised: ilma X-Forwarded-For ja X-Real-IP päiseta näeb rakendus tegeliku kliendi asemel aadressi 127.0.0.1, ning X-Forwarded-Proto annab rakendusele teada, et algne päring tuli HTTPS-i kaudu.

Samm 3. Aktiveerige konfiguratsioon

sudo ln -s /etc/nginx/sites-available/app.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Käsk nginx -t kontrollib süntaksit enne teenuse uuestilaadimist — ärge jätke seda vahele.

Samm 4. WebSocketi tugi

Kui rakendus kasutab WebSocketit (vestlused, reaalajas uuendused), lisage plokki location päiste Upgrade edastamine:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Samm 5. Lülitage sisse HTTPS

Paigaldage certbot ja hankige Let’s Encrypti sertifikaat — see kirjutab TLS-i ise konfiguratsiooni:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com

Pärast seda kuulab Nginx porti 443 sertifikaadiga ja pordi 80 päringud suunatakse ümber HTTPS-ile.

Mitme rakendusserveri vahel koormuse jaotamine

Koormuse jaotamiseks kirjeldage upstream-grupp:

upstream backend {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Ajalõpud ja üleslaaditavate failide maht

Vaikimisi piirab Nginx päringu keha 1 MB-ga ja katkestab rakenduse aeglased vastused. Failide üleslaadimise ja pikkade operatsioonidega rakenduste jaoks suurendage piiranguid plokis server või location:

client_max_body_size 50m;
proxy_connect_timeout 60s;
proxy_send_timeout 120s;
proxy_read_timeout 120s;

Direktiiv client_max_body_size määrab üleslaadimise maksimaalse mahu ja ajalõpud proxy_* selle, kui kaua oodata rakenduse ühendust ja vastust, enne kui tagastada 504 Gateway Timeout.

Proksimine tee järgi

Ühe domeeni saab jaotada mitme rakenduse vahel URL-i eesliite järgi. Näiteks /api/ läheb ühele rakendusele ja ülejäänu esiotsale:

location /api/ {
    proxy_pass http://127.0.0.1:4000/;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location / {
    proxy_pass http://127.0.0.1:3000;
}

Pöörake tähelepanu lõpukaldkriipsule reas proxy_pass http://127.0.0.1:4000/ — see lõikab eesliite /api/ ära ja rakendus saab tee ilma selleta.

Põhilised direktiivid

Direktiiv Otstarve
proxy_pass rakendusserveri aadress
proxy_set_header päiste edastamine rakendusele
proxy_http_version 1.1 vajalik keep-alive’i ja WebSocketi jaoks
upstream serverite grupp koormuse jaotamiseks

Korduma kippuvad küsimused

Viga 502 Bad Gateway — mis on põhjus? Nginx ei saanud rakendusega ühendust: rakendus pole käivitatud, kuulab teist porti või on kokku jooksnud. Kontrollige ss -tulpn | grep 3000 ja rakenduse logisid.

Rakendus näeb kliendi asemel IP-d 127.0.0.1 — miks? Päised pole edasi antud. Lisage X-Forwarded-For ja X-Real-IP ning seadistage rakendus neid päiseid usaldama.

Kuidas kontrollida konfiguratsiooni enne rakendamist? Käivitage sudo nginx -t — see näitab süntaksivead ilma teenust uuesti laadimata.

Kas rakendusserveri port tuleb väljapoole avada? Ei. Rakendus kuulab aadressi 127.0.0.1 ja väljapoole on avatud ainult Nginxi pordid 80 ja 443. Nii on turvalisem.

Kuidas TLS-sertifikaati uuendada? certbot seab automaatse uuendamise taimeri. Kontroll: sudo certbot renew --dry-run.

Vajate serverit Nginxi ja oma rakenduste majutamiseks? Võtke kasutusele Linuxi VPS jaotisest VPS rent või tellige seadistus teenusega serverite haldus.

Inga Vītola