समस्या निवारण:बहुत अधिक रीडायरेक्ट

त्रुटि "बहुत अधिक पुनर्निर्देश" का अर्थ है कि वेबसाइट को अलग-अलग पतों के बीच इस तरह से पुनर्निर्देशित किया जाता है जो कभी पूरा नहीं होगा। अक्सर यह प्रतिस्पर्धी रीडायरेक्ट का परिणाम होता है, एक HTTPS (SSL) को बाध्य करने का प्रयास करता है और दूसरा HTTP (गैर-SSL) पर वापस रीडायरेक्ट करता है, या URL के www और गैर-www रूपों के बीच होता है।

यदि आप Wordpress, Magento, आदि जैसे CMS का उपयोग कर रहे हैं, जो एक base_url का उपयोग करता है या साइट के भीतर URL प्रकार कॉन्फ़िगरेशन, आप कोड या डेटाबेस में कॉन्फ़िगरेशन के साथ एक .htaccess फ़ाइल में रीडायरेक्ट के साथ विरोध कर सकते हैं। ये परस्पर विरोधी रीडायरेक्ट आगे और पीछे फ़्लॉप हो जाएंगे और कभी भी पूर्ण नहीं होंगे।

आपका ब्राउज़र इसे छोड़ने से पहले केवल एक निश्चित संख्या में रीडायरेक्ट (अक्सर दस या तो) की अनुमति देकर आपकी रक्षा करता है और त्रुटि संदेश "बहुत अधिक रीडायरेक्ट" की रिपोर्ट करता है। यह क्रोम, फ़ायरफ़ॉक्स और अन्य ब्राउज़रों के बीच अलग तरह से दिखाई देता है।

फ़ायरफ़ॉक्स

पेज ठीक से रीडायरेक्ट नहीं हो रहा है। <डोमेन> . से कनेक्शन के दौरान एक त्रुटि हुई

क्रोम

यह पेज काम नहीं कर रहा है <डोमेन> ने आपको कई बार रीडायरेक्ट किया है

यहां तक ​​कि परीक्षण उपयोगिता कर्ल डिफ़ॉल्ट रूप से 50 रीडायरेक्ट के बाद छोड़ देता है।

कर्ल: अधिकतम (X) रीडायरेक्ट का अनुसरण किया गया

curl -svILk https://www.example.com
 ....
 * Maximum (50) redirects followed

पहला चरण:कैशे और कुकीज

जैसा कि ऊपर ब्राउज़र त्रुटियों में दिखाया गया है, ये लूपिंग रीडायरेक्ट ब्राउज़र में कुकीज़ के पुराने रीडायरेक्ट को कैशिंग करने के कारण भी हो सकते हैं। परीक्षण में पहला कदम आपके ब्राउज़र में आपके कैशे और कुकीज़ को साफ़ करना होगा। यदि आपने पहले ही ब्राउज़र में कैशे और कुकीज़ को साफ़ कर दिया है, तो यह कुछ और उन्नत समस्या निवारण पर आगे बढ़ने का समय है।

रीडायरेक्ट लूप्स के लिए डेवलपर टूल का उपयोग करना

इस प्रकार के रीडायरेक्ट लूप के समस्या निवारण में अगला चरण फ़ायरफ़ॉक्स या क्रोम में डेवलपर टूल का उपयोग करना है। ये उपकरण आमतौर पर F12 कुंजी दबाकर खोले जाते हैं। सुनिश्चित करें कि आपने नेटवर्क . का चयन किया है इनमें से किसी एक में टैब करें और फिर उस पृष्ठ को पुनः लोड करें जिसमें आपको कोई समस्या आ रही है।

पृष्ठ को पुनः लोड करने के बाद, आपको नई विंडो में आपके लिए सूचीबद्ध पुनर्निर्देशों की श्रृंखला दिखाई देनी चाहिए। रीडायरेक्ट को देखते हुए, आप देख सकते हैं कि क्या वे कुछ अलग चीज़ों के बीच रीडायरेक्ट कर रहे हैं या एक ही चीज़ पर रीडायरेक्ट कर रहे हैं। किसी भी तरह से, आप केवल अंतिम उपयोगकर्ता की ब्राउज़र त्रुटि के बजाय, त्रुटि की ओर ले जाने वाले चरण देख सकते हैं।

