HTTP/3 是什麼？跟 HTTP/2 差在哪、為什麼需要 QUIC，公司網站要不要開一次看懂

HTTP/3 是網頁傳輸協定的第三代主要版本，也就是瀏覽器跟網站伺服器之間「怎麼講話」的最新規則。它最大的改變是把底下的運輸方式從用了四十多年的 TCP，換成建立在 UDP 上的 QUIC。換掉之後，網頁在手機網路不穩、Wi-Fi 切到 4G、封包掉一兩個的時候，比較不會整頁卡住，第一次連線也少等一輪。IETF 在 2022 年 6 月把它正式定為標準 RFC 9114，現在主流瀏覽器幾乎都支援。

會寫這篇，是因為我們這個月在幫自家服務換新主機時，剛好被 HTTP/3 結結實實上了一課：新主機的反向代理軟體預設就把 HTTP/3 打開了，還主動告訴瀏覽器「下次可以用 HTTP/3 來找我」，可是防火牆只放行了傳統的 TCP 443。結果就是瀏覽器照著指示去敲一扇沒開的門，敲不到才回頭走舊路。這件事讓我們重新把 HTTP/3 從頭整理一次，寫成一篇沒有網路背景也看得懂的版本。

先給趕時間的人一張速覽表，後面每一段再慢慢拆。

HTTP/3 是什麼？用送貨的比喻一次看懂

先講結論：HTTP/3 改的是「貨怎麼送」，網頁內容本身一個字都沒變。你在網址列看到的 https、網頁的 HTML、圖片、按鈕，全部照舊；改的是這些東西從伺服器搬到你手機上的那段路。

HTTP 這個詞先拆開來看。它是瀏覽器和伺服器之間的共同語言，瀏覽器說「給我首頁」，伺服器回「好，這是首頁跟它要用的 30 張圖」。語言講好了，還需要一條運輸管道把資料送過去，過去這條管道一直是 TCP。

用送貨來比喻三代的差別最好懂：

• HTTP/1.1（1997 年）：一台貨車一次只送一個包裹，送完回來才能送下一個。網頁有 30 張圖，瀏覽器只好同時叫好幾台車，路上塞成一團。
• HTTP/2（2015 年）：一台大貨車可以同時裝很多包裹，效率好很多。問題是整台車走在 TCP 這條單線道上，只要其中一個箱子掉下車，整台車都得停下來等它撿回來，後面的包裹就算完好也得陪著等。
• HTTP/3（2022 年正式標準）：改成一隊機車快遞，每個包裹各騎一台。某一台在路上掉了東西，只有那一台要回頭補，其他機車照樣送達。這隊機車走的路就叫 QUIC。

技術上的對照整理在下面這張表。看不懂的欄位先跳過沒關係，後面幾段會一個一個解釋。

表格裡的「HTTPS」「TLS」是同一件事的兩個名字：網址前面那個鎖頭代表的加密。如果還不太清楚加密憑證怎麼運作，可以先看 SSL 憑證是什麼，HTTP/3 等於把這層加密直接內建，沒有不加密的版本。

為什麼需要 HTTP/3？TCP 的三個老毛病

一句話：TCP 是 1970 年代為了有線網路設計的，今天大部分人是拿著手機、在捷運上、用時好時壞的行動網路上網，老規則開始不合身。HTTP/3 要解決的就是下面這三件事。

毛病一：一個封包掉了，大家一起等

這個問題有個專有名詞叫「線頭阻塞」（head-of-line blocking），意思就是排在隊伍最前面的人卡住，後面的人全部動不了。TCP 保證資料「照順序」送到，所以第 5 號封包掉了，就算第 6 到 20 號都已經到了，也得先放在旁邊，等第 5 號重送回來才一起交給瀏覽器。HTTP/2 把很多檔案塞進同一條 TCP 連線，反而讓這個問題更明顯：一張圖掉了一個封包，整頁的 CSS、JavaScript 一起陪等。

毛病二：連線前的寒暄太長

