Daftar pemeriksaan pemecahan masalah domain kustom untuk masalah DNS dan SSL

Apa arti “custom domain not working” biasanya

“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:

• Halaman “domain tidak ditemukan”
• Domain memuat situs yang salah
• Peringatan “tidak aman” meskipun HTTPS diaktifkan
• Loop redirect (memantul antara http dan https, atau antara root domain dan www)

Sebagian besar waktu, hanya satu hal yang salah:

• DNS mengarah ke tempat yang salah, atau catatan yang dibutuhkan hilang
• Target hosting tidak dikonfigurasi untuk hostname itu (server tidak mengenali domain Anda)
• SSL belum diterbitkan, diterbitkan untuk hostname berbeda, atau tidak bisa diterbitkan karena DNS tidak cocok
• Cache menyembunyikan perubahan Anda (cache browser, cache resolver DNS, atau nilai TTL lama)

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.

Konsep DNS kecil yang penting (tanpa istilah teknis berlebih)

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.

Jenis catatan DNS dengan bahasa sederhana

Berikut fungsi jenis catatan utama:

• A: menunjuk nama ke alamat IPv4 (seperti 203.0.113.10)
• AAAA: menunjuk nama ke alamat IPv6
• CNAME: menunjuk nama ke hostname lain (umum untuk www)
• TXT: menyimpan teks untuk verifikasi dan keamanan (pemeriksaan kepemilikan, SPF, dan sejenisnya)

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.

Langkah demi langkah: pohon keputusan sederhana untuk mengisolasi penyebab

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:

1. Apakah domain ter-resolve sama sekali? Jika Anda melihat NXDOMAIN (atau “domain not found”), catatan hilang, Anda sedang mengedit zona DNS yang salah, atau nameserver bukan seperti yang Anda kira.
2. Jika ter-resolve, apakah mengarah ke target yang benar? Jika halaman dimuat tetapi situsnya salah, halaman parkir, atau server lama, target A/AAAA/CNAME salah atau ada catatan sisa yang mengambil prioritas.
3. Jika mengarah benar, apakah kegagalannya hanya HTTPS? Jika HTTP berfungsi tetapi HTTPS menampilkan peringatan sertifikat, SSL mungkin masih diterbitkan, hostname pada sertifikat mungkin tidak cocok, atau platform menunggu DNS stabil.
4. Apakah berfungsi di satu perangkat atau jaringan tetapi tidak di lain? Perlakukan sebagai caching atau propagasi.
5. Apakah redirect gagal (www vs apex)? Jika 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.

Langkah 1: konfirmasi hostname dan target yang diharapkan

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:

• Salin catatan DNS saat ini untuk hostname yang Anda ubah
• Catat setiap A, AAAA, CNAME, dan TXT yang ada
• Catat TTL

Juga konfirmasi Anda mengedit zona DNS yang benar. Mudah untuk memperbarui domain yang salah, lingkungan yang salah, atau akun penyedia yang salah.

Langkah 2: pilih jenis catatan DNS yang tepat (A, AAAA, CNAME, TXT)

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:

• CNAME pada nama yang juga memiliki jenis catatan lain
• Beberapa A atau AAAA untuk nama yang sama padahal Anda bermaksud hanya satu
• Catatan lama yang tersisa untuk www atau root domain
• Catatan TXT dibuat di hostname yang salah

Langkah 3: verifikasi nameserver sehingga Anda mengedit di tempat yang benar

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.

Konfirmasi nameserver otoritatif

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:

• Jika host DNS Anda memberi nameserver seperti ns1... dan ns2..., nilai itu harus muncul tepat di registrar.
• Jika Anda baru saja mengganti penyedia DNS, konfirmasi perpindahan selesai sebelum melakukan pengeditan catatan lebih lanjut.
• Jika platform menunjukkan “saran catatan DNS,” itu biasanya panduan. Anda tetap perlu menambahkan catatan di penyedia DNS otoritatif.

Mengapa “saya sudah memperbarui, tapi tidak berubah” terjadi

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.

Langkah 4: pemeriksaan propagasi dan caching yang benar-benar membantu

“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:

• Uji di Wi-Fi rumah atau kantor, lalu di data seluler
• Minta seseorang di jaringan lain untuk mencoba
• Gunakan jendela pribadi/incognito (untuk mengesampingkan redirect yang di-cache)
• Restart perangkat atau flush cache DNS lokal jika Anda tahu caranya
• Periksa kembali hostname tepat (root vs www)

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.

Langkah 5: waktu SSL dan mengapa “tunggu sebentar” kadang benar

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:

