Kit alat kecil untuk menyahpepijat ubah hala dan pengepala HTTP dalam produksi

Masalah menyahpepijat HTTP dalam produksi

Kebanyakan masalah HTTP tidak kelihatan dalam pelayar. Rantaian ubah hala gagal secara senyap, pengepala cache tersalah satu aksara, dasar CORS menyekat permintaan tanpa penjelasan. Alat pembangun pelayar menunjukkan hasil pertukaran itu, tetapi selalunya menyembunyikan pertukaran mentah yang menyebabkan masalah tersebut.

Ini paling penting dalam produksi, apabila anda tidak boleh menambah logging atau memulakan semula perkhidmatan untuk melihat perkara yang berubah. Anda memerlukan alat yang menunjukkan pertukaran HTTP sebenar: pengepala permintaan, pengepala respons, kod status, sasaran ubah hala, pemasaan. Berikut ialah lima alat yang melakukan kerja itu dengan boleh dipercayai, bersama teknik pelayar yang melengkapkannya.

curl: asasnya

curl ialah alat pertama yang patut digunakan kerana ia menunjukkan dengan tepat apa yang dihantar oleh pelayan, tanpa tafsiran pelayar di tengah-tengah.

Untuk melihat pengepala respons tanpa isi:

curl -I https://example.com

Untuk mengikuti ubah hala dan melihat setiap langkah:

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

Bendera -v (verbose) menunjukkan permintaan dan respons penuh, termasuk semua pengepala. Bendera -L mengikuti ubah hala secara automatik. Bersama-sama, kedua-duanya menunjukkan keseluruhan rantaian ubah hala, iaitu tempat kebanyakan masalah produksi berlaku.

Untuk melihat hanya lokasi ubah hala:

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

Ini berguna apabila anda perlu mengesahkan rantaian ubah hala tanpa gangguan daripada pengepala penuh. Bendera -w memformat output supaya hanya menunjukkan kod status dan URL seterusnya dalam rantaian.

curl juga membolehkan anda menghantar pengepala tersuai, yang penting untuk menguji tingkah laku CDN, pengesahan, atau titik akhir API:

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

httpie: curl dengan lalai yang lebih baik

httpie ialah alat Python yang melakukan apa yang curl lakukan, tetapi dengan sintaks yang lebih mudah diingati dan output yang lebih mudah dibaca. Ia bukan pengganti—curl lebih berkuasa dan lebih meluas dipasang—tetapi untuk semakan pantas, httpie lebih cepat digunakan.

Untuk melihat pengepala:

http HEAD https://example.com

Untuk mengikuti ubah hala:

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

Bendera --all menunjukkan setiap respons dalam rantaian ubah hala, bukan hanya respons akhir. Ini bersamaan dengan curl -L -v, tetapi outputnya berkod warna dan lebih mudah diimbas.

Untuk menghantar JSON:

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

httpie menganggap JSON secara lalai, yang menjimatkan taip apabila anda menguji API. Ia juga memaparkan respons dengan format yang kemas, menjadikannya lebih mudah untuk mengesan pengepala yang cacat atau nilai yang tidak dijangka.

Browser DevTools: tab Network

Tab Network dalam pelayar ialah tempat yang patut anda mulakan jika masalah hanya berlaku dalam pelayar. Ia menunjukkan maklumat yang sama seperti curl, tetapi ia juga menunjukkan tafsiran pelayar: sama ada ia menyekat permintaan, bagaimana ia mengendalikan caching, sama ada ia menghantar cookies.

Untuk melihat pengepala permintaan dan respons penuh, klik mana-mana permintaan dalam tab Network, kemudian lihat seksyen Headers. Paparan "Raw" menunjukkan pengepala tepat seperti ia dihantar, tanpa pemformatan.

Untuk melihat rantaian ubah hala, cari permintaan dengan kod status 3xx. Pelayar mengumpulkannya di bawah permintaan akhir, tetapi anda boleh mengembangkannya untuk melihat setiap langkah. Di sinilah anda akan menemui gelung ubah hala, pengepala Location yang hilang, atau ubah hala yang menunjuk ke domain yang salah.

