Reverse Proxy arxitekturasi: qanday ishlaydi?

Reverse Proxy arxitekturasi qanday ishlaydi

Foydalanuvchi example.com saytini ochadi, lekin javobni amalda yaratadigan ilova boshqa portda, boshqa serverda yoki bir nechta backend serverlardan birida ishlayotgan bo‘lishi mumkin. Foydalanuvchi buni bilishi shart emas. Reverse proxy client va backend servislar o‘rtasida turadi: u tashqi so‘rovni qabul qiladi, uni qayerga yuborishni aniqlaydi, kerakli serverga uzatadi va backend javobini clientga qaytaradi.

Request oqimining aynan shu nuqtasida joylashgani reverse proxy’ga oddiy trafik uzatishdan ko‘ra ancha ko‘p vazifani bajarish imkonini beradi. U HTTPS’ni markazlashtirishi, requestlarni yo‘naltirishi, yuklamani taqsimlashi, javoblarni cache qilishi, ichki servislarni yashirishi va ilova arxitekturasi uchun yagona nazorat qilinadigan kirish nuqtasini yaratishi mumkin.

Qisqa javob

Reverse proxy — bir yoki bir nechta backend server nomidan requestlarni qabul qiladigan server. Client uchun reverse proxy yakuniy serverdek ko‘rinadi. Ichkarida esa u requestni mos upstream servisga uzatadi va undan olingan javobni clientga qaytaradi.

HTTP terminologiyasida ta’rif biroz aniqroq: RFC 9110 reverse proxy’ni gateway turi sifatida tasvirlaydi — ya’ni client tomondan origin serverdek ko‘rinadigan, lekin requestlarni boshqa serverlarga uzatadigan vositachi. (rfc-editor.org)

Odatdagi request oqimi quyidagicha ko‘rinadi:

Browser
   ↓
Reverse Proxy
   ↓
Application Server
   ↓
Database

Bir nechta ilova yoki server ishlatilganda:

                    ┌── App Server 1
Client → Reverse Proxy ── App Server 2
                    └── API Server

Asosiy imkoniyatlar

Har bir reverse proxy bu funksiyalarning barchasini bajarishi shart emas. Uning xatti-harakati konfiguratsiya va arxitekturaga bog‘liq.

Reverse Proxy nima?

Quyidagi public manzilga ega saytni olaylik:

https://example.com

Ilovaning o‘zi esa ichki tizimda quyidagi manzilda ishlashi mumkin:

http://10.0.1.12:8080

10.0.1.12:8080 manzilini foydalanuvchilarga to‘g‘ridan-to‘g‘ri ochib qo‘yish o‘rniga, reverse proxy public endpoint’da requestlarni qabul qiladi. example.com uchun request kelganda, proxy uni ichki ilovaga uzatadi.

NGINX bu jarayonni requestni qabul qilish, uni sozlangan proxied serverga yuborish, javobni olish va shu javobni clientga qaytarish sifatida ta’riflaydi. (docs.nginx.com)

Bu muhim abstraction qatlamini yaratadi:

Public architecture:
User → example.com

Actual architecture:
User → Reverse Proxy → Internal Service

Keyinchalik ichki servis boshqa serverga ko‘chirilishi yoki bir nechta server bilan almashtirilishi mumkin. Foydalanuvchilar esa infratuzilma o‘zgarganini bilishi shart emas.

Reverse Proxy va Forward Proxy

Bu ikki tushunchani adashtirish oson.

Forward proxy client nomidan ishlaydi. Client ataylab o‘z trafikini u orqali tashqi serverlarga yuboradi.

Client → Forward Proxy → Internet

Reverse proxy esa server tomonini ifodalaydi. Clientlar odatda qaysi backend requestni yakunda qayta ishlashini bilmasdan public servisga ulanadi.

Internet → Reverse Proxy → Backend

RFC 9110 bu vositachilar rollarini bir-biridan ajratadi va reverse proxy’larni gateway sifatida ko‘rsatadi. (rfc-editor.org)

INTERNAL LINK: Forward Proxy va Reverse Proxy

Request qanday o‘tadi?

Brauzer quyidagi requestni yuborganini tasavvur qilaylik:

GET /api/products HTTP/1.1
Host: example.com

