Isang maliit na toolkit para sa pag-debug ng mga redirect at HTTP header sa production

Ang problema sa pag-debug ng HTTP sa production

Karamihan sa mga problema sa HTTP ay hindi nakikita sa browser. Tahimik na nabibigo ang isang redirect chain, may isang character na mali sa cache header, o may CORS policy na humaharang sa request nang walang paliwanag. Ipinapakita sa iyo ng developer tools ng browser ang resulta ng pag-uusap, pero madalas nilang itinatago ang raw na palitang naging sanhi ng problema.

Pinakamahalaga ito sa production, kung saan hindi ka basta makakapagdagdag ng logging o makakapag-restart ng services para makita kung ano ang nagbago. Kailangan mo ng mga tool na nagpapakita ng aktuwal na palitang HTTP: request headers, response headers, status codes, redirect targets, timing. Narito ang limang tool na maaasahang gumagawa niyan, kasama ang mga teknik sa browser na kapaki-pakinabang na pandagdag.

curl: ang pundasyon

curl ang unang tool na dapat abutin dahil ipinapakita nito mismo kung ano ang ipinadala ng server, nang walang interpretasyon ng browser sa gitna.

Para makita ang response headers nang walang body:

curl -I https://example.com

Para sundan ang mga redirect at makita ang bawat hakbang:

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

Ipinapakita ng -v flag (verbose) ang buong request at response, kasama ang lahat ng header. Awtomatikong sinusundan ng -L flag ang mga redirect. Magkasama, ipinapakita nila ang buong redirect chain, na karaniwang kinalalagyan ng karamihan sa mga problema sa production.

Para makita lamang ang mga redirect location:

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

Kapaki-pakinabang ito kapag kailangan mong i-verify ang redirect chain nang walang ingay ng buong headers. Pino-format ng -w flag ang output para ipakita lamang ang status code at ang susunod na URL sa chain.

Pinapayagan ka rin ng curl na magpadala ng custom headers, na mahalaga sa pag-test ng CDN behavior, authentication, o API endpoints:

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

httpie: curl na may mas magagandang default

Ang httpie ay isang Python tool na ginagawa ang ginagawa ng curl, pero may syntax na mas madaling tandaan at output na mas madaling basahin. Hindi ito kapalit—mas makapangyarihan ang curl at mas malawak itong naka-install—pero para sa mabilisang pagsusuri, mas mabilis gamitin ang httpie.

Para makita ang headers:

http HEAD https://example.com

Para sundan ang mga redirect:

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

Ipinapakita ng --all flag ang bawat response sa redirect chain, hindi lamang ang huli. Katumbas ito ng curl -L -v, pero color-coded ang output at mas madaling i-scan.

Para magpadala ng JSON:

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

Ipinagpapalagay ng httpie na JSON ang default, kaya nababawasan ang pagta-type kapag nagte-test ka ng APIs. Ipinapakita rin nito ang response sa pretty-printed na anyo, kaya mas madaling makita ang malformed headers o hindi inaasahang values.

Browser DevTools: Network tab

Ang Network tab ng browser ang dapat mong simulan kung sa browser lamang lumalabas ang problema. Ipinapakita nito ang parehong impormasyon gaya ng curl, pero ipinapakita rin nito ang interpretasyon ng browser: kung hinarang ba nito ang isang request, paano nito hinandle ang caching, kung nagpadala ba ito ng cookies.

Para makita ang buong request at response headers, i-click ang anumang request sa Network tab, pagkatapos ay tingnan ang Headers section. Ipinapakita ng "Raw" view ang headers kung paano mismo ipinadala ang mga ito, nang walang formatting.

Para makita ang redirect chains, hanapin ang mga request na may 3xx status codes. Iginugrupo ng browser ang mga ito sa ilalim ng final request, pero maaari mong i-expand ang mga ito para makita ang bawat hakbang. Dito mo makikita ang redirect loops, nawawalang Location headers, o redirects na tumuturo sa maling domain.

