რას აკეთებს reverse proxy: TLS, hostname-ები და გადაცემული IP

შენი აპლიკაცია პორტზე უსმენს, რომელიც მას გამოეყო - 3000, 8000, ხუთნიშნა რაღაც. ვიზიტორები სახელს კრიფავენ და ელიან 443 პორტს და ბოქლომს. მათ შორის მდგომი რამ reverse proxy-ია, და მისი გაგება ხსნის პანელის proxy სლოტში მომხდარი ჯადოქრობის უმეტესობას, უმეტეს ხარვეზს, რომელიც პირველ დეპლოიზე ჩნდება, და ზუსტად იმასაც, რატომ ჩანს შენს ლოგებში შენი ყველა ვიზიტორი ერთი და იმავე IP მისამართით.

reverse proxy არის სერვერი, რომელიც სხვა სერვერების სახელით იღებს კავშირებს. "Reverse" მას განასხვავებს იმ proxy-სგან, რომელსაც ბრაუზერში აკონფიგურირებ: forward proxy კლიენტის სახელით მოქმედებს და მალავს, ვინ ეკითხება, reverse proxy სერვერის სახელით მოქმედებს და მალავს, რა პასუხობს. Nginx, Caddy, Traefik, HAProxy და ნებისმიერი ჰოსტინგ პანელის proxy ფენა ერთსა და იმავე საქმეს აკეთებს.

მოთხოვნის გზა, თანმიმდევრობით#

ეტაპობრივად, ასე ემართება ერთ მოთხოვნას:

1. ვიზიტორის ბრაუზერი შენს დომენს მისამართად თარგმნის - proxy-ის მისამართად და არა შენი აპლიკაციისა.
2. ის ხსნის TCP კავშირს 443 პორტზე და იწყებს TLS handshake-ს. პირველ დაუშიფრავ შეტყობინებაში ის ასახელებს ჰოსტს, რომელიც უნდა, ეს არის SNI ველი.
3. proxy არჩევს შესაბამის სერტიფიკატს, ასრულებს handshake-ს და მოთხოვნას შიფრავს. შენი აპლიკაცია სერტიფიკატს არასოდეს ხედავს.
4. proxy კითხულობს Host header-ს და წყვეტს, რომელ backend-ს ეკუთვნის ეს hostname.
5. ის ხსნის უბრალო HTTP კავშირს შენს აპლიკაციასთან მის შიდა პორტზე და მოთხოვნას იმეორებს, ამატებს header-ებს, რომლებიც აფიქსირებს, ვინ და როგორ ითხოვდა თავდაპირველად.
6. შენი აპლიკაცია პასუხობს ამ შიდა კავშირზე. proxy პასუხს დაშიფრულ კავშირზე უკან აბრუნებს.

კავშირი ბრაუზერსა და proxy-ს შორის და კავშირი proxy-სა და აპლიკაციას შორის ორი ცალკე TCP კავშირია სხვადასხვა სიცოცხლის ხანგრძლივობით. სწორედ ეს ერთი ფაქტია ამ პოსტში აღწერილი თითქმის ყველა სიურპრიზის წყარო: შენი აპლიკაციის წარმოდგენა კლიენტზე, სქემაზე, ჰოსტსა და timeout-ზე მეორე კავშირს აღწერს და არა პირველს.

რას გაძლევს ეს#