Requestni birinchi bo‘lib reverse proxy qabul qiladi. Keyin u:

1. TLS connection’ni yakunlashi;
2. hostname yoki URL path’ni tekshirishi;
3. upstream serverni tanlashi;
4. request headerlarini o‘zgartirishi yoki qo‘shishi;
5. upstream bilan yangi connection ochishi yoki mavjudini qayta ishlatishi;
6. requestni uzatishi;
7. upstream javobini qabul qilishi;
8. kerak bo‘lsa uni buffer yoki cache qilishi;
9. javobni clientga qaytarishi mumkin.

Shuning uchun reverse proxy oddiy redirect emas. HTTP redirect holatida clientga boshqa manzilga yangi request yuborishi kerakligi aytiladi. Proxying’da esa backend bilan aloqa proxy ortida amalga oshadi va odatda client uchun ko‘rinmaydi.

Routing va Load Balancing

Bitta reverse proxy bir nechta ichki ilovani tashqi tomondan ochib bera oladi.

Masalan:

example.com/        → frontend
example.com/api/    → API service
example.com/admin/  → admin application

U bir xil ilovaning bir nechta instance’lari o‘rtasida ham requestlarni taqsimlashi mumkin:

              ┌→ app-1
Client → Proxy ├→ app-2
              └→ app-3

Buning uchun NGINX server group’larini qo‘llab-quvvatlaydi. Boshqa usul sozlanmagan bo‘lsa, HTTP load balancing uchun default usul round-robin hisoblanadi. Boshqa strategiyalar active connectionlar soni yoki serverlarga berilgan weight kabi omillarni hisobga olishi mumkin. (nginx.org)

Shuning uchun load balancing va reverse proxying bir-biriga bog‘liq, lekin ular bir xil tushuncha emas. Reverse proxy barcha trafikni bitta backend’ga yuborishi mumkin; load balancing qiladigan reverse proxy esa bir nechta backend orasidan tanlaydi.

INTERNAL LINK: Load Balancing qanday ishlaydi

TLS Termination

Keng tarqalgan arxitektura quyidagicha:

Browser
   │ HTTPS
   ↓
Reverse Proxy
   │ HTTP or HTTPS
   ↓
Application

Public TLS connection reverse proxy’da yakunlanishi mumkin. Proxy sertifikatni saqlaydi, TLS handshake’ni bajaradi va keyin backend bilan alohida connection yaratadi.

Masalan, NGINX sozlangan sertifikat va private key yordamida HTTPS connectionlarni qabul qilishi mumkin. Zamonaviy NGINX hujjatlarida TLS 1.2 va TLS 1.3 default holatda yoqilgan protokollar sifatida ko‘rsatilgan. (nginx.org)

Proxy va backend o‘rtasidagi connection ham TLS ishlatishi kerakmi yoki yo‘qmi — bu trust boundary, network topology va xavfsizlik talablariga bog‘liq. Proxy’da TLS termination ishlatilishi ichki trafik har doim shifrlanmagan bo‘lishi kerak degani emas.

Request ma’lumotlarini saqlash

Reverse proxy’ga to‘g‘ridan-to‘g‘ri ulangan backend tarmoq darajasida proxy’ning o‘zini peer sifatida ko‘radi. Qo‘shimcha metadata bo‘lmasa, ilova dastlabki client IP manzili yoki request protokoli haqidagi ma’lumotni ololmasligi mumkin.

RFC 7239 proxy orqali dastlabki client, host va protokol haqidagi ma’lumotlarni uzatish uchun standart Forwarded HTTP header’ini belgilaydi. RFC shuningdek X-Forwarded-For va X-Forwarded-Proto kabi nostandart headerlar ham keng ishlatilishini qayd etadi. (rfc-editor.org)

Masalan, NGINX konfiguratsiyasi quyidagicha bo‘lishi mumkin:

upstream app_backend {
    server app1:8080;
    server app2:8080;
}

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/example.com.crt;
    ssl_certificate_key /etc/nginx/example.com.key;

    location / {
        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;

        proxy_pass http://app_backend;
    }
}

NGINX hujjatlarida proxy_set_header upstream serverlarga yuboriladigan request headerlarini boshqarish uchun ishlatiladigan directive sifatida ko‘rsatilgan. (docs.nginx.com)