फ़ायरफ़ॉक्स में डेवलपर टूल

रीडायरेक्ट लूप्स के लिए कर्ल का उपयोग करना

इस लेख को लिखने के हिस्से के रूप में, हमने एक काफी सरल बैश स्क्रिप्ट को एक साथ रखा है जिसका उपयोग किसी भी यूनिक्स जैसी प्रणाली पर कर्ल के साथ किया जा सकता है। आज्ञा। कर्ल का उपयोग करना अच्छा है, क्योंकि यह चीजों को उसी तरह कैश नहीं करता है जैसे ब्राउज़र करता है, इसलिए यह कभी-कभी समस्या निवारण करते समय आपको एक अलग दृष्टिकोण दे सकता है।

निम्नलिखित को अपने पसंदीदा टेक्स्ट एडिटर में कॉपी करें और इसे redirects.sh . के रूप में सहेजें ।

#!/bin/bash
 echo
 for domain in $@; do
 echo --------------------
 echo $domain
 echo --------------------
 curl -sILk $domain | egrep 'HTTP|Loc' | sed 's/Loc/ -> Loc/g'
 echo
 done

फिर redirects.sh . को चिह्नित करें निष्पादन योग्य के रूप में फ़ाइल।

chmod +x redirects.sh

आप नीचे दिए गए उदाहरणों की तरह, स्क्रिप्ट नाम के बाद अपना डोमेन जोड़कर हमारी स्क्रिप्ट चला सकते हैं। यह कई डोमेन की जांच भी कर सकता है और यह प्रत्येक यूआरएल के रीडायरेक्ट की जांच करेगा, बदले में, परीक्षण किए गए अलग डोमेन के बीच एक हेडर डालेगा।

उदाहरण आउटपुट

./redirects.sh liquidweb.com
 --------------------
 liquidweb.com
 --------------------
 HTTP/1.1 301 Moved Permanently
 -> Location: https://liquidweb.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.liquidweb.com/
 HTTP/1.1 200 OK

HTTP से HTTPS पर अनंत रीडायरेक्ट का उदाहरण

./redirects.sh http://www.example.com
 --------------------
 http://www.example.com
 --------------------
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: http://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: http://www.example.com/
 HTTP/1.1 301 Moved Permanently
 ....
 -> Location: https://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: http://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: http://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.example.com/

रीडायरेक्ट प्रकारों पर एक साइड नोट

कर्ल . को देख रहे हैं ऊपर आउटपुट आप देख सकते हैं कि HTTP प्रतिक्रिया कोड 301 है। 301 रीडायरेक्ट "स्थायी" रीडायरेक्ट हैं, जिसका अर्थ है कि कुछ स्थायी रूप से स्थानांतरित हो गया है, और आपको या आपके ब्राउज़र को इसे अभी और भविष्य में नए स्थान पर देखना होगा। 302 रीडायरेक्ट "अस्थायी" रीडायरेक्ट हैं जिसका मतलब है कि कुछ अभी के लिए स्थानांतरित हो गया है, लेकिन हमेशा नए स्थान पर नहीं हो सकता है।

301 रीडायरेक्ट अक्सर .htaccess फ़ाइल में रीडायरेक्ट या रीराइट एंट्री के रूप में लिखे जाते हैं। हालांकि, 302 पुनर्निर्देशन या तो डिजाइन या परंपरा द्वारा अक्सर एक वेबसाइट के कोड के भीतर उत्पन्न होते हैं। तो अंगूठे का अच्छा नियम है 301s .htaccess फ़ाइलों में हैं, और 302s साइट कोड में हैं। यह हमेशा सच नहीं हो सकता है, लेकिन इसे ध्यान में रखना एक अच्छी बात है।

.htaccess फ़ाइल में रीडायरेक्ट करता है

