用於在 production 偵錯重新導向與 HTTP 標頭的小型工具組

在 production 偵錯 HTTP 的問題

多數 HTTP 問題在瀏覽器中是看不見的。重新導向鏈默默失敗、快取標頭只差一個字元、CORS 政策在沒有說明的情況下封鎖請求。瀏覽器的開發者工具會顯示這段對話的結果，但往往隱藏了造成問題的原始交換內容。

這在 production 中尤其重要，因為你不能為了看出變更而加入 logging 或重新啟動服務。你需要能顯示實際 HTTP 對話的工具：request headers、response headers、status codes、redirect targets、timing。以下是五個能可靠完成這項工作的工具，以及可搭配使用的瀏覽器技巧。

curl: the foundation

curl 是第一個應該拿來使用的工具，因為它會精確顯示 server 送出的內容，中間沒有瀏覽器的解讀。

若要只查看 response headers 而不顯示 body：

curl -I https://example.com

若要跟隨重新導向並查看每一步：

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

-v flag（verbose）會顯示完整的 request 與 response，包括所有 headers。-L flag 會自動跟隨 redirects。兩者一起使用時，會顯示整個 redirect chain，而多數 production 問題就藏在這裡。

若只想查看 redirect locations：

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

當你需要驗證 redirect chain、但不想被完整 headers 的雜訊干擾時，這很有用。-w flag 會格式化輸出，只顯示狀態碼與鏈中的下一個 URL。

curl 也可以讓你送出 custom headers，這對測試 CDN 行為、authentication 或 API endpoints 是必要的：

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

httpie: curl with better defaults

httpie 是一個 Python 工具，能做 curl 做的事，但語法更容易記住，輸出也更容易閱讀。它不是替代品——curl 更強大、也更廣泛預先安裝——但用於快速檢查時，httpie 更快。

若要查看 headers：

http HEAD https://example.com

若要跟隨 redirects：

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

--all flag 會顯示 redirect chain 中的每一個 response，而不只是最後一個。這相當於 curl -L -v，但輸出有色彩標示，也更容易掃讀。

若要送出 JSON：

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

httpie 預設假設使用 JSON，這在測試 APIs 時可以少打一些內容。它也會對 response 進行 pretty-print，讓你更容易發現格式錯誤的 headers 或非預期的 values。

Browser DevTools: Network tab

如果問題只在瀏覽器中發生，瀏覽器的 Network tab 是你應該開始的地方。它會顯示和 curl 相同的資訊，但也會顯示瀏覽器的解讀：是否封鎖了某個 request、如何處理 caching、是否送出了 cookies。

若要查看完整的 request 與 response headers，請在 Network tab 中點選任一 request，然後查看 Headers 區段。「Raw」view 會精確顯示 headers 被送出時的樣子，不做任何格式化。

若要查看 redirect chains，請尋找 status code 為 3xx 的 requests。瀏覽器會將它們歸在最終 request 之下，但你可以展開它們查看每一步。這裡會找到 redirect loops、缺少的 Location headers，或指向錯誤 domain 的 redirects。

若要查看 timing，請查看任一 request 的 Timing tab。這會顯示瀏覽器花在 DNS lookup、TCP connection、TLS handshake，以及等待 server 的時間。如果某個 redirect 很慢，timing tab 會告訴你問題是 network latency 還是 server processing。

一個限制是：基於安全原因，瀏覽器會隱藏某些 headers。Set-Cookie headers 可見，但實際 cookie values 會被遮蔽。Authorization headers 有時會完全隱藏。如果你需要查看這些內容，請使用 curl。

mitmproxy: the intercepting proxy

mitmproxy 是一個 Python 工具，會位於你的瀏覽器與 server 之間，即時顯示每一個 request 與 response。它比 curl 複雜，但它是唯一能顯示瀏覽器實際送出內容的工具，包括瀏覽器自動加入的 headers。

啟動方式：

mitmproxy

