Reverse Proxy सेटअप

Apache को reverse proxy की तरह चलाने का मतलब है यह अकेली चीज़ है जिससे public internet सीधे बात करता है, पीछे one या ज़्यादा backend application servers को चुपचाप forward करते हुए जिन्हें कभी खुद expose होने की ज़रूरत नहीं।

In this page:

App Server के आगे Apache क्यों रखें
Core Directives, दोबारा
असली Client Information Pass करना
एक Proxy के जरिए WebSockets

App Server के आगे Apache क्यों रखें

Gunicorn, uWSGI, या Node.js जैसे application servers application code चलाने में अच्छे हैं, लेकिन Apache उन चीज़ों में बेहतर है जो हर production site को वैसे भी चाहिए होती हैं: TLS terminate करना, static files सीधे और efficiently serve करना, responses compress करना, और logging centralize करना -- यह सब बिना application को खुद इनमें से कुछ भी implement करने की ज़रूरत के।

Core Directives, दोबारा

जैसा mod_proxy lesson में covered है, ProxyPass matching requests को एक backend address पर forward करता है, और ProxyPassReverse response में Location/Set-Cookie headers rewrite करता है ताकि redirects और cookies backend के internal address की जगह public URL reference करें। एक reverse proxy setup असल में सिर्फ इन दो directives को site के main traffic पर apply करना है, सिर्फ एक /api/ path पर नहीं।

असली Client Information Pass करना

एक बार Apache app के आगे बैठ जाए, backend को दिखने वाली हर request Apache के अपने IP (127.0.0.1) से आती दिखती है, असली visitor से नहीं। ProxyPreserveHost On original Host header रखता है, और X-Forwarded-For (असली client IP) और X-Forwarded-Proto (original request HTTP थी या HTTPS) जैसे headers add करने चाहिए ताकि backend application अभी भी वह information देख सके जो उसे चाहिए -- IP-based rate limiting या सही HTTPS links generate करने जैसी चीज़ों के लिए।

Warning: X-Forwarded-For के बिना, backend तक पहुँचने वाली हर request proxy के अपने address से आती दिखती है -- backend पर उस चीज़ को तोड़ते हुए जो client IP से log, rate-limit, या decisions लेती है।

एक Proxy के जरिए WebSockets

एक plain HTTP proxy configuration WebSocket connections handle नहीं करता, जो खुले रहते हैं और request/response pattern follow करने की बजाय bidirectionally communicate करते हैं। WebSocket traffic को Apache के जरिए सही तरीके से proxy करने के लिए Upgrade: websocket header से match करने वाले एक RewriteRule के साथ mod_proxy_wstunnel चाहिए।

उदाहरण: A reverse proxy passing along real client info

apacheconf

<VirtualHost *:443>
    ServerName example.com
    SSLEngine On
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto "https"

    ProxyPass "/" "http://127.0.0.1:8000/"
    ProxyPassReverse "/" "http://127.0.0.1:8000/"
</VirtualHost>

{# Flagged by hand after confirming a runner can't handle this example (a shell command / go.mod file stored as a TopicExample, a language feature the configured runner version doesn't support, or output that blows a runner's sandbox limit) -- see TopicExample.norun. Never render the run button for these, regardless of language, since it would just fail at execute_code (or worse, hang the Judge0 queue on a submission that can never finish cleanly). #}

{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}

आम गलतियां

X-Forwarded-For/X-Forwarded-Proto भूल जाना, ताकि backend application असली client IP या original connection HTTPS था या नहीं यह न बता सके।
एक WebSocket endpoint के लिए mod_proxy_wstunnel की बजाय एक plain ProxyPass इस्तेमाल करना, इस पर depend करने वाले real-time features को चुपचाप तोड़ते हुए।
Apache से proxy करने के अलावा backend application server के port को publicly expose करना, attackers को इसे सीधे पहुँचने का एक दूसरा, unprotected तरीका देते हुए।

🔒

Chapter Quiz — Complete all 4 topics to unlock

0/4 topics done

Complete these topics first:

← Previous Lesson Log Rotation Next Lesson → Load Balancing