nginx 中的 ERR_SPDY_PROTOCOL_ERROR 是什么意思？

Question

我和我的一些同事收到了net::ERR_SPDY_PROTOCOL_ERROR錯誤。

我們使用 ngnix 版本 1.8.0。 錯誤不穩定（難以復制），Ngnix錯誤日志也沒有這個錯誤。

您建議我們如何發現並解決這個問題？

Answer 1

我在嘗試為我在 Chrome 上ERR_SPDY_PROTOCOL_ERROR問題尋求幫助時遇到了這個問題。 認為這可能會使其他人受益。

我們的情況/解決方案：我們使用連接到EC2實例的AWS 應用程序負載均衡器。 我們在 EC2 代理上運行的腳本之一是來自客戶端瀏覽器的請求。 我們最近更新了腳本 - 沒有相關更改 - 並注意到 Chrome 和 Safari 對代理腳本的請求開始失敗。 Chrome 顯示ERR_SPDY_PROTOCOL_ERROR錯誤，當我們ERR_SPDY_PROTOCOL_ERROR時，我們可以看到此請求使用的是 HTTP/2。 Firefox 請求繼續正常工作。

我們的解決方案：我們關閉了 ALB 中的 HTTP/2 支持。 一下子就解決了問題。

AWS CLI 命令：

aws elbv2 modify-load-balancer-attributes --load-balancer-arn <your_load_balancer_arn> --attributes Key=routing.http2.enabled,Value=false

Answer 2

我遇到了同樣的問題，檢查 Nginx 分區/硬盤驅動器中是否有足夠的空間，我們添加了一些，它對我們有用。

Answer 3

TL;DR ：如果您正在緩存資產，請檢查您的 nginx 服務器上的驅動器空間。

我們的場景

我不確定在哪里發布我的答案，因為在 Chrome 中獲取ERR_SPDY_PROTOCOL_ERROR時這可能是一個邊緣情況（以及在 Firefox 中等效的“加載資源失敗”錯誤）。 但是這篇文章幫助我縮小了罪魁禍首。 它不是標題、gzip、重定向或 adblock/ublock。

我們從機器上部署了 2 個 Web 應用程序，並且兩者都運行良好。 最近，我們部署了對緩存資產進行更改的應用程序之一。 部署完成后，我們立即從 Chrome 獲取ERR_SPDY_PROTOCOL_ERROR 。 有趣的是，它收到了HTTP 200 ，如果您直接導航到資產，Chrome 將呈現資產。 但是，在頁面上加載資產會導致它失敗。

有趣的是，另一個 Web 應用程序非常好。 調查 Chrome 上的網絡內部結構，我們發現服務器正在關閉連接。 幾個小時后，我們確定這是因為我們的 nginx 服務器已經耗盡了驅動器空間。 我不知道為什么當您直接導航到資產時，這會導致資產正確加載，但在加載頁面時會失敗，但清除空間立即解決了問題。

Answer 4

正如您從其他答案中可以看出的那樣，很多不同的事情都可能導致這種情況。 對我來說，我有一個其他瀏覽器忽略的格式錯誤的標頭（一個額外的: ）。 唯一的答案是調試提示，在加載損壞的頁面時檢查 Chrome 的 net-internals 事件：chrome://net-internals/#events

對我來說，當我看到這一行時，我知道這是一個標題問題

t=65422 [st=53]      HTTP_TRANSACTION_READ_HEADERS  [dt=4]
                 --> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR) 

從標頭響應中刪除額外的:后，HTTP/2 開始在 Chrome 中工作。 我建議從您的服務器獲取原始響應並進行非常仔細的檢查以確保沒有語法錯誤。

Answer 5

似乎有很多潛在的原因。 我今天打的是標題行

add_header X-Frame-Options：拒絕；

出於某種原因，當前的 chrome 會使用 ssl+http2。 其他 X-Frame 標頭似乎沒有問題。

Answer 6

這是 Chromium 瀏覽器和某些防病毒程序（例如 AVG 和 Avast）之間存在的已知問題，尤其是在使用 SSL 連接時。 它無法在用戶端解決。 網站開發人員有責任防止此問題的發生。

Web 開發人員的文檔在這里： http : //dev.chromium.org/spdy/spdy-best-practices

