১৯ নভে, ২০২৫·7 মিনিট
DNS ও SSL সমস্যার জন্য কাস্টম ডোমেন ট্রাবলশুটিং চেকলিস্ট
এই কাস্টম ডোমেন ট্রাবলশুটিং চেকলিস্টটি ব্যবহার করে সহজ ভেরিফিকেশন ধাপ নিয়ে DNS রেকর্ড সমস্যা, প্রোপাগেশন বিলম্ব এবং SSL সময়গত সমস্যাগুলো নির্ণয় করুন।
“কাস্টম ডোমেন কাজ করছে না” বলতে সাধারণত কী বোঝায়
“কাস্টম ডোমেন কাজ করছে না” বলতে অনেক ভিন্ন ধরনের ত্রুটি বোঝানো হতে পারে। আপনার ব্রাউজার লক্ষণ দেখায়, কারণ জানায় না। কিছুই বদলানোর আগে প্রথমে লিখে নিন আপনি ঠিক কী দেখছেন।
সাধারণ লক্ষণগুলো:
- একটি “domain not found” পেজ
- ডোমেনটি ভুল ওয়েবসাইট লোড করছে
- HTTPS চালু থাকা সত্ত্বেও “অপ্রটected” সতর্কতা
- রিডাইরেক্ট লুপ (http এবং https বা root ও www এর মধ্যে বারবার ফিরে আসা)
বেশিরভাগ ক্ষেত্রে, সমস্যা একটির মধ্যে সীমাবদ্ধ:
- DNS ভুল জায়গায় পয়েন্ট করছে, বা প্রয়োজনীয় রেকর্ড অনুপস্থিত
- হোস্টিং টার্গেট ঐ হোস্টনেমের জন্য কনফিগার করা নেই (সার্ভার আপনার ডোমেন চিনছে না)
- SSL এখনও ইস্যু হয়নি, ভুল হোস্টনেমের জন্য ইস্যু হয়েছে, বা DNS মেলাতে না পারায় ইস্যু করা যাচ্ছে না
- ক্যাশিং আপনার পরিবর্তনগুলো লুকিয়ে রাখছে (ব্রাউজার ক্যাশ, DNS রিসলভার ক্যাশ, বা পুরানো TTL মান)
ট্রাবলশুটিং শুরু করার আগে নিশ্চিত করুন আপনার কাছে দুটি জায়গার অ্যাক্সেস আছে: যেখানে আপনি DNS রেকর্ড এডিট করেন (রেজিস্ট্রার বা DNS প্রদানকারী) এবং যেখানে আপনি ডোমেনটি হোস্টিং দিকে জোড়া করছেন। উদাহরণস্বরূপ, যদি আপনি Koder.ai-তে ডেপ্লয় করা অ্যাপকে কাস্টম ডোমেন যুক্ত করেন, আপনার ডোমেনের DNS অ্যাক্সেস এবং অ্যাপের হোস্টিং/ডেপ্লয়মেন্ট সেটআপে ডোমেন সেটিংস, উভয়ের অ্যাক্সেস চাই।
কিছু সমাধান তাৎক্ষণিক (যেমন টাইপো ঠিক করা)। অন্যগুলো সময় নেয়। DNS পরিবর্তন দেখাতে সময় পর্যন্ত লাগতে পারে, এবং SSL সাধারণত DNS সঠিকভাবে পয়েন্ট করা এবং ডোমেন পৌঁছযোগ্য না হওয়া পর্যন্ত শেষ হবে না। লক্ষ্য হলো অনুমান বন্ধ করে প্রতিটি স্তর পর্যায়ক্রমে নিশ্চিত করা।
ছোট কিন্তু গুরুত্বপূর্ণ DNS ধারণাসমূহ (জারগন ছাড়া)
অধিকাংশ ডোমেন সমস্যা বোঝায় (1) আপনি যে হোস্টনেম পরীক্ষা করছেন, (2) কোথায় DNS ম্যানেজ করা হচ্ছে, এবং (3) রেকর্ডটি আসলে কোথায় পয়েন্ট করছে—এই তিনটার মধ্যে মিল নেই। এই তিনটি এক হয়ে গেলে SSL সাধারণত শেষ ধাপ।
ডোমেনের দুইটি সাধারণ ফর্ম আছে: রুট ডোমেন (example.com, apex বলা হয়) এবং সাবডোমেন (www.example.com, app.example.com)। এগুলো সম্পর্কিত কিন্তু আলাদা DNS রেকর্ড থাকতে পারে। তাই স্বাভাবিক যে www কাজ করে আর apex কাজ করে না, অথবা উল্টোটা ঘটে।
নেমসার্ভার ঠিক করে কে আপনার DNS জোনের দায়িত্বে। যদি আপনি একটি কোম্পানি থেকে ডোমেন কিনে থাকেন কিন্তু নেমসার্ভার অন্যত্র নির্দেশ করে, আপনাকে সেই নেমসার্ভার যেখানে নির্দেশ করছে সেখানে DNS এডিট করতে হবে। অনেক “আমি আপডেট করেছি কিন্তু কিছুই পরিবর্তন হয়নি” কেস হয় ভুল ড্যাশবোর্ডে রেকর্ড বদলানোর কারণে।
DNS রেকর্ড টাইপ সংক্ষেপে
এগুলো প্রধান রেকর্ড টাইপের কাজগুলো:
- A: একটি নামকে IPv4 ঠিকানায় পয়েন্ট করে (যেমন 203.0.113.10)
- AAAA: একটি নামকে IPv6 ঠিকানায় পয়েন্ট করে
- CNAME: একটি নামকে অন্য হোস্টনেমে পয়েন্ট করে (www-র জন্য সাধারণ)
- TXT: ভেরিফিকেশন ও সিকিউরিটির জন্য টেক্সট সংরক্ষণ করে (ওনারশিপ চেক, SPF ইত্যাদি)
TTL হচ্ছে “এটি কতক্ষণ ক্যাশে রাখবে” টাইমার। কম TTL মানে ক্যাশ দ্রুত রিফ্রেশ হয়। বেশি TTL মানে আপনি লম্বা অপেক্ষা করতে পারেন, এমনকি আপনি রেকর্ড ঠিক করলে ও। পুরানো মান কিছু সময় দেখা স্বাভাবিক।
ধাপে ধাপে: সহজ ডিসিশন ট্রি কারণে আলাদা করার জন্য
যখন কাস্টম ডোমেন ব্যর্থ হয়, সাধারণত চারটি একটি বাটকেটে পড়ে: DNS রেজলভ হয় না, DNS ভুল জায়গায় রেজলভ করে, SSL প্রস্তুত নয়, অথবা কেবল কিছু মানুষের কাছে ব্যর্থ কারণ ক্যাশিং।
এই ডিসিশন ট্রি ব্যবহার করুন:
- আপনাকে কি ডোমেন রেজলভই করছে না? যদি আপনি NXDOMAIN (বা “domain not found”) দেখেন, রেকর্ড অনুপস্থিত, আপনি ভুল DNS জোন এডিট করছেন, বা নেমসার্ভার আপনার ভাবার মতো নয়।
- যদি রেজলভ করে, কি এটি সঠিক টার্গেট দেখাচ্ছে? যদি পেজ লোড হয় কিন্তু ভুল সাইট, পার্ক করা পেজ বা পুরানো সার্ভার দেখায়, A/AAAA/CNAME টার্গেট ভুল বা কোন পুরানো রেকর্ড অগ্রাধিকার নিচ্ছে।
- যদি সঠিকভাবে পয়েন্ট করে, সমস্যা কি কেবল HTTPS? যদি HTTP কাজ করে কিন্তু HTTPS সার্টিফিকেট সতর্কতা দেখায়, SSL এখনও ইস্যু হতে পারে, সার্টিফিকেটের হোস্টনেম মিলছে না, বা প্ল্যাটফর্ম DNS থিতিয়ে যাওয়ার জন্য অপেক্ষা করছে।
- এটা কি এক ডিভাইস বা নেটওয়ার্কে কাজ করে কিন্তু অন্যটিতে না? এটাকে ক্যাশিং বা প্রোপাগেশন হিসেবে বিবেচনা করুন।
- রিডাইরেক্ট ভেঙে যাচ্ছে কি (www বনাম apex)? যদি
wwwকাজ করে কিন্তু root ডোমেন না করে (বা উল্টো), আপনি সম্ভবত কেবল একটি হোস্টনেম কনফিগার করেছেন, বা টক্কর-করা রিডাইরেক্ট নিয়ম আছে।
যে হোস্টিং প্ল্যাটফর্মগুলো ডোমেন ও সার্টিফিকেট অটোমেট করে, সেখানে “cannot find host” এবং “certificate pending” এর মধ্যে পার্থক্য জানালে আপনি জানবেন DNS ঠিক করতে হবে নাকি SSL-এ অপেক্ষা করতে হবে।
ধাপ 1: হোস্টনেম ও প্রত্যাশিত টার্গেট নিশ্চিত করুন
অনেক ডোমেন ত্রুটি শুরু হয় একটি সাধারণ মিল না থাকার কারণেই: আপনি এক হোস্টনেমের DNS সেট করেছেন, কিন্তু আপনি অন্যটি পরীক্ষা করছেন।
প্রথমে লিখে নিন যে কোন হোস্টনেমটি লাইভ করতে চান। রুট ডোমেন দেখতে example.com। একটি সাবডোমেন দেখতে www.example.com বা app.example.com। এগুলো আলাদা DNS এন্ট্রি, তাই “www কাজ করে” মানে apex কাজ করবে, এমন নয়।
পরের ধাপে, আপনার হোস্টিং প্ল্যাটফর্ম থেকে প্রত্যাশিত টার্গেট খুঁজে বের করুন। কিছু হোস্ট IP ঠিকানা দেয় (A বা AAAA রেকর্ডের জন্য)। কিছু অন্য একটি হোস্টনেম দেয় (CNAME-এর জন্য)। যদি আপনার হোস্ট ডোমেইন সেটআপ স্ক্রিনে কোনো মান দেয়, সেটাই সুত্রগ্রাহ্য রাখুন।
কিছুই বদলানোর আগে, বর্তমান সেটিংস কপি করে রাখুন:
- আপনি যেই হোস্টনেম পরিবর্তন করছেন তার বর্তমান DNS রেকর্ড কপি করুন
- যেকোনো বিদ্যমান A, AAAA, CNAME, এবং TXT রেকর্ড নোট করুন
- TTL রেকর্ড করে রাখুন
এছাড়া নিশ্চিত করুন আপনি সঠিক DNS জোন এডিট করছেন। ভুল ডোমেন, ভুল এনভায়রনমেন্ট, বা ভুল প্রদানকারী অ্যাকাউন্টে আপডেট করা সহজ।
ধাপ 2: সঠিক DNS রেকর্ড টাইপ বেছে নিন (A, AAAA, CNAME, TXT)
অনেক সমস্যা কেবল ভুল রেকর্ড টাইপের। দুইটি কেইস আলাদা করে দেখুন: রুট ডোমেন (example.com) এবং সাবডোমেন (www.example.com)। অনেক DNS প্রদানকারীর কাছে তারা আলাদাভাবে আচরণ করে।
A রেকর্ড একটি নামকে IPv4 ঠিকানায় পয়েন্ট করে। অনেক সেটআপে রুট ডোমেনের জন্য A রেকর্ড ব্যবহার করা হয় কারণ কিছু প্রদানকারী apex-এ CNAME অনুমতি দেয় না। যদি আপনার হোস্ট একটি IP দেয়, A রেকর্ড সাধারণত সঠিক।
AAAA হলো IPv6 ভার্সন। একটি ভুল AAAA রেকর্ড পুরানো গন্তব্যে পয়েন্ট করলে বিভ্রান্তিকর “আমার কাছে কাজ করে” আচরণ তৈরি হতে পারে, কারণ কিছু ভিজিটর IPv6 মারফত পৌঁছাবে আর কেউ IPv4 মারফত। যদি আপনার হোস্ট IPv6 টার্গেট না দিয়ে থাকে, ভুল AAAA রেকর্ড মুছে ফেলা প্রায়ই অদ্ভুত বাগ মেটায়।
CNAME একটি সাবডোমেনকে অন্য হোস্টনেমে পয়েন্ট করে (প্রায়ই www-এর জন্য)। যখন হোস্ট আপনাকে একটি নামকৃত এন্ডপয়েন্ট লক্ষ্য করতে বলছে, তখন এটি সুবিধাজনক।
TXT রেকর্ড ভেরিফিকেশন এবং চ্যালেঞ্জের জন্য—সাধারণ ভুলগুলোর মধ্যে আছে ভুল নাম (root বনাম _acme-challenge বনাম সাবডোমেন), অতিরিক্ত স্পেস, বা ভুল মান পেস্ট করা।
কনফ্লিক্টগুলো খুঁজে দেখুন—এগুলো সবচেয়ে ঝামেলা করে:
- একই নামের উপর CNAME থাকা এবং অন্য রেকর্ড টাইপও থাকা
- একই নামে একাধিক A বা AAAA রেকর্ড থাকা যেখানে আপনি কেবল একটি চান
- www বা root ডোমেনের জন্য পুরানো রেকর্ড থাকে
- ভুল হোস্টনেমে TXT রেকর্ড তৈরি করা
ধাপ 3: authoritative nameservers যাচাই করুন যাতে আপনি সঠিক জায়গায় এডিট করছেন
পরিষ্কার ডোমেন সেটআপ নিয়ে শুরু করুন
Koder.ai-তে অ্যাপ তৈরি ও ডেপ্লয় করুন, পরে কাস্টম ডোমেন জোড়া লাগান আত্মবিশ্বাসের সঙ্গে।
অনেক “কাস্টম ডোমেন কাজ করছে না” কেস আসলেই রেকর্ড ভ্যালু নিয়ে নয়। সেগুলো ঘটে কারণ রেকর্ড ভুল প্রদানকারীতে যোগ করা হয়েছে। যদি আপনার ডোমেন Provider A-র nameservers ব্যবহার করে, Provider B-র ড্যাশবোর্ডে রেকর্ড বদলালেও কোনো_public পরিবর্তন হবে না, যদিও ওই ড্যাশবোর্ডে রেকর্ড ঠিক দেখায়।
authoritative nameservers নিশ্চিত করুন
আপনার কম্পিউটার থেকে DNS-কে জিজ্ঞেস করে একটি দ্বিতীয় মতামত নিন:
dig NS example.com
এই কমান্ড যে nameservers রিটার্ন করে সেগুলোই authoritative।
একটি দ্রুত সেনসিবিলিটি চেক:
- যদি আপনার DNS হোস্ট আপনাকে
ns1...এবংns2...মতো nameservers দিচ্ছে, ওই একই মানগুলো রেজিস্ট্রারে মেলে থাকতে হবে। - যদি আপনি সম্প্রতি DNS প্রদানকারী বদলেছেন, বদলটি সম্পন্ন হয়েছে কিনা নিশ্চিত করুন তারপর রেকর্ড এডিট চালিয়ে যান।
- যদি প্ল্যাটফর্ম “suggested DNS records” দেখায়, তা সাধারণত নির্দেশনা; রেকর্ডগুলো authoritative DNS প্রদানকারীতে যোগ করাই লাগবে।
কেন “আমি আপডেট করেছি, কিন্তু কিছুই বদলায়নি” ঘটে
যদি আপনি ভুল প্রদানকারীর কাছে রেকর্ড আপডেট করেন, প্রায়ই দুইটি ড্যাশবোর্ডই মিলবে না। কেবলই authoritative nameservers-ই গণ্য।
নেমসার্ভার রেজিস্ট্রারে পরিবর্তনের পরে বিলম্বেও খেয়াল রাখবেন। ট্রানজিশন উইন্ডো চলাকালীন ফলাফল অনিশ্চিত দেখাতে পারে আপনি কোথা থেকে পরীক্ষা করছেন তার উপর নির্ভর করে। যদি nameservers এখনও পরিবর্তিত হচ্ছে, nameserver সেট স্টেবল না হওয়া পর্যন্ত রেকর্ড এডিট থামান, তারপর চালিয়ে যান।
ধাপ 4: কার্যকর প্রোপাগেশন ও ক্যাশিং চেকগুলো
“Propagation” কোনও এক সুইচ নয়। এটা DNS ক্যাশের চেইন (ISP, ফোন ক্যারিয়ার, পাবলিক রিসলভার, এবং আপনার নিজস্ব ডিভাইস) আপডেট হওয়ার ভিন্ন গতির সমষ্টি। এজন্য আপনার ডোমেন সহকর্মীর কাছে কাজ করতে পারে কিন্তু আপনার কাছে না।
TTL (time to live) বলছে কতক্ষণ পর্যন্ত কোনো রিসলভার উত্তরটি রাখতে পারবে। যদি পুরাতন TTL 1 ঘণ্টা ছিল, কিছু মানুষ প্রায় এক ঘণ্টা পুরানো মান দেখতে থাকবে। TTL কমানো কেবল তখনই সাহায্য করে যদি আপনি পরিবর্তনের আগে সেটি কমিয়ে থাকতেন।
ক্যাশিং ডিলেই থেকে আসা সমস্যা আলাদা করতে কয়েকটি দ্রুত চেক করুন:
- হোম বা অফিস Wi‑Fi-তে টেস্ট করুন, তারপর মোবাইল ডেটায় টেস্ট করুন
- ভিন্ন নেটওয়ার্কে কাউকে চেষ্টা করতে বলুন
- প্রাইভেট উইন্ডো ব্যবহার করুন (ক্যাশ করা রিডাইরেক্ট বাদ দিতে)
- ডিভাইস রিস্টার্ট করুন বা লোকাল DNS ক্যাশ ফ্লাশ করুন যদি জানেন কিভাবে
- সঠিক হোস্টনেমটি (root বনাম
www) ফেরত যাচাই করুন
যদি যেকোনো জায়গায় রেকর্ড ভুল থাকে (ভুল IP, অনুপস্থিত www, পুরানো CNAME), সেটি ঠিক করুন। যদি বেশিরভাগ স্থানে রেকর্ড ঠিক দেখা যায় কিন্তু এক নেটওয়ার্ক পুরোনো মান দেখায়, এটি সাধারণত ক্যাশিং ডিলেই।
ধাপ 5: SSL সময় এবং কেন "কিছুক্ষণ অপেক্ষা করুন" সঠিক হতে পারে
SSL সার্টিফিকেট সাধারণত এক মৌলিক কারণে ব্যর্থ হয়: সার্টিফিকেট প্রদানকারী ডোমেনটি ভেরিফাই করতে পারে না যতক্ষণ না DNS সঠিকভাবে পয়েন্ট করে।
সাধারণ সিকোয়েন্স সহজ:
- সঠিক DNS রেকর্ড সেট করুন।
- অপেক্ষা করুন যতক্ষণ না সেগুলো বহু স্থানে থেকে সঠিকভাবে রেজলভ হয়।
- প্রয়োজনীয় ভেরিফিকেশন সম্পন্ন করুন (প্রায়ই একটি TXT রেকর্ড)।
- সার্টিফিকেট ইস্যু শেষ হওয়া পর্যন্ত অপেক্ষা করুন।
সাধারণ ব্লকারগুলো চোখসহজে মিস করা যায়। ভুল A বা CNAME টার্গেট ভ্যালিডেশন চেকগুলোকে ভুল সার্ভারে নিয়ে যায়। একটি স্থবির AAAA রেকর্ড কিছু ভিজিটরকে আপনার কাজ করা A রেকর্ড অগ্রাহ্য করে ভুল সার্ভারে পাঠাতে পারে, ফলে HTTPS কেবল তাদের জন্যই ব্যর্থ হবে। প্রয়োজনীয় TXT অনুপস্থিত থাকলে প্ল্যাটফর্ম সার্টিফিকেট ইস্যু করতে পারবে না।
লক্ষণগুলো ব্যবহার করে “এখনই ইস্যু হচ্ছে” এবং “মিসকনফিগারড” আলাদা করুন:
- এখনই ইস্যু হচ্ছে: HTTP কাজ করতে পারে, কিন্তু HTTPS অস্থায়ী ডিফল্ট সার্টিফিকেট বা “not valid yet”-র মত বার্তা দেখায়।
- মিসকনফিগারড: আপনি অন্য ওয়েবসাইট, ISP পার্কিং পেজ, বা DNS লুকআপ ব্যর্থতা (NXDOMAIN) দেখেন।
অপেক্ষার সময়, রেকর্ড বারবার বদলাবেন না। প্রতিটি পরিবর্তন ঘড়ির কাঁটা রিসেট করে এবং বিভিন্ন নেটওয়ার্কে ভিন্ন উত্তর তৈরি করতে পারে। একবার সঠিক রেকর্ড সেট করুন, তারপর সার্টিফিকেট ইস্যু হওয়া পর্যন্ত রেজলিউশন ও ভেরিফিকেশন পুনরায় যাচাই করুন।
Koder.ai-এর মতো প্ল্যাটফর্ম ব্যবহার করলে, নিরাপদ ফ্লো একই: নিশ্চিত করুন DNS প্রত্যাশিত টার্গেটে পয়েন্ট করছে, ভুল AAAA রেকর্ড থাকলে মুছে ফেলুন, এবং DNS স্থিতিশীল হওয়ার পরে SSL-কে সময় দিন।
প্রতিটি ধাপ কীভাবে যাচাই করবেন (অনুমান ছাড়া)
আপনার বিল্ড খরচ অফসেট করুন
Koder.ai সম্পর্কে কনটেন্ট তৈরি করে বা টিমমেট ও ফাউন্ডারদের রেফার করে ক্রেডিট উপার্জন করুন।
ভালো ট্রাবলশুটিং মূলত তুলনা: যা আপনি দেখছেন বনাম আপনি কী আশা করেছিলেন। “আমার ফোনে লোড হচ্ছে”-এর উপর নির্ভর করবেন না—পুনরাবৃত্তি যোগ্য চেক ব্যবহার করুন।
DNS উত্তরগুলি আপনার প্রত্যাশিত টার্গেটের সাথে মিলান
একটি 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)। সাধারণত একটি সঠিক হলেও অন্যটি পুরোনো কোথাও পয়েন্ট করে থাকে।
ব্রাউজার আচরণ যাচাই করুন (HTTP, HTTPS, ও রিডাইরেক্ট)
apex ও www উভয়ের জন্য http:// এবং https:// উভয় খুলুন। আপনি একটি স্পষ্ট “হোম” ডোমেইন এবং একটি পরিষ্কার রিডাইরেক্ট চান।
- একটি ক্যানোনিক্যাল ডোমেইন বেছে নিন (apex অথবা
www) এবং অন্যটিকে সেটার দিকে রিডাইরেক্ট করুন। - পিং-পং রিডাইরেক্ট এড়িয়ে চলুন (A থেকে B, তারপর B থেকে A)।
- যদি HTTP কাজ করে কিন্তু HTTPS ব্যর্থ, SSL এখনও ইস্যু হচ্ছে বা DNS কোনো অপ্রত্যাশিত স্থানে পয়েন্ট করছে।
যদি নেটওয়ার্ক অনুযায়ী ফলাফল ভিন্ন হয়, হয়তো আপনি ক্যাশিং বা প্রোপাগেশন দেখছেন। একটি ছোট লগ রাখুন: আপনি কী বদলালেন, কোথায় বদলালেন, সময়, এবং আপনি কি পর্যবেক্ষণ করেছেন।
ঘন্টা নষ্ট করে দেওয়া সাধারণ ভুলগুলো
অধিকাংশ DNS ও SSL সমস্যা রহস্য নয়। এগুলো ছোট ভুল—আপনি ভুল জিনিস চেক করছেন, বা খুব দ্রুত পরিবর্তন করে পরিষ্কার রিড রিড আউটপুট পাচ্ছেন না।
সবচেয়ে সময় খেয়াল খাওয়ানো বিষয় হলো দুই জায়গায় DNS এডিট করা। নামসার্ভার বদলানোর পরে প্রায়ই এটা হয়: আপনি রেজিস্ট্রারে রেকর্ড আপডেট করেন, কিন্তু DNS আসলে অন্য জায়গায় হোস্ট হচ্ছে। এক ড্যাশবোর্ড ঠিক দেখলেও পাবলিক ফলাফল বদলাবে না।
আরেকটি ক্লাসিক ভুল হলো রুট ডোমেনে CNAME দেওয়ার চেষ্টা করা যেখানে প্রদানকারী তা সমর্থন করে না। আপনাকে A রেকর্ড বা যদি আপনার DNS প্রদানকারী ALIAS বা ANAME স্টাইল রেকর্ড দেয় তা ব্যবহার করতে হতে পারে।
IPv6ও ঝামেলা বাড়াতে পারে। একটি পুরানো AAAA রেকর্ড কিছু ভিজিটরকে ভুল সার্ভারে পাঠাতে পারে যখন অন্যরা সঠিক IP পায়।
“জাস্ট ইন কেস” রেকর্ড নিয়ে যুক্তিহীন হোন—একাধিক A রেকর্ড ভুল কনফিগারেশনের মতো আচরণ করতে পারে যদি একটি লক্ষ্য ভুল থাকে, বিশেষত কাস্টম ডোমেন হোস্টেড অ্যাপ পয়েন্ট করলে।
একটি চূড়ান্ত নিয়ম: ঘড়ি রিসেট করা বন্ধ করুন।
- প্রতি কয়েক মিনিটে রেকর্ড বদলাবেন না।
- পুরোনো ও নতুন টার্গেট একসাথে মিশাবেন না।
- ক্যাশ সেধে উঠার আগে ফলাফল বিচার করবেন না।
ছোট, শান্ত পরিবর্তন বারবার টুইকিং থেকে ভাল।
বাস্তব উদাহরণ: www কাজ করে কিন্তু রুট ডোমেন করে না
দ্রুত তৈরি করুন, মালিকানা রাখুন
চ্যাট দিয়ে অ্যাপ জেনারেট করুন, তারপর যখন খুশি সোর্স এক্সপোর্ট করে সম্পূর্ণ কন্ট্রোল রাখুন।
আপনি নতুন অ্যাপ লঞ্চ করেছেন এবং example.com ও www.example.com উভয় সেটআপ করেছেন। কয়েক মিনিট পরে www.example.com ভালো লোড করে, কিন্তু রুট ডোমেন DNS এরর দেখায়, পুরোনো সাইট লোড করে, অথবা HTTPS Pending থাকে। এই প্যাটার্ন সাধারণ এবং সাধারণত একটি ছোট কারণে হয়ে থাকে।
শুরু করুন বিরক্তিকর প্রশ্ন দিয়ে: আপনি কি সঠিক জায়গায় DNS এডিট করছেন? যদি আপনার ডোমেন একটি কোম্পানিতে রেজিস্টার করা কিন্তু DNS অন্যত্র হোস্ট করা হয়, আপনি সারাদিন রেকর্ড বদলালেও কিছুই হবে না। প্রথমে nameservers চেক করুন, তারপর ওই nameservers যেই প্রদানকারীকে নির্দেশ করছে তার DNS প্যানেল খুলুন।
পরের ধাপ, দুইটি হোস্টনেম তুলনা করুন। www সাধারণত CNAME হয়। রুট ডোমেন কঠিন: অনেক প্রদানকারী apex-এ CNAME অনুমোদন করে না, তাই সাধারণত A রেকর্ড প্রয়োজন হয় IP-এ, অথবা যদি প্রদানকারী ALIAS/ANAME দিলে সেগুলো ব্যবহার করতে হবে।
একটি কার্যকর সিদ্ধান্ত পথ:
- nameservers ভুল বা অপ্রত্যাশিত? আগে সেটা ঠিক করুন।
- nameservers সঠিক কিন্তু
example.com-এ কোনো রেকর্ড নেই (বা কোথাও অন্যত্র পয়েন্ট করছে)? apex রেকর্ড ঠিক করুন। - রেকর্ড ঠিক দেখা গেল কিন্তু আচরণ ডিভাইস অনুযায়ী আলাদা? প্রোপাগেশন ও ক্যাশে জন্য অপেক্ষা করুন।
- DNS সঠিকভাবে রেজলভ করছে কিন্তু HTTPS ব্যর্থ? SSL স্থিতিশীল DNS-এর জন্য অপেক্ষা করছে।
সঠিক শেষ অবস্থা হলো একঘেয়েমি: example.com ও www.example.com উভয় একই অ্যাপের দিকে যায়, একটি ক্যানোনিক্যাল থাকে (অন্যটি রিডাইরেক্ট করে), এবং HTTPS বৈধ।
৫ মিনিটে চালাতে যোগ্য দ্রুত চেকলিস্ট
ডোমেন সেটআপ ব্যর্থ হলে, বেশিরভাগ সমাধান কয়েকটি দ্রুত চেক থেকে আসে। কোনো কিছু বদলানোর আগে এগুলো চালান।
- নিশ্চিত করুন আপনি সঠিক জায়গায় DNS এডিট করছেন (আপনার ড্যাশবোর্ডকে ডোমেনের authoritative nameservers-ের সাথে মিলান)।
- হোস্টনেম ও টার্গেট সঠিক এবং একেবারে মিল আছে কিনা যাচাই করুন (কোনো সাবডোমেন বাদ পড়ে নাই, অতিরিক্ত ডট নেই)। আপনার রেকর্ড টাইপ (A, AAAA, CNAME, TXT) আপনার হোস্ট যা প্রত্যাশা করে তা সাথে তুলুন।
- কনফ্লিক্ট সরান (একই নামে CNAME ও অন্য রেকর্ড, বা যেগুলো আর প্রয়োজন নেই এমন পুরানো A/AAAA রেকর্ড)।
- দুইটি ভিউপয়েন্ট থেকে চেক করুন (মোবাইল ডেটা ও Wi‑Fi)। যদি একটি কাজ করে আর অন্যটি না করে, সাধারণত ক্যাশিং বা প্রোপাগেশন।
- TTL-কে সম্মান করুন। TTL যদি 300 সেকেন্ড হয়, বিচার করার আগে 5–10 মিনিট অপেক্ষা করুন। TTL যদি 3600 হয়, প্রায় এক ঘণ্টার আশা রাখুন।
DNS স্পষ্টভাবে সঠিক হলে তারপর SSL চেক করুন। বহু প্ল্যাটফর্ম কেবল তখন সার্টিফিকেট ইস্যু করে যখন তারা আপনার ডোমেনকে ধারাবাহিকভাবে সঠিক টার্গেটে রেজলভ করতে পারে। যদি আপনি অতি তাড়াহুড়ো করে চেক করেন, আপনি স্বাভাবিক দেরিকে ত্রুটি ভেবে ফেলতে পারেন।
আপনি যদি Koder.ai-তে ডিপ্লয় করা অ্যাপে কাস্টম ডোমেন যোগ করে থাকেন, ডোমেন সেটআপ স্ক্রিনকে প্রত্যাশিত টার্গেট হিসেবে নিন, তারপর authoritative DNS-এ ঠিক সেটি মিলিয়ে দিন এবং DNS প্রোপাগেশন সময় পাওয়ার পরে স্ট্যাটাস পুনঃপরীক্ষা করুন।
পরবর্তী ধাপ: প্রতিটি লঞ্চের জন্য ডোমেন সেটআপকে পুনরাবৃত্তিযোগ্য করুন
DNS ও SSL ত্রুটিগুলো পুনরাবৃত্তি না করতে দ্রুত একটি ছোট “ডোমেন সেটআপ নোট” রাখুন। এটি একটি পুনঃব্যবহৃত রানবুক যা আপনি পরেরবার লঞ্চে কপি করে ব্যবহার করতে পারবেন।
একটি সহজ ডোমেন সেটআপ নোট টেমপ্লেট
এটি আপনার প্রজেক্ট ডকসে রাখুন এবং DNS স্পর্শ করার আগে পূরণ করুন:
- ডোমেন ও হোস্টনেম (root, www, এবং যেকোন সাবডোমেন)
- প্রত্যাশিত রেকর্ড টাইপ ও টার্গেট (A, CNAME, TXT) এবং সেগুলো কোথা থেকে এসেছে
- DNS কোথায় এডিট করা হয় (কোন প্রদানকারী) এবং সক্রিয় nameservers কী
- SSL প্রত্যাশা (কে ইস্যু করে, “ready” কেমন দেখায়)
- আপনি কোন ভেরিফিকেশন টুল চালাবেন এবং প্রত্যাশিত ফলাফল
লঞ্চের সময়, একজন ব্যক্তি DNS অধিকারী রাখুন। DNS সবচেয়ে বেশি ভেঙে যায় যখন দুজন আলাদা জিনিস “থিক” করছে (উদাহরণ: একজন nameservers বদলাচ্ছে আর অন্যজন রেকর্ড এডিট করছে)।
হোস্টিং পাশে, নিরাপদ রিভার্সের পরিকল্পনা রাখুন। যদি আপনার প্ল্যাটফর্ম স্ন্যাপশট বা রোলব্যাক সমর্থন করে, রাউটিং বদলানোর আগে একটি স্ন্যাপশট নিন যাতে আপনি দ্রুত সর্বশেষ known-good অবস্থায় ফিরে যেতে পারেন। Koder.ai তে আপনি Planning Mode ব্যবহার করে ডোমেন ধাপগুলো লিখে রাখতে পারেন, সেগুলো ধাপে প্রয়োগ করতে পারেন, এবং কোনো পরিবর্তন প্রোডাকশন ভেঙে দিলে রোলব্যাক করতে পারেন।
কখন এগিয়ে নেওয়া উচিত (আর কাকে জানাবেন)
আপনি যদি DNS নিশ্চিত করে নিয়েও ব্যর্থতা দেখেন, অনুমান করা বন্ধ করে প্রমাণসহ এগিয়ে দিন:
- রেজিস্ট্রার nameservers লক করা আছে বা আপনি সেগুলো পরিবর্তন করতে পারছেন না
- প্রত্যাশিত TTL উইন্ডোর পরে DNS এডিট কোনো কিছুর ক্ষেত্রে দেখা যায় না
- DNS সঠিকভাবে রেজলভ হওয়ার অনেক ঘণ্টা পরে SSL এখনও ব্যর্থ (মিনিট নয়, ঘণ্টা বিবেচনা করুন)
- আপনি কনেরফ্লিক্টিং রেকর্ড দেখছেন যা সরাতে পারছেন না (প্রদানকারী UI বাগ বা split DNS)
এগিয়ে নেওয়ার সময় হোস্টনেম, প্রত্যাশিত রেকর্ড, বর্তমান রিসলভার রেজাল্ট এবং টাইমস্ট্যাম্প যোগ করুন। এটি ধীর ব্যাক-অ্যান্ড-ফোরটকে দ্রুত ফিক্সে পরিণত করে।
সাধারণ প্রশ্ন
What does “custom domain not working” usually mean?
এটি সাধারণত চেইনের এক স্তর ঠিক নেই এমনটাই বোঝায়: DNS রেজলভ হচ্ছে না, DNS ভুল টার্গেটে রেজলভ করছে, সার্ভার/হোস্ট আপনার হোস্টনেম চিনছে না, অথবা HTTPS/SSL এখনও ইস্যু হচ্ছে না। শুরু করুন দেখে নিয়ে যে ঠিক কী এরর দেখা যাচ্ছে এবং আপনি কোন হোস্টনেম টাইপ করছেন (apex বনাম www)।
Why does www work but the root domain (example.com) fails?
কারণ example.com (apex) এবং www.example.com আলাদা হোস্টনেম এবং আলাদা DNS রেকর্ড থাকে। বেশিরভাগ সময় www-এর জন্য সঠিক CNAME থাকলেও apex-এ কোনো A রেকর্ড নেই, ভুল A রেকর্ড আছে, অথবা আপনার DNS প্রদানকারী CNAME অনুপযোগী বলে সমস্যা হয়।
How do I know if I’m editing DNS in the right place?
রেজিস্ট্রার-এ ডোমেনের nameservers দেখুন এবং সেগুলোকে আপনি যে DNS প্রদানকারীর ড্যাশবোর্ডে এডিট করছেন সেই প্রয়োজ্য প্রদানকারীর সাথে মিলান। সক্রিয় nameservers-এ তালিকাভুক্ত প্রদানকারীই authoritative; অন্য কোথাও রেকর্ড এডিট করলে পাবলিক ইন্টারনেটে কিছুই পরিবর্তন হবে না।
Which DNS record type should I use (A, AAAA, CNAME, TXT)?
যখন আপনার হোস্ট একটি IPv4 ঠিকানা দেয় তখন A রেকর্ড ব্যবহার করুন, যদি আপনার হোস্ট IPv6 টার্গেট দেয় তখন AAAA ব্যবহার করুন, এবং যখন হোস্ট আপনাকে অন্য একটি হোস্টনেম দেয় তখন CNAME ব্যবহার করুন (সাধারণত www-এর জন্য)। TXT রেকর্ড হলো ভেরিফিকেশন ও চ্যালেঞ্জের জন্য, এবং সেগুলো অবশ্যই আপনার হোস্ট যে নির্দিষ্ট নাম বলেছে সেখানে তৈরি করতে হবে।
Can an IPv6 (AAAA) record break my domain even if the A record is correct?
একটি স্থবির বা ভুল AAAA রেকর্ড কিছু ব্যবহারকারীকে IPv6-এ পুরানো সার্ভারে পাঠাতে পারে, যখন אחרים IPv4-এ সঠিক সার্ভারে যায়—ফলত: “আমার কাছে কাজ করে” কন্ডিশন। যদি আপনার হোস্ট IPv6 টার্গেট না দিয়ে থাকে, তাহলে ভুল AAAA রেকর্ড মুছে ফেলা সাধারণত সহজ সমাধান।
What causes redirect loops between http/https or between apex/www?
প্রধানত কারণ আপনি হোস্টিং সাইডে কেবল একটি হোস্টনেম কনফিগার করেছেন (শুধু apex বা শূদু www) অথবা এমন প্রতিযোগিতামূলক রিডাইরেক্ট নিয়ম আছে যা HTTP ও HTTPS বা apex ও www-এর মধ্যে বাউন্স করে। একটি ক্যানোনিক্যাল হোস্টনেম বেছে নিন, দুটো হোস্টনেমই কনফিগার করুন, এবং কেবল একটি পরিষ্কার রিডাইরেক্ট পথ নিশ্চিত করুন।
If DNS is correct, can HTTPS still take time to work?
হ্যাঁ। DNS বহু স্থানে সঠিকভাবে রেজলভ না করলে সার্টিফিকেট প্রদানকারী ডোমেনটি ভেরিফাই করতে পারে না, তাই SSL ইস্যুতে সময় লাগা স্বাভাবিক। DNS কয়েকটি স্থানে ধীরে ধীরে স্থিতিশীল না হওয়া পর্যন্ত SSL সাধারণত ইস্যু হবে না। DNS পরিষ্কারভাবে সঠিক হওয়ার পরে অপেক্ষা করাই সঠিক সিদ্ধান্ত।
How long should I wait for DNS changes, and what is TTL?
TTL হলো কতক্ষণ রেসল্ভার একটি উত্তর ক্যাশে রাখবে—এই সময়কাল শেষ না হলে কেউ কেউ পুরানো মান দেখতে পারে। দুইটি ভিন্ন নেটওয়ার্ক (উদাহরণ: Wi‑Fi ও মোবাইল ডেটা) থেকে টেস্ট করুন এবং DNS বারবার বদলাবেন না যাতে আপনি প্রোপাগেশন পরিষ্কারভাবে পর্যবেক্ষণ করতে পারেন।
What’s the quickest way to verify DNS and browser behavior without guessing?
dig বা nslookup-এর মতো টুল ব্যবহার করে A/AAAA/CNAME/TXT উত্তরগুলি আপনার প্রত্যাশিত টার্গেটের সাথে মিল করছে কিনা তাও নিশ্চিত করুন, তারপর apex ও www উভয়ের জন্য http:// এবং https:// টেস্ট করুন। যদি এক নেটওয়ার্ক অন্যটির তুলনায় ভিন্ন DNS উত্তর দেখায়, সেটা ক্যাশিং; সব নেটওয়ার্কে ভুল উত্তর দেখা গেলে সেটা কনফিগারেশন ত্রুটি।
How should I troubleshoot a custom domain for a deployed app on Koder.ai?
Koder.ai-তে, অ্যাপের ডোমেন সেটআপ স্ক্রীনকে প্রত্যাশিত DNS টার্গেটের সূত্র হিসেবে বিবেচনা করুন, তারপর authoritative প্রদানকারীর কাছে ঠিক সেটাই মিলিয়ে দিন। DNS বদলানোর পরে সেটেল হওয়ার জন্য সময় দিন এবং SSL পুনঃপরীক্ষা করুন; লাইভ প্রোজেক্টে রাউটিং বদলালে স্ন্যাপশট/রোলব্যাক ব্যবহার করলে দ্রুত পূর্ববর্তী স্থিতিশীল অবস্থা ফিরে যাওয়া যায়।