• შენი აპლიკაცია სერტიფიკატებს არასოდეს ამუშავებს. ერთით ნაკლები განსაახლებელი რამ, ერთით ნაკლები კერძო გასაღები მანქანაზე, რომელიც შენს კოდს უშვებს, და აპლიკაციის გადატვირთვა არ სჭირდება, როცა სერტიფიკატი იცვლება.
• რამდენიმე სახელი ერთ მისამართსა და ერთ პორტზე. ერთ საჯარო IP-სა და ერთ 443-ს ნებისმიერი რაოდენობის hostname-ის მომსახურება შეუძლია, რადგან მარშრუტის გადაწყვეტილება მისამართით კი არა, SNI-სა და Host header-ით მიიღება.
• შენი origin პორტი დახურული რჩება. მხოლოდ proxy უნდა იყოს ინტერნეტიდან მისაწვდომი. აპლიკაცია შეიძლება მხოლოდ 127.0.0.1-ზე იყოს მიბმული და გარედან სრულად მიუწვდომელი იყოს.
• ადგილი საერთო საკითხებისთვის. შეკუმშვა, სიხშირის ლიმიტები, მოთხოვნის ზომის ზღვრები, IP-ების ბლოკი და წვდომის ლოგები ერთ კონფიგურაციაში ცხოვრობს და არა შენს ყველა აპლიკაციაში.
• აპლიკაციის გადატანა DNS-ის შეხების გარეშე. გამოქვეყნებულია proxy-ის მისამართი. მის უკან backend-ის ჩანაცვლება კონფიგურაციის გადატვირთვაა.

ფასი არის ერთი დამატებითი გადასვლა და ერთი დამატებითი რამ, რომელიც შეიძლება არასწორად მოეწყოს, და ეს არის პოსტის დანარჩენი ნაწილი.

TLS termination და სერტიფიკატები#

TLS-ის დასრულება ნიშნავს, რომ proxy ინახავს კერძო გასაღებს, შიფრავს და backend-თან უბრალო HTTP-ით საუბრობს. ეს ბოლო მონაკვეთი დაუშიფრავია, რაც შემაშფოთებლად ჟღერს, სანამ არ შენიშნავ, რომ ის ჩვეულებრივ loopback-ზე ან ერთი მანქანის შიდა კერძო ქსელში გადის. თუ ის არასანდო ქსელს კვეთს, გინდა, TLS მეორე მონაკვეთზეც იყოს - ხელახალი დაშიფვრა და არა termination - და ეს გადაწყვეტილებაა, რომელიც შეგნებულად უნდა მიიღო და არა ნაგულისხმევად.

სერტიფიკატებს დღეს თითქმის ყველა proxy ავტომატურად გასცემს, ACME-ით. მექანიკა ღირს, რომ იცოდე, რადგან ყველა ჩავარდნა მასზეა:

• HTTP-01 გამოწვევა მუშაობს ასე: სერტიფიკატის ორგანო /.well-known/acme-challenge/-ის ქვეშ ფაილს 80 პორტზე ითხოვს. ამიტომ 80 პორტი უნდა დარჩეს ღია და proxy-მდე უნდა აღწევდეს, იმ საიტზეც კი, რომელიც ყველაფერს HTTPS-ზე გადამისამართებს. 80 პორტის სრულად დაბლოკვა განახლების ჩავარდნის ყველაზე გავრცელებული საკუთარი შეცდომაა.
• DNS ჩანაწერი უკვე proxy-ზე უნდა მიუთითებდეს, სანამ გაცემა წარმატებით დასრულდება. სერტიფიკატი ვერ გაიცემა სახელზე, რომელიც იმ მანქანაზე არ იხსნება, რომელსაც ამოწმებენ.
• განახლება ვადის ამოწურვამდე ბევრად ადრე ხდება. სერტიფიკატები ჩვეულებრივ 90 დღით მოქმედებს და დაახლოებით 30-ე დღეს ახლდება, რაც დროებითი ჩავარდნის ხელახლა ცდისთვის ფართო ფანჯარას ტოვებს, ისე, რომ ამას არავინ შენიშნავს.
• ლიმიტები რეგისტრირებულ დომენზე და კვირაზეა. საიტის განმეორებით წაშლა და ხელახლა შექმნა გამართვისას მათ ამოწურავს და ჩაკეტვა დღეების განმავლობაში გრძელდება.

