Melacak Sumber Redirect Loop HTTPS Lewat Header Respons curl

Pernahkah kamu baru saja memasang SSL di website atau mengaktifkan CDN, lalu browser langsung menolak menampilkan halaman dan melempar pesan ERR_TOO_MANY_REDIRECTS? Masalah ini sangat umum terjadi ketika kita menambahkan lapisan reverse proxy atau CDN di depan server origin. Di meja dukungan teknis hosting, tiket dengan keluhan ini biasanya memakan waktu lama jika diselesaikan dengan coba-coba mengubah pengaturan secara acak. Browser membatasi jumlah pengalihan alamat (redirect) berturut-turut untuk mencegah infinite loop yang menghabiskan memori dan koneksi jaringan. Ketika browser melihat permintaan diputar-putar tanpa henti, biasanya setelah belasan hingga puluhan lompatan, proses koneksi langsung dihentikan. Masalahnya, pesan error di browser tidak memberi tahu kita siapa yang mengalihkan ke siapa. Untuk melihat apa yang sebenarnya terjadi di balik layar, alat paling bersih dan cepat yang bisa kita pakai adalah curl langsung dari terminal.

Membaca rantai redirect dengan satu perintah curl

Langkah pertama yang paling efektif bukan membuka dashboard CDN atau membongkar file konfigurasi, melainkan melihat rantai status HTTP dan header Location secara berurutan. Parameter -I memberi tahu curl untuk hanya meminta header (HEAD request), sedangkan -L menginstruksikan curl untuk mengikuti setiap pengalihan sampai selesai. Berikut contoh perintah yang bisa kamu jalankan dari terminal:

BASH

curl -IL https://contohdomain.com

Jika website sedang mengalami redirect loop, curl akan menampilkan daftar respons HTTP yang panjang dan akhirnya berhenti saat mencapai batas maksimum pengalihan (biasanya 50 kali pengalihan). Setiap blok respons memiliki dua baris penting yang harus kita perhatikan: kode status HTTP di baris pertama dan header Location: beberapa baris di bawahnya. Kode status HTTP pengalihan biasanya berupa 301 Moved Permanently atau 302 Found. Header Location menunjukkan alamat tujuan ke mana permintaan tersebut dilempar. Dengan membaca rantai ini dari atas ke bawah, kita bisa langsung melihat pola lompatannya: apakah website melempar bolak-balik antara protokol HTTP dan HTTPS, ataukah melempar bolak-balik antara versi www dan non-www.

Membedakan server mana yang melempar redirect

Ketika sebuah website berada di balik CDN atau reverse proxy, ada dua pihak yang berpotensi mengeluarkan respons HTTP 301 atau 302: proxy di lapisan depan (edge) atau web server di server origin (misalnya Apache, Nginx, atau LiteSpeed). Mengetahui siapa yang melempar redirect adalah kunci utama agar kita tidak salah sasaran saat memperbaiki konfigurasi. Perhatikan header Server pada setiap blok respons curl. Jika blok respons pertama menampilkan header Server: cloudflare (atau nama vendor CDN lain) dan mengalihkan trafik dari http:// ke https://, itu berarti lapisan edge yang menjalankan aturan redirect tersebut. Namun, jika blok respons berikutnya menampilkan header server origin kita, misalnya Server: nginx atau Server: Apache, dan melempar balik ke http://, berarti server origin yang bertanggung jawab atas pengalihan kedua. Untuk memastikan bagaimana respons server origin secara independen tanpa campur tangan CDN, kita bisa meminta curl melewati edge dan langsung menghubungi IP server asli. Kita bisa memanfaatkan parameter --resolve pada curl agar nama domain diarahkan langsung ke alamat IP origin tanpa perlu mengubah DNS publik atau file /etc/hosts di komputer lokal:

BASH

curl -IL https://contohdomain.com --resolve contohdomain.com:443:203.0.113.10

Catatan: IP 203.0.113.10 di atas adalah contoh ilustratif. Ganti dengan alamat IP asli server origin kamu. Jika curl langsung ke IP origin menghasilkan respons 200 OK, berarti web server origin kamu sebenarnya sudah siap melayani HTTPS dengan baik, dan konflik murni terjadi karena perbedaan persepsi protokol antara CDN dan origin.

Akar masalah klasik: SSL termination dan kesalahpahaman protokol

Pola paling sering yang menyebabkan loop adalah ketidakcocokan mode enkripsi antara proxy dan origin. Situasi ini biasanya berjalan seperti ini:

Pengunjung meminta URL https://contohdomain.com melalui browser.
Lapisan proxy atau CDN menerima koneksi HTTPS tersebut dengan sukses. Ini disebut SSL termination, di mana enkripsi dibuka di lapisan proxy.
Proxy kemudian meneruskan permintaan tersebut ke server origin di belakangnya. Namun, proxy menghubungi server origin menggunakan koneksi biasa (http:// port 80), bukan https:// port 443.
Server origin menerima permintaan di port 80. Aplikasi web (seperti WordPress) atau konfigurasi web server melihat koneksi masuk sebagai HTTP polos. Karena server origin dipasangi aturan untuk selalu memaksa pengunjung memakai HTTPS, origin mengeluarkan respons 301 Moved Permanently dengan header Location: https://contohdomain.com.
Proxy menerima respons 301 tersebut dan menyampaikannya ke browser pengunjung.
Browser pengunjung kembali meminta https://contohdomain.com ke proxy, dan siklus kembali lagi ke langkah 2 tanpa pernah selesai.

Di beberapa panel CDN, kondisi ini kerap terjadi jika mode SSL diatur ke Flexible sementara server origin atau aplikasi web di dalamnya sudah mengaktifkan fitur Force HTTPS. Server origin tidak sadar bahwa pengunjung aslinya sudah memakai HTTPS, karena koneksi yang sampai ke pintu origin hanyalah koneksi HTTP internal.

Menyelaraskan header X-Forwarded-Proto dan sertifikat origin

Solusi paling bersih untuk masalah SSL termination loop adalah mengubah mode enkripsi di CDN menjadi Full (atau Strict jika server origin memiliki sertifikat valid). Dengan begitu, koneksi dari CDN ke server origin juga menggunakan HTTPS di port 443, sehingga server origin tidak akan merasa perlu melempar pengalihan lagi. Namun, bagaimana jika server origin memang sengaja hanya melayani HTTP di port 80 di balik reverse proxy internal? Dalam skenario ini, reverse proxy harus mengirimkan header informasi ke origin, biasanya berupa X-Forwarded-Proto: https. Header ini memberi tahu aplikasi di belakang bahwa permintaan aslinya datang lewat HTTPS. Jika aplikasi kamu menggunakan WordPress di server Nginx tanpa modifikasi konfigurasi, WordPress membaca variabel $_SERVER['HTTPS']. Karena koneksi dari proxy masuk lewat port 80, PHP menganggap koneksi tidak aman dan terus melempar redirect. Agar web server memahami header forwarding dari proxy, blok konfigurasi Nginx atau Apache perlu disesuaikan untuk membaca nilai X-Forwarded-Proto dari IP proxy yang terpercaya. Bagi pengguna yang baru saja beralih web server, perbedaan pembacaan aturan semacam ini sering kali terlewat, seperti yang pernah kita bahas saat mengira file .htaccess masih berguna saat pindah dari Apache ke Nginx.

Benturan aturan www dan non-www

Selain urusan HTTPS, header Location pada output curl sering mengungkap benturan aturan kanonisasi domain (canonical URL). Ini terjadi ketika ada dua aturan yang saling bertolak belakang antara file konfigurasi web server dan pengaturan aplikasi. Sebagai contoh, konfigurasi virtual host web server kamu mengarahkan semua trafik contohdomain.com ke www.contohdomain.com. Di saat yang sama, pengaturan siteurl dan home di database aplikasi web kamu justru disetel ke https://contohdomain.com (tanpa www). Akibatnya, web server melempar pengunjung ke versi www, lalu begitu aplikasi dieksekusi, aplikasi melempar balik pengunjung ke versi non-www. Dengan menjalankan curl -IL, kamu bisa melihat URL di header Location melompat bergantian: baris pertama mengarah ke https://www.contohdomain.com, baris kedua mengarah ke https://contohdomain.com, dan seterusnya. Begitu polanya terlihat, kamu cukup menyamakan salah satu aturan: sesuaikan konfigurasi web server agar searah dengan pengaturan aplikasi, atau perbarui URL di aplikasi agar selaras dengan aturan server. Inti dari melacak redirect loop adalah membedah jalur pengalihan satu per satu tanpa melibatkan cache browser yang sering mengaburkan hasil pengujian. Dengan membaca header status dan Location secara berurutan lewat curl, kita bisa mengetahui dengan pasti komponen mana yang melempar pengalihan, ke mana tujuannya, dan di lapisan mana aturan tersebut harus diselaraskan.