Linux サーバーの nginx アクセス ログにある大量の http 400 エラーを解決する方法

サーバー内のエラー レコードは次のようになります:

124.65.133.242 – – [27/oct/2014:14:30:51 0800] “- ” 400 0 “-” “-”
124.65.133.242 – – [27/oct/2014:14:31:45 0800] “-” 400 0 “-” “-”
124.65.133.242 – – [ 27/oct/2014:14:31:45 0800] "-" 400 0 "-" "-"
124.65.133.242 – – [27/oct/2014:14:31:45 0800] "-" 400 0 "-" "-"

viewpoint

nginx のログ ファイルを分析したところ、通常のアクセス後に数個の 400 エラーが発生していることがわかりました。 1 ～ 6 回連続して発生する可能性があり、すべての顧客訪問で 400 エラーが生成されるわけではありません。

400 エラーを生成した以前のアクセスを観察するのは正常です。ステータス コード 200、通常のファイル、通常のソース、通常のユーザー エージェント... すべてが調和しているのに、なぜ 400 なのかエラーが発生しますか?どうですか?

注意深く観察した結果、400 エラーを生成した前回の訪問のユーザー エージェントはすべて Google Chrome ブラウザによって残されていることがわかりました。これは、400 エラーが Chrome ブラウザによって生成されたことを意味します。ただし、ローカル パケット キャプチャの後、Chrome が異常なリクエストやデータ パケットをサーバーに送信していないことが判明しました。

パケット キャプチャ分析では、Chrome がサーバーにアクセスするときに複数の接続 (通常は 5 ～ 6 の範囲) を開始したことが判明しました。要求されたリソースがそれほど多くの接続を必要としない場合、Chrome は未使用の接続を閉じます。使用される接続は、プリ接続と呼ばれます。

通常、Web サイトにアクセスすると、最初に HTML マスター ファイルが取得され、Web ページに必要な CSS、JS、画像などの他のメディア リソース ファイルにリンクされます。ファイルとメイン HTML ファイルはドメインの下にあります。事前接続とは、HTML ファイルの取得を待ってからサーバーに接続して他のファイルを取得するのではなく、HTML を取得する前に多数の TCP 接続を確立することを意味します。サーバーの処理には時間がかかるため、このテクノロジーにより Web ページのレンダリングを大幅に高速化できます。

Web ページの HTML リンクのリソースが比較的小さい場合、またはクライアントにキャッシュがありダウンロードに接続する必要がない場合、Web ページによって発行される 5 ～ 6 個の接続のうちの 1 つだけが存在する可能性があります。 Chrome ブラウザが必要ですが、その他のブラウザは閉じる必要があります。これにより、サーバーがリクエストを送信せずに接続されてしまうという問題が発生します。この場合、nginx は 400 エラーとして処理しますが、接続が閉じられているため、エラー メッセージはクライアントに送信されず、ログ ファイルにはエラーが記録されますが、ファイルには何も表示されません。パケットキャプチャ解析の現象です。

テスト
上記の分析結果を確認するのは非常に簡単です。コマンド ライン cmd.exe を開き、そこに telnet serverip 80 を入力し、接続が成功するまで待ちます。この時点で nginx ログ ファイルを確認すると、追加の 400 エラー レコードがあります。

コメント
事前接続の利点はすでに非常に明らかですが、欠点もあります。ウェブマスターがそれを最適化し、Cookie を使用しないテクノロジを使用している場合、または Webページ静的リソースとは異なるサーバーを使用する場合、Web ページに必要な CSS および JS リソースはメイン HTML と同じドメインになく、同じ IP 上にない可能性があります。その場合、事前接続は役に立たないだけでなく、 , しかし、メインの HTML サーバーにも不都合が生じます。必要な負担がかかります。

その他の理由

インターネット上で多くの人が関連記事を書いていますが、そのほとんどの理由は、ヘッダー サイズがサイズを超えて 400 の応答が発生するためです。しかし、実際には、ポートが生きているかどうかを確認するだけのポート テスト ツールのような別の可能性もあります。 lvs などもこの種の問題を引き起こす可能性があり、その場合、大量の 400 エラーがログに表示されます。

上記の問題については、nginx.conf の client_header_buffer_size とlarge_client_header_buffers の両方を増やすことで、この問題を軽減できます。

以上がLinux サーバーの nginx アクセス ログにある大量の http 400 エラーを解決する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。