वेब ऐप्स के लिए कस्टम डोमेन सेटअप: DNS, SSL, और कटओवर
वेब ऐप्स के लिए कस्टम डोमेन सेटअप: स्पष्ट DNS रिकॉर्ड कदम, SSL जारी करना, रीडायरेक्ट्स और डाउनटाइम व कूकी इश्यूज़ से बचने के लिए कम-जोखिम कटओवर योजना।
कस्टम डोमेन क्या बदलता है (और क्या गलत हो सकता है)
कस्टम डोमेन सिर्फ बेहतर URL नहीं है। जैसे ही आप प्लेटफ़ॉर्म के सबडोमेन (उदाहरण के लिए Koder.ai पर बना कोई ऐप) से अपने खुद के डोमेन पर जाते हैं, ब्राउज़र और नेटवर्क उसे एक अलग साइट की तरह मानते हैं। इसका असर रूटिंग, सुरक्षा और उपयोगकर्ता सेशन के व्यवहार पर पड़ता है।
कस्टम डोमेन पर स्विच करने के बाद कुछ चीजें तुरंत बदल जाती हैं:
- DNS रूटिंग: उपयोगकर्ता पुराने होस्टनेम पर नहीं जाते और नए DNS लक्ष्य पर पहुँचते हैं।
- TLS/SSL: सर्टिफिकेट को नए होस्टनेम(स) से मेल खाना चाहिए और यह असली उपयोगकर्ताओं के आने से पहले सक्रिय होना चाहिए।
- रीडायरेक्ट्स: आप तय करते हैं कि उपयोगकर्ता
wwwपर आएँ या apex डोमेन पर, और HTTP से HTTPS संबंधी नियमों का पालन होना चाहिए। - कूकीज़ और सेशन्स: कूकीज़ डोमेन के हिसाब से सीमाबद्ध होती हैं।
old-platform.exampleके लिए बनी लॉगिन कूकीapp.yourdomain.comपर स्वतः काम नहीं करेगी। - कैशिंग और प्रोपेगेशन: DNS रिज़ॉल्वर और ब्राउज़र परिणामों को कैश करते हैं, इसलिए सभी एक ही क्षण में बदलते नहीं हैं।
छोटे-से-मध्यम आउटेज अक्सर टाइमिंग की वजह से आते हैं। DNS नए होस्ट पर ट्रैफ़िक भेजना शुरू कर देता है जबकि SSL सर्टिफिकेट तैयार नहीं होता — इससे ब्राउज़र वार्निंग आती हैं। या उल्टा: SSL तैयार है लेकिन कई उपयोगकर्ता पुराने स्थान पर बने रहते हैं क्योंकि उनका DNS कैश समाप्त नहीं हुआ।
रीडायरेक्ट्स भी लॉगिन को बारीक तरीकों से तोड़ सकते हैं। होस्टनेम बदलने वाला रीडायरेक्ट (apex से www या इसके विपरीत) कूकीज़ खो सकता है अगर वे दूसरी होस्ट पर सेट की गई थीं। ऑथ प्रोवाइडर तब फेल कर सकते हैं जब उनका callback URL अभी भी पुराने डोमेन की तरफ हो।
एक कम-जोखिम वाला कटओवर overlap के लिए योजना बनाना है: पुराना URL काम करता रहे, नया डोमेन समानांतर में तैयार हो, ट्रैफ़िक एक नियंत्रित पल में स्विच हो और रोलबैक इतना आसान हो कि बस DNS वापस बदलना पड़े।
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 कौन संभालता है
कई लोग डोमेन रजिस्टर करते हैं, पर DNS कहीं और होस्ट हो सकता है। पुष्टि करें कि आज रिकॉर्ड्स कहाँ संपादित होते हैं, किसके पास एक्सेस है, और क्या कोई ऑटोमेशन बदलाव कर रहा है (कंपनी IT, एजेंसी, या managed DNS प्रोवाइडर)। अगर आप लॉग इन कर के वर्तमान रिकॉर्ड नहीं देख सकते तो पहले वही ठीक करें।
यह भी ऑडिट करें कि डोमेन का अभी क्या उपयोग हो रहा है। ईमेल क्लासिक जाल है: रिकॉर्ड हटाने या ओवरराइट करने से मेल डिलीवरी टूट सकती है।
प्रोसिड करने से पहले ये निर्णय लिख लें:
- प्राथमिक होस्टनेम (apex या
www) और रीडायरेक्ट दिशा - अभी आवश्यक सबडोमेन (app, api, admin) बनाम बाद की योजनाएँ
- DNS कहाँ होस्ट होता है और कौन परिवर्तन पब्लिश कर सकता है
- मौजूदा महत्वपूर्ण रिकॉर्ड (MX, SPF, DKIM, DMARC, वेरिफिकेशन TXT)
- कूकी और ऑथ अपेक्षाएँ (एक होस्ट बनाम सबडोमेन्स पर साझा)
अगर मार्केटिंग पहले से example.com पर ईमेल चलाती है, तो मेल-संबंधी रिकॉर्ड को बरकरार रखें और केवल वही जोड़ें जो ऐप को चाहिए।
आप जिन DNS रिकॉर्ड्स का उपयोग करेंगे और वे क्यों जरूरी हैं
कस्टम डोमेन मूव का सबसे बड़ा जोखिम ऐप नहीं होता। यह एक गलत DNS बदलाव होता है जो ट्रैफ़िक को कहीं न ले जाए, ईमेल तोड़े, या SSL वेरिफिकेशन फेल कर दे।
मूल रिकॉर्ड (A, CNAME, और सहायक)
एक A रिकॉर्ड किसी नाम को IP एड्रेस पर पॉइंट करता है। साधारण शब्दों में: “लोगों को इस सर्वर पर भेजो।” यह आमतौर पर apex (example.com) के लिए उपयोग होता है जब आपके प्रोवाइडर ने फ़िक्स्ड IP दिया हो।
एक CNAME रिकॉर्ड एक नाम को दूसरे नाम पर पॉइंट करता है। साधारण शब्दों में: “इस नाम को उस होस्टनेम का उपनाम मानो।” यह आमतौर पर www.example.com के लिए प्लेटफ़ॉर्म होस्टनेम की ओर पॉइंट करने में उपयोग होता है।
कई DNS प्रोवाइडर apex के लिए ALIAS/ANAME भी देते हैं। यह CNAME जैसा व्यवहार करता है पर example.com पर काम करता है। यदि आपका प्रोवाइडर इसे सपोर्ट करता है तो यह IP बदलते रहने पर प्रबंधित करना आसान बनाता है।
सरल मानसिक मॉडल:
- A: name -> IP (direct)
- CNAME: name -> name (alias)
- TXT: name -> text (प्रूफ और पॉलिसी)
- MX: name -> mail servers (सिर्फ तब छेड़ें जब आप मेल बदलना चाहें)
TXT रिकॉर्ड: सत्यापन, SSL, और ईमेल सुरक्षा
अक्सर आप TXT रिकॉर्ड जोड़ेंगे डोमेन ओनरशिप चेक के लिए (प्लेटफ़ॉर्म वेरिफिकेशन) और SSL प्रमाणपत्र मान्यकरण के लिए (कुछ CAs TXT टोकन के जरिए वैलिडेट करते हैं)। TXT ईमेल पॉलिसी जैसे SPF के लिए भी प्रयोग होता है। किसी मौजूद SPF TXT को आकस्मिक रूप से हटाना या बदलना मेल डिलीवरी तोड़ सकता है।
TTL: आपका “बदलने की गति” नॉब
TTL नियंत्रित करता है कि दूसरे सिस्टम आपकी DNS उत्तर कितनी देर के लिए कैश रखें। कटओवर से एक दिन पहले उन रिकॉर्ड्स का TTL घटा दें जिन्हें आप बदलने वाले हैं (अक्सर 300 से 600 सेकंड)। सब कुछ स्थिर होने के बाद इसे फिर बढ़ा दें ताकि क्वेरी लोड घटे।
मौजूदा रिकॉर्ड्स को ओवरराइट करने से बचें और रोलबैक दस्तावेज़ित रखें
संपादन से पहले जोन का एक्सपोर्ट या स्क्रीनशॉट लें। हर रिकॉर्ड जो आप बदलेंगे, उसकी पुरानी वैल्यू, नई वैल्यू और TTL लिख लें। अगर कुछ गलत हुआ तो रोलबैक का मतलब पहले वाले मानों को बहाल करना है।
यह खासकर तब महत्वपूर्ण है जब आपका डोमेन पहले से MX, DKIM या अन्य TXT रिकॉर्ड्स के साथ ईमेल के लिए सेट हो।
SSL जारी करना: वैलिडेशन, टाइमिंग और कवरेज
SSL (लॉक आइकन) ब्राउज़र और आपके ऐप के बीच ट्रैफ़िक को एनक्रिप्ट करता है। आधुनिक ब्राउज़र और कई APIs डिफ़ॉल्ट रूप से HTTPS की उम्मीद करते हैं। इसके बिना आपको वार्निंग, ब्लॉक्ड अनुरोध और कुछ फीचर (service workers, geolocation, कुछ पेमेंट फ्लो) में समस्या हो सकती है।
सर्टिफिकेट जारी करने के लिए CA को यह सत्यापित करना होता है कि आप डोमेन के मालिक हैं। आम वेरिफिकेशन तरीके HTTP वैलिडेशन और DNS TXT वैलिडेशन हैं:
- HTTP validation में एक अस्थायी फ़ाइल या रेस्पॉन्स आपके ऐप पर एक विशेष URL पर रखा जाता है।
- DNS TXT validation में आप DNS जोन में एक TXT रिकॉर्ड जोड़ते हैं।
जब आप CDN का उपयोग कर रहे हों या आपका ऐप नया डोमेन पर अभी पहुँचा नहीं जा रहा हो तो DNS वेलिडेशन अक्सर आसान रहता है।
सर्टिफिकेट कहाँ जारी होता है यह आपके सेटअप पर निर्भर करता है। कुछ टीमें सीधे होस्टिंग स्टैक पर सर्टिफिकेट जारी करती हैं, कुछ CDN पर करती हैं, और कुछ प्लेटफ़ॉर्म (जैसे Koder.ai) कस्टम डोमेन सेटअप के दौरान इसे संभालते हैं। महत्वपूर्ण बात यह जानना है कि सर्टिफिकेट लाइफसायकल, साथ ही रिन्यूअल किसके जिम्मे है।
टाइमिंग और रिट्राइ
सर्टिफिकेट जारी होना हमेशा तुरंत नहीं होता। DNS प्रोपेगेशन, वेलिडेशन चेक और रेट लिमिट्स धीमा कर सकते हैं। रिट्राइ के लिए योजना बनाएं और कटओवर को अंतिम मिनट पर न रखें।
व्यावहारिक टाइमिंग योजना:
- कटओवर से एक दिन पहले DNS TTL घटाएँ ताकि बदलाव जल्दी लागू हों।
- वेरिफिकेशन रिकॉर्ड पहले ही जोड़ दें (DNS TXT या HTTP टोकन)।
- तब तक प्रतीक्षा करें जब तक कि सभी होस्टनेम के लिए सर्टिफिकेट जारी न हो जाए।
- तभी ट्रैफ़िक नए लक्ष्य पर पॉइंट करें।
कवरेज: सही होस्टनेम शामिल हैं यह सुनिश्चित करें
एक सर्टिफिकेट को हर उस होस्टनेम को कवर करना चाहिए जहाँ उपयोगकर्ता पहुँचेंगे। SAN सूची (Subject Alternative Names) चेक करें। यदि आपका ऐप example.com और www.example.com दोनों पर उपलब्ध होगा तो सर्टिफिकेट दोनों को शामिल करे।
वाइल्डकार्ड (*.example.com) कई सबडोमेन्स के लिए मददगार हो सकता है, पर यह apex (example.com) को कवर नहीं करता।
ठोस उदाहरण: यदि आपने सिर्फ www.example.com के लिए सर्टिफिकेट जारी किया है, तो जो उपयोगकर्ता example.com टाइप करेंगे उन्हें वार्निंग दिखेगी जब तक आप किसी ऐसे लेयर पर रीडायरेक्ट नहीं कर रहे जहाँ example.com के लिए वैध सर्टिफिकेट हो।
रीडायरेक्ट नियम: www, apex, HTTP से HTTPS, और सुरक्षित डिफ़ॉल्ट्स
रीडायरेक्ट सुनने में सरल लगते हैं, पर अधिकांश डोमेन समस्याएँ यहीं उभरती हैं: लूप्स, मिक्स्ड कंटेंट, और उपयोगकर्ता तब लॉगआउट हो जाते हैं क्योंकि वे होस्टनेम के बीच बाउंस हुए।
एक canonical होस्ट चुनें और उस पर टिके रहें: या www.example.com या example.com (apex)। दूसरा entry point आपके चुने हुए canonical होस्ट पर रीडायरेक्ट होना चाहिए ताकि कूकीज़, सेशन्स और SEO संकेत सुसंगत रहें।
सुरक्षित डिफ़ॉल्ट्स:
- एक canonical होस्ट, दूसरे होस्ट से एकल 301 रीडायरेक्ट
- हर अनुरोध के लिए
http://सेhttps://पर 301 - रीडायरेक्ट के दौरान पूरा पाथ और क्वेरी स्ट्रिंग बचाएँ (deep links काम करते रहें)
- केवल एक बार रीडायरेक्ट करें (जैसे http -> https -> www से बचें)
HTTP से HTTPS के लिए ऐसे नियम से बचें जो उपयोगकर्ताओं को बार-बार उछालें। लूप रोकने का आसान तरीका यह है कि निर्णय उस आधार पर लें कि रिक्वेस्ट वास्तव में क्या था। यदि आपका ऐप proxy या CDN के पीछे है, तो उसे forwarded headers का सम्मान करने के लिए कॉन्फ़िगर करें; वर्ना ऐप सोच सकता है कि हर रिक्वेस्ट HTTP ही है और बार-बार रीडायरेक्ट करेगा।
मूव के दौरान पुराने पाथ्स को जीवित रखें। यदि आप रूट बदल रहे हैं (जैसे /login से /sign-in), तो उन पाथ्स के लिए स्पष्ट रीडायरेक्ट जोड़ें। होमपेज पर blanket रीडायरेक्ट पर निर्भर न रहें — यह बुकमार्क और शेयर किए गए लिंक तोड़ता है।
शुरू में HSTS लागू करने से बचें। अगर आप इसे बहुत जल्दी लागू कर दें और बाद में आपको वैलिडेशन या ट्रबलशूटिंग के लिए HTTP पर सर्व करना पड़े तो ब्राउज़र इन अनुरोधों को अस्वीकार कर सकते हैं। HTTPS स्थिर होने और सबडोमेन कवरेज निश्चित होने के बाद ही HSTS चालू करें।
प्रभावित न करने वाले परीक्षण के लिए एक अस्थायी टेस्ट होस्टनेम इस्तेमाल करें, कुछ गहरे लिंक (ऑथ पेजेज सहित) आज़माएँ, और कमांड-लाइन अनुरोध चलाकर हर रीडायरेक्ट स्टेप और अंतिम डेस्टिनेशन देखें।
चरण-दर-चरण कम-जोखिम कटओवर योजना (नो डाउनटाइम)
एक सुरक्षित कटओवर ज्यादातर टाइमिंग का मामला है। आप चाहते हैं कि नया डोमेन तैयार और टेस्ट किया हुआ हो इससे पहले कि असली उपयोगकर्ता वहाँ भेजे जाएँ, और DNS बदलाव जल्दी फैलें ताकि किसी समस्या में आप फंसे न रहें।
1) प्रोडक्शन DNS छूने से पहले तैयारी और परीक्षण
उन रिकॉर्ड्स का TTL घटाएँ जिन्हें आप बदलने वाले हैं, यह अच्छी तरह से पहले करें—संभव हो तो एक दिन पहले—फिर पुराने TTL विंडो के पार प्रतीक्षा करें ताकि कैशेस नया छोटा TTL पकड़ लें।
इसके बाद होस्ट/प्रोवाइडर में कस्टम डोमेन जोड़ें और जो वेरिफिकेशन वे मांगते हैं पूरा करें। यदि आप Koder.ai जैसे प्लेटफ़ॉर्म का उपयोग कर रहे हैं, तो पहले वहां डोमेन जोड़ें ताकि प्लेटफ़ॉर्म ओनरशिप कन्फर्म कर सके और रूटिंग तैयार कर सके।
SSL जल्दी जारी करें। वेलिडेशन पर निर्भर करते हुए यह मिनटों से अधिक समय ले सकता है और आप स्विच के दौरान उस देरी का जोखिम नहीं लेना चाहते।
डोमेन सार्वजनिक करने से पहले एक निजी टेस्ट करें: अपने मशीन पर अस्थायी host entry का उपयोग कर नई एन्डपॉइंट को हिट करें और पुष्टि करें कि साइट सही सर्टिफिकेट के साथ HTTPS पर लोड होती है।
2) छोटे, उलटने योग्य कदमों में कटओवर करें
स्टेज्ड अप्रोच अपनाएँ ताकि आप जल्दी रोक सकें अगर कुछ अजीब दिखे:
- पहले से TTL घटाएँ, फिर पिछले TTL अवधि के पूरा होने तक प्रतीक्षा करें।
- अपने होस्ट में डोमेन वेरिफिकेशन पूरा करें और आंतरिक रूप से पुष्टि करें कि डोमेन सही ऐप की ओर पॉइंट कर रहा है।
- स्विच करने से पहले हर होस्टनेम के लिए SSL सक्रिय होने की पुष्टि करें (apex और/या
www)। - नियंत्रित ढंग से DNS बदलें: यदि संभव हो तो किसी सबडोमेन, छोटे क्षेत्र या सीमित ऑडियंस रूट से शुरू करें।
- पुराने डोमेन को ऑनलाइन और रीडायरेक्टिंग रखें जब तक आप ट्रैफ़िक और एरर रेट को मॉनिटर कर रहे हों।
यदि आप DNS स्तर पर असली कैनरी नहीं कर सकते, तब भी स्टेजिंग कर सकते हैं—उदाहरण के लिए पहले केवल एक होस्टनेम (www) बदलें और apex को तब तक न छुएँ जब तक आप आश्वस्त न हों।
3) शांत रहते हुए रोलबैक की योजना बनाएं
लिखित लिख लें कि आप किसे वापस करेंगे (कौन से रिकॉर्ड, कौन से मान) और कौन यह करेगा। रोलबैक सामान्यतः DNS को पहले जैसा रखना होता है।
सुनिश्चित करें कि पुराना सेटअप अभी भी मान्य है (पुराने डोमेन पर SSL समेत) ताकि उपयोगकर्ता सफ़ाई से वापस आ सकें जब तक आप नए पाथ को ठीक कर रहे हों।
मूव के बाद टूटती कूकीज़, सेशन्स और ऑथ से कैसे बचें
डोमेन बदलना सिर्फ DNS नहीं है। कई ऐप्स में "लॉग इन होना" कूकीज़ पर निर्भर करता है जो ब्राउज़र विशेष होस्टनेम से जोड़ता है। यदि आप होस्टनेम बदलते हैं, तो ब्राउज़र पुरानी कूकी भेजना बंद कर देगा और ऐप को लगेगा कि सभी लॉग आउट हो गए।
कूकी सेटिंग्स अक्सर कारण होती हैं:
- Domain तय करता है कि कौन से होस्टनेम कूकी प्राप्त कर सकते हैं।
app.old.comके लिए सेट कूकीapp.new.comपर नहीं भेजी जाएगी।.example.comपर सेट कूकीapp.example.comऔरwww.example.comदोनों पर काम कर सकती है। - Path यह सीमित करता है कि कूकी कहाँ भेजी जाएगी। अगर यह बहुत संकीर्ण है (जैसे
/api) तो आपकी वेब UI इसे नहीं देख पाएगी। - Secure मतलब कूकी केवल HTTPS पर ही भेजी जाएगी। मूव के बाद HTTP अनुरोधों में यह नहीं जाएगा।
- SameSite क्रॉस-साइट रीडायरेक्ट और एम्बेडेड फ्लो को प्रभावित करता है।
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 को कवर करे, भले ही आप एक को दूसरे पर रीडायरेक्ट करें।
आउटेज या अजीब व्यवहार पैदा करने वाली सामान्य गलतियाँ:
- बदलाव से पहले TTL घटाए बिना DNS बदलना, और फिर पुराने उत्तरों केexpire होने के लिए घंटों इंतजार करना
- ऐसे रीडायरेक्ट नियम रखना जो लूप बनाते हों (
www→ apex, फिर apex वापसwww), या एक जगह HTTP और दूसरी जगह HTTPS जबरदस्ती करना http://हार्डकोडेड एसेट्स भेजकर mixed content भेजना, जो ब्राउज़र वार्निंग और फीचर ब्रेक कर देता है- गैर-वेब DNS रिकॉर्ड्स (खासकर MX और TXT) भूल जाना, जो ईमेल और डोमेन वेरिफिकेशन तोड़ सकते हैं
- केवल एक ब्राउज़र में टेस्ट करना और cached HSTS या कूकी क्वीर्क्स को न चेक करना जो अन्य उपयोगकर्ता देखेंगे
एक त्वरित सैनीटी चेक: दोनों होस्टनेम (www और apex) को HTTPS पर खोलें, लॉग इन करें, रिफ्रेश करें, और पुष्टि करें कि एड्रेस बार कभी HTTP पर वापस न जाए।
यदि आप यह Koder.ai जैसे प्लेटफ़ॉर्म पर कर रहे हैं, तो सुनिश्चित करें कि कस्टम डोमेन्स जुड़े हैं और SSL जारी हुआ है इससे पहले कि आप प्रोडक्शन DNS छुएं, और रोलबैक विकल्प तैयार रखें ताकि बुरा रीडायरेक्ट या रिकॉर्ड बदलाव लंबे समय तक न टिका रहे।
कटओवर से पहले, दौरान, और बाद की क्विक चेकलिस्ट
एक शांत कटओवर ज्यादातर तैयारी का मामला है। लक्ष्य सरल है: उपयोगकर्ता लॉग इन रहना चाहिए, कूकीज़ काम करती रहें, और यदि कुछ गलत लगे तो आप तेजी से रोलबैक कर सकें।
कटओवर से पहले
ये सब पुराने डोमेन पर ट्रैफ़िक रहते हुए करें। अगर संभव हो तो एक दिन दें ताकि DNS बदलाव बैठ जाएँ।
- उन रिकॉर्ड्स का TTL घटाएँ जिन्हें आप बदलने वाले हैं और वर्तमान मान लिख लें ताकि आप उन्हें जल्दी restore कर सकें।
- हर होस्टनेम दस्तावेज़ित करें जिसे आप सर्व करेंगे (apex,
www, api, आदि) और अपना SSL वैलिडेशन तरीका चुनें (DNS या HTTP)। - रीडायरेक्ट नियम तैयार करें और स्टेजिंग में टेस्ट करें: HTTP → HTTPS,
www→ apex (या इसके विपरीत), और एक canonical होस्ट। - ऐसे ऑथ सेटिंग्स अपडेट करें जो सटीक URLs पर निर्भर करते हैं: OAuth callback URLs, allowed origins, कूकी डोमेन सेटिंग्स, और कोई SSO कॉन्फ़िग।
- तय करें कि कटओवर के दौरान कौन क्या मॉनिटर करेगा (लॉग, uptime checks, support inbox) और एक छोटा परिवर्तन विंडो सेट करें।
कटओवर के दौरान और बाद
DNS फ्लिप करते समय पहले घंटे को एक incident drill की तरह ट्रीट करें। रीयल यूज़र फ्लो देखें, सिर्फ स्टेटस डैशबोर्ड नहीं।
- दौरान: 4xx/5xx स्पाइक्स, रीडायरेक्ट लूप, और लॉगिन फेल्स (खासकर “invalid redirect URI” या अचानक सेशन ड्रॉप्स) मॉनिटर करें।
- बाद में: कई ब्राउज़रों में प्रमाणपत्र चेन मान्य है यह पुष्टि करें और महत्वपूर्ण पेज HTTPS पर बिना मिक्स्ड-कंटेंट वार्निंग के लोड हों।
- बाद में: canonical होस्ट व्यवहार की पुष्टि करें (अंततः केवल एक होस्ट एड्रेस बार में दिखे) और महत्वपूर्ण कूकीज़ सही तरीके से सेट और भेजी जा रही हों।
- बाद में: पुराना डोमेन कुछ समय के लिए रीडायरेक्ट करते रहें। कई उपयोगकर्ता पुराने बुकमार्क, ईमेल, या कैश्ड लिंक के जरिए वापस आएँगे।
भले ही Koder.ai (या कोई अन्य प्लेटफ़ॉर्म) आपके लिए कस्टम डोमेन्स और SSL संभाले, यह चेकलिस्ट अभी भी मायने रखती है। ज़्यादातर समस्याएँ DNS और रीडायरेक्ट्स से आती हैं, ऐप कोड से नहीं।
उदाहरण परिदृश्य: प्लेटफ़ॉर्म URL से कस्टम डोमेन पर जाना
आपका ऐप अस्थायी प्लेटफ़ॉर्म एड्रेस 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 का अनुरोध करें। सर्टिफिकेट जारी और सक्रिय होने तक ट्रैफ़िक न बदलें, नहीं तो उपयोगकर्ताओं को ब्राउज़र वार्निंग का सामना करना पड़ेगा।
कटओवर टाइमलाइन स्पष्ट चेकपॉइंट्स के साथ:
- T-24h: TTL घटाएँ, पुष्टि करें कि आप जल्दी रोलबैक कर सकते हैं
- T-0: ऐप होस्ट में डोमेन सक्षम करें, SSL तैयार होने की पुष्टि करें
- T+15m: एक incognito विंडो में
example.comटेस्ट करें (होमपेज, स्टैटिक एसेट्स, API कॉल्स) - T+30m: रीडायरेक्ट्स सक्षम करें (HTTP → HTTPS, और
www→ apex) - रोलबैक पल: यदि लॉगिन या API कॉल फेल हों, DNS को पहले वाले टार्गेट पर revert करें और प्लेटफ़ॉर्म URL जीवित रखें
मूव के बाद कूकी बिहेवियर सत्यापित करें। लॉग इन करें, रिफ्रेश करें, और जांचें कि आप दोनों 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, सबडोमेन्स), और रिन्यूअल किसका काम है।
यदि आप किसी प्लेटफ़ॉर्म पर बनाते और डिप्लॉय करते हैं, तो डोमेन्स को प्राथमिक सुविधा के रूप में रखते हुए और स्नैपशॉट/रोलबैक सहज रखने से भविष्य में डोमेन और रीडायरेक्ट परिवर्तनों का जोखिम कम होता है।
अक्सर पूछे जाने वाले प्रश्न
Should my main site be on the apex domain or on www?
Default to one canonical hostname and redirect everything else to it.
- Choose either
example.com(apex) orwww.example.comas the “real” one. - Treat the other as a single 301 redirect.
This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.
When should I lower DNS TTL before switching domains?
Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.
- Common cutover TTL: 300–600 seconds
- After the move is stable: raise TTL back up (often 1–4 hours)
Only lower TTL on the records you’re actually going to change.
What DNS record should I use: A, CNAME, or ALIAS?
For many app setups:
- Use CNAME for subdomains like
www.example.comorapp.example.comwhen you’re pointing to a provider hostname. - Use A (or ALIAS/ANAME if your DNS supports it) for the apex
example.com.
Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.
Do I need SSL ready before I change DNS?
Don’t switch user traffic until HTTPS is valid on the new hostname(s).
A practical order:
- Add the domain in your host/platform (for example, in Koder.ai custom domain settings)
- Complete domain verification (often via TXT)
- Wait until the certificate is issued for every hostname you’ll serve
- Only then update DNS to send real users there
This avoids browser warnings and blocked requests right at cutover.
How do I avoid breaking email when I add web records to my domain?
Most email breakage happens when people delete or overwrite MX and TXT records.
Before changing anything:
- Identify existing MX, SPF, DKIM, DMARC, and verification TXT records
- Add only the new records you need for the app
- Don’t “replace” an existing SPF TXT unless you know how to merge values
A quick safety step is exporting or screenshotting the current zone so you can restore it fast.
How do I avoid redirect loops when forcing HTTPS and www/apex?
Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.
Use these safe defaults:
- Exactly one redirect from non-canonical host → canonical host
- Exactly one redirect from
http://→https:// - Preserve path and query string
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.
Will switching to a custom domain log users out?
Yes, it’s common if cookies were scoped to the old hostname.
What to check:
- Cookie Domain: cookies set for
old-hostwon’t be sent tonew-host - Cookie SameSite: SSO/payment redirects can fail if it’s too strict
- Cookie Secure: cookies won’t be sent over HTTP
A low-risk approach is keeping the old hostname working during a transition so users can refresh sessions on the new domain.
What auth and SSO settings do I need to update after a domain change?
Update identity settings before cutover.
Typical items that must match the new domain exactly:
- OAuth/SSO redirect (callback) URLs
- Allowed origins / CORS settings
- Any allowlisted logout URLs
If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.
What’s the simplest rollback plan if the cutover goes wrong?
A rollback is usually just restoring the previous DNS values.
Keep it simple:
- Write down the “old” record values (and TTL) before you edit anything
- Keep the old endpoint live long enough to receive traffic again
- Decide who will revert the records and how you’ll confirm it worked
If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.
What should I test right after the domain cutover?
Focus on real user paths, not just the homepage.
Test these on both the canonical host and the redirecting host:
- Login/logout, password reset, email verification
- A deep link with a query string
- An authenticated page refresh (session stays valid)
- API calls your frontend depends on
Also verify the address bar ends on one hostname and always on HTTPS, with no mixed-content warnings.