ロードバランサーでHTTPヘッダーを設定することをお勧めしますか？
Nginxリバースプロキシの背後に2つのngnixアプリケーションサーバーがあるセットアップを管理しています。 X-XSS-ProtectionやStrict-Transport-Securityのようなヘッダーを設定したいと思います。現在、アプリケーションサーバーとロードバランサーの両方に設定されているため、ヘッダーが複雑になっています。
Error parsing header X-XSS-Protection: 1; mode=block, 1; mode=block: expected semicolon at character position 14. The default protections will be applied.
重複するヘッダー値が同じヘッダーキーに追加されていることがわかります。私の質問はこれです：ヘッダーを設定するための一般的な慣習/受け入れられているベストプラクティスは何ですか？バックエンドにヘッダーを設定してロードバランサーから削除する必要がありますか、それともロードバランサーを1つの設定ヘッダーにする必要がありますか？
私の意見では、ヘッダーがどこに設定されているかは問題ではありません。 Nginxでヘッダーを設定する利点は、コードの変更やデプロイなどと比較して、変更が非常に簡単なことです。NginxまたはF5ロードバランサーのいずれかを使用してヘッダーを書き直さなければならないケースが2つあります。より多くの柔軟性を提供します。
質問が広すぎるため、より有用な情報を取得するには、より具体的な例を示す必要があります。
開発者として、開発環境も考慮に入れると思います。
実稼働環境とメインのプリプロッド環境にはロードバランサーしかなく、開発環境の前にはロードバランサーがありません。このため、NGinx Webサーバーでヘッダーを設定して、開発環境にもヘッダーを設定することを好みます。
これは、HTTPSを終了するかどうかにも依存します：ロードバランサーで、またはNginxで、あるいはその両方で？同じ理由で（環境の一貫性を維持するため）、セキュリティを強化するために、ロードバランサーでHTTPSを終了してから、ロードバランサーとウェブサーバー間でHTTPSへのトラフィックを再暗号化して、ウェブサーバーに直接接続しても引き続きサービスが提供されるようにします。 HTTPS。
NGinx WebサーバーがHTTPS上にない場合、特定のヘッダー（HSTS）をWebサーバーに設定しないでください。ただし、環境にこれらのヘッダーを設定しない場合に、これらのヘッダーの影響を開発およびテストする方法についての質問が明らかに発生します。ロードバランサーなし。
はい、接続を処理するのは接続フロントエンドの仕事なので、はい。アプリケーションはそれ自体で忙しいので、それを行うためだけにすべてのリソースを残すのが最善です。 SSL/TLS、共通ヘッダー、リダイレクト、バランシング、ブロッキング、ドロップなどは、アプリケーションに到達する前に処理するのが最適です。また、ボーナスとして構成の良い共通点を提供します。