Baca status, header, redirect chain, dan error koneksi dengan curl agar Anda tahu apakah masalah berada pada HTTP, TLS, DNS, atau aplikasi.
Dipublikasikan 8 September 2026
Tujuan latihan
Mengumpulkan bukti HTTP dari terminal dan membedakan respons sukses, redirect, error server, serta kegagalan koneksi tanpa mengubah konfigurasi.
Persiapan
Terminal Linux atau macOS dengan curl. Pada Windows PowerShell gunakan curl.exe. Contoh merupakan panduan latihan dan bukan hasil pengujian produksi.
Request URL→
DNS / TLS / HTTP→
Status + header + tujuan
Masalah
Browser sering menyederhanakan apa yang terjadi di belakang layar. Sebuah URL dapat mengalami redirect, menerima error HTTP, atau gagal bahkan sebelum HTTP terjadi. Dengan curl, Anda dapat melihat lapisan mana yang benar-benar memberi respons sebelum menyimpulkan penyebab masalah.
1. Ambil header tanpa mengikuti redirect
Mulai dengan HEAD agar status dan response header terlihat tanpa mengambil seluruh body. Perhatikan baris HTTP status, Location, Content-Type, Server, dan header diagnostik lain yang relevan. Jika server memperlakukan HEAD berbeda dari GET, validasi lagi dengan GET pada langkah berikutnya.
Status 2xx menunjukkan request diproses pada level HTTP, 3xx menunjukkan pengalihan, 4xx menunjukkan request ditolak/tidak ditemukan dari sisi client atau policy, dan 5xx menunjukkan kegagalan pada server/edge. Status HTTP bukan bukti aplikasi sehat: 200 dapat berisi halaman error aplikasi, sedangkan 403 dapat memang merupakan hasil policy yang diharapkan.
3. Ikuti redirect chain secara terkontrol
Gunakan -L untuk mengikuti redirect dan batasi jumlahnya dengan --max-redirs. Catat setiap status serta Location. Redirect yang berulang antara dua URL mengarah ke kemungkinan loop konfigurasi; redirect satu kali dari HTTP ke HTTPS biasanya normal.
Jika HEAD memberi hasil yang meragukan, gunakan GET. -D - menampilkan response header sedangkan -o menyimpan body. Buka file hasil untuk memastikan konten sesuai URL yang dimaksud, bukan sekadar melihat status 200.
Jika curl menampilkan status seperti 404 atau 500, koneksi sudah mencapai pihak yang mengirim respons HTTP. Sebaliknya, pesan seperti Could not resolve host, Connection timed out, connection refused, atau certificate verify failed terjadi sebelum aplikasi memberi status HTTP. Arah troubleshooting harus mengikuti lapisan yang gagal.
Kesalahan umum
Jangan langsung memakai -k/--insecure saat ada error TLS karena itu menyembunyikan validasi sertifikat yang justru perlu diperiksa. Jangan menganggap -I selalu identik dengan GET, jangan membaca hanya status terakhir ketika ada redirect, dan jangan menganggap 200 otomatis berarti halaman yang benar.
Checklist verifikasi
Catat URL awal, status tiap hop, Location, URL akhir, Content-Type, pesan error curl, dan apakah GET menghasilkan konten yang diharapkan. Jika hasil berbeda antarjaringan, simpan waktu pengujian dan resolver/jaringan yang digunakan agar perbandingan memiliki konteks.
Pelajaran
curl berguna bukan hanya untuk melihat apakah website hidup, tetapi untuk memisahkan kegagalan DNS, TCP/TLS, redirect, dan HTTP. Mulai dari bukti yang paling sederhana, lalu lanjutkan ke lapisan berikutnya hanya jika lapisan sebelumnya sudah terkonfirmasi.