1. Atur catatan DNS yang benar.
2. Tunggu sampai mereka resolve dengan benar dari beberapa lokasi.
3. Selesaikan verifikasi yang diperlukan (seringkali catatan TXT).
4. Biarkan penerbitan sertifikat selesai.

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”:

• Masih diterbitkan: HTTP mungkin berfungsi, tetapi HTTPS menampilkan sertifikat default sementara atau pesan “not valid yet” gaya sementara.
• Salah konfigurasi: Anda melihat situs yang berbeda, halaman parkir ISP, atau lookup DNS gagal (NXDOMAIN).

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.

Cara memverifikasi setiap langkah (tanpa menebak)

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.

Periksa jawaban DNS terhadap target yang diharapkan

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.

Periksa perilaku browser (HTTP, HTTPS, dan redirect)

Buka kedua http:// dan https:// untuk apex dan www. Anda menginginkan satu domain “utama” yang jelas dan satu redirect yang bersih.

• Pilih satu domain kanonis (apex atau www) dan redirect yang lainnya ke sana.
• Hindari loop redirect (A redirect ke B, lalu B redirect kembali ke A).
• Jika HTTP berfungsi tetapi HTTPS gagal, SSL sedang diterbitkan atau DNS masih mengarah ke tempat yang tak terduga.

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.

Kesalahan umum yang membuang waktu berjam-jam

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.

• Jangan ubah catatan setiap beberapa menit.
• Jangan campur target lama dan baru sekaligus.
• Tunggu cache stabil sebelum menilai hasil.

Perubahan kecil yang tenang lebih baik daripada pengutak-atik terus-menerus.

Contoh realistis: www berfungsi tapi root domain tidak

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:

• Nameserver salah atau tak terduga? Perbaiki itu dulu.
• Nameserver benar tapi example.com tidak punya catatan (atau mengarah ke tempat lain)? Perbaiki catatan apex.
• Catatan terlihat benar tetapi perilaku berbeda menurut perangkat atau jaringan? Tunggu propagasi dan bersihkan cache.
• DNS resolve dengan benar tetapi HTTPS gagal atau macet? SSL menunggu DNS yang konsisten.

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.

Daftar periksa cepat yang bisa Anda jalankan dalam 5 menit

Saat penyiapan domain gagal, sebagian besar perbaikan berasal dari beberapa pemeriksaan cepat. Jalankan ini sebelum mengubah hal lain.

• Konfirmasi Anda mengedit DNS di tempat yang benar (cocokkan dashboard Anda dengan nameserver otoritatif domain).
• Verifikasi hostname dan target tepat (tidak ada subdomain yang hilang, tidak ada titik ekstra). Bandingkan jenis catatan Anda (A, AAAA, CNAME, TXT) dengan yang diharapkan host.
• Hapus konflik (CNAME plus catatan lain pada nama yang sama, atau A/AAAA lama yang tidak diperlukan).
• Periksa dari dua sudut pandang (data seluler dan Wi‑Fi). Jika satu berhasil dan yang lain tidak, biasanya caching atau propagasi.
• Hormati TTL. Jika TTL 300 detik, tunggu 5–10 menit sebelum menilai. Jika TTL 3600, harapkan mendekati satu jam.

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.

Langkah selanjutnya: buat penyiapan domain dapat diulang untuk setiap peluncuran

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.

Template catatan penyiapan domain sederhana

Simpan di dokumen proyek Anda dan isi sebelum menyentuh DNS:

• Domain dan hostname (root, www, dan subdomain apa pun)
• Jenis catatan dan target yang diharapkan (A, CNAME, TXT) dan sumbernya
• Tempat DNS diedit (penyedia mana) dan nameserver aktif
• Ekspektasi SSL (siapa penerbitnya, seperti apa tanda "siap")
• Langkah verifikasi yang akan Anda jalankan (alat dan hasil yang diharapkan)

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.

Kapan harus mengeskalasi (dan kepada siapa)

Jika Anda sudah mengonfirmasi DNS benar dan masih melihat kegagalan, berhenti menebak dan eskalasikan dengan bukti:

• Registrar menunjukkan nameserver terkunci atau Anda tidak bisa mengubahnya
• Edit DNS tidak muncul di mana pun setelah jendela TTL yang diharapkan
• SSL terus gagal lama setelah DNS resolve dengan benar (pikirkan jam, bukan menit)
• Anda melihat catatan yang bertentangan yang tidak bisa dihapus (bug UI penyedia atau split DNS)

Saat mengeskalasi, sertakan hostname, catatan yang diharapkan, hasil resolver saat ini, dan cap waktu. Ini mengubah bolak-balik lambat menjadi perbaikan cepat.