Website Mendadak Error Setelah Ganti Server? Periksa DNS, TTL, dan Proxy Sebelum Panik

Salah satu situasi yang paling membingungkan saat mengelola website adalah ketika sebagian orang sudah melihat versi baru, sementara sebagian lainnya masih diarahkan ke server lama. Ada juga kasus website bisa dibuka tanpa www, tetapi gagal ketika memakai www. Email domain ikut berhenti masuk, atau Cloudflare menampilkan error meski server sebenarnya masih aktif.

Masalah seperti ini sering kali bukan semata-mata kesalahan hosting. Penyebabnya bisa berada di lapisan DNS, yaitu sistem yang menerjemahkan nama domain menjadi alamat IP atau tujuan layanan. Memahami bagian ini penting setiap kali Anda pindah server, mengganti alamat IP, menambahkan subdomain, atau mengaktifkan Cloudflare.

DNS bukan sekadar “alamat website”

Bayangkan domain sebagai nama sebuah gedung, sedangkan DNS adalah petugas yang memberi tahu pengunjung gedung itu berada di alamat mana. Jika alamatnya berubah, petugas dan buku petunjuk di berbagai tempat perlu diperbarui. Tidak semua orang menerima pembaruan pada waktu yang sama karena informasi DNS dapat disimpan sementara oleh resolver dan perangkat.

Beberapa jenis record yang umum digunakan adalah:

• A record: mengarahkan nama domain ke alamat IPv4 server.
• AAAA record: mengarahkan domain ke alamat IPv6.
• CNAME: membuat nama host mengarah ke nama host lain.
• MX: menentukan server yang menerima email untuk domain.
• TXT: menyimpan informasi verifikasi atau kebijakan, misalnya SPF dan verifikasi layanan.

Untuk website, perubahan biasanya melibatkan record A, AAAA, atau CNAME. Namun, mengganti record website tanpa memeriksa MX dan TXT dapat membuat email atau verifikasi layanan ikut bermasalah.

TTL menjelaskan mengapa perubahan tidak langsung terasa

TTL, atau Time to Live, adalah lama sebuah record boleh disimpan oleh resolver DNS sebelum perlu mengambil informasi baru. TTL yang lebih panjang dapat mengurangi frekuensi pencarian DNS, tetapi membuat perubahan membutuhkan waktu lebih lama untuk terlihat. Cloudflare juga mengingatkan bahwa cache lokal dapat membuat perubahan record terasa lebih lama dari perkiraan. ([developers.cloudflare.com](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/?utm_source=openai))

Misalnya, Anda mengganti IP server dari 203.0.113.10 menjadi 203.0.113.20. Resolver yang masih menyimpan alamat lama mungkin tetap mengarahkan sebagian pengunjung ke server sebelumnya sampai masa TTL berakhir. Karena itu, istilah “propagasi DNS” bukan berarti semua server internet menerima pembaruan dalam satu detik.

Jika perubahan server sudah direncanakan, turunkan TTL beberapa jam atau sehari sebelumnya. Setelah perpindahan selesai dan hasilnya stabil, TTL dapat dinaikkan lagi. Langkah ini bukan jaminan perubahan akan seketika, tetapi membantu mengurangi waktu cache lama bertahan.

Periksa apakah masalah ada di DNS atau server

Jangan langsung menghapus dan membuat ulang semua record. Mulailah dengan pertanyaan sederhana: domain saat ini menunjuk ke mana?

1. Cek record A dan AAAA untuk domain utama serta www.
2. Bandingkan IP yang muncul dengan informasi dari provider hosting.
3. Periksa apakah ada record lama yang masih aktif.
4. Pastikan nameserver domain mengarah ke penyedia DNS yang benar.
5. Uji dari jaringan berbeda, misalnya Wi-Fi rumah dan jaringan seluler.

Di komputer, Anda dapat memakai perintah berikut:

dig example.com A
dig www.example.com A
dig example.com MX

Perintah tersebut membantu melihat jawaban DNS yang diterima resolver. Untuk pemeriksaan yang lebih sederhana, Anda juga dapat menggunakan layanan pengecekan DNS publik. Yang perlu dicari bukan hanya apakah record tersedia, tetapi apakah nilainya sesuai dengan server yang seharusnya.

Cloudflare: bedakan DNS only dan Proxied

