Nginx reverse proxy: Node.js ва Python иловаларни интернетга тўғри чиқариш

Node.js, Python (Django, FastAPI, Flask) ёки бошқа замонавий технологияда ёзилган илова одатда ўзининг ички сервери билан ишга тушади ва 3000, 5000 ёки 8000 каби портни тинглайди. Браузерда http://server-ip:3000 деб ёзсангиз илова очилади, лекин мижозларга бундай манзил бериб бўлмайди. Фойдаланувчи example.uz деб ёзади ва 80 ёки 443-портга мурожаат қилади. Ана шу бўшлиқни Nginx reverse proxy тўлдиради: у ташқаридан келган сўровни қабул қилади ва орқадаги иловага узатади, кейин жавобни мижозга қайтаради.

Reverse proxy аслида нима иш қилади

Оддий proxy фойдаланувчи томонида туради ва унинг номидан интернетга чиқади. Reverse proxy эса сервер томонида туради ва ичкаридаги хизматларни ташқи дунёдан тўсиб, улар номидан жавоб беради. Мижоз браузери фақат Nginx билан гаплашади, илова қайси портда ёки нечта нусхада ишлаётганини билмайди. Бу ёндашув хавфсизликни оширади, чунки илова порти интернетга очилмайди ва фақат 127.0.0.1 манзилида тинглайди.

Бундан ташқари Nginx SSL шифрлашни ўз зиммасига олади, статик файлларни (расм, CSS, JavaScript) иловани безовта қилмасдан ўзи тарқатади, сиқишни ёқади ва бир нечта илова нусхаси ўртасида юкни тақсимлай олади. Node.js ёки Gunicorn буларнинг кўпини ўзи ҳам қила олади, лекин Nginx айнан шу ишларга мослаб яратилган ва минглаб уланишни жуда кам хотира билан ушлаб туради.

Мисол: Тошкентдаги етказиб бериш хизмати учун API

Фараз қилайлик, Тошкентдаги кичик етказиб бериш хизмати буюртмаларни қабул қилувчи API'ни Node.js'да ёзган ва у VPS серверда 3000-портда ишлайди. Шу билан бирга, admin панел Python FastAPI'да ёзилган ва 8000-портда туради. Мақсад шундай: api.example.uz Node.js иловасига, admin.example.uz эса FastAPI'га йўналтирилсин, иккаласи ҳам HTTPS орқали очилсин. Аввал DNS'да иккала субдомен учун A ёзуви сервер IP манзилига қаратилади, кейин Nginx созланади.

Асосий созлама

Ubuntu ёки Debian серверда Nginx созлама файллари одатда /etc/nginx/sites-available/ папкасида туради. Қуйидаги блок api.example.uz учун сўровларни Node.js иловасига узатади:

server {
    listen 80;
    server_name api.example.uz;

    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;
    }
}

Файлни ёқиш ва Nginx'ни қайта юклаш учун қуйидаги буйруқлар ишлатилади. nginx -t буйруғи созламада синтаксис хатоси йўқлигини текширади, шунинг учун уни ҳар сафар reload'дан олдин ишга тушириш одат бўлиши керак:

sudo ln -s /etc/nginx/sites-available/api.example.uz /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Сарлавҳалар нима учун керак

Nginx сўровни иловага узатганда, илова нуқтаи назаридан барча сўровлар 127.0.0.1 дан келгандек кўринади. Агар X-Real-IP ва X-Forwarded-For сарлавҳалари узатилмаса, логларда ҳақиқий мижоз IP манзили йўқолади, IP бўйича чеклов ва статистикалар нотўғри ишлайди. X-Forwarded-Proto эса иловага сўров HTTPS орқали келганини билдиради. Бусиз Django ёки Express иловаси ўзини HTTP'да деб ўйлаб, чексиз йўналтириш ҳалқасига тушиб қолиши мумкин.

Илова томонида ҳам бу сарлавҳаларга ишонишни ёқиш керак. Express'да бу app.set('trust proxy', 1) билан, Django'да SECURE_PROXY_SSL_HEADER созламаси билан, Uvicorn'да эса --proxy-headers параметри билан амалга оширилади.

WebSocket ва реал вақт иловалари

