nginxのERR_SPDY_PROTOCOL_ERRORはどういう意味ですか？
私と同僚の何人かはnet::ERR_SPDY_PROTOCOL_ERRORエラーを受け取りました。
Ngnixバージョン1.8.0を使用します。エラーは安定しておらず（複製が困難）、Ngnixエラーログにはこのエラーがありません。
これを見つけて解決するにはどうすればいいですか？
ChromeでERR_SPDY_PROTOCOL_ERRORで直面していた問題のヘルプを見つけようとしたときに、この質問に出会いました。これは他の人に利益をもたらすかもしれないと思った。
私たちの状況/解決策：AWS Application Load BalancerをEC2インスタンスに接続して使用します。 EC2で実行するスクリプトの1つは、クライアントブラウザーからのリクエストをプロキシします。最近スクリプトを更新しました-関連する変更はありません-プロキシスクリプトへのChromeとSafariリクエストの両方が失敗し始めたことに気付きました。 Chromeは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
私は同じ問題を抱えていました。Nginxパーティション/ HDDに十分なスペースがあるかどうかを確認してください。いくつか追加して、うまくいきました。
TL; DR：アセットをキャッシュする場合は、nginxサーバーのドライブ容量を確認します。
私たちのシナリオ
ChromeのERR_SPDY_PROTOCOL_ERROR（およびFirefoxの同等の「リソースの読み込みに失敗」エラー）を取得する際にEdgeのケースになる可能性があるため、これに対する回答をどこに投稿すればよいかわかりません。しかし、この投稿は犯人を絞り込むのに役立ちました。ヘッダー、gzip、リダイレクト、またはadblock/ublockではありませんでした。
マシンからデプロイされた2つのWebアプリケーションがあり、どちらも完全に正常に実行されていました。最近、キャッシュされたアセットに変更を加えたアプリケーションの1つをデプロイしました。デプロイが完了すると、すぐにChromeからERR_SPDY_PROTOCOL_ERRORを取得しました。おもしろいことに、HTTP 200を受け取っていたので、アセットに直接移動すると、Chromeがアセットをレンダリングします。ただし、ページにアセットをロードすると失敗します。
興味深いことに、他のWebアプリケーションはまったく問題ありませんでした。 Chromeのネット内部を調査したところ、サーバーが接続を閉じていることがわかりました。数時間後、nginxサーバーのドライブ領域が不足したことが原因であると判断しました。直接ナビゲートするとアセットが適切にロードされるのはなぜなのかわかりませんが、ページをロードすると失敗しますが、スペースをクリアするとすぐに問題が修正されます。
他の答えからもわかるように、さまざまなことが原因です。私にとって、他のブラウザーが無視しているだけの不正なヘッダーがありました（余分な:）。これに対する唯一の答えは、デバッグのヒントです。破損したページの読み込み中に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で動作を開始しました。サーバーから生の応答を取得し、構文エラーがないことを確認するために非常に詳細な検査を行うことをお勧めします。
多くの潜在的な原因があるようです。今日ヒットしたのはヘッダー行
add_header X-Frame-Options：拒否;
現在のchromeは、何らかの理由でssl + http2でそれを禁止します。他のX-Frameヘッダーは問題ないようです。
私にとっては、OPTIONSメソッドを許可しなかったNginx構成でした。 GET | PUT | POST | DELETEのみをホワイトリストに登録したので、ChromeがOPTIONSメソッドを送信しようとしたときに、神は理由を知っているため**、エラーが再現されました。
Firefoxを開いてリクエストを繰り返し、ネットワークインスペクターでOPTIONSリクエストが送信されているかどうかを確認します。
** X-Frame-OptionsまたはHSTS検証を確認する可能性があります。
これは、特にSSL接続を使用している場合、ChromiumブラウザとAVGやAvastなどの特定のウイルス対策プログラムの間に存在する既知の問題です。ユーザーの側では解決できません。この問題の発生を防ぐのは、Webサイト開発者の責任です。
Web開発者向けのドキュメントは次のとおりです。 http://dev.chromium.org/spdy/spdy-best-practices
その記事で特に言及されていない開発者向けの役立つヒントを次に示します。
- ヘッダーとリダイレクト、特に301と302を使用する場合は特に注意してください
- すべてのインクルードは、サーバーのディレクトリの上ではなく、ドメイン名アクセスと同じディレクトリ内または下に保管してください。アンチウイルスはそこにアクセスできません。インクルードファイルを保護するには、includesディレクトリに.htaccessファイルを作成し、1行だけを記述します：Deny from all
- Gzip圧縮を有効にします。 cPanelを使用する場合、これはWebサイト最適化設定で実行できます。
- .htaccessファイルをシンプルにしてください。サーバー出力を切り替えてさまざまなファイル拡張子を作成し、ユーザークライアントをリダイレクトすると、不必要な競合が発生します。
私の経験では、この問題はセッションを使用してデータを保存および渡すときにのみ発生するようです。 Cookie、GetおよびPostは影響を受けないようです。
お役に立てれば。
OPと同様に、これは私にとって断続的な問題であり、サイズが2 MBを超えるAJAXリクエストでのみ発生しました。
この問題は、AWSクラシックELBからALBに移行した後に発生し始めました。
これを解決するには、Chromeをアンインストールし、ユーザープロファイルを削除して（Macでは~/Library/Application Support/Google/Chromeの内容を削除して）、再インストールします。
サーバーのアップグレード後に最近このエラーが発生しました。
Chromeのすべてのユーザーに表示されていましたが、断続的にしか表示されませんでした。
サイトのChromeの「空のキャッシュとハードリロード」更新機能を使用することで、すべてのユーザーの問題を解決することができました。 （ChromeツールのF12、更新ボタンを右クリック）
使用されているSSL証明書についてキャッシュされている何かに関連していると思われます。
私の場合、チャンクサイズを増やすことでこれを解決しました：
http2_chunk_size 300k;
プロキシキャッシュパスの場所を確認します-プロキシキャッシュパスが存在し、スペースがあり、アクセス許可と所有者がnginxプロセスにパスへの書き込みを許可していることを確認します。
例：nginx.conf（スニペット）
proxy_cache_path /proxy_cache levels=1:2 keys_zone=danger_zone:10m inactive=60m;
...次に、/proxy_cacheパスがnginxによって所有され、書き込み可能であることを確認します。
私はそれをしているサイトを持っていましたが、誰かがindex.phpの最初の行のPHPリダイレクトに "Location："を置くのを忘れていたことが判明しました。どうやらChromeだけが気になったようですが、残りのブラウザはそれをうまくロードしました。