.htaccess फ़ाइल एक कॉन्फ़िगरेशन फ़ाइल है जिसका उपयोग किसी वेबसाइट/सर्वर पर प्रति निर्देशिका अपाचे सर्वर व्यवहार को संशोधित करने के लिए किया जाता है। यह एक उपयोगकर्ता-स्तरीय कॉन्फ़िगरेशन फ़ाइल है, और यहां केवल कुछ अपाचे कॉन्फ़िगरेशन संपादित किए जा सकते हैं, हालांकि रीडायरेक्ट सामान्य उपयोग हैं।

आपके पास एकाधिक .htaccess फ़ाइलें हो सकती हैं जो निर्देशिकाओं की एक श्रृंखला पर कैस्केड करती हैं। यदि आपके पास मूल निर्देशिका में .htaccess है, और दूसरा उप-निर्देशिका में है, तो वे दोनों उप-निर्देशिका को प्रभावित करेंगे। इन उदाहरणों में, यह याद रखना महत्वपूर्ण है कि आप कहां हैं और .htaccess फ़ाइलें नहीं हैं, विभिन्न स्तरों पर .htaccess फ़ाइलों के बीच विरोध को रोकने के लिए।

नीचे रीडायरेक्ट उदाहरणों की एक श्रृंखला दी गई है और यह आपकी .htaccess फ़ाइल में रीडायरेक्ट की पहचान करने में सहायता करेगा। इस प्रकार के रीडायरेक्ट करने के लिए ये एकमात्र तरीके नहीं हैं, लेकिन ये आपको दिखाएंगे कि सबसे आम रीडायरेक्ट कैसा दिखता है ताकि आप उन्हें पहचान सकें यदि वे उस .htaccess फ़ाइल में हैं जिसके साथ आप काम कर रहे हैं।

HTTPS ज़बरदस्ती करें

नीचे दिया गया .htaccess कोड पहले जांचता है कि अनुरोध HTTP या HTTPS का उपयोग कर सर्वर में आया है या नहीं। यदि अनुरोध HTTPS का उपयोग नहीं करता है, तो कॉन्फ़िगरेशन ब्राउज़र को उसी वेबसाइट और URL के HTTPS संस्करण पर पुनर्निर्देशित करने के लिए कहेगा जिसका अनुरोध पहले किया गया था।

RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

बल HTTPS:जब एक लोड बैलेंसर या प्रॉक्सी के पीछे (क्लाउडफ्लेयर/इनकैप्सुला/सुकुरी/आदि)

कभी-कभी आप प्रॉक्सी का उपयोग कर रहे होंगे, जैसे लोड बैलेंसर या वेब फ़ायरवॉल, जैसे CloudFlare, Incapsula, या Sucuri। इन्हें फ्रंट एंड पर एसएसएल का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है, लेकिन बैक एंड पर एसएसएल का उपयोग नहीं किया जा सकता है। इसे ठीक से काम करने की अनुमति देने के लिए, आपको न केवल अनुरोध में HTTPS की जांच करने की आवश्यकता है, बल्कि यह भी जांचना होगा कि क्या प्रॉक्सी ने केवल HTTP का उपयोग करके सर्वर को मूल HTTPS अनुरोध पास किया है। यह निम्न नियम जांचता है कि अनुरोध HTTPS से अग्रेषित किया गया था, और यदि ऐसा है तो अतिरिक्त समय को पुनर्निर्देशित करने का प्रयास नहीं करता है।

RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteCond %{HTTP:X-Forwarded-Proto} =http
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

फोर्स नॉन-www

यह रीडायरेक्ट केवल यह जांचता है कि डोमेन नाम की शुरुआत में www के साथ वेबसाइट नाम का अनुरोध किया गया था या नहीं। यदि www शामिल है, तो यह अनुरोध को फिर से लिखता है और ब्राउज़र को डोमेन नाम के गैर-www संस्करण पर पुनर्निर्देशित करने के लिए कहता है।

RewriteEngine On
 RewriteCond %{HTTP_HOST} ^www\. [NC]
 RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

www को बाध्य करें

यह अंतिम रीडायरेक्ट जांचता है कि क्या डोमेन नाम की शुरुआत में www के साथ वेबसाइट नाम का अनुरोध नहीं किया गया था। यदि www शामिल नहीं है, तो यह अनुरोध को फिर से लिखता है और ब्राउज़र को डोमेन के www संस्करण पर पुनर्निर्देशित करने के लिए कहता है।