接著將你的瀏覽器設定為使用 localhost:8080 作為 HTTP proxy。mitmproxy 會在 terminal 介面中顯示每個 request。你可以檢查 headers、在送出前編輯 requests，或以不同參數重播 requests。

這對偵錯只在瀏覽器中發生的問題很有用：CORS preflight requests、cookie handling，或在特定 headers 存在時失敗的 requests。它也適合測試你的網站在 corporate proxy 或 VPN 背後的行為，因為 mitmproxy 可以模擬這些環境。

缺點是設定較複雜。你需要安裝 root certificate，讓 mitmproxy 可以攔截 HTTPS traffic，也需要設定瀏覽器使用 proxy。快速檢查時，curl 更快。深度偵錯時，mitmproxy 值得投入設定時間。

webpagetest: production perspective

WebPageTest 是一個免費服務，會從不同地點的真實瀏覽器載入你的頁面，並顯示完整的 HTTP 對話。它比 curl 慢，但會顯示真實使用者的體驗，包括 CDN 行為、DNS resolution 與 TLS negotiation。

「Request Headers」與「Response Headers」views 會精確顯示瀏覽器送出與接收的內容。「Waterfall」view 會顯示每個 request 的 timing，包括 redirects。這裡會找到只在特定區域或特定 networks 上發生的問題。

WebPageTest 也會顯示 main document 的 redirect chain，而多數 redirect 問題就藏在這裡。如果你的網站先從 http:// redirect 到 https://，再從 www. redirect 到 non-www.，接著從 / redirect 到 /en/，WebPageTest 會顯示全部三個步驟，以及每一步花了多久。

若需要協助你驗證並最佳化這些 HTTP 基礎項目的工具，Wux Webtools 提供多個 utilities，可完全在你的瀏覽器中執行，包括 header analyzers 與 redirect checkers，並透過 client-side 處理所有內容來尊重你的隱私。

When headers lie

最困難的 HTTP 問題，是 server 送出互相矛盾的 headers。Cache-Control header 說 no-cache，但 Expires header 說資源一年內有效。Location header 指向 relative URL，但 Content-Location header 指向其他地方。瀏覽器必須猜測要信任哪一個，而不同瀏覽器的猜法也不同。

發生這種情況時，你需要按照 server 送出的順序查看 raw headers。curl -v 可以做到。mitmproxy 也可以。瀏覽器的 DevTools 有時會為了可讀性而重新排序 headers，這會隱藏問題。

另一個常見問題是：headers 是由 CDN 或 load balancer 加上的，而不是你的 application。如果你正在偵錯 caching 問題，就需要知道 Cache-Control header 來自你的 app 還是 CDN。curl 會顯示最終結果，但不會告訴你每個 header 來自哪裡。要做到這點，你需要繞過 CDN（直接打到 origin server）並比較 headers。

The redirect loop problem

Redirect loops 是 production 中最常見的 HTTP 問題。它們發生在兩台 servers 對某個 URL 應指向何處意見不一致時：CDN redirect 到 origin，origin 又 redirect 回 CDN。或者 load balancer 將 HTTP redirect 到 HTTPS，但 app 因為看不到 X-Forwarded-Proto header，又將 HTTPS redirect 回 HTTP。

若要偵錯這點，你需要查看完整的 redirect chain，包括每一步的 Location header。curl -L -v 可以做到，但它會在 50 次 redirects 後停止，以避免 infinite loops。如果你碰到這個限制，就代表你有 redirect loop。

修正通常是設定變更：告訴 app 信任 X-Forwarded-Proto header，或告訴 CDN 停止 redirect 已經是 HTTPS 的 requests。但在你看見這個 loop 之前，無法修正它；而瀏覽器通常只顯示幾次 redirects 就會放棄。

What to check first

當 production 出問題時，請依序檢查以下項目：

1. Status code: 是否符合預期？301 是 permanent，302 是 temporary，307 會保留 HTTP method。如果你看到錯誤的 code，問題就在 redirect configuration。

