Nginx reverse proxy: Node.js va Python ilovalarni internetga to'g'ri chiqarish

Node.js, Python (Django, FastAPI, Flask) yoki boshqa zamonaviy texnologiyada yozilgan ilova odatda o'zining ichki serveri bilan ishga tushadi va 3000, 5000 yoki 8000 kabi portni tinglaydi. Brauzerda http://server-ip:3000 deb yozsangiz ilova ochiladi, lekin mijozlarga bunday manzil berib bo'lmaydi. Foydalanuvchi example.uz deb yozadi va 80 yoki 443-portga murojaat qiladi. Ana shu bo'shliqni Nginx reverse proxy to'ldiradi: u tashqaridan kelgan so'rovni qabul qiladi va orqadagi ilovaga uzatadi, keyin javobni mijozga qaytaradi.

Reverse proxy aslida nima ish qiladi

Oddiy proxy foydalanuvchi tomonida turadi va uning nomidan internetga chiqadi. Reverse proxy esa server tomonida turadi va ichkaridagi xizmatlarni tashqi dunyodan to'sib, ular nomidan javob beradi. Mijoz brauzeri faqat Nginx bilan gaplashadi, ilova qaysi portda yoki nechta nusxada ishlayotganini bilmaydi. Bu yondashuv xavfsizlikni oshiradi, chunki ilova porti internetga ochilmaydi va faqat 127.0.0.1 manzilida tinglaydi.

Bundan tashqari Nginx SSL shifrlashni o'z zimmasiga oladi, statik fayllarni (rasm, CSS, JavaScript) ilovani bezovta qilmasdan o'zi tarqatadi, siqishni yoqadi va bir nechta ilova nusxasi o'rtasida yukni taqsimlay oladi. Node.js yoki Gunicorn bularning ko'pini o'zi ham qila oladi, lekin Nginx aynan shu ishlarga moslab yaratilgan va minglab ulanishni juda kam xotira bilan ushlab turadi.

Misol: Toshkentdagi yetkazib berish xizmati uchun API

Faraz qilaylik, Toshkentdagi kichik yetkazib berish xizmati buyurtmalarni qabul qiluvchi API'ni Node.js'da yozgan va u VPS serverda 3000-portda ishlaydi. Shu bilan birga, admin panel Python FastAPI'da yozilgan va 8000-portda turadi. Maqsad shunday: api.example.uz Node.js ilovasiga, admin.example.uz esa FastAPI'ga yo'naltirilsin, ikkalasi ham HTTPS orqali ochilsin. Avval DNS'da ikkala subdomen uchun A yozuvi server IP manziliga qaratiladi, keyin Nginx sozlanadi.

Asosiy sozlama

Ubuntu yoki Debian serverda Nginx sozlama fayllari odatda /etc/nginx/sites-available/ papkasida turadi. Quyidagi blok api.example.uz uchun so'rovlarni Node.js ilovasiga uzatadi:

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

Faylni yoqish va Nginx'ni qayta yuklash uchun quyidagi buyruqlar ishlatiladi. nginx -t buyrug'i sozlamada sintaksis xatosi yo'qligini tekshiradi, shuning uchun uni har safar reload'dan oldin ishga tushirish odat bo'lishi kerak:

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

Sarlavhalar nima uchun kerak

Nginx so'rovni ilovaga uzatganda, ilova nuqtai nazaridan barcha so'rovlar 127.0.0.1 dan kelgandek ko'rinadi. Agar X-Real-IP va X-Forwarded-For sarlavhalari uzatilmasa, loglarda haqiqiy mijoz IP manzili yo'qoladi, IP bo'yicha cheklov va statistikalar noto'g'ri ishlaydi. X-Forwarded-Proto esa ilovaga so'rov HTTPS orqali kelganini bildiradi. Busiz Django yoki Express ilovasi o'zini HTTP'da deb o'ylab, cheksiz yo'naltirish halqasiga tushib qolishi mumkin.

Ilova tomonida ham bu sarlavhalarga ishonishni yoqish kerak. Express'da bu app.set('trust proxy', 1) bilan, Django'da SECURE_PROXY_SSL_HEADER sozlamasi bilan, Uvicorn'da esa --proxy-headers parametri bilan amalga oshiriladi.

WebSocket va real vaqt ilovalari