以下是該文章中未具體提及的一些對開發人員有用的提示：

• 使用標頭和重定向時要格外小心，尤其是 301 和 302 的
• 將您的所有包含保存在與您的域名訪問相同的目錄中或下，而不是在服務器中的目錄之上。 防病毒軟件無法在那里訪問它們。 為了保護您的包含文件，請在包含目錄中創建一個 .htaccess 文件並簡單地寫一行：拒絕所有人
• 啟用 Gzip 壓縮。 如果您使用 cPanel，這可以在您的網站優化設置中完成。
• 保持 .htaccess 文件簡單。 切換服務器輸出以創建不同的文件擴展名和重定向用戶客戶端將產生不必要的沖突。

根據我的經驗，這個問題似乎只有在使用 Sessions 存儲和傳遞數據時才會發生。 Cookies、Get 和 Post 似乎不受影響。

希望這可以幫助。

Answer 7

對我來說，是 Nginx 配置不允許 OPTIONS 方法。 我只將 GET|PUT|POST|DELETE 列入白名單，所以當 Chrome 嘗試發送 OPTIONS 方法時，天知道為什么**，錯誤被重現。

打開 Firefox 並重復請求，然后查看網絡檢查器以檢查是否正在發送任何 OPTIONS 請求。

** 可能是為了檢查 X-Frame-Options 或 HSTS 驗證。

Answer 8

我有一個網站這樣做，結果是有人忘記將“位置：”放在 index.php 第一行的 PHP 重定向中，使標題無效。 顯然只有 Chrome 關心，其他瀏覽器仍然可以正常加載。

Answer 9

與 OP 一樣，這對我來說是一個間歇性問題，僅在 AJAX 請求 > 2mb 大小時發生。

在我們從 AWS 經典 ELB 遷移到 ALB 后，問題開始出現。

我通過卸載 Chrome，刪除我的用戶配置文件（在 Mac 上刪除~/Library/Application Support/Google/Chrome ），然后重新安裝來解決此問題。

Answer 10

我最近在服務器升級后看到了這個錯誤。

我在 Chrome 中為所有用戶看到它，但只是間歇性地。

通過讓所有用戶使用 Chrome 的“清空緩存和硬重新加載”刷新功能，我能夠為所有用戶解決這個問題。 （Chrome 工具 F12，右鍵單擊刷新按鈕）

我懷疑它與緩存的有關正在使用的 SSL 證書的內容有關。

Answer 11

檢查您的代理緩存路徑的位置 - 檢查它是否存在，是否有空間，以及權限和所有者是否允許nginx進程寫入該路徑。

例如nginx.conf（片段）

proxy_cache_path /proxy_cache levels=1:2 keys_zone=danger_zone:10m inactive=60m;

...然后檢查/proxy_cache路徑是否由nginx擁有和寫入。

Answer 12

就我而言，我通過增加塊大小解決了這個問題：

http2_chunk_size             300k;

Answer 13

如果你得到

ERR_HTTP2_PROTOCOL_ERROR

或者

ERR_SPDY_PROTOCOL_ERROR

在 Chrome 或 Safari 瀏覽器中使用 Nginx Content-Security-Policy，首先通過訪問 chrome 隱藏界面來檢查此問題： chrome://net-internals/#events並選擇 HTTP/2 選項卡下的“實時 HTTP/2 會話”按鈕。

如果您在刷新后針對您的域收到類似以下內容：

HTTP2_SESSION_RECV_INVALID_HEADER

--> error = "標題名稱中的字符無效。"

您應該使用以下方法編寫 CSP 標頭：

add_header Content-Security-Policy "<values>";

這種方法對我來說效果很好。

注意：CSP 中不允許出現空格。 僅使用空格來區分策略參數及其值。 要在 chrome 中重現此問題，您可以使用add_header Content-Security-Policy: "<values>"; 其中有額外的:這將被視為無效。

Answer 14

我們目前的結構是

AWS ELB=>Nginx=>JBoss

它提示我們同樣的crome錯誤ERR_SPDY_PROTOCOL_ERROR

它在沒有 ELB 默認啟用的 http2 的情況下正常工作，我們不希望它被禁用。 在進一步調查中發現我們的 JBoss 服務器正在壓縮響應。我們禁用了它並且一切正常。