1. Location header: 它是否指向正確位置？是 absolute URL 還是 relative URL？Relative URLs 會相對於目前 URL 解析；如果 base URL 不是你以為的那個，就可能產生非預期結果。

1. Cache headers: 瀏覽器是否正在 caching 這個 redirect？301 redirect 預設會被 cached，這表示設定錯誤的 redirect 即使修好後，仍可能讓你的網站中斷數小時。檢查 Cache-Control 與 Expires headers，看看瀏覽器會記住這個 redirect 多久。

1. CORS headers: 如果 request 是 cross-origin，server 是否送出正確的 Access-Control-Allow-Origin header？如果沒有，瀏覽器會封鎖 request，而你會在 console 中看到 CORS error。Server 的 response headers 是唯一能修正此問題的地方——你無法在瀏覽器中繞過它。

1. Timing: 這個 request 花了多久？如果很慢，是 network latency 還是 server processing？瀏覽器的 DevTools 與 WebPageTest 都會顯示 timing breakdowns，告訴你時間花在哪裡。

若想更深入了解瀏覽器在 privacy 與 headers 相關行為上的變化，請參閱 2026 年 cookies 有哪些變化，以及該如何因應，其中涵蓋近期瀏覽器更新對 headers 與 consent 的影響。

Key takeaways

• curl -L -v 會顯示完整的 redirect chain 與所有 headers，不包含瀏覽器解讀
• 瀏覽器的 Network tab 會顯示瀏覽器對 response 做了什麼，包括 caching 與 CORS decisions
• mitmproxy 會顯示瀏覽器送出了什麼，包括瀏覽器自動加入的 headers
• WebPageTest 會顯示真實使用者的體驗，包括 CDN 行為與區域差異
• Redirect loops 與互相矛盾的 headers 是最常見的 production 問題，若沒有 raw HTTP inspection，這些問題是看不見的

FAQ

Q: Why does curl show different headers than the browser?

A: 因為瀏覽器會自動加入 headers（User-Agent、Accept、Cookie），並依照自己的規則處理 caching 與 CORS。curl 只會送出你要求它送出的內容。若要查看瀏覽器實際送出的內容，請使用 mitmproxy 或瀏覽器的 DevTools。

Q: How do I debug a redirect that only happens for some users?

A: 檢查 redirect 是否取決於使用者送出的 headers：User-Agent、Accept-Language、Cookie，或 IP address（透過 X-Forwarded-For）。使用 curl 送出與使用者相同的 headers，或使用 WebPageTest 從使用者所在地載入頁面。

Q: What's the difference between 301 and 302 redirects?

A: 301 是 permanent，會告訴瀏覽器 cache 這個 redirect（有時是永久）。302 是 temporary，會告訴瀏覽器不要 cache。如果不確定該用哪個，請用 302——你之後隨時可以改成 301。

Q: Why does my redirect work in curl but not in the browser?

A: 可能是因為瀏覽器正在 cache 舊的 redirect，或因為瀏覽器基於 CORS 或 mixed content rules 封鎖了 redirect。請檢查瀏覽器的 DevTools console 是否有錯誤，並檢查 Cache-Control headers，看看瀏覽器是否正在使用 cached response。

Q: How do I see the headers a CDN adds?

A: 使用 curl 打到 CDN URL，然後再次使用 curl 直接打到 origin server（繞過 CDN）。比較 headers。只出現在第一個 response 中的那些，就是 CDN 加上的。

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

💡 試試這個： 在排查重新導向問題時，Redirect Checker 會追蹤完整鏈結，並顯示每一跳的狀態碼和標頭。

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

Sources

• curl documentation — curl command-line options 與行為的官方參考
• HTTPie documentation — httpie 語法與功能指南
• MDN Web Docs: HTTP redirections — HTTP redirect status codes 與行為的完整說明
• WebPageTest documentation — 如何解讀 WebPageTest results 與 headers