डोमेन रीडायरेक्ट चेकर

सर्वर सहायता नया DNS और डोमेन

Mutqan सर्वर डोमेन से चारों शुरुआती URL बनाता है, हर एक को हॉप-दर-हॉप फ़ॉलो करता है (हर रूप के लिए अधिकतम पाँच रिस्पॉन्स, हर हॉप के लिए छह सेकंड, पूरी जाँच के लिए बीस सेकंड, पेज की सामग्री पढ़े बिना) और देखता है कि वे कहाँ ख़त्म होते हैं। आपको हर स्टेटस कोड और Location हेडर दिखता है, चारों के सहमत होने पर canonical होस्ट, और सादे HTTP पर ख़त्म होने, HTTPS से HTTP पर उतरने, अस्थायी रीडायरेक्ट, लंबी श्रृंखला, लूप और resolve न होने वाले रूपों पर नोट्स। हर हॉप उसी पब्लिक-एड्रेस जाँच से गुज़रता है जिससे पहला अनुरोध।

गोपनीयता: Mutqan सर्वर इस पेज पर बताई गई छोटी, तय टेस्ट रिक्वेस्ट आपके बताए होस्ट को भेजता है, और कुछ भी स्टोर नहीं होता। इसे सिर्फ़ उन्हीं सिस्टम पर इस्तेमाल करें जिन्हें टेस्ट करने की आपको अनुमति है।

डोमेन के www, बिना-www, HTTP और HTTPS पते कैसे रीडायरेक्ट होने चाहिए?

साइट को एक ही canonical पते पर जवाब देना चाहिए और http/https व www/बिना-www के बाक़ी तीन मेलों को स्थायी रीडायरेक्ट (301 या 308) से वहीं भेजना चाहिए, ताकि ब्राउज़र, लिंक और सर्च इंजन एक ही साइट देखें। सादा HTTP, HTTPS पर रीडायरेक्ट होना चाहिए — अगर डोमेन HSTS preload होना है तो पहले उसी होस्ट पर — और श्रृंखला छोटी रहनी चाहिए: हर अतिरिक्त हॉप पेज लोड से पहले एक और आना-जाना है।

डोमेन रीडायरेक्ट चेकर कैसे इस्तेमाल करें

  1. डोमेन लिखें (www. के साथ या बिना; पेस्ट किया URL होस्ट नाम तक छोटा हो जाता है)।
  2. "रीडायरेक्ट जाँचें" दबाएँ।
  3. सारांश पढ़ें: लक्ष्य है एक canonical होस्ट, चारों रूप एकरूप, और चार में से चार HTTPS पर ख़त्म।
  4. नोट्स और हर रिस्पॉन्स की टेबल से उन रीडायरेक्ट को ठीक करें जो अस्थायी हैं, बहुत लंबे हैं या ग़लत जगह ख़त्म होते हैं।

डोमेन रीडायरेक्ट चेकर की खूबियाँ

  • एक ही जाँच में चारों रूप: डोमेन के http://, https://, http://www. और https://www.
  • हर श्रृंखला का हर रिस्पॉन्स, स्टेटस कोड और Location हेडर के साथ, CSV में डाउनलोड करने लायक़
  • चारों के सहमत होने पर canonical होस्ट, और क्या वे एक ही स्कीम और होस्ट पर ख़त्म होते हैं
  • सादे HTTP पर ख़त्म होने, HTTPS से HTTP पर उतरने, अस्थायी रीडायरेक्ट, दो से ज़्यादा रीडायरेक्ट वाली श्रृंखला, एरर पेज और लूप पर नोट्स
  • यह जाँच कि सादा HTTP पहले उसी होस्ट के HTTPS पर रीडायरेक्ट होता है, जो तब मायने रखता है जब डोमेन को HSTS preload करना हो
  • हर रूप की साफ़ त्रुटि: resolve नहीं होता, समय समाप्त, पहुँच नहीं, ब्लॉक एड्रेस, अमान्य Location हेडर

इनपुट और आउटपुट

इनपुट

  • डोमेन नाम: बिना-www नाम या www. वाला नाम (चारों रूप हमेशा बिना-www नाम से बनते हैं), या URL, जो अपने होस्ट तक छोटा होता है।
  • अंतरराष्ट्रीय नाम चलते हैं; IP एड्रेस नहीं, क्योंकि www. वाले रूपों के लिए नाम चाहिए।

आउटपुट

  • सारांश: डोमेन, canonical होस्ट (जब सारे रूप एक होस्ट पर ख़त्म हों), चारों एकरूप हैं या नहीं, कितने HTTPS पर ख़त्म होते हैं और कितने विफल रहे।
  • चारों रूप: शुरुआती URL, रीडायरेक्ट की संख्या, स्टेटस श्रृंखला, अंतिम URL और नतीजा।
  • हर रिस्पॉन्स: हर हॉप का URL, स्टेटस कोड और Location हेडर।
  • निष्कर्ष: क्या ठीक करना है, या पुष्टि कि चारों रूप एक ही पते पर ख़त्म होते हैं।

डोमेन रीडायरेक्ट चेकर का उदाहरण

