現在、ELBで http://www.example.org と https://www.example.org の両方を提供しています。
http://www.example.org を指すすべてのリクエストが https://www.example.org にリダイレクトされるように設定します。
ELBはhttpsリクエストをhttpリクエストとして送信するため、以下を使用します。
server {
listen 80;
server_name www.example.org;
rewrite ^ https://$server_name$request_uri? permanent;
}
https://www.example.org に対して行われたリクエストは引き続きnginxのポート80に対して行われるため、機能しません。
私はそれを次のように書き換えることが可能であることを知っています
server {
listen 80;
server_name www.example.org;
if ($http_x_forwarded_proto != "https") {
rewrite ^(.*)$ https://$server_name$1 permanent;
}
}
しかし、私が読んだすべてのことは、if
はnginx構成内のすべてのコストで回避されるべきであり、これはすべての単一の要求に対してであろうと述べました。また、ヘルスチェック用に特別な個別の設定をセットアップする必要があることを意味します( ここで説明 : "…ELBの背後にいて、ELBがHTTPSエンドポイントとして機能し、送信のみを行っている場合サーバーへのHTTPトラフィックにより、ELBが必要とするヘルスチェックに対してHTTP 200 OK応答で応答する機能が中断されます。
ログインをnginx構成ではなくWebアプリケーションのコードに入れることを検討しています(そしてこの質問のために、それがDjangoベースのアプリケーションであると仮定しましょう)が、それがよりもオーバーヘッドになるかどうかはわかりません構成のif
。
それがそのように正しく機能している場合は、恐れることはありません。 http://wiki.nginx.org/IfIsEvil
Ifの動作に一貫性がないことに注意することが重要です。2つの同一のリクエストが与えられた場合、一方がランダムに失敗してもう一方が機能することはなく、適切なテストとifsを使用できることを理解することで。ただし、利用可能な他のディレクティブを使用するというアドバイスは、依然として非常に当てはまります。
NGINXセットアップ
server {
listen 80;
server_name www.example.org;
rewrite ^ https://$server_name$request_uri? permanent;
}
server {
listen 1443;
server_name www.example.org;
}
このソリューションは条件付きロジックを使用しますが、受け入れられた答えが示唆するように、これも問題ないと思います。参照: https://stackoverflow.com/questions/4833238/nginx-conf-redirect-multiple-conditions
また、画像のawsセキュリティ設定で追加のポートを開く必要もありません。 AWS LBでsslを終了し、httpsトラフィックをインスタンスのhttpポート80にルーティングできます。
この例では、LBヘルスチェックはアプリサーバーにルーティングされるポート80で/ healthにヒットするため、ヘルスチェックはnginxとアプリの両方が呼吸していることを検証します。
server {
listen 80 default deferred;
set $redirect_to_https 0;
if ($http_x_forwarded_proto != 'https') {
set $redirect_to_https 1;
}
if ($request_uri = '/health') {
set $redirect_to_https 0;
}
if ($redirect_to_https = 1) {
rewrite ^ https://www.example.com$request_uri? permanent;
}
...
}
これで、AWSロードバランサー設定でHTTPポート80をHTTPSポート443にリダイレクトする新しいリスナーを作成できるようになりました。これで、nginx/Apache設定に触れる必要がなくなりました。