RewriteEngine On
 RewriteCond %{HTTP_HOST} !^www\. [NC]
 RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

वर्डप्रेस

वर्डप्रेस सीएमएस index.php में URL को फिर से लिखने के लिए एक .htaccess फ़ाइल का उपयोग करता है। फ़ाइल, लेकिन यह वेबसाइट के URL को डेटाबेस में मान के रूप में परिभाषित करता है। यदि आप साइट पर उपयोग किए जा रहे डेटाबेस का नाम पहले से नहीं जानते हैं, तो आप इसे वर्डप्रेस के लिए मुख्य कॉन्फ़िगरेशन में देख सकते हैं (wp-config.php )।

आप फ़ाइल को टेक्स्ट एडिटर में भी खोल सकते हैं और इन मानों की तलाश कर सकते हैं, लेकिन SSH कनेक्शन से, आप प्रोग्राम grep का उपयोग कर सकते हैं। . यह आपको केवल डेटाबेस नाम से अधिक देता है, लेकिन हमें आगे जो करने की आवश्यकता है उसके लिए डेटाबेस नाम सबसे महत्वपूर्ण है।

grep DB wp-config.php

define('DB_NAME', 'wordpress_database');
 define('DB_USER', 'wordpress_username');
 define('DB_PASSWORD', 'Password');
 define('DB_HOST', 'localhost');
 define('DB_CHARSET', 'utf8');
 define('DB_COLLATE', '');

wp_options तालिका

एक बार जब आप डेटाबेस का नाम जान लेते हैं, तो आप Wordpress डेटाबेस के विकल्प तालिका को देख सकते हैं कि डेटाबेस में URL किस पर सेट है। विकल्प तालिका में तालिका नाम की शुरुआत में कोई भी उपसर्ग हो सकता है, लेकिन यह अक्सर "wp_" होता है डिफ़ॉल्ट रूप से, इसलिए विकल्प तालिका का पूरा नाम आमतौर पर wp_options . होता है . महत्वपूर्ण दो पंक्तियाँ हैं होम और siteurl विकल्प तालिका में पंक्तियाँ। आप इन्हें phpMyAdmin . का उपयोग करके पा सकते हैं , या किसी अन्य डेटाबेस प्रबंधन उपयोगिता, लेकिन कमांड लाइन से, आप केवल निम्न mysql भी चला सकते हैं आदेश।

mysql -e 'show tables' wordpress_database | grep options

prefix_options

कॉन्फ़िगर किए गए यूआरएल की जांच करना

कमांड लाइन से, आप जांच सकते हैं कि होम . के वर्तमान मान क्या हैं और siteurl विकल्प तालिका में पंक्तियाँ। कमांड को आपको नीचे दिए गए उदाहरण की तरह आउटपुट और आउटपुट भेजना चाहिए। महत्वपूर्ण हिस्सा यह है कि ये ज्यादातर परिस्थितियों में एक दूसरे से मेल खाते हैं और वे वही हैं जो आप उम्मीद करते हैं। यदि वे आपकी अपेक्षा के अनुरूप नहीं हैं तो आप उन्हें तदनुसार अपडेट करना चाहेंगे।

mysql -e 'select * from wp_options where option_name rlike "home|siteurl"' wordpress_database
 +-----------+-------------+----------------------------------+----------+
 | option_id | option_name | option_value                     | autoload |
 +-----------+-------------+----------------------------------+----------+
 |        36 | home        | http://www.example.com           | yes |
 |         1 | siteurl     | http://www.example.com           | yes |
 +-----------+-------------+----------------------------------+----------+

कॉन्फ़िगर किए गए यूआरएल को अपडेट करना

निम्न आदेश wp_options . की दो पंक्तियों को अपडेट करेगा किसी दिए गए डेटाबेस के लिए एक नए URL के लिए तालिका। यह आदेश उन अधिकांश स्थितियों के अनुकूल होना चाहिए जहां आपको किसी Wordpress साइट के लिए कॉन्फ़िगर किए गए URL को अपडेट या सही करने की आवश्यकता होती है। base_urls को अपडेट कर रहा है Wordpress मल्टीसाइट में कॉन्फ़िगर किया गया इस लेख के दायरे से बाहर है, लेकिन इसमें कई wp_option को अपडेट करना शामिल होगा। टेबल टाइप करें।