Untuk melihat pemasaan, lihat tab Timing bagi mana-mana permintaan. Ini menunjukkan berapa lama pelayar mengambil masa untuk pencarian DNS, sambungan TCP, jabat tangan TLS, dan menunggu pelayan. Jika sesuatu ubah hala perlahan, tab pemasaan memberitahu anda sama ada masalahnya ialah kependaman rangkaian atau pemprosesan pelayan.

Satu batasan: pelayar menyembunyikan sesetengah pengepala atas sebab keselamatan. Pengepala Set-Cookie kelihatan, tetapi nilai cookie sebenar dikaburkan. Pengepala Authorization kadangkala disembunyikan sepenuhnya. Jika anda perlu melihatnya, gunakan curl.

mitmproxy: proksi pemintas

mitmproxy ialah alat Python yang berada di antara pelayar anda dan pelayan, menunjukkan setiap permintaan dan respons secara masa nyata. Ia lebih kompleks daripada curl, tetapi ia satu-satunya alat yang menunjukkan apa yang sebenarnya dihantar oleh pelayar, termasuk pengepala yang ditambah oleh pelayar secara automatik.

Untuk memulakannya:

mitmproxy

Kemudian konfigurasikan pelayar anda untuk menggunakan localhost:8080 sebagai proksi HTTP. mitmproxy akan menunjukkan setiap permintaan dalam antara muka terminal. Anda boleh memeriksa pengepala, mengedit permintaan sebelum dihantar, atau memainkan semula permintaan dengan parameter berbeza.

Ini berguna untuk menyahpepijat masalah yang hanya berlaku dalam pelayar: permintaan preflight CORS, pengendalian cookie, atau permintaan yang gagal apabila pengepala tertentu hadir. Ia juga berguna untuk menguji bagaimana laman anda berkelakuan di belakang proksi korporat atau VPN, kerana mitmproxy boleh mensimulasikan persekitaran tersebut.

Kelemahannya ialah kerumitan persediaan. Anda perlu memasang sijil akar supaya mitmproxy boleh memintas trafik HTTPS, dan anda perlu mengkonfigurasikan pelayar anda untuk menggunakan proksi. Untuk semakan pantas, curl lebih cepat. Untuk penyahpepijatan mendalam, mitmproxy berbaloi dengan masa persediaannya.

webpagetest: perspektif produksi

WebPageTest ialah perkhidmatan percuma yang memuatkan halaman anda daripada pelayar sebenar di lokasi berbeza dan menunjukkan pertukaran HTTP penuh. Ia lebih perlahan daripada curl, tetapi ia menunjukkan pengalaman pengguna sebenar, termasuk tingkah laku CDN, resolusi DNS, dan rundingan TLS.

Paparan "Request Headers" dan "Response Headers" menunjukkan dengan tepat apa yang dihantar dan diterima oleh pelayar. Paparan "Waterfall" menunjukkan pemasaan setiap permintaan, termasuk ubah hala. Di sinilah anda akan menemui masalah yang hanya berlaku di wilayah tertentu atau pada rangkaian tertentu.

WebPageTest juga menunjukkan rantaian ubah hala untuk dokumen utama, iaitu tempat kebanyakan masalah ubah hala berlaku. Jika laman anda mengubah hala daripada http:// kepada https://, kemudian daripada www. kepada bukan-www., kemudian daripada / kepada /en/, WebPageTest menunjukkan ketiga-tiga langkah dan berapa lama setiap satu mengambil masa.

Untuk alat yang membantu anda mengesahkan dan mengoptimumkan asas HTTP ini, Wux Webtools menawarkan beberapa utiliti yang berjalan sepenuhnya dalam pelayar anda, termasuk penganalisis pengepala dan penyemak ubah hala yang menghormati privasi anda dengan memproses semuanya di sisi klien.

Apabila pengepala berbohong

