Gunakan daftar pemeriksaan pemecahan masalah domain kustom ini untuk mendiagnosis masalah catatan DNS, penundaan propagasi, dan waktu penerbitan SSL, dengan langkah verifikasi yang sederhana.
“Custom domain not working” adalah istilah umum untuk beberapa kegagalan berbeda. Browser Anda menampilkan gejala, bukan penyebabnya. Sebelum mengubah apa pun, sebutkan terlebih dahulu apa yang sebenarnya Anda lihat.
Gejala umum meliputi:
Sebagian besar waktu, hanya satu hal yang salah:
Sebelum memecahkan masalah, pastikan Anda punya akses ke dua tempat: tempat Anda mengedit catatan DNS (registrar atau penyedia DNS) dan tempat Anda menautkan domain di sisi hosting. Misalnya, jika Anda menghubungkan aplikasi yang dideploy di Koder.ai ke domain kustom, Anda memerlukan akses DNS untuk domain itu dan pengaturan domain di layar hosting atau deployment aplikasi.
Beberapa perbaikan instan (seperti memperbaiki kesalahan ketik). Yang lain butuh waktu. Perubahan DNS bisa memakan waktu untuk muncul, dan SSL biasanya tidak akan selesai sampai DNS mengarah dengan benar dan domain dapat dijangkau. Tujuannya adalah berhenti menebak dan mengonfirmasi setiap lapisan secara berurutan.
Sebagian besar masalah domain berasal dari ketidakcocokan antara (1) hostname yang Anda uji, (2) tempat DNS dikelola, dan (3) apa yang sebenarnya ditunjuk oleh catatan. Setelah ketiganya selaras, SSL biasanya langkah terakhir.
Domain memiliki dua bentuk umum: root domain (example.com, juga disebut apex) dan subdomain (www.example.com, app.example.com). Mereka terkait, tetapi dapat memiliki catatan DNS yang berbeda. Jadi wajar jika www berfungsi sementara apex gagal, atau sebaliknya.
Nameserver menentukan siapa yang mengendalikan zona DNS Anda. Jika Anda membeli domain dari satu perusahaan tetapi nameserver mengarah ke yang lain, Anda harus mengedit DNS di tempat nameserver menunjuk. Banyak situasi “sudah saya perbarui tapi tidak berubah” terjadi karena catatan diedit di dashboard yang salah.
Berikut fungsi jenis catatan utama:
TTL adalah pengaturan “berapa lama disimpan di cache”. TTL rendah berarti cache menyegarkan lebih cepat. TTL tinggi berarti Anda mungkin harus menunggu lebih lama, bahkan setelah Anda memperbaiki catatan. Melihat nilai lama untuk sementara waktu bisa normal.
Saat domain kustom gagal, Anda biasanya bisa mengelompokkannya menjadi salah satu dari empat kategori: DNS tidak resolve, DNS resolve ke tempat yang salah, SSL belum siap, atau hanya gagal untuk beberapa orang karena caching.
Gunakan pohon keputusan ini:
www berfungsi tetapi root domain tidak (atau sebaliknya), kemungkinan Anda hanya mengonfigurasi satu hostname, atau ada aturan redirect yang bertentangan.Bekerjalah lebih cepat dengan menuliskan hostname tepat yang gagal (apex vs www) dan pesan kesalahan yang tepat. Pada platform hosting yang mengotomatiskan domain dan sertifikat, perbedaan antara “cannot find host” dan “certificate pending” memberitahu Anda apakah harus memperbaiki catatan DNS atau cukup menunggu SSL setelah DNS terlihat.
Banyak kegagalan domain dimulai dengan ketidakcocokan sederhana: Anda menyiapkan DNS untuk satu hostname, tetapi menguji hostname lain.
Pertama, tuliskan hostname tepat yang ingin Anda aktifkan. Root domain terlihat seperti example.com. Subdomain terlihat seperti www.example.com atau app.example.com. Ini adalah entri DNS terpisah, jadi “www berfungsi” tidak berarti root domain juga akan berfungsi.
Selanjutnya, temukan target yang diharapkan dari platform hosting Anda. Beberapa platform memberikan alamat IP (untuk A atau AAAA). Lainnya memberikan hostname target (untuk CNAME). Jika host Anda memberi nilai di layar pengaturan domain, anggap itu sebagai sumber kebenaran.
Sebelum mengubah apa pun, catat apa yang saat ini disetel. Sederhanakan:
Juga konfirmasi Anda mengedit zona DNS yang benar. Mudah untuk memperbarui domain yang salah, lingkungan yang salah, atau akun penyedia yang salah.
Banyak masalah hanyalah jenis catatan yang salah untuk hostname yang ingin Anda sambungkan. Mulailah dengan memisahkan dua kasus: root domain (example.com) dan subdomain (www.example.com). Mereka berperilaku berbeda di banyak penyedia DNS.
A record menunjuk nama ke alamat IPv4. Banyak pengaturan menggunakan A record untuk root domain karena beberapa penyedia tidak mengizinkan CNAME di apex. Jika host Anda memberi IP, A record biasanya benar.
AAAA adalah versi IPv6. Catatan AAAA yang tersisa yang mengarah ke tujuan lama dapat menyebabkan perilaku membingungkan “bekerja untukku”, karena beberapa pengunjung akan menggunakan IPv6 sementara yang lain menggunakan IPv4. Jika host Anda tidak memberi target IPv6, menghapus AAAA yang salah sering memperbaiki kegagalan yang tidak konsisten.
CNAME menunjuk subdomain ke hostname lain (sering digunakan untuk www). Ini berguna ketika host ingin Anda menargetkan endpoint bernama yang dapat berubah di belakang layar.
TXT untuk verifikasi dan tantangan (termasuk beberapa pemeriksaan SSL). Kesalahan umum termasuk meletakkan TXT pada nama yang salah (root vs _acme-challenge vs subdomain), menambahkan spasi ekstra, atau menempelkan nilai yang salah.
Sebelum melanjutkan, cari konflik. Ini yang paling sering menyebabkan masalah:
Banyak kasus “custom domain not working” bukan soal nilai catatan sama sekali. Mereka terjadi karena catatan ditambahkan di penyedia yang salah. Jika domain Anda menggunakan nameserver Penyedia A, mengubah catatan di dasbor Penyedia B tidak akan berpengaruh, bahkan jika catatan terlihat benar di sana.
Periksa nameserver yang sebenarnya digunakan domain Anda. Anda biasanya dapat melihat ini di pengaturan domain registrar di bagian “Nameservers”. Untuk second opinion, tanyakan DNS langsung dari komputer Anda:
dig NS example.com
Nameserver yang dikembalikan oleh perintah itu adalah yang otoritatif.
Pemeriksaan cepat:
ns1... dan ns2..., nilai itu harus muncul tepat di registrar.Jika Anda memperbarui catatan di penyedia yang salah, Anda sering melihat dua dashboard yang tidak cocok. Hanya nameserver otoritatif yang penting.
Juga waspadai penundaan setelah mengubah nameserver di registrar. Selama jendela transisi, hasil bisa terlihat tidak konsisten tergantung dari mana Anda menguji. Jika nameserver masih berubah, jeda pengeditan catatan sampai set nameserver stabil, lalu lanjutkan.
“Propagasi” bukan satu saklar. Ini rantai cache DNS (ISP, operator seluler, resolver publik, dan perangkat Anda sendiri) yang memperbarui dengan kecepatan berbeda. Itu sebabnya domain Anda bisa berfungsi untuk rekan kerja tetapi gagal untuk Anda.
TTL (time to live) memberi tahu cache berapa lama mereka boleh menyimpan jawaban. Jika TTL lama adalah 1 jam, beberapa orang akan terus melihat nilai lama selama hampir satu jam. Menurunkan TTL hanya membantu jika Anda melakukannya sebelum melakukan perubahan.
Untuk membedakan penundaan caching dari kesalahan nyata, lakukan beberapa pemeriksaan cepat:
Jika catatan salah di mana pun yang Anda periksa (IP salah, tidak ada www, CNAME lama), perbaiki. Jika catatan terlihat benar di sebagian besar tempat tetapi satu jaringan masih menunjukkan nilai lama, biasanya itu penundaan cache.
Sertifikat SSL biasanya gagal karena satu alasan dasar: penyedia sertifikat tidak dapat memvalidasi domain sampai DNS mengarah ke tempat yang benar secara konsisten.
Urutan normalnya sederhana:
Pemblokir umum mudah terlewat. A atau CNAME yang salah mengirim pemeriksaan validasi ke server yang salah. Catatan AAAA yang kadaluwarsa dapat menimpa A record yang berfungsi untuk beberapa pengunjung, sehingga HTTPS gagal hanya untuk mereka. Tidak adanya TXT yang diperlukan dapat mencegah platform menerbitkan sertifikat.
Gunakan gejala untuk membedakan “masih diterbitkan” dari “salah konfigurasi”:
Sambil menunggu, jangan terus menerus mengubah catatan. Setiap perubahan mengatur ulang jam dan dapat menciptakan dunia terpecah di mana jaringan berbeda melihat jawaban berbeda. Tetapkan catatan yang benar sekali, lalu periksa kembali resolusi dan verifikasi sampai sertifikat diterbitkan.
Jika Anda menggunakan platform seperti Koder.ai, alur teraman sama: konfirmasi DNS mengarah ke target yang diharapkan, hapus AAAA yang salah jika ada, dan beri waktu untuk SSL setelah DNS stabil.
Pemecahan masalah yang baik sebagian besar adalah perbandingan: apa yang Anda lihat versus apa yang Anda harapkan. Jangan mengandalkan “di ponsel saya muncul”. Gunakan pemeriksaan yang dapat diulang.
Gunakan alat lookup DNS (seperti nslookup atau dig) dan pastikan nilai yang dikembalikan cocok dengan yang Anda inginkan (IP untuk A atau AAAA, hostname untuk CNAME, token untuk TXT).
# Apex (root) domain
dig example.com A
dig example.com AAAA
# www subdomain
dig www.example.com CNAME
# TXT (sering digunakan untuk verifikasi)
dig example.com TXT
Periksa kedua nama yang mungkin Anda gunakan: apex (example.com) dan www (www.example.com). Seringkali satu benar sementara yang lain masih mengarah ke tempat lama.
Buka kedua http:// dan https:// untuk apex dan www. Anda menginginkan satu domain “utama” yang jelas dan satu redirect yang bersih.
www) dan redirect yang lainnya ke sana.Jika hasil berbeda berdasarkan jaringan, kemungkinan Anda melihat caching atau propagasi. Simpan catatan kecil: apa yang Anda ubah, di mana Anda mengubahnya, waktu, dan apa yang Anda amati.
Kebanyakan masalah DNS dan SSL bukanlah misteri. Mereka kesalahan kecil yang membuat Anda terus memeriksa hal yang salah, atau mengubah sesuatu terlalu cepat sehingga sulit mendapatkan pembacaan yang jelas.
Waktu paling banyak terbuang adalah mengedit DNS di dua tempat. Ini sering terjadi setelah mengganti nameserver: Anda memperbarui catatan di registrar, tetapi DNS sebenarnya dihosting di tempat lain (atau sebaliknya). Semua terlihat benar di satu dashboard, namun publik tidak melihat perubahan.
Kesalahan klasik lain adalah mencoba menaruh CNAME di root domain pada penyedia yang tidak mendukungnya. Anda mungkin perlu A record, atau catatan ALIAS/ANAME jika penyedia DNS Anda menyediakannya.
IPv6 juga dapat menyebabkan masalah. Meninggalkan AAAA lama dapat mengirim beberapa pengunjung ke server yang salah sementara pengunjung lain mengenai IPv4 dengan benar.
Berhati-hatilah dengan catatan “biar saja” yang tidak diperlukan. Beberapa A record dapat berperilaku seperti load balancing tidak sengaja jika satu target salah, terutama saat menunjuk domain kustom ke aplikasi yang dihosting.
Satu aturan terakhir: berhenti mereset jam.
Perubahan kecil yang tenang lebih baik daripada pengutak-atik terus-menerus.
Anda meluncurkan aplikasi baru dan menyiapkan example.com dan www.example.com. Beberapa menit kemudian, www.example.com terbuka dengan baik, tetapi root domain menunjukkan kesalahan DNS, memuat situs lama, atau HTTPS tetap menunggu. Pola ini umum dan biasanya penyebabnya kecil.
Mulailah dengan pertanyaan membosankan: apakah Anda mengedit DNS di tempat yang benar? Jika domain Anda terdaftar di satu perusahaan tetapi DNS dihosting di perusahaan lain, Anda bisa mengubah catatan sepanjang hari dan tidak terjadi apa-apa. Periksa nameserver terlebih dahulu, lalu buka panel DNS untuk penyedia yang ditunjuk nameserver itu.
Selanjutnya, bandingkan dua hostname. www biasanya CNAME. Root domain lebih rumit: banyak penyedia tidak mengizinkan CNAME di apex, jadi sering diperlukan A record ke IP, atau catatan ALIAS/ANAME jika didukung.
Jalur keputusan yang bekerja dalam praktik:
example.com tidak punya catatan (atau mengarah ke tempat lain)? Perbaiki catatan apex.Status akhir yang benar itu membosankan: baik example.com maupun www.example.com mengarah ke aplikasi yang sama, satu menjadi kanonis (yang lain redirect), dan HTTPS valid.
Saat penyiapan domain gagal, sebagian besar perbaikan berasal dari beberapa pemeriksaan cepat. Jalankan ini sebelum mengubah hal lain.
Setelah DNS benar jelas, periksa SSL. Banyak platform hanya menerbitkan sertifikat setelah mereka bisa resolve domain Anda ke target yang diharapkan secara konsisten. Jika Anda cek terlalu awal, Anda bisa mengira penundaan normal sebagai kesalahan nyata.
Jika Anda menambahkan domain kustom ke aplikasi yang dideploy di Koder.ai, anggap layar pengaturan domain aplikasi sebagai referensi untuk target DNS yang diharapkan, lalu periksa status hanya setelah DNS punya waktu untuk menyebar.
Cara tercepat untuk menghindari mengulang kesalahan DNS dan SSL adalah menyimpan "catatan penyiapan domain" singkat untuk setiap proyek. Ini runbook yang dapat digunakan ulang yang bisa Anda salin saat peluncuran berikutnya.
Simpan di dokumen proyek Anda dan isi sebelum menyentuh DNS:
Selama peluncuran, tunjuk satu orang sebagai pemilik DNS. DNS paling sering rusak ketika dua orang "memperbaiki" hal berbeda pada saat yang sama (misalnya satu mengganti nameserver sementara yang lain mengedit catatan).
Di sisi hosting, rencanakan pembalikan aman. Jika platform Anda mendukung snapshot atau rollback, ambil snapshot sebelum mengubah routing sehingga Anda dapat kembali ke keadaan terakhir yang baik dengan cepat. Jika Anda membangun di Koder.ai, Anda dapat menggunakan Planning Mode untuk menulis langkah domain yang akan Anda ambil, menerapkannya secara berurutan, dan rollback jika perubahan merusak produksi.
Jika Anda sudah mengonfirmasi DNS benar dan masih melihat kegagalan, berhenti menebak dan eskalasikan dengan bukti:
Saat mengeskalasi, sertakan hostname, catatan yang diharapkan, hasil resolver saat ini, dan cap waktu. Ini mengubah bolak-balik lambat menjadi perbaikan cepat.
Biasanya berarti salah satu lapisan rantai salah: DNS tidak ter-resolve, DNS ter-resolve ke target yang salah, server/hosting tidak mengenali hostname Anda, atau HTTPS/SSL belum selesai diterbitkan. Mulailah dengan menuliskan pesan kesalahan yang tepat yang Anda lihat dan hostname yang Anda ketik (apex vs www).
Karena example.com (apex) dan www.example.com adalah hostname terpisah dengan catatan DNS terpisah. Umumnya www menggunakan CNAME yang benar sementara apex tidak punya A record, punya A record yang salah, atau konfigurasi yang tidak didukung di penyedia DNS Anda.
Periksa nameserver domain di registrar Anda dan bandingkan dengan penyedia DNS yang sedang Anda edit. Hanya penyedia yang tercantum di nameserver aktif yang bersifat otoritatif; mengubah catatan di tempat lain tidak akan mengubah apa yang dilihat publik.
Gunakan A jika host memberi Anda alamat IPv4, AAAA hanya jika host memberi Anda alamat IPv6, dan CNAME ketika host memberi Anda hostname lain (paling umum untuk www). TXT untuk verifikasi dan tantangan, dan harus dibuat pada nama persis yang ditentukan host Anda.
Catatan AAAA yang kadaluwarsa atau salah bisa mengarahkan beberapa pengunjung lewat IPv6 ke server lama sementara pengunjung lain ke alamat IPv4 yang benar, menciptakan kebingungan “bekerja untuk saya”. Jika host Anda tidak memberi target IPv6, menghapus AAAA yang salah sering menyelesaikan masalah.
Seringkali karena Anda hanya mengonfigurasi satu hostname pada sisi hosting (hanya apex atau hanya www), atau ada aturan redirect yang saling bertentangan sehingga memantulkan antara HTTP dan HTTPS atau antara apex dan www. Pilih satu hostname kanonis, konfigurasikan kedua hostname, dan pastikan hanya ada satu jalur redirect yang jelas.
Ya. Menunggu adalah langkah yang tepat setelah DNS jelas mengarah ke target yang benar dari berbagai lokasi. Penerbitan SSL biasanya tidak akan selesai sampai domain ter-resolve secara konsisten ke tujuan yang diharapkan; bolak-balik mengubah DNS hanya akan mengulang proses.
TTL adalah berapa lama resolver menyimpan jawaban, jadi meskipun Anda sudah memperbaiki catatan, beberapa jaringan mungkin tetap menyajikan nilai lama sampai jendela TTL berakhir. Uji dari dua jaringan berbeda (misalnya Wi‑Fi dan data seluler) dan hindari melakukan perubahan DNS setiap beberapa menit agar Anda dapat mengamati propagasi dengan bersih.
Gunakan pemeriksaan berulang seperti dig atau nslookup untuk memastikan jawaban A/AAAA/CNAME/TXT sesuai target yang Anda harapkan, lalu uji http:// dan https:// untuk baik apex dan www. Jika satu jaringan menunjukkan jawaban DNS berbeda dari jaringan lain, anggap itu caching; jika semua jaringan menunjukkan jawaban yang salah, anggap itu kesalahan konfigurasi.
Di Koder.ai, anggap layar pengaturan domain aplikasi sebagai sumber kebenaran untuk target DNS yang diharapkan, lalu samakan DNS dengan itu secara tepat di penyedia otoritatif. Setelah mengubah DNS, beri waktu agar stabil sebelum memeriksa SSL lagi, dan gunakan snapshot/rollback jika Anda menyesuaikan routing pada proyek langsung sehingga Anda bisa kembali ke keadaan yang sudah terbukti cepat.