打開一個 https 網站之前，瀏覽器跟伺服器要先「打招呼」：TCP 握手一輪，加密的 TLS 握手再一到兩輪，招呼打完才開始傳網頁。每一輪都是一次「從你家到伺服器來回」的時間，伺服器在美國的話一輪就可能超過 150 毫秒。QUIC 把運輸和加密的招呼合併成一輪；之前來過的網站，甚至可以在第一個封包就夾帶請求，業界稱為 0-RTT（零來回）。

毛病三：換網路就斷線

TCP 用「你的 IP 位址＋埠號」來認一條連線。走出辦公室、手機從 Wi-Fi 自動切到 4G，IP 變了，對 TCP 來說就是另一個人，連線只能斷掉重來。QUIC 改用一組「連線編號」（connection ID）認人，IP 換了，編號沒變，對話可以接著講。正在上傳檔案、看影片、填長表單的人最有感。

三個毛病和 HTTP/3 的解法並排看會更清楚：

最後一列常被忽略，影響其實很深。TCP 的程式碼住在 Windows、Android、路由器的核心裡，想改進一點點都要等幾十億台設備更新。QUIC 改成在瀏覽器和伺服器程式裡實作，Google 改一版 Chrome，全世界幾週內就用上了。這也是為什麼 HTTP/3 能從實驗到標準只花了十年左右。

連線不斷線這件事，對「業務在外面用手機回客戶」的系統特別重要。我們做的 SalesKing 數位訊息平台，使用者多半是在客戶現場、在路上用手機收發訊息，網路切換是家常便飯，所以我們在換主機時才會特別去查 HTTP/3 這一層有沒有設定對。

QUIC 是什麼？HTTP/3 底下那條新路

QUIC 是 HTTP/3 用來搬資料的運輸協定，最早由 Google 在 2012 年左右開始實驗，後來交給網路標準組織 IETF 改寫，2021 年 5 月成為正式標準 RFC 9000。HTTP/3 就是「跑在 QUIC 上的 HTTP」，兩者幾乎總是一起出現。

要懂 QUIC，得先知道它底下的 UDP。把網路上的兩種老運輸方式想成兩種郵件：

• TCP 像掛號信：每封都要簽收，掉了一定補寄，而且保證照寄出的順序送到。可靠，但手續多、慢。
• UDP 像明信片：丟進郵筒就不管了，不簽收、不補寄、不保證順序。快，但會掉。過去主要拿來做視訊通話、線上遊戲、DNS 查詢這類「慢了不如不要」的事。

QUIC 的做法是：拿明信片（UDP）當載具，自己在上面加一套「簽收、補寄、排序、加密」的規則。補寄是一個包裹一個包裹各自處理，所以沒有 TCP 那種整條線一起等的問題。加密則直接用 TLS 1.3 做進協定裡，連「這是第幾號封包」這類資訊都加密，路上的設備看得到的東西比 TCP 少很多。

這也帶出一個實務上很重要的細節：HTTP/3 走的是 UDP 443 埠，傳統 https 走的是 TCP 443 埠。名字一樣叫 443，對防火牆來說是兩扇不同的門。很多人開了 HTTP/3 卻沒感覺，或是開了之後反而有人連不上，問題都出在這裡，後面會專門講。

HTTP/3 真的比較快嗎？數字要分情境看

先講結論：網路好的時候差不多，網路差的時候 HTTP/3 明顯比較穩。宣稱「開了 HTTP/3 網站快一倍」的說法，多半是挑了最差網路條件下的數字。

最常被引用的是 Google 自己在 2017 年發表的 QUIC 大規模部署論文。那是 QUIC 還沒成為標準前的早期版本，數字可以當成歷史參考：Google 搜尋的回應延遲，桌機降低 8.0%、手機降低 3.6%；YouTube 影片播到一半卡住重新緩衝的比例，桌機降 18.0%、手機降 15.3%。幅度看起來不大，但放在每天幾十億次搜尋上，是很可觀的體感差異。

叫車平台 Uber 的工程團隊也在 官方部落格 公布過，他們的乘客和司機 App 改用 QUIC 後，最慢那一批請求（尾端延遲）降低了 10 到 30%。Uber 的使用者幾乎都在移動中上網，這正好是 TCP 最吃虧的情境。