Чат, буюртма ҳолатини жонли кузатиш ёки билдиришномалар учун WebSocket ишлатилса, оддий proxy созламаси етарли эмас. WebSocket HTTP уланишни янгилаш (Upgrade) орқали очилади ва Nginx бу сарлавҳаларни ўзи узатмайди. Қуйидаги қаторларни location блокига қўшиш керак:

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 3600s;

proxy_read_timeout қиймати муҳим: стандарт ҳолатда Nginx 60 сония ичида backend'дан маълумот келмаса уланишни узади. Узоқ очиқ турадиган WebSocket учун бу қийматни ошириш ёки илова томонида вақти-вақти билан ping юбориш керак.

Python иловалари: Gunicorn ва Uvicorn

Django иловаси одатда Gunicorn орқали, FastAPI эса Uvicorn орқали ишга туширилади. Иккала ҳолатда ҳам иловани фақат локал манзилда тинглашга мажбурлаш тавсия этилади, акс ҳолда порт ташқаридан ҳам очиқ қолади:

gunicorn myproject.wsgi:application --bind 127.0.0.1:8000 --workers 3
uvicorn main:app --host 127.0.0.1 --port 8000 --proxy-headers

Django лойиҳасида статик файлларни Gunicorn орқали эмас, тўғридан-тўғри Nginx орқали бериш анча тезроқ. Бунинг учун collectstatic билан йиғилган папка алоҳида location /static/ блоки орқали кўрсатилади ва илова фақат динамик сўровлар билан банд бўлади.

SSL сертификатини улаш

Сайт HTTP'да ишлай бошлагач, Let's Encrypt сертификатини Certbot ёрдамида олиш мумкин. Certbot Nginx созламасини ўзи таҳрирлайди, 443-порт блокини қўшади ва HTTP'дан HTTPS'га йўналтиришни ёқади:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d api.example.uz -d admin.example.uz

Сертификат 90 кун амал қилади ва Certbot ўрнатилганда автоматик янгилаш таймери ҳам қўшилади. Янгилаш ишлашини sudo certbot renew --dry-run буйруғи билан олдиндан синаб кўриш фойдали.

Иловани доимий ишлатиб туриш

Reverse proxy фақат орқадаги илова тирик бўлсагина ишлайди. Агар Node.js жараёни терминал ёпилганда тўхтаса, Nginx 502 Bad Gateway хатосини қайтаради. Шунинг учун иловани systemd хизмати ёки PM2 каби жараён менежери орқали ишга тушириш керак. Systemd хизматидаги Restart=always параметри илова кутилмаганда йиқилса уни қайта ишга туширади, systemctl enable эса сервер қайта юкланганда ҳам автоматик старт беради.

Энг кўп учрайдиган хатолар

proxy_pass охиридаги слэш. proxy_pass http://127.0.0.1:3000/; ва слэшсиз вариант йўлларни турлича узатади. location /api/ ичида слэш қўйилса, /api/ қисми кесиб ташланади. Илова йўллари билан мослигини текширинг.
Илова 0.0.0.0 манзилида тинглаяпти. Бунда порт Nginx'ни четлаб ўтиб тўғридан-тўғри очиқ қолади. Локал манзилга боғланг ёки firewall билан ёпинг.
Катта файл юклашда 413 хатоси. Nginx стандарт ҳолатда 1 MB дан катта сўровни рад этади. client_max_body_size 20m; каби қиймат қўшинг.
Секин жавобларда 504. Узоқ ҳисоб-китоб қиладиган endpoint'лар учун proxy_read_timeout ни оширинг, лекин асосий ечим оғир ишни фон навбатига ўтказишдир.

Қайси хостингда бу мумкин

Nginx созламасини тўлиқ ўзингиз бошқариш учун root ҳуқуқи керак, яъни бу VPS ёки алоҳида серверда қилинади. sayt.uz VPS серверлари Ўзбекистондаги маълумотлар марказида жойлашган, шунинг учун маҳаллий фойдаланувчилар учун кечикиш паст бўлади. Оддий PHP сайт учун эса буларнинг ҳеч бири керак эмас: виртуал хостингда Nginx ва PHP аллақачон созланган ҳолда ишлайди. Node.js ёки Python иловасини shared хостингда ишга тушириш имконияти ҳақида аниқ маълумотни sayt.uz кабинетидан ёки техник ёрдам орқали олиш мумкин.