Toolkit kecil untuk debugging redirect dan header HTTP di production

Masalah dalam debugging HTTP di production

Sebagian besar masalah HTTP tidak terlihat di browser. Rangkaian redirect gagal tanpa pesan yang jelas, satu karakter pada header cache salah, kebijakan CORS memblokir request tanpa penjelasan. Developer tools di browser menunjukkan hasil dari percakapan tersebut, tetapi sering menyembunyikan pertukaran mentah yang menyebabkan masalah.

Ini paling penting di production, ketika Anda tidak bisa menambahkan logging atau me-restart layanan untuk melihat apa yang berubah. Anda memerlukan alat yang menampilkan percakapan HTTP yang sebenarnya: request headers, response headers, status code, target redirect, timing. Berikut lima alat yang melakukan pekerjaan itu dengan andal, ditambah teknik browser yang melengkapinya.

curl: fondasinya

curl adalah alat pertama yang sebaiknya Anda gunakan karena ia menunjukkan persis apa yang dikirim server, tanpa interpretasi browser di tengahnya.

Untuk melihat response headers tanpa body:

curl -I https://example.com

Untuk mengikuti redirect dan melihat setiap langkah:

curl -L -v https://example.com

Flag -v (verbose) menampilkan request dan response lengkap, termasuk semua header. Flag -L mengikuti redirect secara otomatis. Bersama-sama, keduanya menunjukkan seluruh rangkaian redirect, tempat sebagian besar masalah production muncul.

Untuk hanya melihat lokasi redirect:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -L https://example.com

Ini berguna ketika Anda perlu memverifikasi rangkaian redirect tanpa gangguan dari header lengkap. Flag -w memformat output agar hanya menampilkan status code dan URL berikutnya dalam rangkaian.

curl juga memungkinkan Anda mengirim header kustom, yang penting untuk menguji perilaku CDN, authentication, atau endpoint API:

curl -H "Authorization: Bearer token" -H "Accept: application/json" https://api.example.com

httpie: curl dengan default yang lebih baik

httpie adalah alat Python yang melakukan apa yang dilakukan curl, tetapi dengan sintaks yang lebih mudah diingat dan output yang lebih mudah dibaca. Ini bukan pengganti—curl lebih kuat dan lebih luas terpasang—tetapi untuk pemeriksaan cepat, httpie lebih cepat.

Untuk melihat header:

http HEAD https://example.com

Untuk mengikuti redirect:

http --follow --all https://example.com

Flag --all menampilkan setiap response dalam rangkaian redirect, bukan hanya yang terakhir. Ini setara dengan curl -L -v, tetapi output-nya diberi warna dan lebih mudah dipindai.

Untuk mengirim JSON:

http POST https://api.example.com name=value

httpie mengasumsikan JSON secara default, sehingga menghemat pengetikan saat Anda menguji API. Ia juga memformat response dengan rapi, sehingga lebih mudah menemukan header yang salah bentuk atau nilai yang tidak terduga.

Browser DevTools: tab Network

Tab Network di browser adalah tempat Anda sebaiknya mulai jika masalah hanya terjadi di browser. Ia menampilkan informasi yang sama seperti curl, tetapi juga menunjukkan interpretasi browser: apakah request diblokir, bagaimana caching ditangani, apakah cookie dikirim.

Untuk melihat request dan response headers secara lengkap, klik request apa pun di tab Network, lalu lihat bagian Headers. Tampilan "Raw" menunjukkan header persis seperti saat dikirim, tanpa formatting.

Untuk melihat rangkaian redirect, cari request dengan status code 3xx. Browser mengelompokkannya di bawah request final, tetapi Anda dapat memperluasnya untuk melihat setiap langkah. Di sinilah Anda akan menemukan redirect loop, header Location yang hilang, atau redirect yang mengarah ke domain yang salah.

Untuk melihat timing, lihat tab Timing pada request apa pun. Ini menunjukkan berapa lama browser menghabiskan waktu untuk DNS lookup, koneksi TCP, TLS handshake, dan menunggu server. Jika redirect lambat, tab timing memberi tahu apakah masalahnya adalah latensi jaringan atau pemrosesan server.

Satu keterbatasan: browser menyembunyikan beberapa header karena alasan keamanan. Header Set-Cookie terlihat, tetapi nilai cookie sebenarnya disamarkan. Header Authorization terkadang disembunyikan sepenuhnya. Jika Anda perlu melihatnya, gunakan curl.

mitmproxy: proxy intersepsi

mitmproxy adalah alat Python yang berada di antara browser dan server, menampilkan setiap request dan response secara real time. Ini lebih kompleks daripada curl, tetapi merupakan satu-satunya alat yang menunjukkan apa yang sebenarnya dikirim browser, termasuk header yang ditambahkan browser secara otomatis.

Untuk menjalankannya:

mitmproxy

