Nginx の共通構成 - リバースプロキシ - https リダイレクト - ポートフォワーディング

第 2 レベルのディレクトリマッピング
現在、フロントエンドプロジェクトとバックエンドプロジェクトが分離されている多くのシナリオでは、通常、フロントエンド用に 1 つのポートがあり、バックエンド用に 1 つのポートがあります。

たとえば、フロントエンドは https://example.com/index.html で、呼び出しインターフェイスは https://example.com:4433 です。

この種の展開は、一部の小規模プロジェクトでは少し面倒ですが、もちろん、パブリックネットワーク環境でのクロスドメインアクセスにサブドメイン名や他のドメイン名を使用することも選択できます。

ここで話しているのは、同じドメイン名と同じポートであり、フロントエンドとバックエンドが同時にサービスにアクセスできるということです。

フロントエンドアドレス: https://example1.com

インターフェースアドレス: https://example.com

ここでは、最初に、元のサーバー構成を変更せずにテストして合格したリバースプロキシメソッドを記録します。リバースプロキシ経由で example.com/api を example.com:4443/ に直接リダイレクトします

location ^~ /api/ {
	proxy_pass  https://example.com:4433/;
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location セクションの ^~ は先頭一致として特定の文字を表しており、/api/ で始まる一致 URL ルールは次のとおりです。

通常のマッチングを意味するため、ここには記述できません。通常のルールを使用する場合、proxy_pass セクションで URI を設定することはできません。いわゆる URI は、ポート 4433 の後ろの / です。

ここで、proxy_pass の背後にあるドメイン名は https://examle.com:443/ として記述する必要があります。

/が書かれていない場合、example.com/api/index.phpにアクセスするとexample.com:4433/api/index.phpにプロキシされます。バックエンドのルートパスを見つけることができないため、/ で終わります。

非標準の HTTPS ポートリダイレクト
2083 などの非標準の https ポートで HTTP リダイレクト HTTPS アクセスをサポートする場合は、次の構成を参照してください。

error_page 497 https://$host:2083$request_uri;

この方法で構成しない場合、デフォルトでは、ユーザーが Web サイトのプロトコルについてよくわからない場合、HTTP プロトコルを使用して HTTPS Web サイトにアクセスできなくなります。

错误例：プレーン HTTP リクエストが HTTPS ポートに送信されました

HTTP
毎日の HTTPS への強制ジャンプ訪問者のセキュリティを確保するために、多くの場合、サイト全体で HTTPS アクセスを維持する必要があります。その場合は、次の構成を使用できます。

server {
    listen 80 default_server;
    server_name example.com;
    rewrite ^(.*) https://$server_name$1 permanent;
    #上面的rewrite也可以写作
    return 301 https://$host$request_uri;
}
server {
	listen 443 ssl;
	server_name example.com;
}

この方法では、80 によって監視されているすべての HTTP リンクを HTTPS ポートにリダイレクトします。

HSTS ポリシーにより HTTPS 接続が維持される
同時に、HSTS ポリシーを有効にして、次のコードを追加することで、訪問者のブラウザに HTTPS 接続の使用を強制的に継続させることもできます。

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains;preload" 常に;
max-age: 単位時間(秒)内でのHTTPS接続の強制使用を設定します。ここでは1年です。
includeSubDomains: オプション。サイトのすべてのサブドメインが同時に有効になります。
preload: オプションの非標準値。「HSTS プリロードリスト」の使用を定義するために使用されます。
always: オプション。さまざまな組み込みエラー応答を含め、すべての応答がこの応答ヘッダーを送信するようにします。

Nginx リバースプロキシ
フロントエンドとバックエンドの統合ドメイン名ポート、ロードバランシングなど、多くのリバースプロキシシナリオがあります。

location / {
    proxy_pass  http://example.com;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

パラメータ設定を完了する

location / {
	proxy_pass  http://example.com;
	proxy_redirect     off;
	proxy_set_header   Host             $host;
	proxy_set_header   X-Real-IP        $remote_addr;
	proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
	proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
	proxy_max_temp_file_size 0;
	proxy_connect_timeout      90;
	proxy_send_timeout         90;
	proxy_read_timeout         90;
	proxy_buffer_size          4k;
	proxy_buffers              4 32k;
	proxy_busy_buffers_size    64k;
	proxy_temp_file_write_size 64k;
}

ポートフォワーディング
Nginx ポートフォワーディングのパフォーマンスも非常に強力で、イントラネットデータベースやその他のサービスポートが公開されるシナリオで使用できます。

たとえば、イントラネットの MySQL データベースポート 192.168.1.2 は、Nginx が配置されているサーバーのポート 33062 を通じて公開されます。

upstream TCP3306 {
	hash $remote_addr consistent;
	server 192.168.1.2:3306;
}

server {
	listen 33062;
	proxy_connect_timeout 5s;
	proxy_timeout 300s;
	proxy_pass TCP3306;
}

Nginx の共通構成 - リバース プロキシ - https リダイレクト - ポート フォワーディング

おすすめ

Nginx の共通構成 - リバースプロキシ - https リダイレクト - ポートフォワーディング