RE:NODE-ზე app და web გეგმები proxy სლოტს შეიცავს. A ჩანაწერს პანელში ნაჩვენებ მისამართზე უთითებ და სერტიფიკატი ავტომატურად გაიცემა და ახლდება 21-დღიან ფანჯარაში - ასე რომ სახელს, რომელიც აღარ იხსნება, სამი კვირა რეზერვი აქვს, სანამ რამე ამოიწურება. შენი დომენი და მისი სერტიფიკატი თანმიმდევრობას განიხილავს, ხოლო HTTPS და Let's Encrypt ახსნილი გვიჩვენებს, რას ადასტურებს ვალიდაცია სინამდვილეში.

მარშრუტიზაცია hostname-ით#

reverse proxy-მ, რომელიც რამდენიმე აპლიკაციის წინ დგას, უნდა იცოდეს, რომელს ეკუთვნის მოთხოვნა, და პასუხი ყოველ მოთხოვნაში ორჯერ მოდის.

SNI - Server Name Indication - TLS გაფართოებაა. კლიენტი hostname-ს ClientHello-ში ათავსებს, ღიად, სანამ რაიმე დაშიფვრა არსებობს, სწორედ იმიტომ, რომ სერვერმა იცოდეს, რომელი სერტიფიკატი წარადგინოს. მის გარეშე ერთ მისამართს მხოლოდ ერთი სერტიფიკატის მომსახურება შეეძლებოდა. ამიტომაც არის hostname, რომელსაც სტუმრობ, ხილული ყველასთვის, ვინც კავშირს უთვალთვალებს, მაშინაც კი, როცა დანარჩენი დაშიფრულია.

`Host` header დაშიფრულ მოთხოვნაში მოდის, handshake-ის დასრულების შემდეგ. proxy მას backend-ის ასარჩევად იყენებს. ეს ორი ჩვეულებრივ ერთნაირია, და მათ შორის შეუსაბამობას ზოგი proxy პირდაპირ უარყოფს.

პრაქტიკაში ეს ნიშნავს: შენი აპლიკაცია, როგორც წესი, არ იცნობს საკუთარ საჯარო სახელს. ის პასუხობს ყველაფერს, რაც მის პორტზე მოდის. აქედან ორი შედეგი გამომდინარეობს.

თუ შენი აპლიკაცია აბსოლუტურ URL-ებს აგებს - გადამისამართებები, პაროლის აღდგენის ბმულები, canonical tag-ები, sitemap-ები - მას საკუთარი საჯარო hostname უნდა ეცნობოს, ან ქვემოთ აღწერილი გადაცემული header-ებით, ან კონფიგურაციის მნიშვნელობით. აპლიკაცია, რომელიც კავშირიდან ხვდება, წერილში http://localhost:3000/reset?token=...-ს გამოიტანს, და ეს ის ხარვეზია, რომელიც მხოლოდ production-ში ჩნდება.

და რადგან backend ნებისმიერ Host-ს იღებს, ის სიამოვნებით მოემსახურება შენს საიტს მოთხოვნას სხვისი hostname-ით, თუ ეს მოთხოვნა მას პირდაპირ მიუვა. მიაბი აპლიკაცია loopback-ს ან შეზღუდე proxy-ის მისამართით და ნუ დატოვებ origin პორტს საჯარო ინტერფეისზე ღიას.

header-ები, რომლებიც თავდაპირველ მოთხოვნას ატარებს#

რადგან proxy ამყარებს კავშირს შენს აპლიკაციასთან, შენი აპლიკაცია კლიენტად proxy-ის მისამართს ხედავს. ყველა ვიზიტორი ერთი და იგივე ადამიანი გგონია. თუ IP-ით ზღუდავ სიხშირეს, წერ ლოგს, განსაზღვრავ ადგილმდებარეობას ან ბანავ, ამას ყველაფერს საკუთარ proxy-ს უკეთებ.

თავდაპირველი დეტალები ამის ნაცვლად header-ებში მოდის:

X-Forwarded-For სიაა, რომელსაც ჯაჭვში ყოველი proxy ავსებს. ყველაზე მარცხენა ჩანაწერი თავდაპირველი კლიენტია და მის მარჯვნივ ყოველი ჩანაწერი proxy-ია, რომელმაც მოთხოვნა დაამუშავა. Forwarded RFC 7239-ის სტანდარტიზებული ჩანაცვლებაა და სწორია, მაგრამ ნაკლებად მხარდაჭერილი; X- header-ები დე ფაქტო სტანდარტია და სწორედ ისინი მოგივა რეალურად.

უსაფრთხოების საკითხი სინტაქსზე მნიშვნელოვანია. ეს header-ები უბრალოდ header-ებია. კლიენტს შეუძლია გამოგზავნოს X-Forwarded-For: 1.2.3.4 და, თუ შენი აპლიკაცია მას კრიტიკის გარეშე ირწმუნებს, ააგებ IP allow-list-ს, რომელშიც ნებისმიერს შეუძლია გაიაროს, და სიხშირის შემზღუდველს, რომელსაც ნებისმიერი header-ის შეცვლით აუვლის გვერდს. წესი ასეთია: header-ს ენდე მხოლოდ იმ proxy-ებისგან, რომლებსაც აკონტროლებ, და დათვალე მარჯვნიდან. თუ იცი, რომ შენს წინ ზუსტად ერთი სანდო proxy დგას, კლიენტის მისამართი ბოლო ჩანაწერია, რომელიც შენმა proxy-მ დაამატა და არა სიის პირველი. framework-ები ამას გამოხატავენ როგორც სანდო proxy-ების რაოდენობას ან სანდო მისამართების სიას, რაც შემდეგი განყოფილების თემაა.

RE:NODE-ზე კლიენტის რეალური მისამართი X-Forwarded-For-ში მოდის, და მისი წაკითხვა არის განსხვავება ვიზიტორის მიხედვით სიხშირის შეზღუდვასა და შემზღუდველს შორის, რომელიც ყველას ერთდროულად ბლოკავს - სიხშირის ლიმიტები და ბოროტად გამოყენება თავად ლიმიტის დაგეგმვას განიხილავს.

framework-ისთვის იმის თქმა, რომ ის proxy-ს უკან დგას#

ყოველ სერვერულ framework-ს ამისთვის გადამრთველი აქვს, ნაგულისხმევად გამორთული, რადგან გადაცემული header-ების უპირობო ნდობა სახიფათოა. მისი ჩართვა framework-ს აიძულებს, header-ები წაიკითხოს და რეალური კლიენტი, სქემა და ჰოსტი აჩვენოს.

// 1 = trust exactly one proxy in front of usapp.set("trust proxy", 1);// req.ip and req.protocol now describe the real client

from werkzeug.middleware.proxy_fix import ProxyFixapp.wsgi_app = ProxyFix(app.wsgi_app, x_for=1, x_proto=1, x_host=1)

SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")USE_X_FORWARDED_HOST = TrueALLOWED_HOSTS = ["app.example.com"]

$ uvicorn main:app --host 0.0.0.0 --port 8000 --proxy-headers$ gunicorn app:wsgi --bind 0.0.0.0:8000 --forwarded-allow-ips="10.0.0.0/8"

Laravel-ს აქვს TrustProxies middleware თვისებით $proxies; დააყენე ის proxy-ის მისამართზე და არა ყველაფერზე, თუ შეგიძლია. Next.js URL-ების გენერირებისას კითხულობს X-Forwarded-Host-სა და X-Forwarded-Proto-ს და გადამრთველი არ სჭირდება, მაგრამ ყველაფერი, რასაც მასში თვითონ წერ, სჭირდება.