ऐसा डोमेन जिसके चारों रूप https://www. पर पहुँचते हैं

इनपुट:

wikipedia.org

आउटपुट:

सारांश: डोमेन wikipedia.org · Canonical होस्ट www.wikipedia.org · एकरूप हाँ · HTTPS पर ख़त्म 4 / 4 · त्रुटि वाले रूप 0
चारों रूप:
http://wikipedia.org/ | 2 | 301 → 301 → 200 | https://www.wikipedia.org/ | ठीक (2xx)
https://wikipedia.org/ | 1 | 301 → 200 | https://www.wikipedia.org/ | ठीक (2xx)
http://www.wikipedia.org/ | 1 | 301 → 200 | https://www.wikipedia.org/ | ठीक (2xx)
https://www.wikipedia.org/ | 0 | 200 | https://www.wikipedia.org/ | ठीक (2xx)
निष्कर्ष: चारों रूप एक ही पते पर ख़त्म होते हैं: https://www.wikipedia.org

डोमेन रीडायरेक्ट चेकर के नतीजे कैसे पढ़ें

सही नतीजा: एक canonical होस्ट वाले एकरूप रूप, और चार में से चार HTTPS पर ख़त्म — यानी हर रूप एक ही HTTPS पते पर पहुँचता है।

जो रूप "सादे HTTP पर ही रहता है" या "HTTP पर उतर जाता है", वह विज़िटर को बिना एन्क्रिप्शन वाला पेज दिखाता है; उसे 301 या 308 से HTTPS पते पर भेजें।

canonical डोमेन बदलने पर अस्थायी रीडायरेक्ट (302, 303, 307) सर्च इंजन को बताता है कि पुराना पता ही असली है; जब तक बदलाव सच में अस्थायी न हो, 301 या 308 इस्तेमाल करें।

अलग-अलग अंतिम होस्ट का मतलब है कि रूप दो साइट परोस रहे हैं; एक होस्ट चुनें और बाक़ी को उस पर रीडायरेक्ट करें।

डोमेन रीडायरेक्ट चेकर कब इस्तेमाल करें

  • लॉन्च या HTTPS पर माइग्रेशन जाँचना: हर रूप नए canonical पते पर पहुँचना चाहिए।
  • HSTS preload आवेदन की तैयारी, जिसके लिए उसी होस्ट पर HTTPS रीडायरेक्ट ज़रूरी है।
  • पता लगाना कि "example.com" चलता है पर "www.example.com" नहीं, या इसका उल्टा, क्यों।
  • www और बिना-www दोनों पर जवाब देने वाली साइट से बने SEO डुप्लिकेट की जाँच।

समस्या निवारण

  • www. वाले रूपों के लिए "resolve नहीं होता": www नाम का कोई A या AAAA रिकॉर्ड नहीं है। DNS प्रोवाइडर पर एक जोड़ें (या CNAME)।
  • https:// के लिए "पहुँच नहीं" या "समय समाप्त": पोर्ट 443 पर कोई वेब सर्वर जवाब नहीं देता, या TLS handshake विफल होता है; SSL Certificate Checker वजह बताता है।
  • "अस्वीकार (ब्लॉक एड्रेस)": नाम या श्रृंखला का कोई हॉप ऐसे प्राइवेट या रिज़र्व एड्रेस पर resolve होता है जिससे Mutqan सर्वर कभी कनेक्ट नहीं होता।
  • "रीडायरेक्ट लूप": दो नियम अनुरोध को आगे-पीछे भेजते हैं, अक्सर सर्वर का HTTPS रीडायरेक्ट CDN के रीडायरेक्ट से टकराता है। उनमें से एक बंद करें।

डोमेन रीडायरेक्ट चेकर के बारे में अक्सर पूछे जाने वाले सवाल

मेरी साइट www वाली हो या बिना www वाली?

दोनों ठीक हैं। ज़रूरी यह है कि आप एक चुनें और बाक़ी तीन रूपों को स्थायी रीडायरेक्ट से उस पर भेजें, ताकि लिंक, कुकी और सर्च इंजन एक ही पता देखें। टूल बताता है कि रूप किस होस्ट पर ख़त्म होते हैं और कहीं और ख़त्म होने वाले रूप पर चेतावनी देता है।

रीडायरेक्ट 301 हो या 302, क्या फ़र्क़ पड़ता है?

हाँ, पड़ता है। 301 और 308 बताते हैं कि बदलाव स्थायी है, इसलिए ब्राउज़र उसे कैश कर सकते हैं और सर्च इंजन पुराने पते के संकेत नए पते पर ले जाते हैं; 302, 303 और 307 बताते हैं कि यह अस्थायी है और मूल पता ही इंडेक्स रहता है। canonical डोमेन का रीडायरेक्ट आम तौर पर स्थायी होता है, और 308 व 307 अनुरोध का तरीक़ा (method) भी नहीं बदलते, जो फ़ॉर्म और API के लिए ज़रूरी है।

लंबी रीडायरेक्ट श्रृंखला दिक़्क़त क्यों है?