反過來也有研究提醒別過度樂觀。亞太網路資訊中心 APNIC 在 2018 年的 測量文章 指出，網路會把封包順序打亂的環境下，早期的 QUIC 會誤以為封包掉了，表現反而比 TCP 差。實作這幾年改善很多，但它提醒我們：協定沒有萬靈丹，要看實際網路。

最後兩列是我們最常看到的誤會。網站慢，九成原因是圖片沒壓、程式太重、主機太弱，這些在 網站主機怎麼選 和 Core Web Vitals 治理指南 都有整理。HTTP/3 是把路修平，車子本身如果超載，修路的效果有限。

現在有多少網站在用 HTTP/3？瀏覽器都支援嗎

答案是已經很普及：網站端大約四成，瀏覽器端超過九成五。

網站技術調查機構 W3Techs 的 統計 顯示，2026 年 7 月全球約 40% 的網站已經支援 HTTP/3。其中有一個很極端的分布：透過 Cloudflare 這類 CDN 當反向代理的網站，支援比例高達 88.8%，因為 CDN 業者在自己的機房就把 HTTP/3 做好了，網站主幾乎不用動手。

瀏覽器端，維基百科的 HTTP/3 條目 整理 caniuse 的資料，2026 年 7 月超過 95% 的主流瀏覽器支援。Chrome 從 2020 年 4 月起預設開啟，Firefox 從 2021 年 4 月的 88 版開始預設開啟，Safari 則隨 iOS 14、macOS 11 加入支援，近幾版已經對所有使用者開放。

有個有趣的現象：就算網站支援 HTTP/3，很多人的第一次造訪其實還是走 HTTP/2。原因是瀏覽器一開始不知道這個網站會講 HTTP/3，只能先用 TCP 連上，伺服器在回應裡附一句「我也有 HTTP/3 喔」（這句話叫 Alt-Svc 標頭），瀏覽器記下來，下一次才改走 QUIC。HTTP Archive 的 2024 Web Almanac 就特別說明，這個機制讓 HTTP/3 的實際使用量在統計上被低估。

比較新的做法是在 DNS 裡直接寫一筆「HTTPS 記錄」，瀏覽器查網址的時候就知道可以用 HTTP/3，第一次造訪也能直接走 QUIC。CDN 業者多半會自動幫你加，自架主機則要自己設定。

HTTP/3 跟 SEO 有關係嗎？直接沒有，間接有

直接講：Google 從沒說過 HTTP/3 是排名因素，開了不會因此多排幾名。Google 官方的 Googlebot 說明 寫得很清楚，爬蟲目前用 HTTP/1.1 和 HTTP/2 抓網頁，而且用哪一版對排名沒有影響。

間接的關係在「真實使用者體驗」。Google 的 Core Web Vitals 用的是真實 Chrome 使用者的載入數據，這些使用者大多已經在用 HTTP/3。手機使用者比例高的網站，HTTP/3 讓首位元組時間（TTFB）和最大內容繪製（LCP）在網路差時比較穩，分數會好看一點。想看自己網站的實際分數，可以用 PageSpeed Insights 查「實際使用者體驗」那一區。

所以我們的建議很務實：HTTP/3 是「順手就開」的項目，排在圖片壓縮、快取設定、主機升級之後。如果你正在處理網站速度，先把那些大項目做完，HTTP/3 是最後幫你再磨一點的工具。

開 HTTP/3 前一定要知道的坑：UDP 443 防火牆

這一段是我們這個月實際踩過的經驗，也是網路上最少人講清楚的地方。

事情是這樣：我們把幾個自家服務搬到新主機，主機上的反向代理軟體（負責接收外部連線、轉給後面程式的那一層）預設就開著 HTTP/3，每個回應都附上一句 `alt-svc: h3=":443"`，告訴瀏覽器「之後可以用 HTTP/3 來」。可是主機的 伺服器防火牆 一開始只開了 TCP 80 和 443，UDP 443 是關著的。