trust proxy-ში რიცხვი გადასვლების რაოდენობაა, და მისი არასწორად დაყენება ხმაურით კი არა, შეუმჩნევლად ვლინდება. თუ ძალიან დაბალია, კლიენტის ნაცვლად proxy-ის მისამართს ხედავ. თუ ძალიან მაღალია, კითხულობ ჩანაწერს, რომელიც კლიენტმა მიაწოდა, და ეს გაყალბებადი შემთხვევაა. დათვალე proxy-ები, რომლებიც რეალურად გზაზე დგას - პანელის proxy ერთია, მის წინ CDN ორია - და შეამოწმე req.ip-ის ლოგირებით მანქანიდან, რომლის მისამართიც იცი.

Express API-ის production-ში დეპლოი პირველი შემთხვევის დანარჩენ სიას შეიცავს, ხოლო Node აპლიკაციის დეპლოი GitHub-იდან კოდის სერვერზე მოხვედრას განიხილავს.

WebSocket-ები, streaming და timeout-ები#

HTTP მოთხოვნა მოკლეა. WebSocket მოთხოვნაა, რომელიც ხანგრძლივ კავშირად იქცევა, და proxy-ები, რომლებსაც ამის შესახებ არ უთქვამთ, ხელს შეგიშლიან.

განახლება ჩვეულებრივი HTTP მოთხოვნაა, რომელიც ატარებს Connection: Upgrade და Upgrade: websocket. proxy-მ ორივე header უნდა გადასცეს და upstream მონაკვეთზე HTTP/1.1-ით უნდა ისაუბროს, რადგან განახლების მექანიზმი HTTP/1.0-ში არ არსებობს. nginx-ში ეს ოთხი სტრიქონია:

location /socket.io/ {    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_read_timeout 3600s;}

მართული proxy-ები განახლებას ჩვეულებრივ ავტომატურად ამუშავებენ. რასაც ავტომატურად არ ამუშავებენ, timeout-ია: proxy 60-წამიანი read timeout-ით უმოქმედო WebSocket-ს ყოველ წუთს გაწყვეტს, რაც ხელახალი დაკავშირების ციკლს იძლევა, რომელიც ქსელის ხარვეზს ჰგავს და სინამდვილეში კონფიგურაციის მნიშვნელობაა. გააგზავნე აპლიკაციის დონის ping ყოველ 20-30 წამში, ან გაზარდე timeout, ან ორივე.

Server-sent events-სა და streaming პასუხებს მეორე პრობლემა აქვთ: პასუხის ბუფერიზაცია. proxy, რომელიც ბუფერიზაციას აკეთებს, შენს stream-ს დაიჭერს, სანამ საკმარისი არ დაგროვდება, და კლიენტი გრძელ სიჩუმეს, შემდეგ კი ყველაფერს ერთდროულად მიიღებს. Nginx-ს ამ მარშრუტებზე proxy_buffering off სჭირდება, ან X-Accel-Buffering: no პასუხის header აპლიკაციისგან.

Sticky სესიებიც აქ ჩნდება. თუ აპლიკაციის რამდენიმე ეგზემპლარს ერთი proxy-ს უკან უშვებ და შენი WebSocket ბიბლიოთეკა HTTP long-polling-ზე ეშვება - Socket.IO ამას აკეთებს - ერთი კლიენტის მიმდევარი მოთხოვნები ერთ ეგზემპლარამდე უნდა მივიდეს, თორემ სესია ვერ მოიძებნება. ან ჩართე sticky მარშრუტიზაცია, ან გამოიყენე საერთო adapter, რომ ეგზემპლარებმა მდგომარეობა გაიზიარონ. WebSocket-ები reverse proxy-ს უკან თითოეულს დეტალურად განიხილავს.

რას არ გააკეთებს reverse proxy#

აქ მოლოდინები ჩვეულებრივ არასწორია, და ღირს პირდაპირ თქმა.

