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 सँग कुनै सम्बन्ध राख्छ।