結果是：記住這句話的 Chrome，下次連線會先試 QUIC，對著關起來的 UDP 443 敲門，等不到回應才退回 TCP。網頁最後還是打得開，只是第一個請求多等了一段。這種問題最麻煩的地方是「不會壞、只是有時候慢一點」，很難從使用者回報抓出來。

有一個細節救了我們一部分網站：經過 CDN 代理的網域完全不受影響，因為瀏覽器的 QUIC 連線是連到 CDN 機房，CDN 再用自己的方式回源。只有直接連到主機、沒有經過 CDN 的網域會中招。最後我們在防火牆補開 UDP 443，再從外部分別用 IPv4 和 IPv6 實測，確認兩邊都有 QUIC 回應才收工。

另一個方向的坑在訪客端。很多公司的資安設備會刻意擋掉 UDP 443：資安業者 SSL Dragon 的 排錯說明 整理過，Palo Alto 的官方建議就是封鎖 QUIC，Fortinet 也有對應的設定，因為 QUIC 全程加密，設備沒辦法像檢查 TCP 那樣檢查內容。被擋的時候，Chrome 可能出現 `ERR_QUIC_PROTOCOL_ERROR`。pfSense 論壇上也有網管 直接說，很多企業網路最後都會這樣處理。

好消息是瀏覽器會自動退回 HTTP/2，所以網站主不用擔心「開了 HTTP/3 讓公司網路的人打不開」。整理成一張檢查表：

講到防護設備，順帶一提：網站的應用程式防火牆和 DDoS 防護，如果交給 CDN 做，HTTP/3 的設定也一起交給它最省事。想了解這兩層差在哪，可以看 WAF 是什麼，以及 Cloudflare 怎麼在 主機掛掉時救援。

公司網站要不要開 HTTP/3？檢查與開啟的方法

我們的判斷很簡單：要開，但要開對。成本幾乎是零，好處落在手機和網路差的訪客身上，唯一要顧的是上一段講的 UDP 443。

先檢查：你的網站現在有沒有 HTTP/3

• Chrome 開發者工具：按 F12 打開 Network（網路）分頁，在欄位標題按右鍵勾選 Protocol，重新整理兩次。看到 `h3` 就是 HTTP/3，`h2` 是 HTTP/2。第一次常是 h2，原因是前面講的 Alt-Svc 機制。
• 線上檢測工具：搜尋「HTTP/3 check」，輸入網址就能看到結果，最適合不想碰指令的人。
• curl 指令：新版 curl 可以強制用 HTTP/3 連線，最準，工程師用這個。

# 強制用 HTTP/3 連線，看回應的第一行是不是 HTTP/3
curl -sI --http3-only https://example.com | head -1

# 看伺服器有沒有宣告支援 HTTP/3（找 alt-svc 那一行）
curl -sI https://example.com | grep -i alt-svc

再開啟：依你的網站架構選做法

用 Caddy 自架的人最輕鬆，新版本預設就會開 HTTP/3。Nginx 則要 1.25 以上版本，官方的 ngx_http_v3_module 說明 有完整參數，最小設定大概長這樣：

server {
    listen 443 ssl;
    listen 443 quic reuseport;   # 多開一個 UDP 443 給 QUIC
    http2 on;

    ssl_certificate     /etc/ssl/example.crt;
    ssl_certificate_key /etc/ssl/example.key;

    # 告訴瀏覽器：下次可以用 HTTP/3 來
    add_header Alt-Svc 'h3=":443"; ma=86400' always;
}

設定改完，防火牆記得放行 UDP 443。主機放在雲端的話，通常有「主機內的防火牆」和「雲端後台的安全群組」兩層，兩層都要開。還在比較主機方案的話，台灣 VPS 與雲端主機比較 有整理各家的網路與防火牆設定方式。

如果你的網站是外包廠商做的、主機也是對方管，這些不用自己動手，直接把這段丟給廠商問一句「我們的網站有沒有開 HTTP/3、UDP 443 有沒有放行」就好。回答得出來的廠商，通常其他維運細節也比較讓人放心。

如果你的公司有內部系統要給外面的同事連線，除了速度，存取控管也一樣重要，可以延伸看 Cloudflare Zero Trust 是什麼。