Masalah HTTP yang paling sukar ialah masalah apabila pelayan menghantar pengepala yang bercanggah. Pengepala Cache-Control mengatakan no-cache, tetapi pengepala Expires mengatakan sumber itu sah selama setahun. Pengepala Location menunjuk ke URL relatif, tetapi pengepala Content-Location menunjuk ke tempat lain. Pelayar perlu meneka yang mana satu untuk dipercayai, dan pelayar berbeza meneka secara berbeza.

Apabila ini berlaku, anda perlu melihat pengepala mentah mengikut urutan pelayan menghantarnya. curl -v melakukan ini. Begitu juga mitmproxy. DevTools pelayar kadangkala menyusun semula pengepala demi kebolehbacaan, yang menyembunyikan masalah tersebut.

Satu lagi isu biasa: pengepala yang ditambah oleh CDN atau load balancer, bukan oleh aplikasi anda. Jika anda menyahpepijat masalah caching, anda perlu tahu sama ada pengepala Cache-Control datang daripada app anda atau daripada CDN. curl menunjukkan hasil akhir, tetapi ia tidak memberitahu dari mana setiap pengepala datang. Untuk itu, anda perlu memintas CDN (dengan mengakses pelayan asal secara terus) dan membandingkan pengepala.

Masalah gelung ubah hala

Gelung ubah hala ialah masalah HTTP yang paling biasa dalam produksi. Ia berlaku apabila dua pelayan tidak bersetuju tentang ke mana sesuatu URL patut menunjuk: CDN mengubah hala ke origin, origin mengubah hala kembali ke CDN. Atau load balancer mengubah hala HTTP ke HTTPS, tetapi app mengubah hala HTTPS kembali ke HTTP kerana ia tidak melihat pengepala X-Forwarded-Proto.

Untuk menyahpepijat ini, anda perlu melihat rantaian ubah hala penuh, termasuk pengepala Location pada setiap langkah. curl -L -v melakukan ini, tetapi ia berhenti selepas 50 ubah hala untuk mencegah gelung tanpa henti. Jika anda mencapai had itu, anda mempunyai gelung ubah hala.

Pembetulannya biasanya perubahan konfigurasi: beritahu app supaya mempercayai pengepala X-Forwarded-Proto, atau beritahu CDN supaya berhenti mengubah hala permintaan yang sudah HTTPS. Tetapi anda tidak boleh membetulkannya sehingga anda melihat gelung itu, dan pelayar tidak akan menunjukkan lebih daripada beberapa ubah hala sebelum ia menyerah.

Perkara yang perlu disemak dahulu

Apabila sesuatu rosak dalam produksi, semak perkara ini mengikut urutan:

1. Kod status: Adakah ia seperti yang anda jangkakan? 301 adalah kekal, 302 adalah sementara, 307 mengekalkan kaedah HTTP. Jika anda melihat kod yang salah, masalahnya berada dalam konfigurasi ubah hala anda.

1. Pengepala Location: Adakah ia menunjuk ke tempat yang betul? Adakah ia URL mutlak atau relatif? URL relatif diselesaikan terhadap URL semasa, yang boleh menghasilkan keputusan tidak dijangka jika URL asas bukan seperti yang anda fikirkan.

1. Pengepala cache: Adakah pelayar menyimpan ubah hala dalam cache? Ubah hala 301 disimpan dalam cache secara lalai, yang bermakna ubah hala yang salah konfigurasi boleh merosakkan laman anda selama berjam-jam walaupun selepas anda membetulkannya. Semak pengepala Cache-Control dan Expires untuk melihat berapa lama pelayar akan mengingati ubah hala tersebut.

1. Pengepala CORS: Jika permintaan adalah cross-origin, adakah pelayan menghantar pengepala Access-Control-Allow-Origin yang betul? Jika tidak, pelayar akan menyekat permintaan itu, dan anda akan melihat ralat CORS dalam konsol. Pengepala respons pelayan ialah satu-satunya tempat untuk membetulkannya—anda tidak boleh mengatasinya dalam pelayar.