Lalu konfigurasikan browser Anda untuk menggunakan localhost:8080 sebagai HTTP proxy. mitmproxy akan menampilkan setiap request dalam antarmuka terminal. Anda dapat memeriksa header, mengedit request sebelum dikirim, atau memutar ulang request dengan parameter berbeda.

Ini berguna untuk debugging masalah yang hanya terjadi di browser: request CORS preflight, penanganan cookie, atau request yang gagal ketika header tertentu ada. Ini juga berguna untuk menguji bagaimana situs Anda berperilaku di belakang corporate proxy atau VPN, karena mitmproxy dapat mensimulasikan lingkungan tersebut.

Kekurangannya adalah kompleksitas setup. Anda perlu memasang root certificate agar mitmproxy dapat mengintersepsi traffic HTTPS, dan Anda perlu mengonfigurasi browser agar menggunakan proxy. Untuk pemeriksaan cepat, curl lebih cepat. Untuk debugging mendalam, mitmproxy sepadan dengan waktu setup-nya.

webpagetest: perspektif production

WebPageTest adalah layanan gratis yang memuat halaman Anda dari browser nyata di berbagai lokasi dan menampilkan percakapan HTTP lengkap. Ini lebih lambat daripada curl, tetapi menunjukkan apa yang dialami pengguna nyata, termasuk perilaku CDN, DNS resolution, dan TLS negotiation.

Tampilan "Request Headers" dan "Response Headers" menunjukkan persis apa yang dikirim dan diterima browser. Tampilan "Waterfall" menunjukkan timing setiap request, termasuk redirect. Di sinilah Anda akan menemukan masalah yang hanya terjadi di wilayah tertentu atau pada jaringan tertentu.

WebPageTest juga menampilkan rangkaian redirect untuk dokumen utama, tempat sebagian besar masalah redirect muncul. Jika situs Anda redirect dari http:// ke https://, lalu dari www. ke non-www., lalu dari / ke /en/, WebPageTest menunjukkan ketiga langkah tersebut dan berapa lama masing-masing memakan waktu.

Untuk alat yang membantu Anda memvalidasi dan mengoptimalkan fondasi HTTP ini, Wux Webtools menawarkan beberapa utilitas yang berjalan sepenuhnya di browser Anda, termasuk header analyzers dan redirect checkers yang menghormati privasi Anda dengan memproses semuanya di sisi client.

Ketika header berbohong

Masalah HTTP yang paling sulit adalah ketika server mengirim header yang saling bertentangan. Header Cache-Control mengatakan no-cache, tetapi header Expires mengatakan resource valid selama satu tahun. Header Location menunjuk ke URL relatif, tetapi header Content-Location menunjuk ke tempat lain. Browser harus menebak mana yang dapat dipercaya, dan browser yang berbeda bisa menebak secara berbeda.

Ketika ini terjadi, Anda perlu melihat header mentah dalam urutan yang dikirim server. curl -v melakukan ini. Begitu juga mitmproxy. DevTools browser terkadang mengurutkan ulang header agar lebih mudah dibaca, yang justru menyembunyikan masalah.

Masalah umum lainnya: header yang ditambahkan oleh CDN atau load balancer, bukan oleh aplikasi Anda. Jika Anda melakukan debugging masalah caching, Anda perlu tahu apakah header Cache-Control berasal dari aplikasi Anda atau dari CDN. curl menunjukkan hasil akhir, tetapi tidak memberi tahu dari mana setiap header berasal. Untuk itu, Anda perlu melewati CDN (dengan mengakses origin server secara langsung) dan membandingkan header.

Masalah redirect loop

Redirect loop adalah masalah HTTP paling umum di production. Ini terjadi ketika dua server tidak sepakat tentang ke mana sebuah URL harus mengarah: CDN melakukan redirect ke origin, origin melakukan redirect kembali ke CDN. Atau load balancer melakukan redirect HTTP ke HTTPS, tetapi aplikasi melakukan redirect HTTPS kembali ke HTTP karena tidak melihat header X-Forwarded-Proto.

Untuk debugging ini, Anda perlu melihat rangkaian redirect lengkap, termasuk header Location di setiap langkah. curl -L -v melakukan ini, tetapi berhenti setelah 50 redirect untuk mencegah loop tak berhingga. Jika Anda mencapai batas itu, berarti Anda memiliki redirect loop.

Perbaikannya biasanya berupa perubahan konfigurasi: beri tahu aplikasi untuk mempercayai header X-Forwarded-Proto, atau beri tahu CDN untuk berhenti melakukan redirect pada request yang sudah HTTPS. Tetapi Anda tidak bisa memperbaikinya sampai Anda melihat loop tersebut, dan browser tidak akan menunjukkan lebih dari beberapa redirect sebelum menyerah.

Apa yang diperiksa terlebih dahulu

Ketika sesuatu rusak di production, periksa hal-hal ini secara berurutan:

