宣告支援不等於實際可用
伺服器在 Alt-Svc 回應標頭中宣告支援 HTTP/3，用戶端透過 HTTP/1.1 或 HTTP/2 接收該標頭。這個標頭只是一項承諾。HTTP/3 透過 UDP 上的 QUIC 運作，因此即使 UDP 完全遭封鎖，頁面仍可能正常載入，瀏覽器也會不作提示地繼續使用 HTTP/2.
curl -sI https://server.example/ | grep -i alt-svc確認實際傳輸
只有透過 QUIC 完成的請求才能確認 HTTP/3. 請使用編譯時啟用了 HTTP/3 支援的 curl；許多系統套件沒有這項支援，此時選項會被拒絕，這並不能說明伺服器有問題。在瀏覽器開啟開發人員工具，查看通訊協定欄，這類請求會顯示 h3。首次造訪時瀏覽器可能使用 HTTP/2，因此請重新載入頁面。
curl -V | grep -i http3
curl -sS --http3-only -o /dev/null -w '%{http_version}\n' https://server.example/檢查 NGINX 設定
NGINX 除了 TCP 接聽器，還需要 QUIC 接聽器，所用版本與其建置也必須支援 QUIC。必須使用 TLS 1.3，因為 QUIC 直接使用它。重新載入前先檢查設定。Alt-Svc 中的 ma 值是用戶端記住這項承諾的時間，單位為秒，因此測試時應設定較短的時間。
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=300' always;
nginx -V 2>&1 | grep -o with-http_v3_module
sudo nginx -t在整條路徑上開放 UDP 443
最常見的失敗原因是防火牆允許 TCP 443，卻不允許 UDP 443。檢查伺服器與所有外部過濾器。可在伺服器上確認通訊端是否正在接聽。有些企業和公共網路會刻意封鎖 QUIC，因此從一個網路測試失敗，並不能證明伺服器有問題：請從另一個網路重試。
sudo ss -lunp | grep ':443'
sudo ufw allow 443/udp
sudo tcpdump -ni any udp port 443新通訊協定比較快嗎？
HTTP/3 對有封包遺失或需要切換網路的連線幫助最大，因為一個遺失的封包不會阻塞其他串流。在良好的有線連線上，差異可能很小，而伺服器的 CPU 使用量可能更高。請量測自己的實際情況，不要假定一定會更快，並為無法使用 UDP 的用戶端保留 HTTP/2。
CH-J Server Manager 中的 HTTP/3 測試
Server Diagnostics 內附 HTTP 用戶端，因此測試不依賴系統的 curl。只有完成 QUIC 傳輸後，它才會回報 HTTP/3 已確認，並且只將 Alt-Svc 視為支援宣告。若 UDP 逾時，它會指出伺服器支援狀態仍未驗證，因為原因可能出在您與伺服器之間的網路上；退回使用其他通訊協定不會被視為成功。