17 दिस॰ 2025·8 मिनट
वेब ऐप्स के लिए कस्टम डोमेन सेटअप: DNS, SSL, और कटओवर
वेब ऐप्स के लिए कस्टम डोमेन सेटअप: स्पष्ट DNS रिकॉर्ड कदम, SSL जारी करना, रीडायरेक्ट्स और डाउनटाइम व कूकी इश्यूज़ से बचने के लिए कम-जोखिम कटओवर योजना।
वेब ऐप्स के लिए कस्टम डोमेन सेटअप: स्पष्ट DNS रिकॉर्ड कदम, SSL जारी करना, रीडायरेक्ट्स और डाउनटाइम व कूकी इश्यूज़ से बचने के लिए कम-जोखिम कटओवर योजना।
कस्टम डोमेन सिर्फ बेहतर URL नहीं है। जैसे ही आप प्लेटफ़ॉर्म के सबडोमेन (उदाहरण के लिए Koder.ai पर बना कोई ऐप) से अपने खुद के डोमेन पर जाते हैं, ब्राउज़र और नेटवर्क उसे एक अलग साइट की तरह मानते हैं। इसका असर रूटिंग, सुरक्षा और उपयोगकर्ता सेशन के व्यवहार पर पड़ता है।
कस्टम डोमेन पर स्विच करने के बाद कुछ चीजें तुरंत बदल जाती हैं:
www पर आएँ या apex डोमेन पर, और HTTP से HTTPS संबंधी नियमों का पालन होना चाहिए।old-platform.example के लिए बनी लॉगिन कूकी app.yourdomain.com पर स्वतः काम नहीं करेगी।छोटे-से-मध्यम आउटेज अक्सर टाइमिंग की वजह से आते हैं। DNS नए होस्ट पर ट्रैफ़िक भेजना शुरू कर देता है जबकि SSL सर्टिफिकेट तैयार नहीं होता — इससे ब्राउज़र वार्निंग आती हैं। या उल्टा: SSL तैयार है लेकिन कई उपयोगकर्ता पुराने स्थान पर बने रहते हैं क्योंकि उनका DNS कैश समाप्त नहीं हुआ।
रीडायरेक्ट्स भी लॉगिन को बारीक तरीकों से तोड़ सकते हैं। होस्टनेम बदलने वाला रीडायरेक्ट (apex से www या इसके विपरीत) कूकीज़ खो सकता है अगर वे दूसरी होस्ट पर सेट की गई थीं। ऑथ प्रोवाइडर तब फेल कर सकते हैं जब उनका callback URL अभी भी पुराने डोमेन की तरफ हो।
एक कम-जोखिम वाला कटओवर overlap के लिए योजना बनाना है: पुराना URL काम करता रहे, नया डोमेन समानांतर में तैयार हो, ट्रैफ़िक एक नियंत्रित पल में स्विच हो और रोलबैक इतना आसान हो कि बस DNS वापस बदलना पड़े।
कुछ भी बदलने से पहले लिख लें कि आप उपयोगकर्ताओं को कौन से नाम टाइप करने देना चाहते हैं और कौन से नाम चुपचाप रीडायरेक्ट होंगे। "आधे काम कर रहे हैं" जैसी समस्याओं का कारण अक्सर टीम के बीच एक सच्चा होस्टनेम न चुना जाना होता है।
सबसे बड़ा निर्णय: प्राथमिक होस्टनेम के तौर पर apex (example.com) रखें या www (www.example.com)। दोनों काम कर सकते हैं, पर एक चुनें और दूसरे को रीडायरेक्ट रखें। यह कूकीज़ के लिए भी महत्वपूर्ण है: ऐप एक सुसंगत होस्ट पर होने पर सेशन्स संभालना आसान होता है।
फिर तय करें कि अभी किन सबडोमेन की ज़रूरत है और किन्हें बाद में जोड़ा जा सकता है। आम पैटर्न है app.example.com वेब ऐप के लिए और api.example.com APIs के लिए, बाद में admin.example.com या assets.example.com जोड़ना। यदि आप Koder.ai जैसे प्लेटफ़ॉर्म पर कस्टम डोमेन सेट कर रहे हैं, तो ये विकल्प सीधे SSL वेरिफिकेशन और DNS में पॉइंटिंग से मैप होते हैं।
कई लोग डोमेन रजिस्टर करते हैं, पर DNS कहीं और होस्ट हो सकता है। पुष्टि करें कि आज रिकॉर्ड्स कहाँ संपादित होते हैं, किसके पास एक्सेस है, और क्या कोई ऑटोमेशन बदलाव कर रहा है (कंपनी IT, एजेंसी, या managed DNS प्रोवाइडर)। अगर आप लॉग इन कर के वर्तमान रिकॉर्ड नहीं देख सकते तो पहले वही ठीक करें।
यह भी ऑडिट करें कि डोमेन का अभी क्या उपयोग हो रहा है। ईमेल क्लासिक जाल है: रिकॉर्ड हटाने या ओवरराइट करने से मेल डिलीवरी टूट सकती है।
प्रोसिड करने से पहले ये निर्णय लिख लें:
www) और रीडायरेक्ट दिशाअगर मार्केटिंग पहले से example.com पर ईमेल चलाती है, तो मेल-संबंधी रिकॉर्ड को बरकरार रखें और केवल वही जोड़ें जो ऐप को चाहिए।
कस्टम डोमेन मूव का सबसे बड़ा जोखिम ऐप नहीं होता। यह एक गलत DNS बदलाव होता है जो ट्रैफ़िक को कहीं न ले जाए, ईमेल तोड़े, या SSL वेरिफिकेशन फेल कर दे।
एक A रिकॉर्ड किसी नाम को IP एड्रेस पर पॉइंट करता है। साधारण शब्दों में: “लोगों को इस सर्वर पर भेजो।” यह आमतौर पर apex (example.com) के लिए उपयोग होता है जब आपके प्रोवाइडर ने फ़िक्स्ड IP दिया हो।
एक CNAME रिकॉर्ड एक नाम को दूसरे नाम पर पॉइंट करता है। साधारण शब्दों में: “इस नाम को उस होस्टनेम का उपनाम मानो।” यह आमतौर पर www.example.com के लिए प्लेटफ़ॉर्म होस्टनेम की ओर पॉइंट करने में उपयोग होता है।
कई DNS प्रोवाइडर apex के लिए ALIAS/ANAME भी देते हैं। यह CNAME जैसा व्यवहार करता है पर example.com पर काम करता है। यदि आपका प्रोवाइडर इसे सपोर्ट करता है तो यह IP बदलते रहने पर प्रबंधित करना आसान बनाता है।
सरल मानसिक मॉडल:
अक्सर आप TXT रिकॉर्ड जोड़ेंगे डोमेन ओनरशिप चेक के लिए (प्लेटफ़ॉर्म वेरिफिकेशन) और SSL प्रमाणपत्र मान्यकरण के लिए (कुछ CAs TXT टोकन के जरिए वैलिडेट करते हैं)। TXT ईमेल पॉलिसी जैसे SPF के लिए भी प्रयोग होता है। किसी मौजूद SPF TXT को आकस्मिक रूप से हटाना या बदलना मेल डिलीवरी तोड़ सकता है।
TTL नियंत्रित करता है कि दूसरे सिस्टम आपकी DNS उत्तर कितनी देर के लिए कैश रखें। कटओवर से एक दिन पहले उन रिकॉर्ड्स का TTL घटा दें जिन्हें आप बदलने वाले हैं (अक्सर 300 से 600 सेकंड)। सब कुछ स्थिर होने के बाद इसे फिर बढ़ा दें ताकि क्वेरी लोड घटे।
संपादन से पहले जोन का एक्सपोर्ट या स्क्रीनशॉट लें। हर रिकॉर्ड जो आप बदलेंगे, उसकी पुरानी वैल्यू, नई वैल्यू और TTL लिख लें। अगर कुछ गलत हुआ तो रोलबैक का मतलब पहले वाले मानों को बहाल करना है।
यह खासकर तब महत्वपूर्ण है जब आपका डोमेन पहले से MX, DKIM या अन्य TXT रिकॉर्ड्स के साथ ईमेल के लिए सेट हो।
SSL (लॉक आइकन) ब्राउज़र और आपके ऐप के बीच ट्रैफ़िक को एनक्रिप्ट करता है। आधुनिक ब्राउज़र और कई APIs डिफ़ॉल्ट रूप से HTTPS की उम्मीद करते हैं। इसके बिना आपको वार्निंग, ब्लॉक्ड अनुरोध और कुछ फीचर (service workers, geolocation, कुछ पेमेंट फ्लो) में समस्या हो सकती है।
सर्टिफिकेट जारी करने के लिए CA को यह सत्यापित करना होता है कि आप डोमेन के मालिक हैं। आम वेरिफिकेशन तरीके HTTP वैलिडेशन और DNS TXT वैलिडेशन हैं:
जब आप CDN का उपयोग कर रहे हों या आपका ऐप नया डोमेन पर अभी पहुँचा नहीं जा रहा हो तो DNS वेलिडेशन अक्सर आसान रहता है।
सर्टिफिकेट कहाँ जारी होता है यह आपके सेटअप पर निर्भर करता है। कुछ टीमें सीधे होस्टिंग स्टैक पर सर्टिफिकेट जारी करती हैं, कुछ CDN पर करती हैं, और कुछ प्लेटफ़ॉर्म (जैसे Koder.ai) कस्टम डोमेन सेटअप के दौरान इसे संभालते हैं। महत्वपूर्ण बात यह जानना है कि सर्टिफिकेट लाइफसायकल, साथ ही रिन्यूअल किसके जिम्मे है।
सर्टिफिकेट जारी होना हमेशा तुरंत नहीं होता। DNS प्रोपेगेशन, वेलिडेशन चेक और रेट लिमिट्स धीमा कर सकते हैं। रिट्राइ के लिए योजना बनाएं और कटओवर को अंतिम मिनट पर न रखें।
व्यावहारिक टाइमिंग योजना:
एक सर्टिफिकेट को हर उस होस्टनेम को कवर करना चाहिए जहाँ उपयोगकर्ता पहुँचेंगे। SAN सूची (Subject Alternative Names) चेक करें। यदि आपका ऐप example.com और www.example.com दोनों पर उपलब्ध होगा तो सर्टिफिकेट दोनों को शामिल करे।
वाइल्डकार्ड (*.example.com) कई सबडोमेन्स के लिए मददगार हो सकता है, पर यह apex (example.com) को कवर नहीं करता।
ठोस उदाहरण: यदि आपने सिर्फ www.example.com के लिए सर्टिफिकेट जारी किया है, तो जो उपयोगकर्ता example.com टाइप करेंगे उन्हें वार्निंग दिखेगी जब तक आप किसी ऐसे लेयर पर रीडायरेक्ट नहीं कर रहे जहाँ example.com के लिए वैध सर्टिफिकेट हो।
रीडायरेक्ट सुनने में सरल लगते हैं, पर अधिकांश डोमेन समस्याएँ यहीं उभरती हैं: लूप्स, मिक्स्ड कंटेंट, और उपयोगकर्ता तब लॉगआउट हो जाते हैं क्योंकि वे होस्टनेम के बीच बाउंस हुए।
एक canonical होस्ट चुनें और उस पर टिके रहें: या www.example.com या example.com (apex)। दूसरा entry point आपके चुने हुए canonical होस्ट पर रीडायरेक्ट होना चाहिए ताकि कूकीज़, सेशन्स और SEO संकेत सुसंगत रहें।
सुरक्षित डिफ़ॉल्ट्स:
http:// से https:// पर 301HTTP से HTTPS के लिए ऐसे नियम से बचें जो उपयोगकर्ताओं को बार-बार उछालें। लूप रोकने का आसान तरीका यह है कि निर्णय उस आधार पर लें कि रिक्वेस्ट वास्तव में क्या था। यदि आपका ऐप proxy या CDN के पीछे है, तो उसे forwarded headers का सम्मान करने के लिए कॉन्फ़िगर करें; वर्ना ऐप सोच सकता है कि हर रिक्वेस्ट HTTP ही है और बार-बार रीडायरेक्ट करेगा।
मूव के दौरान पुराने पाथ्स को जीवित रखें। यदि आप रूट बदल रहे हैं (जैसे /login से /sign-in), तो उन पाथ्स के लिए स्पष्ट रीडायरेक्ट जोड़ें। होमपेज पर blanket रीडायरेक्ट पर निर्भर न रहें — यह बुकमार्क और शेयर किए गए लिंक तोड़ता है।
शुरू में HSTS लागू करने से बचें। अगर आप इसे बहुत जल्दी लागू कर दें और बाद में आपको वैलिडेशन या ट्रबलशूटिंग के लिए HTTP पर सर्व करना पड़े तो ब्राउज़र इन अनुरोधों को अस्वीकार कर सकते हैं। HTTPS स्थिर होने और सबडोमेन कवरेज निश्चित होने के बाद ही HSTS चालू करें।
प्रभावित न करने वाले परीक्षण के लिए एक अस्थायी टेस्ट होस्टनेम इस्तेमाल करें, कुछ गहरे लिंक (ऑथ पेजेज सहित) आज़माएँ, और कमांड-लाइन अनुरोध चलाकर हर रीडायरेक्ट स्टेप और अंतिम डेस्टिनेशन देखें।
एक सुरक्षित कटओवर ज्यादातर टाइमिंग का मामला है। आप चाहते हैं कि नया डोमेन तैयार और टेस्ट किया हुआ हो इससे पहले कि असली उपयोगकर्ता वहाँ भेजे जाएँ, और DNS बदलाव जल्दी फैलें ताकि किसी समस्या में आप फंसे न रहें।
उन रिकॉर्ड्स का TTL घटाएँ जिन्हें आप बदलने वाले हैं, यह अच्छी तरह से पहले करें—संभव हो तो एक दिन पहले—फिर पुराने TTL विंडो के पार प्रतीक्षा करें ताकि कैशेस नया छोटा TTL पकड़ लें।
इसके बाद होस्ट/प्रोवाइडर में कस्टम डोमेन जोड़ें और जो वेरिफिकेशन वे मांगते हैं पूरा करें। यदि आप Koder.ai जैसे प्लेटफ़ॉर्म का उपयोग कर रहे हैं, तो पहले वहां डोमेन जोड़ें ताकि प्लेटफ़ॉर्म ओनरशिप कन्फर्म कर सके और रूटिंग तैयार कर सके।
SSL जल्दी जारी करें। वेलिडेशन पर निर्भर करते हुए यह मिनटों से अधिक समय ले सकता है और आप स्विच के दौरान उस देरी का जोखिम नहीं लेना चाहते।
डोमेन सार्वजनिक करने से पहले एक निजी टेस्ट करें: अपने मशीन पर अस्थायी host entry का उपयोग कर नई एन्डपॉइंट को हिट करें और पुष्टि करें कि साइट सही सर्टिफिकेट के साथ HTTPS पर लोड होती है।
स्टेज्ड अप्रोच अपनाएँ ताकि आप जल्दी रोक सकें अगर कुछ अजीब दिखे:
www)।यदि आप DNS स्तर पर असली कैनरी नहीं कर सकते, तब भी स्टेजिंग कर सकते हैं—उदाहरण के लिए पहले केवल एक होस्टनेम (www) बदलें और apex को तब तक न छुएँ जब तक आप आश्वस्त न हों।
लिखित लिख लें कि आप किसे वापस करेंगे (कौन से रिकॉर्ड, कौन से मान) और कौन यह करेगा। रोलबैक सामान्यतः DNS को पहले जैसा रखना होता है।
सुनिश्चित करें कि पुराना सेटअप अभी भी मान्य है (पुराने डोमेन पर SSL समेत) ताकि उपयोगकर्ता सफ़ाई से वापस आ सकें जब तक आप नए पाथ को ठीक कर रहे हों।
डोमेन बदलना सिर्फ DNS नहीं है। कई ऐप्स में "लॉग इन होना" कूकीज़ पर निर्भर करता है जो ब्राउज़र विशेष होस्टनेम से जोड़ता है। यदि आप होस्टनेम बदलते हैं, तो ब्राउज़र पुरानी कूकी भेजना बंद कर देगा और ऐप को लगेगा कि सभी लॉग आउट हो गए।
कूकी सेटिंग्स अक्सर कारण होती हैं:
app.old.com के लिए सेट कूकी app.new.com पर नहीं भेजी जाएगी। .example.com पर सेट कूकी app.example.com और www.example.com दोनों पर काम कर सकती है।/api) तो आपकी वेब UI इसे नहीं देख पाएगी।Lax अक्सर ठीक रहता है, पर कुछ SSO या पेमेंट रीडायरेक्ट के लिए None और Secure की जरूरत पड़ सकती है।जोखिम कम करने के लिए, एक छोटा संक्रमणकालीन समय रखें जब दोनों डोमेन्स काम करें। पुराना होस्टनेम उत्तर देता रहे और सावधानी से रीडायरेक्ट करें, पर नए डोमेन पर सेशन रिफ्रेश करना संभव करें। अगर संभव हो तो साझा सेशन स्टोर का उपयोग करें ताकि जो उपयोगकर्ता किसी भी होस्टनेम पर आए उसे पहचाना जा सके।
यदि आप SSO या OAuth उपयोग करते हैं तो कटओवर से पहले सेटिंग्स अपडेट करें: callback URLs, allowed origins और किसी भी allowlist में दर्ज redirect URIs। अन्यथा लॉगिन प्रोवाइडर पर सफल होने के बाद भी आपकी ऐप पर लौटते समय फेल हो सकता है।
पहले टूटने वाली फ्लो का परीक्षण करें: साइन-अप (और ईमेल वेरिफिकेशन), लॉगिन/लॉगआउट, पासवर्ड रीसेट, चेकआउट या पेमेंट रिटर्न, और मल्टी-टैब सेशन्स।
उदाहरण: यदि आप www.example.com से example.com रीडायरेक्ट करते हैं, तो सुनिश्चित करें कि कूकीज़ .example.com के लिए सेट हों (या एक सुसंगत होस्टनेम उपयोग करें)। अन्यथा उपयोगकर्ता होस्टनेम के बीच बाउंस होकर अपना सेशन खो देंगे।
ज़्यादातर डोमेन समस्याएँ "रहस्यमयी इंटरनेट मुद्दे" नहीं होतीं। वे DNS, प्रमाणपत्र और रीडायरेक्ट नियमों के छोटे मेल न खाने से होती हैं जो वास्तविक उपयोगकर्ताओं के आने पर ही दिखती हैं।
एक आसान जाल apex डोमेन (example.com) है। कई DNS प्रोवाइडर apex पर सच्चा CNAME अनुमति नहीं देते। यदि आप apex पर CNAME फोर्स करने की कोशिश करते हैं तो वह चुपचाप फेल हो सकता है, असंगत रूप से हल हो सकता है, या कुछ नेटवर्क्स पर ही टूट सकता है। अपने DNS होस्ट के समर्थन के अनुसार सही विकल्प चुनें (अकसर A/AAAA, या ALIAS/ANAME-शैली रिकॉर्ड)।
एक और सामान्य कारण यह है कि आप DNS बदल देते हैं इससे पहले कि नए एंडपॉइंट पर SSL तैयार हो। उपयोगकर्ता आते हैं, ऐप लोड होता है, और फिर ब्राउज़र ब्लॉक कर देता है क्योंकि सर्टिफिकेट गायब है या केवल कुछ होस्टनेम कवर करता है। व्यवहार में, अक्सर आप चाहते हैं कि सर्टिफिकेट दोनों example.com और www.example.com को कवर करे, भले ही आप एक को दूसरे पर रीडायरेक्ट करें।
आउटेज या अजीब व्यवहार पैदा करने वाली सामान्य गलतियाँ:
www → apex, फिर apex वापस www), या एक जगह HTTP और दूसरी जगह HTTPS जबरदस्ती करनाhttp:// हार्डकोडेड एसेट्स भेजकर mixed content भेजना, जो ब्राउज़र वार्निंग और फीचर ब्रेक कर देता हैएक त्वरित सैनीटी चेक: दोनों होस्टनेम (www और apex) को HTTPS पर खोलें, लॉग इन करें, रिफ्रेश करें, और पुष्टि करें कि एड्रेस बार कभी HTTP पर वापस न जाए।
यदि आप यह Koder.ai जैसे प्लेटफ़ॉर्म पर कर रहे हैं, तो सुनिश्चित करें कि कस्टम डोमेन्स जुड़े हैं और SSL जारी हुआ है इससे पहले कि आप प्रोडक्शन DNS छुएं, और रोलबैक विकल्प तैयार रखें ताकि बुरा रीडायरेक्ट या रिकॉर्ड बदलाव लंबे समय तक न टिका रहे।
एक शांत कटओवर ज्यादातर तैयारी का मामला है। लक्ष्य सरल है: उपयोगकर्ता लॉग इन रहना चाहिए, कूकीज़ काम करती रहें, और यदि कुछ गलत लगे तो आप तेजी से रोलबैक कर सकें।
ये सब पुराने डोमेन पर ट्रैफ़िक रहते हुए करें। अगर संभव हो तो एक दिन दें ताकि DNS बदलाव बैठ जाएँ।
www, api, आदि) और अपना SSL वैलिडेशन तरीका चुनें (DNS या HTTP)।www → apex (या इसके विपरीत), और एक canonical होस्ट।DNS फ्लिप करते समय पहले घंटे को एक incident drill की तरह ट्रीट करें। रीयल यूज़र फ्लो देखें, सिर्फ स्टेटस डैशबोर्ड नहीं।
भले ही Koder.ai (या कोई अन्य प्लेटफ़ॉर्म) आपके लिए कस्टम डोमेन्स और SSL संभाले, यह चेकलिस्ट अभी भी मायने रखती है। ज़्यादातर समस्याएँ DNS और रीडायरेक्ट्स से आती हैं, ऐप कोड से नहीं।
आपका ऐप अस्थायी प्लेटफ़ॉर्म एड्रेस myapp.koder.ai पर चल रहा है। यह काम करता है, पर आप चाहते हैं कि ग्राहक example.com का उपयोग करें, www.example.com apex पर रीडायरेक्ट करे, और सब कुछ HTTPS पर मजबूर हो।
एक सरल DNS योजना जोखिम कम रखती है। कुछ भी बदलने से पहले वर्तमान कार्यशील स्थिति नोट कर लें (यदि आपका प्लेटफ़ॉर्म स्नैपशॉट सपोर्ट करता है तो स्नैपशॉट लें, जैसे Koder.ai में होता है) और कटओवर से एक दिन पहले DNS TTL कम कर दें ताकि कैशेस तेज़ी से बदले।
नए रिकॉर्ड जोड़ें जबकि मौजूदा प्लेटफ़ॉर्म URL अपरिवर्तित रखें:
example.com: होस्टिंग टार्गेट की ओर A/ALIAS रिकॉर्ड पॉइंट करें जो आपका प्लेटफ़ॉर्म प्रदान करता हैwww.example.com: CNAME को example.com की ओर पॉइंट करें (या प्लेटफ़ॉर्म टार्गेट की ओर, प्रोवाइडर पर निर्भर)myapp.koder.ai को अपरिवर्तित रखें ताकि आपके पास हमेशा एक ज्ञात-भला fallback रहेएक बार DNS जगह पर होने के बाद, दोनों होस्टनेम (example.com और www.example.com) के लिए SSL का अनुरोध करें। सर्टिफिकेट जारी और सक्रिय होने तक ट्रैफ़िक न बदलें, नहीं तो उपयोगकर्ताओं को ब्राउज़र वार्निंग का सामना करना पड़ेगा।
कटओवर टाइमलाइन स्पष्ट चेकपॉइंट्स के साथ:
example.com टेस्ट करें (होमपेज, स्टैटिक एसेट्स, API कॉल्स)www → apex)मूव के बाद कूकी बिहेवियर सत्यापित करें। लॉग इन करें, रिफ्रेश करें, और जांचें कि आप दोनों www और apex पर लॉग इन बने रहते हैं। अगर सेशन्स टूटते हैं, तो अक्सर कारण कूकी डोमेन या SameSite सेटिंग होती है जो अभी भी पुराने होस्ट को मान रही होती है।
कटओवर काम करने के बाद भी काम खत्म नहीं हुआ। ज़्यादातर डोमेन मूव बाद में इसलिए फेल होते हैं क्योंकि कोई नज़र नहीं रखता: सर्टिफिकेट एक्सपायर होने वाला है, कोई जल्दबाजी में DNS बदल देता है, या रीडायरेक्ट में बदलाव किसी लॉगिन फ्लो को तोड़ देता है।
एक छोटा मॉनिटरिंग रूटीन सेट करें जिसे आप वाकई बनाए रखें। आपको बड़े एंटरप्राइज़ टूल की ज़रूरत नहीं, पर कुछ भरोसेमंद संकेत चाहिए: मुख्य पेजों (होम, लॉगिन, और एक authenticated पेज) के लिए उपलब्धता चेक, प्रमाणपत्र समाप्ति अलर्ट (उदाहरण के लिए 30 दिन और फिर 7 दिन पर), एरर-रेट ट्रैकिंग (केवल uptime नहीं, 4xx/5xx स्पाइक्स देखें), और कभी-कभी रीडायरेक्ट सत्यापन (HTTP → HTTPS और पसंदीदा होस्टनेम विजेता बनता है)।
जब तक आप आश्वस्त न हों, पिछले सेटअप के लिए एक छोटा रोलबैक विंडो रखें (24–72 घंटे)। पुराना DNS टार्गेट, पुराना होस्टिंग कॉन्फ़िग, और पुराना TLS सेटिंग्स तैयार रखें ताकि आप जल्दी से revert कर सकें अगर कोई छिपा मुद्दा जैसे किसी पेमेंट callback या OAuth प्रोवाइडर का अब भी पुराना डोमेन दिखना सामने आए।
एक बार आप आश्वस्त हो जाएँ तो DNS TTL वापस बढ़ा दें। चेंज के दौरान कम TTL उपयोगी है, पर यह रिज़ॉल्वर लोड बढ़ाता है और बाद में छोटी गलतियों का प्रभाव बड़ा कर देता है। एक सामान्य TTL चुनें जो आपके बदलावों की आवृत्ति के अनुरूप हो (कई टीमें 1–4 घंटे चुनती हैं)।
अंत में, अंतिम स्थिति को फ़्रेस्ट रहते हुए दस्तावेज़ित करें: कौन से रिकॉर्ड मौजूद हैं (प्रकार, नाम, मान, TTL), कौन से होस्टनेम सपोर्टेड हैं, और सटीक रीडायरेक्ट नियम क्या हैं। शामिल करें कि प्रमाणपत्र कहाँ जारी होते हैं, वे क्या कवर करते हैं (apex, www, सबडोमेन्स), और रिन्यूअल किसका काम है।
यदि आप किसी प्लेटफ़ॉर्म पर बनाते और डिप्लॉय करते हैं, तो डोमेन्स को प्राथमिक सुविधा के रूप में रखते हुए और स्नैपशॉट/रोलबैक सहज रखने से भविष्य में डोमेन और रीडायरेक्ट परिवर्तनों का जोखिम कम होता है।
Default to one canonical hostname and redirect everything else to it.
example.com (apex) or www.example.com as the “real” one.This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.
Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.
Only lower TTL on the records you’re actually going to change.
For many app setups:
www.example.com or app.example.com when you’re pointing to a provider hostname.example.com.Don’t switch user traffic until HTTPS is valid on the new hostname(s).
A practical order:
This avoids browser warnings and blocked requests right at cutover.
Most email breakage happens when people delete or overwrite MX and TXT records.
Before changing anything:
Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.
Use these safe defaults:
http:// → https://If you’re behind a proxy/CDN, make sure your app respects forwarded scheme headers; otherwise it may think every request is HTTP and keep redirecting forever.
Yes, it’s common if cookies were scoped to the old hostname.
What to check:
old-host won’t be sent to new-hostUpdate identity settings before cutover.
Typical items that must match the new domain exactly:
If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.
A rollback is usually just restoring the previous DNS values.
Keep it simple:
If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.
Focus on real user paths, not just the homepage.
Test these on both the canonical host and the redirecting host:
Also verify the address bar ends on and always on , with no mixed-content warnings.
Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.
A quick safety step is exporting or screenshotting the current zone so you can restore it fast.
A low-risk approach is keeping the old hostname working during a transition so users can refresh sessions on the new domain.