ERR_TOO_MANY_REDIRECTS क्या है?
Scrapeless Agent Browser नेविगेशन और रेंडर की हुई पेज स्थिति का निरीक्षण करने के लिए मैनेज्ड ब्राउज़र सेशन प्रदान करता है।
ERR_TOO_MANY_REDIRECTS का मतलब है कि ब्राउज़र ने रीडायरेक्ट अनुक्रम का पालन करना रोक दिया क्योंकि यह अनुमत रीडायरेक्शन सीमा से अधिक हो गया। दोहराते हुए URL चक्र एक आम कारण है, लेकिन अत्यधिक लंबी चेन भी सीमा समाप्त कर सकती है। यह त्रुटि नेविगेशन निर्णयों से संबंधित है, इसलिए DNS या प्रॉक्सी पहुँचनीयता से शुरू करने के बजाय प्रत्येक हॉप और उसके रिक्वेस्ट संदर्भ की जाँच करें।
संक्षेप में
- ERR_TOO_MANY_REDIRECTS दोहराए जाने वाले लूप या अत्यधिक लंबे रीडायरेक्ट अनुक्रम को दर्शा सकता है।
- स्कीम, होस्टनेम, पाथ और सेशन नियमों में से प्रत्येक अपने-अपने नेविगेशन निर्णय थोप सकते हैं।
- एक साफ ब्राउज़र सेशन तुलना का मामला होता है; यह अपने आप साबित नहीं करता कि संग्रहीत कुकीज़ ही कारण हैं।
- एक कलेक्टर को रीडायरेक्ट इतिहास सुरक्षित रखना चाहिए और डेटा स्वीकार करने से पहले अंतिम संसाधन को मान्य करना चाहिए।
ब्राउज़र रीडायरेक्ट का पालन करना क्यों बंद कर देता है
ERR_TOO_MANY_REDIRECTS रिपोर्ट करता है कि नेविगेशन ने अपना रीडायरेक्ट भत्ता खर्च कर दिया है। प्रत्येक हॉप क्लाइंट को किसी अन्य लोकेशन की ओर निर्देशित करता है, लेकिन अनुक्रम ब्राउज़र की सीमा के भीतर किसी स्वीकार्य एंडपॉइंट तक नहीं पहुँचता। सटीक सीमा एक इम्प्लीमेंटेशन डिटेल है, इसलिए निदान किसी याद किए गए नंबर के बजाय देखे गए अनुक्रम पर निर्भर होना चाहिए।
The HTTP redirection and Location semantics सर्वर-निर्देशित नेविगेशन समझाते हैं। एक रिस्पॉन्स किसी मूव, लॉगिन या कैनोनिकलाइज़ेशन नियम के हिस्से के रूप में क्लाइंट को नए URL पर भेज सकता है। एक स्वस्थ रीडायरेक्ट अनुक्रम का एक सार्थक अंतिम प्रतिनिधित्व होता है। एक लूप उस नेविगेशन को पूरा करने की बजाय बार‑बार किसी स्थिति पर लौट आता है।
एक रीडायरेक्ट लूप दो URLs के बीच अदला‑बदली कर सकता है, कई होस्ट्स के बीच घूम सकता है, या वही नियम दोहराते हुए किसी क्वेरी पैरामीटर को बदलता रह सकता है। केवल शाब्दिक URL समानता के बजाय नियम और स्थिति की तुलना करें। हर हॉप पर नए ट्रैकिंग मान वाला अनुक्रम भी एक ही अनसुलझे एप्लिकेशन निर्णय का प्रतिनिधित्व कर सकता है।
ब्राउज़र स्क्रिप्ट्स या डॉक्यूमेंट निर्देशों के कारण भी नेविगेट कर सकते हैं। उपलब्ध होने पर इनिशिएटर को कैप्चर करें और उन नेविगेशन्स को HTTP रिस्पॉन्स रीडायरेक्ट्स से अलग पहचानें। यदि लोड किया हुआ पेज तुरंत यूज़र को कहीं और भेज देता है, तो रिस्पॉन्स रीडायरेक्ट्स का सर्वर लॉग पूरे ब्राउज़र नेविगेशन की कहानी नहीं दिखा सकता।
रिक्वेस्ट संदर्भ के साथ चेन को ट्रेस करें
एक रीडायरेक्ट ट्रेस में हर हॉप पर रिक्वेस्ट किया गया URL, रिस्पॉन्स स्टेटस, अगला लोकेशन और प्रासंगिक सेशन संदर्भ होना चाहिए। निर्णय की पहचान के लिए आवश्यक स्कीम, होस्टनेम, पाथ और गैर‑संवेदनशील पैरामीटर्स सुरक्षित रखें। रीडायरेक्ट URLs में एम्बेड किए गए ऑथेंटिकेशन टोकन्स को निर्यात न करें।
उस सटीक एंट्री पॉइंट से शुरू करें जो विफल हो रहा है। किसी साइट का होमपेज काम कर सकता है जबकि पुराना आर्टिकल पाथ लूप में फँस जाए, और एक ऑथेंटिकेटेड अकाउंट पेज लूप हो सकता है जबकि सार्वजनिक पेज लोड हो जाए। केवल होमपेज का परीक्षण करने से वह रूट छिप जाता है जो मायने रखता है। विफल पाथ की तुलना किसी नज़दीकी काम कर रहे पाथ से करें ताकि नियम का अंतर मिल सके।
पहली दोहराई गई स्थिति या परस्पर विरोधी नियम की पहचान करें। एक कॉम्पोनेंट किसी होस्टनेम को बाध्य कर सकता है जबकि दूसरा वैकल्पिक होस्टनेम को बाध्य करता है। एक नियम स्लैश जोड़ सकता है जबकि दूसरा उसे हटा देता है। कोई लॉगिन पेज ऐसे डेस्टिनेशन पर रीडायरेक्ट कर सकता है जो तुरंत तय कर लेता है कि यूज़र अनऑथेंटिकेटेड है और उन्हें वापस भेज देता है।
स्वामित्व वाली प्रणालियों के लिए, रिकॉर्ड करें कि प्रत्येक रिस्पॉन्स कौन‑सा कॉम्पोनेंट उत्पन्न करता है। कोई एज सर्विस, रिवर्स प्रॉक्सी, एप्लिकेशन मिडलवेयर और आइडेंटिटी प्रोवाइडर सभी हॉप्स में योगदान दे सकते हैं। केवल दिखाई देने वाले अंतिम URL को ठीक करने से मूल विरोधी नियम सक्रिय रह सकते हैं। ट्रेस को उस निर्णय के ओनर को दिखाना चाहिए जो चक्र बनाता है।
HTTPS टर्मिनेशन और कैनोनिकल URL संघर्ष
स्कीम लूप तब हो सकता है जब ब्राउज़र‑फेसिंग और ओरिजिन‑फेसिंग कॉम्पोनेंट्स रिक्वेस्ट की सुरक्षित स्थिति के बारे में असहमत हों। कोई रिवर्स प्रॉक्सी HTTPS को टर्मिनेट कर सकता है और रिक्वेस्ट को किसी अलग इन्टरनल ट्रांसपोर्ट पर आगे बढ़ा सकता है। यदि एप्लिकेशन मूल स्कीम को गलत समझता है, तो उसका रीडायरेक्ट लॉजिक एज की नीति से टकरा सकता है।
स्वामित्व वाली डिप्लॉयमेंट के लिए प्रलेखित फॉरवर्डिंग और ट्रस्ट कॉन्फ़िगरेशन की जाँच करें। एप्लिकेशन को केवल विश्वसनीय इंटरमीडियरीज़ से मिले प्रॉक्सी‑प्रदत्त रिक्वेस्ट संदर्भ की व्याख्या करनी चाहिए। खुले इंटरनेट से मनमाने फॉरवर्डिंग हेडर्स स्वीकार करना कोई ठोस सुधार नहीं है। सुधार को उस सीमा पर अपेक्षित स्कीम के साथ संरेखित करना चाहिए जो HTTPS टर्मिनेशन की ओनर है।
कैनोनिकल होस्टनेम और पाथ नियमों को भी एक सुसंगत डेस्टिनेशन की ज़रूरत होती है। यदि एप्लिकेशन को एक होस्टनेम चाहिए और एज रीडायरेक्ट दूसरे की माँग करता है, तो हर कॉम्पोनेंट स्थानीय रूप से तर्कसंगत लग सकता है जबकि उनका संयुक्त व्यवहार लूप बनाता है। इच्छित कैनोनिकल URL का दस्तावेज़ बनाएं और उसके नॉर्मलाइज़ेशन नियम को किसी स्पष्ट ओनर को सौंपें।
HTTP Strict Transport Security behavior रिक्वेस्ट सर्वर तक पहुँचने से पहले ब्राउज़र की स्कीम पसंद को प्रभावित कर सकता है। अपने ट्रेस में इस ब्राउज़र पॉलिसी को HTTP रीडायरेक्ट रिस्पॉन्स से अलग रखें। केवल लक्षण गायब करने के लिए ट्रांसपोर्ट प्रोटेक्शन्स हटाने से बचें; डिप्लॉयमेंट के स्कीम निर्णयों को सुधारें।
कुकी और लॉगिन स्टेट रीडायरेक्ट अनुक्रम को बदल सकते हैं
सेशन स्टेट रीडायरेक्ट निर्णयों को प्रभावित कर सकती है। कोई सार्वजनिक पेज सीधे नेविगेट कर सकता है जबकि कोई ऑथेंटिकेटेड पेज आइडेंटिटी प्रोवाइडर, कंसेंट स्क्रीन या अकाउंट राउटर के माध्यम से जाता है। कोई अमान्य या अनुपलब्ध सेशन कुकी एप्लिकेशन को बार‑बार ब्राउज़र को उसी लॉगिन निर्णय से गुज़ारने के लिए छोड़ सकती है।
The HTTP cookie scope and state rules समझाने में मदद करें कि एक होस्ट या पाथ पर उपलब्ध कुकी दूसरे पर क्यों नहीं भेजी जा सकती। संबंधित कुकी की डिलीवरी और ऐप्लिकेशन द्वारा उसकी व्याख्या का निदान करें, बिना उसके गुप्त मान को लॉग्स में कॉपी किए। केवल कुकी की उपस्थिति यह सिद्ध नहीं करती कि सर्वर ने सत्र स्वीकार कर लिया है।
एक साफ प्रोफ़ाइल या प्राइवेट ब्राउज़िंग सत्र उपयोगी तुलनात्मक साक्ष्य प्रदान करता है। यदि उसका रिडायरेक्ट अनुक्रम अलग हो, तो विशिष्ट स्टेट अंतर की जाँच करें: कुकीज़, स्टोरेज, एक्सटेंशन्स, या ऑथेंटिकेशन संदर्भ। प्राइवेट ब्राउज़िंग सत्र परिवेश भी बदल देती है, इसलिए यह अपने आप में “कुकीज़ खराब हैं” का निर्णायक परीक्षण नहीं है।
किसी स्वामित्व वाले लॉगिन फ़्लो के लिए, कॉन्फ़िगर किए गए रिटर्न गंतव्य और वे शर्तें जाँचें जो ऑथेंटिकेशन के पूर्ण होने को चिह्नित करती हैं। कोई लॉगिन सफलता पेज जो ऐसे रूट पर रिडायरेक्ट करता है जो अलग सत्र डोमेन का उपयोग करता है, स्कोप विसंगति को उजागर कर सकता है। कोई आइडेंटिटी प्रोवाइडर गलत स्कीम या होस्ट पर भी लौट सकता है। एक पैरामीटर बदलने से पहले पूरे फ़्लो को ट्रेस करें।
रिडायरेक्ट लूप्स की तुलना अन्य पेज विफलताओं से करें
ERR_TOO_MANY_REDIRECTS के लिए रिडायरेक्ट-चेन साक्ष्य की आवश्यकता होती है। आस-पास की विफलताओं के उपयोगकर्ता-दृश्यमान परिणाम समान हो सकते हैं परंतु कारण भिन्न हो सकते हैं।
| अवलोकन | अर्थ | अगला साक्ष्य |
|---|---|---|
| दोहराई जाने वाली रिडायरेक्ट स्टेट | नियम या सत्र निर्णय एक चक्र बनाते हैं | प्रत्येक हॉप और उसे उत्पन्न करने वाला घटक |
| लंबी सीमित चेन | बहुत अधिक मध्यवर्ती नेविगेशन निर्णय | प्रवेश URL और पूर्ण अनुक्रम |
| सामान्य अंतिम पेज | नेविगेशन अनुरोधित पहचान के बिना समाप्त होता है | अपेक्षित संसाधन और अंतिम URL |
| TLS या कनेक्शन विफलता | परिवहन उपयोगी नेविगेशन से पहले विफल हो जाता है | सुरक्षित कनेक्शन या नेटवर्क साक्ष्य |
कोई पेज जो किसी सामान्य होमपेज पर पहुँचता है, उसके पास सीमित रिडायरेक्ट चेन हो सकती है और फिर भी आपकी सामग्री आवश्यकताओं को पूरा करने में विफल हो सकता है। एक सॉफ़्ट 404 अनुरोधित संसाधन के बिना भी सफलतापूर्वक लौटाया जा सकता है। कोई प्रमाणपत्र त्रुटि उपयोगी सुरक्षित प्रतिक्रिया से पहले नेविगेशन को रोक सकती है। हर विफल पेज को रिडायरेक्ट समस्या की तरह मानने के बजाय विशिष्ट श्रेणी को संरक्षित रखें।
रिडायरेक्ट स्टेटस स्वयं में त्रुटि नहीं है। मौजूदा लिंक और लॉगिन फ़्लो अक्सर रिडायरेक्ट पर निर्भर होते हैं। प्रश्न यह है कि क्या अनुक्रम अपने इच्छित संसाधन तक पहुँचता है और उपयुक्त अनुरोध अर्थ को संरक्षित रखता है। वे ऐप्लिकेशन अनुरोध जो स्टेट बदलते हैं, उनके लिए स्वचालित नेविगेशन की अनुमति देने से पहले यह पुष्टि करें कि क्लाइंट का समर्थित रिडायरेक्ट व्यवहार मेथड और बॉडी को कैसे संभालता है।
वेब डेटा संग्रह में रिडायरेक्ट साक्ष्य
कलेक्टर को मूल URL, रिडायरेक्ट इतिहास, और अंतिम संसाधन पहचान को बनाए रखना चाहिए। असंबंधित अंतिम पेज को निकालते समय मूल URL को स्रोत कुंजी के रूप में उपयोग करने से डेटा सेट भ्रष्ट हो सकता है। किसी स्थानांतरित लेख को उसके संबंधित नए लेख की आवश्यकता होती है; केवल इसलिए कि होमपेज सुलभ है, वह समतुल्य प्रतिनिधित्व नहीं है।
स्वीकृत गंतव्यों के लिए एक स्पष्ट कैप्चर नियम निर्धारित करें। किसी स्वामित्व वाले लॉगिन फ़्लो के लिए डोमेन ट्रांज़िशन अपेक्षित हो सकता है, लेकिन किसी अनाम सार्वजनिक लेख कैप्चर के लिए अनुचित। इन नियमों को वर्कफ़्लो के लिए विशिष्ट रखें। यदि पाथ ऐसे ऑथेंटिकेशन या सहमति स्टेट में प्रवेश करता है जिसे कलेक्टर संभालने के लिए कॉन्फ़िगर नहीं है, तो उस स्थिति को रिकॉर्ड करें, बजाय इसके कि इंटरस्टिशियल को स्रोत सामग्री के रूप में निकाला जाए।
The Scrapeless Agent Browser session environment डायनेमिक नेविगेशन की जाँच के लिए ब्राउज़र एक्सीक्यूशन प्रदान करता है। आपका कलेक्शन लॉजिक यह निर्णय लेने के लिए उत्तरदायी रहता है कि अंतिम पेज उपयोगी है या नहीं। एक सुसंगत सत्र बनाए रखना स्टेट-निर्भर नेविगेशन की तुलना करने में मदद कर सकता है, लेकिन यह किसी ऐसी वेबसाइट पर परस्पर-विरोधी रिडायरेक्ट नियमों को ठीक नहीं कर सकता जिस पर आपका नियंत्रण नहीं है।
किसी स्वामित्व वाले रिडायरेक्ट संघर्ष को ठीक करने के बाद, एक साफ सत्र और पहले प्रभावित सत्र की तुलना करें। मूल प्रवेश URL से शुरू होने वाली चेन का निरीक्षण करें और अपेक्षित अंतिम प्रतिनिधित्व की पुष्टि करें। केवल पहले से-कैनॉनिकल गंतव्य का परीक्षण करने से वह पुराना चक्र छूट सकता है जिसमें उपयोगकर्ता अभी भी सेव किए हुए लिंक के माध्यम से प्रवेश कर रहे हैं।
The Agent Browser product आपके कैप्चर के लिए तब प्रासंगिक है जब नेविगेशन और रेंडर की गई स्टेट मायने रखती है। The cloud proxy routing model उन मध्यस्थों की पहचान करने के लिए पृष्ठभूमि प्रदान करता है जो नेविगेशन पाथ में भाग ले सकते हैं। सत्र आवश्यकताओं को वास्तविक वर्कफ़्लो के अनुरूप रखते हुए current Scrapeless plans की समीक्षा करें।
हर रिडायरेक्ट नियम को अभिसरण कराएँ
ERR_TOO_MANY_REDIRECTS को हल करने का अर्थ है नेविगेशन नियमों के सम्मिलित सेट को किसी उपयोगी एन्डपॉइंट पर अभिसरित करना। पहला परस्पर-विरोधी स्टेट खोजें, उन घटकों की पहचान करें जो उसे उत्पन्न करते हैं, और स्कीम, कैनॉनिकल URL, और सत्र निर्णयों को संरेखित करें।
थर्ड-पार्टी कलेक्शन के लिए, समापन का अर्थ है संरक्षित चेन के साथ एक स्वीकृत अंतिम संसाधन। जब चेन अनसुलझी रहती है, तो नेविगेशन विफलता की सटीक रिपोर्ट करें और उसे सफल सामग्री रिकॉर्ड्स से बाहर रखें।
एक अधिक प्रेक्षणीय वेब डेटा वर्कफ़्लो बनाएँ
किसी प्रबंधित Agent Browser सत्र में नेविगेशन का निरीक्षण करें और रिडायरेक्ट इतिहास को अंतिम सामग्री पहचान से जुड़ा रखें।
आज ही साइन अप करें और प्राप्त करें $5 in free credit — कोई क्रेडिट कार्ड आवश्यक नहीं.
अपना $5 क्रेडिट क्लेम करें →FAQ
प्रश्न: क्या ERR_TOO_MANY_REDIRECTS हमेशा दो-URL लूप का अर्थ है?
ERR_TOO_MANY_REDIRECTS हमेशा दो-URL लूप का अर्थ नहीं है। कोई लंबा चक्र या अत्यधिक रिडायरेक्ट चेन भी ब्राउज़र की सीमा को समाप्त कर सकता है। पूर्ण अनुक्रम को ट्रेस करें और दोहराए गए निर्णयों की जाँच करें, जिनमें बदलते पैरामीटर्स भी शामिल हैं।
प्रश्न: क्या कुकीज़ साफ़ करना हमेशा रिडायरेक्ट लूप को ठीक कर देता है?
कुकीज़ साफ़ करना हमेशा रिडायरेक्ट लूप को ठीक नहीं करता। पहले किसी साफ सत्र की तुलना करें और अंतर की जाँच करें। यदि सभी सत्र एक ही परस्पर-विरोधी स्कीम या URL नियमों का पालन करते हैं, तो डिप्लॉयमेंट को उस घटक पर सुधार की आवश्यकता है जो रिडायरेक्ट्स उत्पन्न करता है।
प्रश्न: क्या HTTPS termination रीडायरेक्ट लूप्स में योगदान दे सकता है?
जब edge और एप्लिकेशन मूल अनुरोध की scheme के बारे में असहमत होते हैं, तो HTTPS termination योगदान दे सकता है। प्रलेखित proxy trust और scheme configuration को सही करें। रीडायरेक्ट नियमों को अभिसरित करते समय transport protections को बरकरार रखें।
प्रश्न: क्या किसी scraper को अंतिम पहुँची जा सकने वाली रीडायरेक्ट पेज को स्वीकार करना चाहिए?
किसी scraper को अंतिम पेज तभी स्वीकार करना चाहिए जब उसकी पहचान और सामग्री संग्रह आवश्यकताओं को पूरा करे। कोई homepage, login स्क्रीन, या consent interstitial पहुँच योग्य हो सकता है, लेकिन अनुरोधित resource का प्रतिनिधित्व न करता हो। अस्वीकार की गई capture के साथ रीडायरेक्ट अनुक्रम को संरक्षित रखें।