Ilova client haqidagi forwarded ma’lumotlarga faqat ma’lum va ishonchli proxy’lardan kelganda ishonishi kerak. Client tomonidan yuborilgan istalgan forwarding header’ni qabul qilish client identity haqidagi noto‘g‘ri ma’lumotlar yoki xavfsizlikka oid noto‘g‘ri qarorlarga olib kelishi mumkin.

Reverse Proxy caching

Ba’zi holatlarda reverse proxy ilovaga murojaat qilmasdan requestga cache’dan javob bera oladi.

First request:
Client → Proxy → Application

Later cache hit:
Client → Proxy

RFC 9111 shared HTTP cache’larning ishlashini belgilaydi va saqlangan javoblarni qayta ishlatish response time hamda network traffic’ni kamaytirishi mumkinligini tushuntiradi. Shu bilan birga, cache qilish imkoniyati HTTP caching qoidalari va response directive’lariga bog‘liq; proxy har bir javobni shunchaki cache qilmasligi kerak. (rfc-editor.org)

Bu ayniqsa authentication talab qiladigan yoki shaxsiylashtirilgan kontent uchun muhim. Cache noto‘g‘ri sozlansa, bir foydalanuvchining javobi boshqasiga ko‘rsatilishi yoki eskirgan ma’lumot qaytarilishi mumkin.

INTERNAL LINK: HTTP Caching qanday ishlaydi

Proxy xatolarini diagnostika qilish

Reverse proxy bilan bog‘liq keng tarqalgan ikki xato muammoni qayerdan izlash kerakligini ko‘rsatadi.

502 Bad Gateway gateway yoki proxy upstream serverdan yaroqsiz javob olganini anglatadi. 504 Gateway Timeout esa gateway belgilangan vaqt ichida upstream’dan kerakli javobni olmaganini bildiradi. (developer.mozilla.org)

Foydali diagnostika oqimi:

SYMPTOM
502 / 504

↓ MEASURE
Proxy logs and upstream timing

↓ POSSIBLE CAUSE
Application failure
Wrong upstream address
Connection refused
DNS failure
Timeout
Firewall/network problem

↓ CONFIRM
Connect to the upstream directly from the proxy host

↓ FIX
Correct the failing layer

↓ RE-MEASURE
Repeat the request and inspect logs

504 paydo bo‘lganda timeout’ni avtomatik ravishda oshirish to‘g‘ri yondashuv emas. Asl sabab sekin database query, ortiqcha yuklangan ilova yoki ishlamay qolgan dependency bo‘lishi mumkin.

Keng tarqalgan xatolar

Xatolardan biri — reverse proxy’ni monitoring talab qilmaydigan, ko‘rinmas komponent deb hisoblash. Agar barcha trafik u orqali o‘tsa, proxy’dagi muammo uning ortidagi barcha backend’larga ta’sir qilishi mumkin.

Yana bir xato — trusted proxy chegaralarini belgilamasdan forwarded IP headerlariga ishonish. Ilova qaysi vositachi client haqidagi ma’lumotni uzatishga haqiqatan ruxsatli ekanini bilishi kerak.

Cache-Control, authentication va cache key’larni tushunmasdan shaxsiylashtirilgan javoblarni cache qilish ham jiddiy konfiguratsiya xavfidir. RFC 9111 shared cache qachon javoblarni saqlashi va qayta ishlatishi mumkinligi bo‘yicha aniq cheklovlar belgilaydi. (rfc-editor.org)

Shuningdek, reverse proxy qo‘shish ilovani avtomatik ravishda tezlashtirmaydi. U yana bir network hop va boshqarilishi kerak bo‘lgan qo‘shimcha komponentni kiritadi. Performance yaxshilanishi connection management, caching, compression yoki load distribution kabi imkoniyatlardan keladi — “reverse proxy” nomining o‘zidan emas.

SeoNest tavsiyasi

Reverse proxy’dan public trafik bitta nazorat qilinadigan qatlam orqali kiradigan va uning ortidagi application service’lar mustaqil deploy qilinadigan aniq arxitektura chegarasi kerak bo‘lganda foydalaning.