Para makita ang timing, tingnan ang Timing tab para sa anumang request. Ipinapakita nito kung gaano katagal ang ginugol ng browser sa DNS lookup, TCP connection, TLS handshake, at paghihintay sa server. Kung mabagal ang isang redirect, sasabihin sa iyo ng timing tab kung network latency ba ang problema o server processing.

Isang limitasyon: itinatago ng browser ang ilang header dahil sa seguridad. Nakikita ang Set-Cookie headers, pero ni-re-redact ang aktuwal na cookie values. Minsan ay ganap na itinatago ang Authorization headers. Kung kailangan mong makita ang mga iyon, gamitin ang curl.

mitmproxy: ang intercepting proxy

Ang mitmproxy ay isang Python tool na pumapagitna sa iyong browser at sa server, at ipinapakita nito sa iyo ang bawat request at response sa real time. Mas kumplikado ito kaysa curl, pero ito ang tanging tool na nagpapakita kung ano ang aktuwal na ipinapadala ng browser, kasama ang headers na awtomatikong idinaragdag ng browser.

Para simulan ito:

mitmproxy

Pagkatapos ay i-configure ang iyong browser na gamitin ang localhost:8080 bilang HTTP proxy. Ipapakita sa iyo ng mitmproxy ang bawat request sa isang terminal interface. Maaari mong inspeksyunin ang headers, i-edit ang requests bago ipadala, o i-replay ang requests gamit ang ibang parameters.

Kapaki-pakinabang ito sa pag-debug ng mga problemang nangyayari lamang sa browser: CORS preflight requests, cookie handling, o requests na nabibigo kapag naroroon ang ilang header. Kapaki-pakinabang din ito sa pag-test kung paano kumikilos ang site mo sa likod ng corporate proxy o VPN, dahil kayang gayahin ng mitmproxy ang mga environment na iyon.

Ang kahinaan nito ay ang pagiging kumplikado ng setup. Kailangan mong mag-install ng root certificate para ma-intercept ng mitmproxy ang HTTPS traffic, at kailangan mong i-configure ang browser na gamitin ang proxy. Para sa mabilisang pagsusuri, mas mabilis ang curl. Para sa malalimang debugging, sulit ang oras ng setup ng mitmproxy.

webpagetest: perspektiba ng production

Ang WebPageTest ay isang libreng serbisyo na naglo-load ng iyong page mula sa tunay na browsers sa iba't ibang lokasyon at ipinapakita sa iyo ang buong palitang HTTP. Mas mabagal ito kaysa curl, pero ipinapakita nito kung ano ang nararanasan ng tunay na users, kasama ang CDN behavior, DNS resolution, at TLS negotiation.

Ipinapakita ng "Request Headers" at "Response Headers" views kung ano mismo ang ipinadala at natanggap ng browser. Ipinapakita ng "Waterfall" view ang timing ng bawat request, kasama ang redirects. Dito mo makikita ang mga problemang nangyayari lamang sa ilang rehiyon o sa ilang network.

Ipinapakita rin ng WebPageTest ang redirect chain para sa main document, na karaniwang kinalalagyan ng karamihan sa mga problema sa redirect. Kung nagre-redirect ang site mo mula http:// papuntang https://, pagkatapos mula www. papuntang non-www., pagkatapos mula / papuntang /en/, ipinapakita ng WebPageTest ang lahat ng tatlong hakbang at kung gaano katagal ang bawat isa.

Para sa mga tool na tumutulong sa iyong i-validate at i-optimize ang mga pundamental na HTTP na ito, nag-aalok ang Wux Webtools ng ilang utility na ganap na tumatakbo sa iyong browser, kasama ang header analyzers at redirect checkers na nirerespeto ang iyong privacy sa pamamagitan ng pagproseso ng lahat client-side.

Kapag nagsisinungaling ang mga header

