तपाईंको Magento रिडिरेक्ट लूप सम्भवतः VPN होइन

तपाईंले पहुँच लगमा 302 देख्नुहुन्छ, स्टोरफ्रन्ट VPN मार्फत लोड हुँदैन, र निष्कर्ष आफैं लेखिन्छ। त्यो निष्कर्ष सामान्यतया रोचक तरिकाले गलत हुन्छ। रिडिरेक्ट प्रतिक्रियाले ब्राउजरलाई जान भनिएको गन्तव्य रेकर्ड गर्छ, र समस्या टनेल, प्रमाणपत्र वा एप्लिकेसनले उत्पन्न गरेको हो कि भनेर केही बताउँदैन। लगको लाइन अनुसन्धानको सुरुवात हो, त्यसको निष्कर्ष होइन।

302 ले कहाँ भन्छ, किन भन्दैन

पहुँच लगको प्रविष्टिले अनुरोध, स्थिति र आकार रेकर्ड गर्छ, र सामान्यतया महत्त्वपूर्ण Location हेडर छोड्छ। एउटा रिडिरेक्ट पूर्ण रूपमा सामान्य हुन सक्छ: प्रामाणिक होस्टनाम, अन्तिम स्ल्यासको सामान्यीकरण, HTTPS मा स्विच। तपाईंलाई क्रम चाहिन्छ, किनकि एउटा उफ्राइ र एउटा लूप फरक-फरक मालिक भएका फरक खराबी हुन्। स्किमहरू बीच दोहोरिने उफ्राइले URL र स्किम ह्यान्डलिङतर्फ संकेत गर्छ। तर ब्राउजरले समाधान गर्न नसक्ने नामतर्फको उफ्राइ पूर्ण रूपमा अन्तै संकेत गर्छ।

यीमध्ये कुनै पनि VPN को बारेमा प्रमाण होइन। टनेल एउटा बाटो हो; रिडिरेक्ट एप्लिकेसनले लेखेको निर्देशन हो।

लगको लाइन होइन, श्रृंखला समात्नुहोस्

ब्राउजरको नेटवर्क दृश्य प्रयोग गर्नुहोस् र प्रत्येक उफ्राइका लागि चार क्षेत्र रेकर्ड गर्नुहोस्: अनुरोध गरिएको URL, स्थिति, Location हेडर र समय। अन्तिम प्रतिक्रिया वा जडान त्रुटिसँग अन्त्य गर्नुहोस्, किनकि रोचक मामला त्यो उफ्राइ हो जो कहिल्यै पूरा हुँदैन। यो एक पटक काम गर्ने बाटोमा र एक पटक असफल हुने बाटोमा गर्नुहोस्, एउटै खाता र एउटै नेभिगेसनसँग। दुई श्रृंखलाको तुलना लगको कुनै पनि एक लाइनभन्दा बढी मूल्यवान छ।

त्यो रेकर्ड निजी राख्नुहोस्। URL ले सत्र पहिचानकर्ता बोक्छन्, र सुरक्षित ब्राउजर अभिलेखले तपाईंले अपेक्षा गरेभन्दा बढी बोक्छ। टिकटमा केही टाँस्नुअघि क्वेरी स्ट्रिङ हटाउनुहोस्।

एप्लिकेसनको आफ्नै URL बारे धारणा

Magento ले कन्फिगरेसनबाट निरपेक्ष URL बनाउँछ, प्रत्येक वेबसाइट वा स्टोर दृश्य अनुसार सीमित। bin/magento config:show web/secure/base_url ले एप्लिकेसनले विश्वास गर्ने मान छाप्छ, र त्यो प्रायः ब्राउजरले प्रयोग गरेको नाम होइन, बिल्ड वा माइग्रेसनबाट बाँकी रहेको होस्टनाम हुन्छ। यदि त्यहाँ आन्तरिक होस्टको नाम छ भने, ब्राउजर जान नसक्ने ठाउँमा पठाइन्छ, र टनेलको कुनै पनि परिवर्तनले त्यो सुधार्दैन।

सुरक्षित र असुरक्षित आधार URL लाई तपाईंको अगाडिका सार्वजनिक नामहरूसँग तुलना गर्नुहोस्। यीमध्ये कुनै एकमा असंगति भएमा तपाईंले हेरिरहनुभएको त्यही रिडिरेक्ट उत्पन्न हुन्छ।

विश्वसनीय प्रोक्सी हेडर एउटा सम्झौता हो

जब TLS लोड ब्यालेन्सरमा अन्त्य हुन्छ, एप्लिकेसनले सादा HTTP देख्छ र यसलाई अन्यथा भन्नुपर्छ। अफलोडर हेडर सेटिङले प्रोक्सीले सेट गर्ने हेडरको नाम दिन्छ, जस्तै फर्वार्ड गरिएको प्रोटोकल, र एप्लिकेसनले स्किम निर्णयहरूमा त्यसलाई विश्वास गर्छ।

त्यो विश्वास एउटा प्रोक्सीसँगको सम्झौता हो, सामान्य अनुमति होइन। स्वेच्छाचारी क्लाइन्टबाट हेडर स्वीकार गर्दा जो कोहीले स्किम दाबी गर्न सक्छ, त्यसैले यो केवल त्यहीँ हुनुपर्छ जहाँ तोकिएको प्रोक्सीले यसलाई सेट गर्छ। यदि हेडरको नाम र प्रोक्सीको व्यवहार मिल्दैन भने, एप्लिकेसनले ब्राउजरले कहिल्यै प्रयोग नगरेको स्किममा रिडिरेक्ट बनाउँछ, र लूप बन्द हुन्छ। प्रोक्सी कन्फिगरेसन र एप्लिकेसन सेटिङ सँगै जाँच्नुहोस्, त्यसपछि परिवर्तन लागू हुन कन्फिगरेसन क्यास फ्लस गर्नुहोस्।

जब लूप सत्र हो, मार्ग होइन

सधैं साइन-इनमा फर्कने श्रृंखला सामान्यतया कुकीको समस्या हो। सत्र कुकी ब्राउजरले वास्तवमै प्रयोग गरेको होस्टनामका लागि जारी भएको थियो कि, र ब्राउजरले सुरक्षित मान्ने जडानमा त्यो सुरक्षित चिन्हित थियो कि, जाँच्नुहोस्। गलत डोमेनमा सीमित कुकीले राउटिङ असफलतासँग ठ्याक्कै मिल्ने लगइन लूप उत्पन्न गर्छ।

प्रमाणित असंगति त्यसको मालिकसँगै सुधार्नुहोस्, त्यो आधार URL, कुकी डोमेन वा प्रोक्सी सम्झौता जे भए पनि, अनि एक 302 हराएको हेर्नुको सट्टा सम्पूर्ण नेभिगेसन फेरि परीक्षण गर्नुहोस्। लूप तोड्न HTTPS आवश्यकता बन्द गर्नु रिडिरेक्टको सट्टा अझ नराम्रो समस्या ल्याउँछ। परिवर्तन भएपछि टनेल अलगै जाँच्नुहोस्: चिनिने निजी स्रोत माग्नुहोस् र त्यो पुग्छ भनी पुष्टि गर्नुहोस्, ताकि अर्को रिडिरेक्टसँग तुलना गर्न सफा आधाररेखा होस्।