proxy_redirect NGINX को आपके VPN होस्ट से नहीं जोड़ता
proxy_redirect पहले ही आ चुकी प्रतिक्रिया में हेडर फिर से लिखता है; यह कभी अपस्ट्रीम नहीं चुनता। proxy_pass, बैकएंड तक का रूट, फिर हेडर जाँचें।
नाम में redirect शब्द है, इसलिए जब VPN के पीछे का बैकएंड पहुँच से बाहर हो तब उसे location ब्लॉक में चिपका दिया जाता है। कुछ नहीं बदलता, और स्पष्ट निष्कर्ष यही है कि निर्देश टूटा है या उसे अलग सिंटैक्स चाहिए। असल में जो हुआ वह सरल और कम प्रशंसनीय है: proxy_redirect ऐसी प्रतिक्रिया पर काम करता है जो पहले ही लौट आई है, और इस परिनियोजन में कोई भी अनुरोध वहाँ तक नहीं पहुँचा।
एक अनुरोध में दो निर्देश, दो क्षण
रिवर्स प्रॉक्सी से गुज़रने वाला HTTP अनुरोध क्रम से कई निर्णयों से गुज़रता है, और दोनों निर्देश उस क्रम के विपरीत सिरों पर रहते हैं। एक तय करता है कि अनुरोध कहाँ जाएगा। दूसरा लौटती प्रतिक्रिया में कुछ हेडर संपादित करता है।
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
यही क्रम पूरा उत्तर है। अगर पहली पंक्ति विफल होने के कारण दूसरी पंक्ति कभी नहीं चलती, तो दूसरा निर्देश गलत कॉन्फ़िगर नहीं है, वह बस पहुँच से बाहर है। दूसरी पंक्ति को कितना भी दोबारा लिखें, वह जिस प्रतिक्रिया को संपादित करना चाहता था वह नहीं बनेगी। पहली पंक्ति से बाहर की ओर जाँच करें, और भ्रामक व्यवहार या तो अनुपस्थित रूट या अस्वीकृत कनेक्शन में बदल जाता है।
अपस्ट्रीम चुनना proxy_pass का काम है
मान लें कि NGINX किसी सार्वजनिक प्रवेश होस्ट पर चलता है और अपने VPN से 10.40.0.20:8080 पर किसी एप्लिकेशन तक पहुँच सकता है। उस एप्लिकेशन को चुनने वाला अंश मौजूदा server ब्लॉक के भीतर ऐसा दिखता है:
location / {
proxy_pass http://10.40.0.20:8080;
}असली स्कीम, पता और पोर्ट इस्तेमाल करें, और इसे परिनियोजन नहीं बल्कि अंश मानें। प्रवेश होस्ट को VPN रूट, अनुमत फ़ॉरवर्डिंग पथ और उस सेवा तक काम करने वाला वापसी ट्रैफ़िक भी रखना होता है, क्योंकि काग़ज़ पर पते तक पहुँचने वाले प्रॉक्सी को भी कर्नेल की सहमति चाहिए।
proxy मॉड्यूल का संदर्भ अपस्ट्रीम चुनाव को प्रतिक्रिया-हेडर पुनर्लेखन से अलग रखता है, और बताता है कि URI वाला proxy_pass मान यह बदल देता है कि मेल खाता location प्रीफ़िक्स कैसे बदला जाएगा। एप्लिकेशन जिस URL की अपेक्षा करता है उसे जाँचे बिना पथ के हिस्से जोड़ना या हटाना 404 पैदा करने का भरोसेमंद तरीका है, जो रूटिंग विफलता जैसा दिखता है।
proxy_redirect निजी पता लीक करने वाली प्रतिक्रियाएँ ठीक करता है
ट्रैफ़िक शुरू होने पर बैकएंड अपना निजी पता बताने वाले Location हेडर के साथ उत्तर दे सकता है। उस हेडर का पीछा करने वाला ब्राउज़र सार्वजनिक प्रवेश बिंदु छोड़ देता है और ऐसी चीज़ तक पहुँचने की कोशिश करता है जिसे वह हल नहीं कर सकता। जान-बूझकर कॉन्फ़िगर किया गया प्रतिक्रिया पुनर्लेखन निजी URL को सार्वजनिक पर मैप करता है:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;दोनों पक्षों को असली मानों से बदलें। संकीर्ण दायरा भी समझें: मेल खाते Location और Refresh हेडर का टेक्स्ट फिर से लिखा जाता है, लेकिन HTML, JavaScript या डाउनलोड की गई फ़ाइलों में एम्बेड किए गए URL नहीं।
अगर कोई एप्लिकेशन हर जगह निरपेक्ष लिंक बनाता है, तो टिकाऊ समाधान उसका अपना बाहरी-URL कॉन्फ़िगरेशन है, प्रॉक्सी पर बढ़ती पुनर्लेखन नियमों की सूची नहीं। आउटपुट सही दिखने तक नियम जोड़ने से ऐसा कॉन्फ़िगरेशन बनता है जो पहले ऐसे पेज पर विफल होता है जिसे किसी ने जाँचा नहीं। एप्लिकेशन की एक सही सेटिंग पूरा संग्रह बदल देती है।
हेडर पुनर्लेखन क्या ठीक नहीं कर सकता
कई निकटवर्ती समस्याएँ रीडायरेक्ट समस्याओं जैसी लगती हैं और हैं नहीं। अपस्ट्रीम को भेजा गया Host हेडर बैकएंड के वर्चुअल होस्ट से मेल खाना चाहिए हो सकता है। TLS अपस्ट्रीम को खास सर्वर नाम और प्रमाणपत्र सत्यापन चाहिए हो सकता है, और प्रतिक्रिया हेडर फिर से लिखना दोनों में से किसी की मदद नहीं करता।
कुकी का दायरा और डोमेन एट्रिब्यूट एप्लिकेशन और उसके कॉन्फ़िगरेशन के हैं। प्रॉक्सी पूरे दिन हेडर गिरा या फिर से लिख सकता है और फिर भी ऐसा सत्र बना सकता है जो दूसरे अनुरोध पर विफल हो, क्योंकि कुकी ऐसे होस्ट के लिए जारी हुई थी जिसे ब्राउज़र ने कभी देखा ही नहीं। वह विफलता रुक-रुक कर होती दिखती है, इसलिए टिकट कतार में इतनी लंबी टिकती है। कुकी का डोमेन पढ़ना आम तौर पर एक मिनट में जाँच खत्म कर देता है।
प्रमाणीकरण और बैकएंड चुनाव को भी इच्छित एप्लिकेशन तक सीमित रखें। सार्वजनिक रिवर्स प्रॉक्सी को सर्वर के VPN से एक एप्लिकेशन उजागर करना चाहिए, उस होस्ट तक पहुँचने वाले हर निजी पते के लिए सामान्य गेटवे बनने के बजाय. एक सामान्य location जो कॉलर जो माँगे वह सब फ़ॉरवर्ड करता है, एक उजागर सेवा को आपके निजी नेटवर्क के नक़्शे में बदल देता है। अपस्ट्रीम का स्पष्ट नाम दें और उसे वहीं रखें।
उसी क्रम में जाँचें जिसमें अनुरोध यात्रा करता है
क्रम से तीन बातें पुष्ट करें: NGINX ने इच्छित location चुना, बैकएंड तक अनुरोध पूरा किया, और ब्राउज़र ने बाद का कोई भी रीडायरेक्ट मानकर उप-संसाधन लोड किए। हर चरण की अपनी लॉग पंक्तियाँ हैं, और उन्हें क्रम से पढ़ना अस्पष्ट 502 को ठोस निष्कर्ष में बदल देता है।
आपको जो अंतर चाहिए वह विफल अपस्ट्रीम कनेक्शन और पहुँच से बाहर के निजी नाम पर भेजे गए ब्राउज़र के बीच है। पहला प्रॉक्सी त्रुटि लॉग में दिखता है; दूसरा ऐसे अनुरोध के रूप में दिखता है जो कभी नहीं आता, और ब्राउज़र ऐसे होस्ट की शिकायत करता है जिसे वह हल नहीं कर सकता। दो अलग समस्याएँ, दो अलग फ़ाइलें, और उनमें से केवल एक का proxy_redirect से कोई संबंध है।