mysql -e 'update wp_options set option_value="https://www.example.com" where option_name rlike "home|siteurl"' wordpress_database

Magento

Magento डेटाबेस नाम निम्न फ़ाइलों में से एक में कॉन्फ़िगर किया गया है, local.xml या env.php . आप Magento डेटाबेस के तालिका नामों के लिए एक उपसर्ग भी कॉन्फ़िगर कर सकते हैं, लेकिन यह आमतौर पर सेट नहीं होता है। तो डेटाबेस की मुख्य कॉन्फ़िगरेशन तालिका के लिए अपेक्षित नाम केवल core_config_data है ।

# Version 1.x
 app/etc/local.xml

# Version 2.x
 app/etc/env.php

core_config_data तालिका

ऐसे कई संभावित URL हैं जिन्हें कॉन्फ़िगर किया जा सकता है, लेकिन उन सभी में "base_url है " डेटाबेस में लाइन के हिस्से के रूप में। कॉन्फ़िगर किया गया प्राथमिक यूआरएल सुरक्षित और असुरक्षित यूआरएल होगा, लेकिन आप छवियों, थीम फाइलों के लिए यूआरएल भी सेट कर सकते हैं, या साइट के प्रशासन क्षेत्र के लिए एक अलग यूआरएल भी सेट कर सकते हैं। आप डेटाबेस प्रबंधन उपयोगिता का उपयोग करके इन्हें फिर से ढूंढ सकते हैं, लेकिन कमांड लाइन से, आप निम्न की तरह कुछ चला सकते हैं।

mysql -e 'select * from core_config_data where path rlike "base_url"' magento_database
 +-----------+---------+----------+-----------------------+----------------------------+
 | config_id | scope   | scope_id | path             | value |
 +-----------+---------+----------+-----------------------+----------------------------+
 |         3 | default |        0 | web/unsecure/base_url | http://www.example.com     |
 |         4 | default |        0 | web/secure/base_url   | http://www.example.com   |
 +-----------+---------+----------+-----------------------+----------------------------+

base_urls को अपडेट करने के लिए Magento डेटाबेस में, आप नीचे दिए गए आदेश की तरह कुछ चलाएंगे। मैगेंटो मल्टीसाइट के बेस_यूआरएल को अपडेट करना भी इस लेख के दायरे से बाहर है, लेकिन इसमें विशिष्ट scope_id को अतिरिक्त रूप से संदर्भित करना शामिल होगा। दी गई वेबसाइट या Magento डेटाबेस में कॉन्फ़िगर किए गए स्टोर के लिए मान।

mysql -e 'update core_config_data set value="https://www.example.com" where path rlike "web/.*/base_url"' magento_database

इसे पूरी तरह से लपेटना

डेटाबेस में कॉन्फ़िगर किए गए URL के साथ, जैसा कि ऊपर दिखाया गया है, यह ध्यान देने योग्य है कि ये CMS साइट कोड के भीतर अपने स्वयं के रीडायरेक्ट तरीके भी प्रदान करते हैं। यदि, उदाहरण के लिए, आपके पास एक .htaccess रीडायरेक्ट है जो किसी ऐसे URL पर रीडायरेक्ट कर रहा है जो डेटाबेस में मौजूद चीज़ों के साथ संरेखित नहीं है, तो आप पहले बताए गए अनंत रीडायरेक्ट लूप के साथ समाप्त हो सकते हैं। हालाँकि, अब आप जानते हैं कि कुछ सामान्य .htaccess पुनर्निर्देश क्या दिखते हैं और कुछ CMS सॉफ़्टवेयर डेटाबेस में कॉन्फ़िगर किए गए URL कहाँ मिलते हैं। आप परीक्षण, जांच और पुष्टि करने के लिए भी अच्छी तरह से सुसज्जित हैं कि क्या ये चीजें एक साथ काम कर रही हैं या एक दूसरे के खिलाफ काम कर रही हैं, और उन्हें हल करने के लिए कुछ कदम हैं।