Ang pinakamahirap na problema sa HTTP ay yaong nagpapadala ang server ng magkakasalungat na header. Sinasabi ng Cache-Control header na no-cache, pero sinasabi ng Expires header na valid ang resource sa loob ng isang taon. Tinuturo ng Location header ang isang relative URL, pero iba ang itinuturo ng Content-Location header. Kailangang hulaan ng browser kung alin ang pagkakatiwalaan, at magkaiba ang hula ng iba't ibang browser.

Kapag nangyari ito, kailangan mong makita ang raw headers sa pagkakasunod-sunod na ipinadala ng server. Ginagawa ito ng curl -v. Gayundin ang mitmproxy. Minsan ay nire-reorder ng DevTools ng browser ang headers para mas madaling basahin, at natatago nito ang problema.

Isa pang karaniwang isyu: headers na idinagdag ng CDN o load balancer, hindi ng iyong application. Kung nagde-debug ka ng caching problem, kailangan mong malaman kung ang Cache-Control header ay nagmula sa app mo o sa CDN. Ipinapakita sa iyo ng curl ang final result, pero hindi nito sinasabi kung saan nagmula ang bawat header. Para doon, kailangan mong i-bypass ang CDN (sa pamamagitan ng direktang pag-hit sa origin server) at ihambing ang headers.

Ang problema ng redirect loop

Ang redirect loops ang pinakakaraniwang problema sa HTTP sa production. Nangyayari ang mga ito kapag hindi magkasundo ang dalawang server kung saan dapat tumuro ang isang URL: nagre-redirect ang CDN papunta sa origin, at nagre-redirect pabalik ang origin papunta sa CDN. O kaya ay nire-redirect ng load balancer ang HTTP papuntang HTTPS, pero nire-redirect ng app ang HTTPS pabalik sa HTTP dahil hindi nito nakikita ang X-Forwarded-Proto header.

Para i-debug ito, kailangan mong makita ang buong redirect chain, kasama ang Location header sa bawat hakbang. Ginagawa ito ng curl -L -v, pero humihinto ito pagkatapos ng 50 redirects para maiwasan ang infinite loops. Kung umaabot ka sa limitasyong iyon, mayroon kang redirect loop.

Karaniwang configuration change ang pag-aayos: sabihin sa app na pagkatiwalaan ang X-Forwarded-Proto header, o sabihin sa CDN na itigil ang pagre-redirect ng requests na HTTPS na. Pero hindi mo ito maaayos hangga't hindi mo nakikita ang loop, at hindi magpapakita ang browser ng higit sa ilang redirect bago ito sumuko.

Ano ang unang susuriin

Kapag may nasira sa production, suriin ang mga ito sa ganitong pagkakasunod-sunod:

1. Status code: Ito ba ang inaasahan mo? Permanent ang 301, temporary ang 302, at pinapanatili ng 307 ang HTTP method. Kung maling code ang nakikita mo, nasa redirect configuration mo ang problema.

1. Location header: Tumuturo ba ito sa tamang lugar? Absolute URL ba ito o relative? Nireresolba ang relative URLs laban sa kasalukuyang URL, na maaaring magdulot ng hindi inaasahang resulta kung hindi pala iyon ang base URL na akala mo.

1. Cache headers: Kina-cache ba ng browser ang redirect? Default na kina-cache ang 301 redirect, na nangangahulugang ang maling configuration na redirect ay maaaring makasira sa site mo nang ilang oras kahit na naayos mo na ito. Suriin ang Cache-Control at Expires headers para makita kung gaano katagal tatandaan ng browser ang redirect.

1. CORS headers: Kung cross-origin ang request, nagpapadala ba ang server ng tamang Access-Control-Allow-Origin header? Kung hindi, haharangin ng browser ang request, at makakakita ka ng CORS error sa console. Ang response headers ng server lamang ang lugar para ayusin ito—hindi mo ito malulusutan sa browser.