1. Pemasaan: Berapa lama permintaan itu mengambil masa? Jika ia perlahan, adakah puncanya kependaman rangkaian atau pemprosesan pelayan? DevTools pelayar dan WebPageTest kedua-duanya menunjukkan pecahan pemasaan yang memberitahu anda ke mana masa itu pergi.

Untuk melihat dengan lebih mendalam bagaimana tingkah laku pelayar telah berubah berkaitan privasi dan pengepala, lihat apa yang berubah untuk cookies pada 2026 dan apa yang perlu dilakukan mengenainya, yang merangkumi implikasi pengepala dan persetujuan daripada kemas kini pelayar terkini.

Perkara utama

• curl -L -v menunjukkan rantaian ubah hala penuh dan semua pengepala, tanpa tafsiran pelayar
• Tab Network pelayar menunjukkan apa yang pelayar lakukan dengan respons, termasuk keputusan caching dan CORS
• mitmproxy menunjukkan apa yang pelayar hantar, termasuk pengepala yang ditambah oleh pelayar secara automatik
• WebPageTest menunjukkan pengalaman pengguna sebenar, termasuk tingkah laku CDN dan perbezaan wilayah
• Gelung ubah hala dan pengepala bercanggah ialah masalah produksi yang paling biasa, dan ia tidak kelihatan tanpa pemeriksaan HTTP mentah

FAQ

Q: Mengapa curl menunjukkan pengepala yang berbeza daripada pelayar?

A: Kerana pelayar menambah pengepala secara automatik (User-Agent, Accept, Cookie) dan mengikut peraturannya sendiri untuk caching dan CORS. curl hanya menghantar apa yang anda suruh ia hantar. Untuk melihat apa yang sebenarnya dihantar oleh pelayar, gunakan mitmproxy atau DevTools pelayar.

Q: Bagaimana saya menyahpepijat ubah hala yang hanya berlaku kepada sesetengah pengguna?

A: Semak sama ada ubah hala bergantung pada pengepala yang dihantar oleh pengguna: User-Agent, Accept-Language, Cookie, atau alamat IP (melalui X-Forwarded-For). Gunakan curl untuk menghantar pengepala yang sama seperti yang dihantar oleh pengguna, atau gunakan WebPageTest untuk memuatkan halaman dari lokasi pengguna.

Q: Apakah perbezaan antara ubah hala 301 dan 302?

A: 301 adalah kekal dan memberitahu pelayar untuk menyimpan ubah hala dalam cache (kadangkala selama-lamanya). 302 adalah sementara dan memberitahu pelayar supaya tidak menyimpannya dalam cache. Jika anda tidak pasti yang mana untuk digunakan, gunakan 302—anda sentiasa boleh menukarnya kepada 301 kemudian.

Q: Mengapa ubah hala saya berfungsi dalam curl tetapi tidak dalam pelayar?

A: Mungkin kerana pelayar sedang menggunakan ubah hala lama daripada cache, atau kerana pelayar menyekat ubah hala disebabkan peraturan CORS atau kandungan bercampur. Semak konsol DevTools pelayar untuk ralat, dan semak pengepala Cache-Control untuk melihat sama ada pelayar menggunakan respons daripada cache.

Q: Bagaimana saya melihat pengepala yang ditambah oleh CDN?

A: Gunakan curl untuk mengakses URL CDN, kemudian gunakan curl sekali lagi untuk mengakses pelayan asal secara terus (memintas CDN). Bandingkan pengepala. Pengepala yang hanya muncul dalam respons pertama datang daripada CDN.

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

💡 Cuba ini: Apabila menjejaki isu ubah hala, Redirect Checker menjejaki keseluruhan rantaian dan memaparkan kod status serta pengepala pada setiap hop.

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

Sumber

• Dokumentasi curl — Rujukan rasmi untuk pilihan baris perintah dan tingkah laku curl
• Dokumentasi HTTPie — Panduan kepada sintaks dan ciri httpie
• MDN Web Docs: HTTP redirections — Penjelasan menyeluruh tentang kod status ubah hala HTTP dan tingkah lakunya
• Dokumentasi WebPageTest — Cara mentafsir keputusan dan pengepala WebPageTest