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 शी काही संबंध आहे.