1. Status code: Apakah sesuai harapan? 301 bersifat permanen, 302 bersifat sementara, 307 mempertahankan HTTP method. Jika Anda melihat code yang salah, masalahnya ada pada konfigurasi redirect Anda.

1. Location header: Apakah mengarah ke tempat yang benar? Apakah berupa URL absolut atau relatif? URL relatif diselesaikan terhadap URL saat ini, yang dapat menghasilkan hasil tak terduga jika base URL tidak seperti yang Anda kira.

1. Cache headers: Apakah browser melakukan caching terhadap redirect? Redirect 301 di-cache secara default, yang berarti redirect yang salah konfigurasi dapat merusak situs Anda selama berjam-jam bahkan setelah Anda memperbaikinya. Periksa header Cache-Control dan Expires untuk melihat berapa lama browser akan mengingat redirect tersebut.

1. CORS headers: Jika request bersifat cross-origin, apakah server mengirim header Access-Control-Allow-Origin yang benar? Jika tidak, browser akan memblokir request, dan Anda akan melihat error CORS di console. Response headers dari server adalah satu-satunya tempat untuk memperbaikinya—Anda tidak bisa mengakalinya di browser.

1. Timing: Berapa lama request berlangsung? Jika lambat, apakah karena latensi jaringan atau pemrosesan server? DevTools browser dan WebPageTest sama-sama menunjukkan rincian timing yang memberi tahu ke mana waktu tersebut habis.

Untuk pembahasan lebih dalam tentang bagaimana perilaku browser bergeser terkait privasi dan header, lihat apa yang berubah untuk cookies pada 2026 dan apa yang perlu dilakukan, yang membahas implikasi header dan consent dari pembaruan browser terbaru.

Poin utama

• curl -L -v menunjukkan rangkaian redirect lengkap dan semua header, tanpa interpretasi browser
• Tab Network di browser menunjukkan apa yang dilakukan browser terhadap response, termasuk keputusan caching dan CORS
• mitmproxy menunjukkan apa yang dikirim browser, termasuk header yang ditambahkan browser secara otomatis
• WebPageTest menunjukkan apa yang dialami pengguna nyata, termasuk perilaku CDN dan perbedaan regional
• Redirect loop dan header yang saling bertentangan adalah masalah production yang paling umum, dan tidak terlihat tanpa inspeksi HTTP mentah

FAQ

Q: Mengapa curl menampilkan header yang berbeda dari browser?

A: Karena browser menambahkan header secara otomatis (User-Agent, Accept, Cookie) dan mengikuti aturannya sendiri untuk caching dan CORS. curl hanya mengirim apa yang Anda perintahkan untuk dikirim. Untuk melihat apa yang sebenarnya dikirim browser, gunakan mitmproxy atau DevTools browser.

Q: Bagaimana cara debug redirect yang hanya terjadi pada sebagian pengguna?

A: Periksa apakah redirect bergantung pada header yang dikirim pengguna: User-Agent, Accept-Language, Cookie, atau alamat IP (melalui X-Forwarded-For). Gunakan curl untuk mengirim header yang sama seperti yang dikirim pengguna, atau gunakan WebPageTest untuk memuat halaman dari lokasi pengguna.

Q: Apa perbedaan antara redirect 301 dan 302?

A: 301 bersifat permanen dan memberi tahu browser untuk melakukan caching terhadap redirect (terkadang selamanya). 302 bersifat sementara dan memberi tahu browser untuk tidak melakukan caching. Jika Anda tidak yakin harus menggunakan yang mana, gunakan 302—Anda selalu bisa mengubahnya menjadi 301 nanti.

Q: Mengapa redirect saya berjalan di curl tetapi tidak di browser?

A: Kemungkinan karena browser melakukan caching terhadap redirect lama, atau karena browser memblokir redirect akibat aturan CORS atau mixed content. Periksa console DevTools browser untuk error, dan periksa header Cache-Control untuk melihat apakah browser menggunakan response yang di-cache.

Q: Bagaimana cara melihat header yang ditambahkan CDN?

A: Gunakan curl untuk mengakses URL CDN, lalu gunakan curl lagi untuk mengakses origin server secara langsung (melewati CDN). Bandingkan header-nya. Header yang hanya muncul pada response pertama berasal dari CDN.

<!-- tool-cta:start -->

💡 Coba ini: Saat menelusuri masalah redirect, Redirect Checker melacak seluruh rantai dan menampilkan kode status serta header di setiap hop.

<!-- tool-cta:end -->

Sumber

• curl documentation — Referensi resmi untuk opsi command-line dan perilaku curl
• HTTPie documentation — Panduan sintaks dan fitur httpie
• MDN Web Docs: HTTP redirections — Penjelasan komprehensif tentang status code dan perilaku HTTP redirect
• WebPageTest documentation — Cara menafsirkan hasil dan header WebPageTest