ის არ ატარებს თამაშის ტრაფიკს. თითქმის ყველა reverse proxy HTTP-ს ლაპარაკობს, ხოლო თითქმის ყველა თამაში საკუთარი პროტოკოლით UDP-ს. Valheim-ს ან Counter-Strike 2-ს HTTP proxy-ს უკან ვერ დააყენებ, და პროქსირებული DNS ჩანაწერის თამაშის სერვერზე მიმართვა იძლევა მისამართს, რომელიც თამაშის კავშირს არასოდეს მიიღებს. იგივე ეხება Cloudflare-ის ნარინჯისფერ ღრუბელს - Cloudflare ვებსაიტებისთვის და გეიმ სერვერებისთვის პირდაპირ ამბობს, რას პროქსირებს და რას არა, ხოლო TCP და UDP გეიმ სერვერებისთვის განმარტავს, რატომ.

ის cache არ არის, სანამ არ გაუწყობ. უმეტესი proxy ნაგულისხმევად ყველა მოთხოვნას გადაგზავნის. cache ფუნქციაა, რომელსაც რთავ და შემდეგ მისი გაუქმებაზე უნდა იფიქრო.

ის DDoS-ისგან დაცვა არ არის. ის შენს აპლიკაციაზე პატარა სამიზნეა და გარკვეულ სისულელეს შთანთქავს, მაგრამ მოცულობითი ნაკადი მის წინ არსებულ არხს ავსებს და მანქანაზე გაშვებული არაფერი ეხმარება.

ის ნელ აპლიკაციას არ ასწორებს. 4-წამიანი პასუხის წინ proxy-ს დამატება მას 4-წამიან პასუხად ტოვებს ერთი დამატებითი მილიწამით. პროფილირება აპლიკაციას გაუკეთე.

ის არავის ავთენტიფიცირებს, სანამ ამასაც არ გააკონფიგურირებ. Basic auth და forward-auth უმეტეს proxy-ში არსებობს და ღირს ადმინის ინტერფეისისთვის გამოყენება, მაგრამ ნაგულისხმევად არაფერი ხდება.

როცა ტყდება: 502, 504, ციკლები და შერეული კონტენტი#

502 Bad Gateway. proxy-მ backend-იდან ვალიდური პასუხი ვერ მიიღო. ათიდან ცხრა შემთხვევაში აპლიკაცია არ მუშაობს, ან 127.0.0.1-ზეა მიბმული, მაშინ როცა proxy სხვა კონტეინერში ან namespace-შია, ან სხვა პორტზეა, ვიდრე კონფიგურირებულია. შეამოწმე, რომ პროცესი ცოცხალია, შემდეგ ss -lntp-ით ნახე, რაზეა მიბმული. თუ proxy და აპლიკაცია ცალკე კონტეინერებშია, აპლიკაციამ 0.0.0.0-ზე უნდა მოუსმინოს.

504 Gateway Timeout. აპლიკაციამ კავშირი მიიღო და დროულად არ უპასუხა. ეს ნელი მოთხოვნაა და არა proxy-ის ხარვეზი. იპოვე ნელი endpoint, სანამ timeout-ს გაზრდი, რადგან მისი გაზრდა ჩვეულებრივ უბრალოდ ჩავარდნას ბრაუზერზე გადაიტანს.

გადამისამართების ციკლი. კლასიკური. შენი აპლიკაცია HTTPS-ს ძალით ამყარებს საკუთარი კავშირის სქემის შემოწმებით, რომელიც უბრალო HTTP-ა, რადგან proxy-მ TLS დაასრულა. ამიტომ ის HTTPS-ზე გადამისამართებს, proxy კვლავ ასრულებს TLS-ს, აპლიკაცია ისევ HTTP-ს ხედავს და ბრაუზერი ოცი წრის შემდეგ თავს ანებებს. გამოსავალი X-Forwarded-Proto-ის ნდობაა - framework-ის გადამრთველები ზემოთ განყოფილებაში - და არა გადამისამართების მოხსნა.

შერეული კონტენტის გაფრთხილებები. იგივე მიზეზი, განსხვავებული სიმპტომი: აპლიკაცია საკუთარი რესურსებისთვის აბსოლუტურ http:// URL-ებს აგენერირებს, რადგან სჯერა, რომ HTTP-ით მოემსახურებიან. გაასწორე სქემის დადგენა, ან გამოიყენე ფარდობითი URL-ები.