Cloudflare dapat berfungsi sebagai pengelola DNS sekaligus reverse proxy. Ketika sebuah record berstatus Proxied, permintaan pengunjung melewati jaringan Cloudflare sebelum diteruskan ke server asal. Ketika berstatus DNS only, DNS hanya mengembalikan alamat tujuan dan koneksi berjalan langsung ke server tersebut. Pada record A, AAAA, dan CNAME, pilihan proxy menentukan bagaimana lalu lintas diproses. ([developers.cloudflare.com](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/?utm_source=openai))

Proxy cocok untuk trafik web yang memang dapat dilayani melalui HTTP atau HTTPS. Namun, jangan asal mengaktifkannya untuk layanan email. Record mail seperti mail.example.com umumnya perlu berstatus DNS only agar koneksi email tidak diarahkan ke proxy web. Cloudflare juga menjelaskan bahwa konfigurasi email memerlukan record seperti MX dan record alamat untuk server email sesuai instruksi provider. ([developers.cloudflare.com](https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/?utm_source=openai))

Jika website menampilkan error 521, 522, atau 525 setelah proxy diaktifkan, penyebabnya bisa berada pada koneksi Cloudflare ke origin, port yang tidak terbuka, firewall server, atau sertifikat TLS di server asal. Dalam kondisi seperti ini, mengubah proxy ke DNS only untuk pengujian dapat membantu mempersempit sumber masalah. Setelah diagnosis selesai, kembalikan pengaturan sesuai kebutuhan keamanan.

Jangan lupa sertifikat SSL

DNS yang benar belum tentu membuat HTTPS langsung berfungsi. Server baru juga harus memiliki sertifikat yang mencakup nama domain yang digunakan, termasuk kemungkinan www.example.com atau subdomain tertentu.

Jika sertifikat dikelola otomatis melalui ACME, pastikan proses validasi domain masih bisa dilakukan. Let’s Encrypt menggunakan ACME untuk memverifikasi kendali atas domain sebelum menerbitkan sertifikat. Mereka juga merekomendasikan otomatisasi renewal karena alur manual meningkatkan risiko sertifikat kedaluwarsa. ([letsencrypt.org](https://letsencrypt.org/docs/client-options/?utm_source=openai))

Jangan terlalu sering menghapus konfigurasi klien ACME lalu meminta sertifikat baru hanya untuk mencoba-coba. Let’s Encrypt menerapkan batas penerbitan sertifikat, termasuk batas untuk kombinasi nama domain yang sama. Untuk pengujian, gunakan staging environment jika tersedia. ([letsencrypt.org](https://letsencrypt.org/docs/rate-limits/?utm_source=openai))

Yang bisa dilakukan sekarang

• Simpan daftar semua record DNS sebelum melakukan perubahan.
• Catat IP server lama dan server baru, termasuk waktu perubahan.
• Turunkan TTL sebelum migrasi yang sudah direncanakan.
• Periksa record A, AAAA, CNAME, MX, dan TXT.
• Uji domain utama, www, subdomain, email, dan HTTPS secara terpisah.
• Pastikan firewall server mengizinkan port 80 dan 443 jika website menggunakan HTTP/HTTPS.
• Jangan menghapus record lama sebelum yakin tidak ada layanan penting yang masih bergantung padanya.
• Tambahkan komentar atau dokumentasi internal untuk menjelaskan fungsi setiap record.

Apa artinya bagi kita?

DNS adalah bagian kecil dari infrastruktur website, tetapi kesalahan di dalamnya bisa terlihat seperti masalah hosting, Cloudflare, SSL, bahkan aplikasi. Karena itu, cara troubleshooting yang baik bukan langsung mengganti provider atau mengulang deployment, melainkan memeriksa jalur permintaan dari awal: domain mengarah ke mana, apakah cache masih menyimpan alamat lama, apakah proxy aktif, lalu apakah server dan sertifikat siap menerima koneksi.

Dengan urutan tersebut, Anda tidak hanya menghemat waktu ketika website error. Anda juga mengurangi risiko email terputus, sertifikat gagal diperbarui, atau pengunjung diarahkan ke server yang sudah tidak digunakan.

Sumber & bacaan lebih lanjut

• Cloudflare DNS: Time to Live (TTL)
• Cloudflare DNS: Manage DNS records
• Cloudflare DNS: DNS record types
• Cloudflare DNS: Set up email records
• Let's Encrypt: ACME client implementations
• Let's Encrypt: Rate limits

– Rio Yotto @rioyotto