Dastlab arxitekturani sodda saqlang. Routing, HTTPS, forwarded headers, logging va mantiqiy upstream timeout’larni ongli ravishda sozlang. Caching yoki murakkab load balancing’ni faqat ilovaga haqiqatan kerak bo‘lganda qo‘shing.

Production tizimlarda proxy’ning har ikki tomonini kuzating: client → proxy va proxy → upstream. Faqat umumiy request duration kechikish qaysi tomonda yuz berganini ko‘rsatmaydi.

FAQ

Reverse proxy backend serverni yashiradimi?

U foydalanuvchilarning backend endpoint bilan to‘g‘ridan-to‘g‘ri ishlashiga yo‘l qo‘ymasligi mumkin, lekin buning o‘zi to‘liq xavfsizlik chegarasi emas. Network rule’lar ham keraksiz direct access’ni cheklashi kerak.

NGINX har doim reverse proxy bo‘ladimi?

Yo‘q. Konfiguratsiyaga qarab NGINX web server, reverse proxy, cache, load balancer va boshqa rollarda ishlashi mumkin. (nginx.org)

CDN reverse proxymi?

Ko‘plab CDN arxitekturalari reverse proxy kabi ishlaydi, chunki foydalanuvchilar CDN infratuzilmasiga ulanadi, u esa origin nomidan kontentni oladi yoki taqdim etadi. Biroq CDN arxitekturasi distributed caching va content delivery bilan bog‘liq qo‘shimcha tushunchalarni ham o‘z ichiga oladi va ular alohida ko‘rib chiqilishi kerak.

INTERNAL LINK: CDN qanday ishlaydi

Reverse proxy load balancer o‘rnini bosadimi?

Har doim ham emas. Reverse proxying vositachilik rolini, load balancing esa trafik qanday taqsimlanishini ifodalaydi. Bir tizim ikkala vazifani ham bajarishi mumkin.

Reverse proxy WebSocket bilan ishlay oladimi?

Ha, agar proxy WebSocket’ni qo‘llab-quvvatlasa va to‘g‘ri sozlangan bo‘lsa. Masalan, NGINX WebSocket proxying uchun maxsus konfiguratsiya talablarini hujjatlashtirgan. (nginx.org)

Yakuniy xulosa

Reverse proxy public clientlar va backend infratuzilma o‘rtasida nazorat qilinadigan chegara yaratadi.

Har bir client har bir application serverga to‘g‘ridan-to‘g‘ri ulanishi o‘rniga, trafik avval proxy orqali o‘tadi. Keyin proxy requestlarni yo‘naltirishi, TLS connectionlarni yakunlashi, dastlabki request metadata’sini saqlashi, trafikni taqsimlashi, mos javoblarni cache qilishi va ichki servislarni izolyatsiya qilishi mumkin.

Tizim kattalashgani sari bunday arxitektura ayniqsa foydali bo‘ladi: ichki infratuzilma o‘zgarsa ham, tashqi interfeys barqaror qolishi mumkin.

Manbalar

1. IETF — RFC 9110: HTTP Semantics, June 2022. HTTP intermediaries, gateways va reverse proxies ta’rifi. RFC 9110 — HTTP Semantics
2. IETF — RFC 7239: Forwarded HTTP Extension, June 2014. Client, host va protokol haqidagi ma’lumotlarni proxy orqali standart tarzda uzatish. RFC 7239 — Forwarded HTTP Extension
3. IETF — RFC 9111: HTTP Caching, June 2022. HTTP cache xatti-harakati va shared cache talablari. RFC 9111 — HTTP Caching
4. NGINX Documentation — NGINX Reverse Proxy. Request forwarding, headerlar va response buffering. NGINX Reverse Proxy documentation
5. NGINX Documentation — Using nginx as HTTP Load Balancer. Upstream server group’lari va load balancing ishlashi. NGINX HTTP Load Balancing documentation
6. NGINX Documentation — Configuring HTTPS Servers. TLS sertifikatlari va HTTPS server konfiguratsiyasi. NGINX HTTPS documentation
7. MDN Web Docs — 502 Bad Gateway / 504 Gateway Timeout. Gateway xatolari semantikasi va upstream timeout o‘rtasidagi farq. MDN — 502 Bad Gateway · MDN — 504 Gateway Timeout