ყველა ვიზიტორს ერთი და იგივე IP აქვს. გადაცემული header-ები არ იკითხება. იხილე ზემოთ.

413 Request Entity Too Large. proxy-ის მოთხოვნის სხეულის ლიმიტია და არა აპლიკაციის. Nginx-ის ნაგულისხმევია 1 MB client_max_body_size-ის მეშვეობით, რაც ატვირთვის უმეტესი ფორმის მოლოდინზე ნაკლებია.

ერთ hostname-ზე მუშაობს და მეორეზე - არა. სერტიფიკატი ან მარშრუტის წესი ერთ სახელს ფარავს და მეორეს - არა. www.example.com და example.com სხვადასხვა სახელია და ორივე უნდა არსებობდეს DNS-შიც და proxy-შიც.

თუ proxy-ს თვითონ უშვებ და არა მართულს, nginx reverse proxy-ის გზამკვლევი შეიცავს სრულ server block-ს TLS-ისა და header-ების სტრიქონებით.

FAQ#

მჭირდება reverse proxy, თუ მხოლოდ ერთ აპლიკაციას ვუშვებ?

ჩვეულებრივ დიახ, რადგან სწორედ ის გაძლევს HTTPS-ს იმისგან, რომ აპლიკაცია სერტიფიკატს ამუშავებდეს, და საშუალებას გაძლევს, აპლიკაციის პორტი ინტერნეტისგან დახურული დატოვო. კერძო ქსელში ერთი შიდა სერვისისთვის შეგიძლია გამოტოვო.

რატომ ხედავს ჩემი აპლიკაცია proxy-ის IP-ს ვიზიტორისას ნაცვლად?

იმიტომ, რომ proxy-მ დაამყარა კავშირი და შენი framework გადაცემულ header-ებს ჯერ არ კითხულობს. ჩართე შენი framework-ის სანდო proxy-ის პარამეტრი და გამოიყენება X-Forwarded-For-ში არსებული კლიენტის მისამართი.

დაშიფრულია კავშირი proxy-სა და ჩემს აპლიკაციას შორის?

ნაგულისხმევად არა. ეს უბრალო HTTP-ა, რაც კარგია, როცა ორივე ერთ მანქანაზე ან ერთ კერძო ქსელშია. თუ ეს მონაკვეთი შენს მიღმა ქსელს კვეთს, დააკონფიგურირე TLS upstream კავშირზეც.

შეიძლება reverse proxy თამაშის სერვერის წინ იდგეს?

HTTP-ისა - არა. თამაშები საკუთარ პროტოკოლებს იყენებს, ძირითადად UDP-ზე, და HTTP proxy-ს მათთან საქმე არ აქვს. თამაშის ტრაფიკს სჭირდება Layer 4 proxy ან პირდაპირი კავშირი თამაშის პორტთან.

რატომ წყდება ჩემი WebSocket-ები ყოველ წუთს?

proxy-ის read timeout-ი უმოქმედო კავშირს ხურავს. გაზარდე timeout ამ მარშრუტზე და გააგზავნე აპლიკაციის დონის ping ყოველ 20-30 წამში, რომ კავშირი არასოდეს დარჩეს გაწყვეტისთვის საკმარისად დიდხანს უმოქმედო.

რა განსხვავებაა reverse proxy-სა და load balancer-ს შორის?

უფრო გადაფარული საქმეებია, ვიდრე განსხვავებული რამეები. load balancer მოთხოვნებს რამდენიმე იდენტურ backend-ზე ანაწილებს; reverse proxy ერთი ან რამდენიმე განსხვავებული backend-ისთვის მოთხოვნებს მარშრუტებს და გარდაქმნის. უმეტესი პროგრამა ორივეს აკეთებს, და რომელ სიტყვას იყენებ, იმაზეა დამოკიდებული, რომელი ფუნქცია გაინტერესებს.