हर हॉप पेज लोड शुरू होने से पहले एक और आना-जाना है, और लंबी श्रृंखलाएँ जल्दी टूटती हैं। http://example.com → https://example.com → https://www.example.com आम और ठीक है; इससे लंबी हर श्रृंखला छोटी करनी चाहिए। जिस रूप को दो से ज़्यादा रीडायरेक्ट चाहिए, टूल उस पर चेतावनी देता है।

"पहले उसी होस्ट के HTTPS पर रीडायरेक्ट नहीं करता" का क्या मतलब है?

यह सिर्फ़ तब मायने रखता है जब डोमेन को HSTS preload सूची में डालना हो। hstspreload.org चाहता है कि सादा HTTP पता पहले उसी होस्ट के HTTPS पर रीडायरेक्ट हो (http://example.com → https://example.com), ताकि www पर जाने से पहले ब्राउज़र को उसी नाम का HSTS हेडर मिल जाए। http://example.com से सीधे https://www.example.com पर जाने वाला, या सादे HTTP पर ही रहने वाला पहला हॉप यह चरण छोड़ देता है; जिस साइट को preload नहीं करना, उसके लिए ऐसा रीडायरेक्ट ठीक है।

क्या जाँच मेरे कंप्यूटर से होती है?

नहीं। अनुरोध Cloudflare एज पर Mutqan सर्वर से जाते हैं, बिना कुकी और बिना पेज की सामग्री पढ़े। जो साइट देश, नेटवर्क या क्लाइंट के प्रकार के हिसाब से रीडायरेक्ट करती है, वह आपके अपने ब्राउज़र को कहीं और भेज सकती है।

तकनीकी नोट्स

रीडायरेक्ट के अर्थ RFC 9110 §15.4 से आते हैं: 301 और 308 स्थायी, 302, 303 और 307 अस्थायी, और 307 व 308 अनुरोध का method बनाए रखते हैं। Location की वैल्यू relative हो सकती है, जिसे उसे लौटाने वाले URL के सापेक्ष पूरा किया जाता है। हर हॉप एक GET अनुरोध है जिसकी सामग्री नहीं पढ़ी जाती; उसका होस्ट पब्लिक DNS से resolve होता है और अनुरोध भेजने से पहले हर एड्रेस का पब्लिक होना ज़रूरी है, इसलिए प्राइवेट एड्रेस में ले जाने वाला रीडायरेक्ट फ़ॉलो नहीं होता, ठुकरा दिया जाता है।

HSTS (RFC 6797 §7.2) चाहता है कि होस्ट सादे HTTP का जवाब HTTPS पर स्थायी रीडायरेक्ट से दे, और hstspreload.org यह भी चाहता है कि वह रीडायरेक्ट उसी होस्ट पर रहे। हर रूप को अधिकतम पाँच रिस्पॉन्स तक फ़ॉलो किया जाता है; जो श्रृंखला पाँचवें पर भी रीडायरेक्ट कर रही हो वह "बहुत ज़्यादा रीडायरेक्ट" कहलाती है, और दो बार दिखा URL लूप।

सीमाएँ और कार्यप्रणाली

अनुरोध Cloudflare एज पर Mutqan सर्वर से जाते हैं। देश, नेटवर्क या क्लाइंट के प्रकार से रीडायरेक्ट करने वाली या ऑटोमेटेड क्लाइंट को ब्लॉक करने वाली साइटें आपके ब्राउज़र में अलग बर्ताव कर सकती हैं।

सिर्फ़ रीडायरेक्ट श्रृंखला पढ़ी जाती है: पेज की सामग्री, meta refresh टैग और JavaScript रीडायरेक्ट फ़ॉलो नहीं होते, और / के अलावा कोई पाथ नहीं जाँचा जाता।

हर रूप पाँच रिस्पॉन्स, हर हॉप छह सेकंड और पूरी जाँच बीस सेकंड के बाद रुक जाती है।

अगर कोई भी रूप किसी अंतिम पते तक नहीं पहुँचता (चारों विफल), तो दिखाने के लिए कोई canonical होस्ट नहीं होता; हर रूप की त्रुटि वजह बताती है।

सुरक्षा और गोपनीयता

Mutqan सर्वर आपके डाले डोमेन के चारों पतों और उनके रीडायरेक्ट वाले हर पते पर सादे GET अनुरोध भेजता है — बिना कुकी और बिना बॉडी के। कुछ भी स्टोर नहीं होता; इसे सिर्फ़ उन्हीं साइट पर इस्तेमाल करें जिन्हें जाँचने की आपको अनुमति है।

संदर्भ

  • RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
  • Redirections in HTTP — MDNMDN Web Docs (Mozilla)HTTP redirects: Location header के साथ 3xx status codes, स्थायी (301, 308) बनाम अस्थायी (302, 303, 307), और redirect loops कैसे बनते हैं।
  • Redirects and Google SearchGoogle Search Centralकिसी पेज या साइट का canonical URL चुनते समय Google स्थायी (301, 308) और अस्थायी (302, 303, 307) सर्वर-साइड रीडायरेक्ट को कैसे लेता है।