URL 長度到底有沒有限制？深度解析瀏覽器、伺服器與協議層面的邊界

關於「URL 長度限制」的傳說眾說紛紜：有人說是瀏覽器限制，有人說 HTTP 協議無限制，也有人說伺服器會攔截。本文透過實測數據與 RFC 規範，釐清各層面的真實邊界。

一、結論先行

• HTTP/1.1 協議（RFC 7230）：未規定 URL 最大長度，僅建議伺服器支援至少 8000 字元。
• 瀏覽器端：有硬性限制，各家不同（IE ≈ 2083、Edge/Chrome ≈ 2 MB、Firefox ≈ 2 MB、Safari ≈ 80 KB）。
• 伺服器端：有配置限制，Apache LimitRequestLine 預設 8190、Nginx large_client_header_buffers 預設 4k/8k、IIS maxUrlLength 預設 260/4096。
• 實際可用長度：取決於 最短板——瀏覽器、Proxy、CDN、WAF、伺服器中最嚴格者。

二、實測案例：Java Client + Apache Module

作者實驗：Java 發送 GET 請求，Apache Module 回傳 strlen(r->args)。結果：

• URL 超過 8208 位元組 時，Java 拋出 HTTP 414 Request-URI Too Long。
• 證明伺服器端確實會攔截過長 URL，並非僅瀏覽器限制。

三、各層面限制詳細表

四、為何 POST 能傳大資料而 GET 受限？

本質差異在於 傳輸載體：

• GET：參數編碼在 Request-Line（GET /path?query HTTP/1.1），受限於第一行長度限制。
• POST：參數放在 Request Body，採用 Content-Length 或 Transfer-Encoding: chunked 分塊傳輸，不受 Request-Line 限制，理論上僅受 client_max_body_size、記憶體、磁碟配額約束。

作者以 UDP 封包類比：GET 如單一封包，POST 可拆分多個封包傳輸再重組。

五、最佳實踐建議

1. 超過 2000 字元的參數改用 POST（或分批、壓縮、Base64 後放 Body）。
2. 長查詢條件：改用 POST /search + JSON Body，或建立「查詢任務」返回 ID 輪詢。
3. 調整伺服器配置：若確需長 URL，同步調大 Apache/Nginx/IIS 相關參數，並確認中間 Proxy/CDN 放行。
4. 避免敏感資料放 URL：會殘留於瀏覽器歷史、伺服器日誌、Referer 標頭，風險極高。
5. RESTful 設計：資源識別用 Path 參數（/users/123），過濾條件用 Query String，複雜查詢改 POST。

理解各層限制來源，才能在架構設計時做出正確選型，避免上線後踩到「URL 過長」的隱形地雷。