Chat, buyurtma holatini jonli kuzatish yoki bildirishnomalar uchun WebSocket ishlatilsa, oddiy proxy sozlamasi yetarli emas. WebSocket HTTP ulanishni yangilash (Upgrade) orqali ochiladi va Nginx bu sarlavhalarni o'zi uzatmaydi. Quyidagi qatorlarni location blokiga qo'shish kerak:

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

proxy_read_timeout qiymati muhim: standart holatda Nginx 60 soniya ichida backend'dan ma'lumot kelmasa ulanishni uzadi. Uzoq ochiq turadigan WebSocket uchun bu qiymatni oshirish yoki ilova tomonida vaqti-vaqti bilan ping yuborish kerak.

Python ilovalari: Gunicorn va Uvicorn

Django ilovasi odatda Gunicorn orqali, FastAPI esa Uvicorn orqali ishga tushiriladi. Ikkala holatda ham ilovani faqat lokal manzilda tinglashga majburlash tavsiya etiladi, aks holda port tashqaridan ham ochiq qoladi:

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 loyihasida statik fayllarni Gunicorn orqali emas, to'g'ridan-to'g'ri Nginx orqali berish ancha tezroq. Buning uchun collectstatic bilan yig'ilgan papka alohida location /static/ bloki orqali ko'rsatiladi va ilova faqat dinamik so'rovlar bilan band bo'ladi.

SSL sertifikatini ulash

Sayt HTTP'da ishlay boshlagach, Let's Encrypt sertifikatini Certbot yordamida olish mumkin. Certbot Nginx sozlamasini o'zi tahrirlaydi, 443-port blokini qo'shadi va HTTP'dan HTTPS'ga yo'naltirishni yoqadi:

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

Sertifikat 90 kun amal qiladi va Certbot o'rnatilganda avtomatik yangilash taymeri ham qo'shiladi. Yangilash ishlashini sudo certbot renew --dry-run buyrug'i bilan oldindan sinab ko'rish foydali.

Ilovani doimiy ishlatib turish

Reverse proxy faqat orqadagi ilova tirik bo'lsagina ishlaydi. Agar Node.js jarayoni terminal yopilganda to'xtasa, Nginx 502 Bad Gateway xatosini qaytaradi. Shuning uchun ilovani systemd xizmati yoki PM2 kabi jarayon menejeri orqali ishga tushirish kerak. Systemd xizmatidagi Restart=always parametri ilova kutilmaganda yiqilsa uni qayta ishga tushiradi, systemctl enable esa server qayta yuklanganda ham avtomatik start beradi.

Eng ko'p uchraydigan xatolar

proxy_pass oxiridagi slash. proxy_pass http://127.0.0.1:3000/; va slashsiz variant yo'llarni turlicha uzatadi. location /api/ ichida slash qo'yilsa, /api/ qismi kesib tashlanadi. Ilova yo'llari bilan mosligini tekshiring.
Ilova 0.0.0.0 manzilida tinglayapti. Bunda port Nginx'ni chetlab o'tib to'g'ridan-to'g'ri ochiq qoladi. Lokal manzilga bog'lang yoki firewall bilan yoping.
Katta fayl yuklashda 413 xatosi. Nginx standart holatda 1 MB dan katta so'rovni rad etadi. client_max_body_size 20m; kabi qiymat qo'shing.
Sekin javoblarda 504. Uzoq hisob-kitob qiladigan endpoint'lar uchun proxy_read_timeout ni oshiring, lekin asosiy yechim og'ir ishni fon navbatiga o'tkazishdir.

Qaysi xostingda bu mumkin

Nginx sozlamasini to'liq o'zingiz boshqarish uchun root huquqi kerak, ya'ni bu VPS yoki alohida serverda qilinadi. sayt.uz VPS serverlari O'zbekistondagi ma'lumotlar markazida joylashgan, shuning uchun mahalliy foydalanuvchilar uchun kechikish past bo'ladi. Oddiy PHP sayt uchun esa bularning hech biri kerak emas: virtual xostingda Nginx va PHP allaqachon sozlangan holda ishlaydi. Node.js yoki Python ilovasini shared xostingda ishga tushirish imkoniyati haqida aniq ma'lumotni sayt.uz kabinetidan yoki texnik yordam orqali olish mumkin.