1. Timing: Gaano katagal ang request? Kung mabagal ito, network latency ba o server processing? Parehong ipinapakita ng DevTools ng browser at WebPageTest ang timing breakdowns na nagsasabi kung saan napunta ang oras.

Para sa mas malalim na pagtingin sa kung paano nagbago ang behavior ng browser kaugnay ng privacy at headers, tingnan ang kung ano ang nagbago para sa cookies noong 2026 at ano ang dapat gawin tungkol dito, na tumatalakay sa mga implikasyon sa header at consent ng mga kamakailang update sa browser.

Mahahalagang punto

• Ipinapakita ng curl -L -v ang buong redirect chain at lahat ng header, nang walang interpretasyon ng browser
• Ipinapakita ng Network tab ng browser kung ano ang ginawa ng browser sa response, kasama ang caching at CORS decisions
• Ipinapakita ng mitmproxy kung ano ang ipinadala ng browser, kasama ang headers na awtomatikong idinaragdag ng browser
• Ipinapakita ng WebPageTest kung ano ang nararanasan ng tunay na users, kasama ang CDN behavior at regional differences
• Redirect loops at magkakasalungat na headers ang pinakakaraniwang problema sa production, at hindi nakikita ang mga ito nang walang raw HTTP inspection

FAQ

Q: Bakit iba ang headers na ipinapakita ng curl kaysa sa browser?

A: Dahil awtomatikong nagdaragdag ng headers ang browser (User-Agent, Accept, Cookie) at sinusunod nito ang sarili nitong mga panuntunan para sa caching at CORS. Ipinapadala lamang ng curl ang sinabi mong ipadala nito. Para makita kung ano talaga ang ipinapadala ng browser, gamitin ang mitmproxy o ang DevTools ng browser.

Q: Paano ko ide-debug ang redirect na nangyayari lamang sa ilang user?

A: Suriin kung nakadepende ang redirect sa headers na ipinapadala ng user: User-Agent, Accept-Language, Cookie, o IP address (sa pamamagitan ng X-Forwarded-For). Gamitin ang curl para ipadala ang parehong headers na ipinadala ng user, o gamitin ang WebPageTest para i-load ang page mula sa lokasyon ng user.

Q: Ano ang pagkakaiba ng 301 at 302 redirects?

A: Permanent ang 301 at sinasabi nito sa browser na i-cache ang redirect (minsan magpakailanman). Temporary ang 302 at sinasabi nito sa browser na huwag itong i-cache. Kung hindi ka sigurado kung alin ang gagamitin, gamitin ang 302—maaari mo naman itong palitan sa 301 sa kalaunan.

Q: Bakit gumagana ang redirect ko sa curl pero hindi sa browser?

A: Malamang dahil kina-cache ng browser ang lumang redirect, o dahil hinaharang ng browser ang redirect dahil sa CORS o mixed content rules. Suriin ang DevTools console ng browser para sa errors, at suriin ang Cache-Control headers para makita kung gumagamit ang browser ng cached response.

Q: Paano ko makikita ang headers na idinaragdag ng CDN?

A: Gamitin ang curl para i-hit ang CDN URL, pagkatapos ay gamitin muli ang curl para direktang i-hit ang origin server (bina-bypass ang CDN). Ihambing ang headers. Ang mga lumalabas lamang sa unang response ay nagmula sa CDN.

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

💡 Subukan ito: Kapag hinahanap ang mga isyu sa redirect, tina-trace ng Redirect Checker ang buong chain at ipinapakita ang mga status code at header sa bawat hop.

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

Sources

• curl documentation — Opisyal na reference para sa curl command-line options at behavior
• HTTPie documentation — Gabay sa syntax at features ng httpie
• MDN Web Docs: HTTP redirections — Komprehensibong paliwanag ng HTTP redirect status codes at behavior
• WebPageTest documentation — Paano bigyang-kahulugan ang WebPageTest results at headers