Nginx proxy_pass の / スラッシュによって引き起こされた殺人事件の詳細な説明

背景

nginx サーバーモジュールは 2 つのサーバーにプロキシする必要があるため、異なるサーバーを区別して転送するために異なる場所のパスが使用されます。

冒頭にこう書かれていた

位置 / {
   proxy_pass http://server1/;
}

場所 / インデックス {
   proxy_pass http://server2/;
}

しかし、server1 にサービスパス /indexNew があることを忘れていたため、server1 にプロキシされ、404 の問題が発生しました。そこで、緊急に構成を次のように変更しました。

場所 /indexNew {
   proxy_pass http://server1/;
}

位置 / {
   proxy_pass http://server1/;
}

場所 / インデックス {
   proxy_pass http://server2/;
}

問題現象

その結果、リクエストは server1 に到達しますが、エラーメッセージは POST がサポートされていないというものです。

{
	「ステータス」: 500,
	"メッセージ": "http://172.28.72.117/-リクエストメソッド 'POST' はサポートされていません",
	"結果"： {}
}

これは、当時アプリケーションから返されたエラーです。nginx をチェックしましたが、エラーはありませんでした。非常に奇妙でした。コードを見ると、/indexNew は確かに POST メソッドであるのに、なぜサポートされていないというエラーが報告されたのでしょうか。

まず、nginx のさまざまな場所の書き込み方法の一致する順序は次のとおりです。

分析する

nginxログにエラーがないので、nginxからアプリケーションへのパケットをキャプチャしてみてください。

tcpdump コマンドを使用してパケットをキャプチャする

tcpdump -w dataAll_normal.pcap -i eth0 -s0 ポート8888

上記のコマンドと同様にパケットをキャプチャし、Wireshark 経由で、/indexNew に関連する http トラフィックパケットがまったく見つからないことがわかります。

次のように場所を変更してみてください

場所 /indexNew {
   proxy_pass http://server1;
}

位置 / {
   proxy_pass http://server1/;
}

場所 / インデックス {
   proxy_pass http://server2/;
}

唯一の違いは、/indexNewのproxy_passの最後のスラッシュ/が削除されていることです。パケットをキャプチャし続けると、/indexNewパケットが検索できることがわかります。

これは変更が正しいことを示します。

エラーを元に戻し、パッケージをキャプチャしようとしますが、/indexNew パッケージを検索できない場合は、IDE を介してアプリケーションをリモートデバッグします。

アプリケーションの URL に /indexNew がなかったため、当然 Wireshark パッケージでも見つけることができませんでした。。。

これは、nginx がアプリケーションを転送する場合、アクセスパスが/のみになるためです。

プロジェクト内のリクエストパス/とのインターフェースは、実際にはGETメソッドです

location の proxy_pass の構文を詳しく見てみましょう。確かに次のようになります。proxy_pass の末尾に / があり、一致する場所のパスが削除され、後続の URL PATH が転送用にインターセプトされます。

したがって、proxy_pass の最後の / の意味に注意して慎重に使用する必要があります。これは、100% の情報転送ではなく、パス要求情報を変更します。

Nginx proxy_pass の / スラッシュが原因の悲惨な事件に関するこの記事はこれで終わりです。Nginx proxy_pass スラッシュに関するその他の関連コンテンツについては、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: