19 नव॰ 2025·8 मिनट
DNS और SSL समस्याओं के लिए कस्टम डोमेन ट्रबलशूटिंग चेकलिस्ट
यह कस्टम डोमेन ट्रबलशूटिंग चेकलिस्ट DNS रिकॉर्ड, प्रसार देरी और SSL टाइमिंग से जुड़ी समस्याओं का निदान करने के सरल सत्यापन चरण बताती है।
यह कस्टम डोमेन ट्रबलशूटिंग चेकलिस्ट DNS रिकॉर्ड, प्रसार देरी और SSL टाइमिंग से जुड़ी समस्याओं का निदान करने के सरल सत्यापन चरण बताती है।
“Custom domain not working” कई विफलताओं का एक समेटा हुआ वाक्य है। ब्राउज़र आपको लक्षण दिखाता है, कारण नहीं। कुछ भी बदलने से पहले लिख लें कि आप असल में क्या देख रहे हैं।
आम लक्षणों में शामिल हैं:
ज़्यादातर मामलों में सिर्फ एक चीज़ गलत होती है:
ट्रबलशूट करने से पहले यह सुनिश्चित कर लें कि आपके पास दो जगहों की पहुँच है: जहाँ आप DNS रिकॉर्ड संपादित करते हैं (रजिस्ट्रार या DNS प्रदाता) और जहाँ आप होस्टिंग साइड पर डोमेन जोड़ते हैं। उदाहरण के लिए, अगर आप Koder.ai पर एक डिप्लॉय्ड ऐप को कस्टम डोमेन से जोड़ रहे हैं, तो आपको डोमेन के लिए DNS एक्सेस और ऐप की होस्टिंग/डिप्लॉयमेंट सेटिंग में डोमेन सेटिंग दोनों चाहिए।
कुछ समाधान तुरंत लगते हैं (जैसे टाइपो ठीक करना)। अन्य में समय लगता है। DNS परिवर्तन दिखने में समय ले सकते हैं, और SSL आमतौर पर तब तक पूरा नहीं होगा जब तक DNS सही नहीं दिखता और डोमेन पहुँचा न जा सके। लक्ष्य है अनुमान लगाना बंद करना और हर लेयर को क्रम से कन्फर्म करना।
अधिकांश डोमेन समस्याएँ (1) जिस होस्टनेम का आप परीक्षण कर रहे हैं, (2) जहाँ DNS मैनेज किया जाता है, और (3) रिकॉर्ड असल में किसकी ओर इशारा कर रहा है—इनके मेल न खाने की वजह से होती हैं। जब ये तीनों मेल खा जाएँ, SSL प्रायः आखिरी कदम होता है।
डोमेन के दो आम रूप होते हैं: root domain (example.com, जिसे apex भी कहते हैं) और सबडोमेन्स (www.example.com, app.example.com)। ये संबंधित हैं, पर इनके अलग DNS रिकॉर्ड हो सकते हैं। इसलिए यह सामान्य है कि www काम करे जबकि apex फेल करे, या इसके विपरीत।
Nameservers तय करते हैं कि आपकी DNS जोन किसके पास है। अगर आपने एक कंपनी से डोमेन खरीदा लेकिन nameservers किसी और की ओर इशारा करते हैं, तो आपको उस जगह पर DNS संपादित करना होगा जहाँ nameservers इशारा कर रहे हैं। कई “मैंने अपडेट किया लेकिन कुछ नहीं बदला” स्थितियाँ इसलिए होती हैं क्योंकि रिकॉर्ड गलत डैशबोर्ड में एडिट किए गए थे।
मुख्य रिकॉर्ड प्रकार और उनका काम:
TTL “किसी उत्तर को कैश में कितनी देर रखा जाए” बताता है। छोटे TTL का मतलब caches तेज़ी से रिफ्रेश होते हैं। बड़े TTL का मतलब आपको ठीक करने के बाद भी इंतज़ार करना पड़ सकता है। पुराने मान कुछ समय तक दिखना सामान्य है।
जब कस्टम डोमेन फेल होता है, तो आप अक्सर इसे चार बकेट में बाँट सकते हैं: DNS रिज़ॉल्व नहीं हो रहा, DNS गलत जगह यूँ दिखा रहा है, SSL तैयार नहीं है, या कुछ लोगों के लिए कैशिंग की वजह से ही फेल होता है।
यह निर्णय-वृक्ष उपयोग करें:
www काम करता है पर root डोमेन नहीं (या इसके विपरीत), तो आपने संभवतः केवल एक होस्टनेम कॉन्फ़िगर किया है, या आपके पास conflicting redirect नियम हैं।तेज़ काम करने के लिए वह एक्ज़ैक्ट होस्टनेम लिख लें जो फेल कर रहा है (apex बनाम www) और जो भी सटीक एरर मैसेज दिख रहा है। ऑटोमेटेड डोमेन और सर्टिफिकेट वाले होस्टिंग प्लेटफ़ॉर्म पर “cannot find host” और “certificate pending” के बीच का फर्क बताता है कि आपको DNS रिकॉर्ड ठीक करने हैं या DNS दिखने के बाद SSL के लिए बस इंतजार करना है।
कई डोमेन फेलियर एक साधारण मिसमैच से शुरू होते हैं: आपने एक होस्टनेम के लिए DNS सेट किया, पर आप दूसरे को टेस्ट कर रहे हैं।
पहले, वह सटीक होस्टनेम लिखें जिसे आप लाइव चाहते हैं। रूट डोमेन example.com जैसा दिखता है। एक सबडोमेन www.example.com या app.example.com जैसा दिखता है। ये अलग DNS एंट्रियाँ हैं, इसलिए “www चलता है” का मतलब यह नहीं कि root डोमेन भी चलेगा।
अगला, अपने होस्टिंग प्लेटफ़ॉर्म से अपेक्षित लक्ष्य खोजें। कुछ प्लेटफ़ॉर्म आपको IP पता देते हैं (A या AAAA के लिए)। अन्य आपको एक लक्ष्य होस्टनेम देते हैं (CNAME के लिए)। अगर आपके होस्ट ने domain setup स्क्रीन में कोई वैल्यू दी है, उसे स्रोत सत्य के रूप में मानें।
कुछ भी बदलने से पहले, मौजूदा सेटअप की नकल कर लें। सरल रखें:
यह भी सत्यापित करें कि आप सही DNS जोन संपादित कर रहे हैं। गलत डोमेन, गलत वातावरण, या गलत प्रोवाइडर अकाउंट अपडेट करना आसान है।
कई समस्याएँ बस गलत रिकॉर्ड प्रकार की वजह से होती हैं। पहले दो मामलों को अलग करें: root डोमेन (example.com) और एक सबडोमेन (www.example.com)। कई DNS प्रदाताओं पर ये अलग तरह से व्यवहार करते हैं।
A रिकॉर्ड किसी नाम को IPv4 पते की ओर निर्देशित करता है। कई सेटअप apex के लिए A रिकॉर्ड का उपयोग करते हैं क्योंकि कुछ प्रोवाइडर apex पर CNAME की अनुमति नहीं देते। अगर आपके होस्ट ने आपको IP दिया है तो आम तौर पर A रिकॉर्ड सही होता है।
AAAA रिकॉर्ड IPv6 का वर्ज़न है। एक बिखरी हुई AAAA रिकॉर्ड पुराने गंतव्य की ओर इशारा कर सकती है और भ्रम पैदा कर सकती है, क्योंकि कुछ विज़िटर IPv6 से जुड़ेंगे जबकि बाकी IPv4 से। अगर आपके होस्ट ने IPv6 लक्ष्य नहीं दिया है, तो एक गलत AAAA रिकॉर्ड हटाने से अक्सर अस्थिर विफलताएँ ठीक हो जाती हैं।
CNAME रिकॉर्ड एक सबडोमेन को दूसरे होस्टनेम पर पॉइंट करता है (अक्सर www के लिए)। यह तब उपयोगी है जब होस्ट चाहता है कि आप एक नामित endpoint को लक्षित करें जो पीछे बदल सकता है।
TXT रिकॉर्ड वेरिफिकेशन और challenges के लिए होते हैं (कुछ SSL चैलेंज भी)। सामान्य गलतियाँ हैं: TXT को गलत नाम पर डालना (root बनाम _acme-challenge बनाम किसी उपडोमेन), अतिरिक्त स्पेस जोड़ना, या गलत वैल्यू पेस्ट करना।
आगे बढ़ने से पहले conflicts देखें। ये सबसे अधिक परेशानी पैदा करते हैं:
कई “custom domain not working” मामले रिकॉर्ड वैल्यू के बारे में नहीं होते। वे इसलिए होते हैं क्योंकि रिकॉर्ड गलत प्रदाता पर जोड़े गए। अगर आपका डोमेन Provider A के nameservers इस्तेमाल करता है, तब Provider B के डैशबोर्ड में रिकॉर्ड बदलने से कुछ नहीं होगा, भले ही वहाँ रिकॉर्ड सही दिख रहे हों।
देखें कि आपका डोमेन असल में किन nameservers का उपयोग कर रहा है। यह आमतौर पर आपके रजिस्ट्रार की domain settings में “Nameservers” के अंतर्गत दिखता है। एक दूसरा तरीका: अपने कंप्यूटर से DNS से पूछें:
dig NS example.com
उस कमांड से जो nameservers लौटते हैं वे ऑथोरिटेटिव होते हैं।
एक त्वरित समझौता जांच:
ns1... और ns2... देता है, तो वही सटीक मान रजिस्ट्रार पर दिखने चाहिए।अगर आप गलत प्रोवाइडर पर रिकॉर्ड अपडेट करते हैं, तो अक्सर दो डैशबोर्ड मिलेंगे जो मेल नहीं खाते। केवल ऑथोरिटेटिव nameservers मायने रखते हैं।
नामसर्वर्स बदलने के बाद देरी पर भी ध्यान दें। ट्रांज़िशन विंडो के दौरान परिणाम असंगत दिख सकते हैं यह निर्भर करता है कि आप कहाँ से टेस्ट कर रहे हैं। अगर nameservers अभी बदल रहे हैं, तो रिकॉर्ड एडिट करने से पहले इंतज़ार करें जब तक नामसर्वर सेट स्थिर न हो जाए, फिर जारी रखें।
“Propagation” कोई एक स्विच नहीं है। यह DNS कैश का एक शृंखला है (ISP, फोन कैरियर, पब्लिक रिज़ॉल्वर, और आपके अपने डिवाइस) जो अलग-अलग गति से अपडेट होते हैं। इसलिए आपका डोमेन आपके सहकर्मी के लिए काम कर रहा हो पर आपके लिए नहीं।
TTL (time to live) बताता है कि कैशेस कितनी देर तक उत्तर रख सकते हैं। अगर पुराना TTL 1 घंटा था, तो कुछ लोग पुराने मान को लगभग एक घंटे तक देखना जारी रख सकते हैं। TTL कम करना तभी मदद करेगा जब आपने बदलाव करने से पहले ही TTL कम किया हो।
कैशिंग देरी और असली गलतियों को अलग करने के लिए कुछ त्वरित चेक करें:
www)अगर किसी भी जगह रिकॉर्ड गलत दिखते हैं (गलत IP, गायब www, पुराना CNAME), तो उसे ठीक करें। अगर अधिकांश जगहों पर रिकॉर्ड सही दिख रहे हैं पर एक नेटवर्क अभी भी पुराना मान दिखा रहा है, तो आम तौर पर यह कैश डिले है।
SSL सर्टिफिकेट आमतौर पर एक ही आधारभूत कारण से फेल होते हैं: सर्टिफिकेट प्रदाता तब तक डोमेन को सत्यापित नहीं कर सकता जब तक DNS लगातार सही जगह पर न दिखे।
सामान्य सीक्वेंस सरल है:
आम ब्लॉकर अक्सर चूक जाते हैं। एक गलत A या CNAME लक्ष्य वैलिडेशन चेक्स को गलत सर्वर पर भेज देगा। एक stale AAAA रिकॉर्ड कुछ विज़िटर्स के लिए आपके काम कर रहे A रिकॉर्ड को ओवरराइड कर सकता है, जिससे HTTPS केवल कुछ लोगों के लिए फेल हो। आवश्यक TXT रिकॉर्ड का गायब होना प्लेटफ़ॉर्म को सर्टिफिकेट जारी करने से रोक सकता है।
लक्षणों का उपयोग करके "अभी जारी हो रहा है" और "गलत कॉन्फ़िगर हुआ" को अलग करें:
इंतज़ार करते समय बार-बार रिकॉर्ड बदलते न रहें। हर बदलाव क्लॉक रीसेट कर देता है और अलग-अलग नेटवर्क पर अलग-अलग उत्तरों की दुनिया बना सकता है। एक बार सही रिकॉर्ड सेट करें, फिर सर्टिफिकेट जारी होने तक रिज़ोल्यूशन और सत्यापन बार-बार चेक करें।
अगर आप Koder.ai जैसे प्लेटफॉर्म का उपयोग कर रहे हैं, तो सबसे सुरक्षित फ्लो वही है: पुष्टि करें कि DNS अपेक्षित लक्ष्य की ओर इशारा कर रहा है, अगर मौजूद हों तो गलत AAAA रिकॉर्ड हटा दें, और DNS स्थिर होने के बाद SSL को समय दें।
अच्छा ट्रबलशूटिंग अधिकतर तुलना है: जो आप देख रहे हैं बनाम जो आप उम्मीद करते हैं। "मेरा फोन चलता है" पर निर्भर न रहें। दोहराने योग्य चेक करें।
एक DNS लुकअप टूल (जैसे nslookup या dig) का उपयोग करें और पुष्टि करें कि लौटाया गया मान वही है जो आप चाहते हैं (A/AAAA के लिए IP, CNAME के लिए होस्टनेम, TXT के लिए टोकन)।
# Apex (root) domain
dig example.com A
dig example.com AAAA
# www subdomain
dig www.example.com CNAME
# TXT (often used for verification)
dig example.com TXT
दोनों नामों की जाँच करें जो आप उपयोग कर सकते हैं: apex (example.com) और www (www.example.com)। अक्सर एक सही होता है जबकि दूसरा कहीं पुराना इशारा कर रहा होता है।
apex और www दोनों के लिए http:// और https:// खोलें। आप एक स्पष्ट “home” डोमेन और एक साफ़ redirect चाहते हैं।
www) और दूसरे को उस पर redirect करें।अगर नेटवर्क के अनुसार परिणाम भिन्न हैं, तो संभावना है कि आप कैशिंग या propagation देख रहे हैं। एक छोटा लॉग रखें: आप क्या बदले, कहाँ बदला, समय, और आपने क्या देखा।
ज़्यादातर DNS और SSL समस्याएँ रहस्यों की तरह नहीं होतीं। वे छोटी गलतियाँ होती हैं जो आपको गलत चीज़ देखती रहती हैं, या बहुत तेज़ी से चीज़ें बदलने की वजह से समस्याएँ स्पष्ट नहीं होतीं।
सबसे आम समय-नाशक गलती है दो जगहों पर DNS एडिट करना। यह अक्सर nameservers बदलने के बाद होता है: आप रजिस्ट्रार पर रिकॉर्ड अपडेट करते हैं, पर DNS असल में कहीं और होस्ट हो रहा होता है (या इसके विपरीत)। एक डैशबोर्ड में सब कुछ सही दिख सकता है, पर सार्वजनिक रूप से कुछ नहीं बदलता।
एक और क्लासिक गलती है root डोमेन पर CNAME लगाने की कोशिश करना उस प्रोवाइडर के साथ जो इसे सपोर्ट नहीं करता। आपको A रिकॉर्ड की ज़रूरत पड़ सकती है, या ALIAS/ANAME-शैली का रिकॉर्ड अगर आपका DNS प्रोवाइडर देता है।
IPv6 भी सिरदर्द पैदा कर सकता है। एक पुराना AAAA रिकॉर्ड कुछ विज़िटर्स को गलत सर्वर पर भेज सकता है जबकि बाकी लोग सही IPv4 पर पहुँचते हैं।
"सुरक्षा के लिए" रखे गए रिकॉर्ड से सावधान रहें। कई A रिकॉर्ड अनजाने में लोड-बैलेंसिंग जैसा व्यवहार कर सकते हैं अगर एक लक्ष्य गलत हो, खासकर कस्टम डोमेन को होस्ट किए गए ऐप की ओर इशारा करते समय।
एक अंतिम नियम: क्लॉक रीसेट करना बंद करें।
छोटे, शांत बदलाव लगातार छेड़छाड़ से बेहतर होते हैं।
www चलता है पर root डोमेन नहींआप नया ऐप लॉन्च करते हैं और दोनों example.com और www.example.com सेट करते हैं। कुछ मिनटों बाद www.example.com ठीक लोड होता है, पर root डोमेन DNS त्रुटि दिखाता है, पुरानी साइट लोड करता है, या HTTPS पेंडिंग रहता है। यह पैटर्न आम है और अक्सर इसका कारण छोटा होता है।
सबसे पहले साधारण प्रश्न से शुरू करें: क्या आप सही जगह DNS एडिट कर रहे हैं? अगर आपका डोमेन एक कंपनी में रजिस्टर है पर DNS कहीं और होस्ट होता है, तो आप दिन भर रिकॉर्ड बदलते रह सकते हैं पर सार्वजनिक बदलाव नहीं दिखेंगे। पहले nameservers चेक करें, फिर उन्हीं नामसर्वरों की तरफ़ इशारा करने वाले प्रोवाइडर के DNS पैनल खोलें।
फिर दो होस्टनामों की तुलना करें। www आम तौर पर CNAME होता है। रूट डोमेन ज़्यादा जटिल है: कई प्रोवाइडर apex पर CNAME की अनुमति नहीं देते, इसलिए अक्सर उसे A रिकॉर्ड (IP) की ज़रूरत होती है, या ALIAS/ANAME-शैली रिकॉर्ड की आवश्यकता हो सकती है अगर सपोर्ट हो।
एक व्यवहारिक निर्णय-पथ:
example.com के पास कोई रिकॉर्ड नहीं है (या वह कहीं और पॉइंट कर रहा है)? apex रिकॉर्ड ठीक करें।सही अंत स्थिति उबाऊ है: दोनों example.com और www.example.com उसी ऐप पर पहुँचते हैं, एक canonical है (दूसरा redirect करता है), और HTTPS वैध है।
जब डोमेन सेटअप फेल होता है, ज़्यादातर समाधान कुछ तेज़ चेक से मिल जाते हैं। कुछ भी बदलने से पहले ये चलाएँ।
DNS स्पष्ट रूप से सही होने के बाद ही SSL जाँचें। कई प्लेटफ़ॉर्म केवल तब सर्टिफिकेट जारी करते हैं जब वे आपके डोमेन को लगातार सही लक्ष्य पर resolve कर सकें। बहुत जल्दी जांचने पर आप सामान्य देरी को गलती समझ सकते हैं।
अगर आप Koder.ai पर एक डिप्लॉय किए गए ऐप के लिए कस्टम डोमेन जोड़ रहे हैं, तो domain setup स्क्रीन को अपेक्षित लक्ष्य मानें, फिर authoritative प्रोवाइडर पर DNS मिलाएँ और DNS के propagate होने के बाद ही स्टेटस री-चेक करें।
DNS और SSL गलतियों को दोहराने से रोकने का सबसे तेज़ तरीका यह है कि हर प्रोजेक्ट के लिए एक छोटा “domain setup note” रखें। यह एक पुन:उपयोग योग्य रनबुक है जिसे आप अगली बार लॉन्च करते समय कॉपी कर सकते हैं।
इसे अपनी प्रोजेक्ट डॉक्स में रखें और DNS छेड़ने से पहले भर लें:
लॉन्च के दौरान, एक व्यक्ति को DNS का मालिक बनाएं। DNS तब टूटता है जब दो लोग एक साथ अलग-अलग चीज़ें “ठीक” करने की कोशिश करते हैं (उदाहरण के लिए, एक नामसर्वर बदलता है जबकि दूसरा रिकॉर्ड एडिट कर रहा है)।
होस्टिंग साइड पर, सुरक्षित वापसी की योजना बनाएं। अगर आपका प्लेटफ़ॉर्म snapshots या rollback सपोर्ट करता है, तो रूटिंग बदलने से पहले स्नैपशॉट लें ताकि आप जल्दी से अंतिम ज्ञात-चालू स्थिति पर लौट सकें। अगर आप Koder.ai पर बनाते हैं, तो Planning Mode का उपयोग करके डोमेन कदम लिख सकते हैं, उन्हें क्रम से लागू कर सकते हैं, और अगर कोई बदलाव उत्पादन तोड़ता है तो वापस ला सकते हैं।
अगर आपने DNS की पुष्टि कर ली है और फिर भी फेल दिख रहा है, तो अनुमान लगाना बंद करें और सबूत के साथ escalate करें:
एस्केलेशन में होस्टनेम, अपेक्षित रिकॉर्ड, वर्तमान रिज़ॉल्वर परिणाम और timestamps शामिल करें। इससे धीमे बैक-एंड-फर्थ की जगह तेज़ फिक्स मिलता है।
यह आम तौर पर यह बताता है कि किसी एक परत में कुछ गलत है: DNS रिसॉल्व नहीं हो रहा, DNS गलत लक्ष्य की तरफ़ जा रहा है, सर्वर/होस्ट आपका होस्टनाम पहचान नहीं रहा, या HTTPS/SSL अभी जारी नहीं हुआ है। शुरू करने के लिए आप जो ठीक दिख रहा है और आपने कौन सा होस्टनाम टाइप किया (apex बनाम www) यह लिखें।
example.com (apex) और www.example.com अलग-अलग होस्टनेम हैं और इनके DNS रिकॉर्ड अलग हो सकते हैं। अक्सर www के लिए सही CNAME होता है जबकि apex पर कोई A रिकॉर्ड नहीं होता या गलत A रिकॉर्ड होता है, या आपका DNS प्रदाता CNAME को apex पर सपोर्ट नहीं करता।
रजिस्ट्रार में दिख रहे नामसर्वर देखें और उन्हें उस DNS प्रोवाइडर से मिलाएँ जहाँ आप रिकॉर्ड बदल रहे हैं। केवल जो प्रोवाइडर सक्रिय नामसर्वर में दिखता है वही ऑथोरिटेटिव है; किसी और जगह रिकॉर्ड बदलने से सार्वजनिक इंटरनेट पर बदलाव नहीं दिखेगा।
जब आपके होस्ट ने IPv4 एड्रेस दिया हो तो A रिकॉर्ड का उपयोग करें, केवल तभी AAAA तब उपयोग करें जब होस्ट ने IPv6 एड्रेस दिया हो, और जब होस्ट ने एक दूसरे होस्टनेम का लक्ष्य दिया हो तो CNAME का प्रयोग करें (यह अक्सर www के लिए होता है)। TXT रिकॉर्ड वेरिफिकेशन और चुनौतियों के लिए होते हैं और इन्हें ठीक उसी नाम पर बनाना चाहिए जो होस्ट बताता है।
एक पुराना या गलत AAAA रिकॉर्ड कुछ विज़िटर्स को IPv6 के ज़रिये पुराने सर्वर पर भेज सकता है जबकि बाकी लोग सही IPv4 पर जा रहे हों—इससे “मुझे तो चलता है” जैसा भ्रम बनता है। अगर होस्ट ने IPv6 नहीं दिया है तो गलत AAAA हटाना अक्सर सबसे आसान समाधान है।
अधिकतर मामलों में आपने होस्टिंग साइड पर केवल एक होस्टनाम कॉन्फ़िगर किया होगा (सिर्फ apex या सिर्फ www), या आपके पास प्रतिस्पर्धी redirect नियम हैं जो HTTP और HTTPS या apex और www के बीच उछाल पैदा करते हैं। एक canonical होस्टनाम चुनें, दोनों होस्टनामों को कॉन्फ़िगर करें, और केवल एक साफ़ redirect पाथ रखें।
हाँ। SSL जारी होने में समय लग सकता है क्योंकि सर्टिफिकेट प्रदाता तब तक डोमेन का सत्यापन नहीं कर सकता जब तक DNS लगातार सही जगह पर न दिखे। DNS स्पष्ट रूप से सही हो और कई जगहों से सही ढंग से रिज़ॉल्व होने के बाद इंतजार करना सही कदम है।
TTL यह बताता है कि रिज़ॉल्वर किसी उत्तर को कितनी देर तक कैश में रखेगा। रिकॉर्ड ठीक करने के बाद भी कुछ नेटवर्क पुराने वैल्यू को TTL समाप्त होने तक दिखा सकते हैं। दो अलग नेटवर्क (उदा. Wi‑Fi और मोबाइल डेटा) से टेस्ट करें और बार-बार DNS बदलने से बचें ताकि propagation साफ़ दिखे।
एक दोहराने योग्य जांच का उपयोग करें जैसे dig या nslookup ताकि A/AAAA/CNAME/TXT के उत्तर आपके अपेक्षित लक्ष्य से मेल खाते हों, और फिर apex और www दोनों के लिए http:// और https:// खोलकर जाँच करें। यदि एक नेटवर्क अन्य से अलग DNS उत्तर दिखाता है तो यह कैशिंग है; अगर सभी नेटवर्क गलत उत्तर दिखाते हैं तो यह कॉन्फ़िगरेशन त्रुटि है।
Koder.ai पर, ऐप के domain setup स्क्रीन को अपेक्षित DNS लक्ष्य के स्रोत के रूप में मानें, और फिर authoritative प्रोवाइडर पर DNS ठीक वैसे ही सेट करें। DNS बदलने के बाद settle होने का समय दें और SSL जांच तब करें; लाइव प्रोजेक्ट पर रूटिंग बदलते समय snapshot/rollback का उपयोग करें ताकि आप जल्दी से वापस आ सकें।