nginx 構成ガイドを作成する

ネット 2023-10-04 18:40:27 訪問数: null

nginx.confの設定

Nginx インストール ディレクトリでnginx.confファイルを見つけます。このファイルは、Nginx の基本的な機能構成を担当します。

プロフィールの概要

Nginx のメイン設定ファイル ( conf/nginx.conf) は次の構造で構成されています。

構成ブロック 機能説明
グローバルブロック Nginxの動作に関するグローバル設定
イベントブロック ネットワーク接続に関する設定
httpブロック プロキシ、キャッシュ、ログ、仮想ホストなどの構成。
サーバーブロック 仮想ホストのパラメータ設定 (1 つの http ブロックに複数のサーバー ブロックを含めることができます)
ロケーションブロック リクエストのルーティングとページの処理方法を定義する

画像.png

設定ファイルの例

比較的完全な構成ファイルの例は次のとおりです。

# 全局段配置
# ------------------------------

# 指定运行nginx的用户或用户组，默认为nobody。
#user administrator administrators;

# 设置工作进程数，通常设置为等于CPU核心数。
#worker_processes 2;

# 指定nginx进程的PID文件存放位置。
#pid /nginx/pid/nginx.pid;

# 指定错误日志的存放路径和日志级别。
error_log log/error.log debug;

# events段配置信息
# ------------------------------
events {
    # 设置网络连接序列化，用于防止多个进程同时接受到新连接的情况，这种情况称为"惊群"。
    accept_mutex on;

    # 设置一个进程是否可以同时接受多个新连接。
    multi_accept on;

    # 设置工作进程的最大连接数。
    worker_connections  1024;
}

# http配置段，用于配置HTTP服务器的参数。
# ------------------------------
http {
    # 包含文件扩展名与MIME类型的映射。
    include       mime.types;

    # 设置默认的MIME类型。
    default_type  application/octet-stream;

    # 定义日志格式。
    log_format myFormat '$remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for';

    # 指定访问日志的存放路径和使用的格式。
    access_log log/access.log myFormat;

    # 允许使用sendfile方式传输文件。
    sendfile on;

    # 限制每次调用sendfile传输的数据量。
    sendfile_max_chunk 100k;

    # 设置连接的保持时间。
    keepalive_timeout 65;

    # 定义一个上游服务器组。
    upstream mysvr {   
      server 127.0.0.1:7878;
      server 192.168.10.121:3333 backup;  #此服务器为备份服务器。
    }

    # 定义错误页面的重定向地址。
    error_page 404 https://www.baidu.com;

    # 定义一个虚拟主机。
    server {
        # 设置单个连接上的最大请求次数。
        keepalive_requests 120;

        # 设置监听的端口和地址。
        listen       4545;
        server_name  127.0.0.1;

        # 定义location块，用于匹配特定的请求URI。
        location  ~*^.+$ {
           # 设置请求的根目录。
           #root path;

           # 设置默认页面。
           #index vv.txt;

           # 将请求转发到上游服务器组。
           proxy_pass  http://mysvr;

           # 定义访问控制规则。
           deny 127.0.0.1;
           allow 172.18.5.54;          
        } 
    }
}

locationパスマッピングの詳しい説明

フォーマット：

location [ = | ~ | ~* | !~ | !~* | ^~ | @ ] uri {...}

各マークの説明：

  • =： 完全に一致。一致が成功した場合は、検索を直ちに停止し、リクエストを処理します。
  • ~: 大文字と小文字を区別して、通常のマッチングを実行します。
  • ~*: 大文字と小文字を区別せずに、通常のマッチングを実行します。
  • !~: 通常の一致、大文字と小文字の区別、および非一致。
  • !~*: 通常の一致、大文字と小文字を区別しない非一致。
  • ^~: 前方一致。一致が成功すると、他には何も一致せずlocation、正規表現は照会されません。
  • @:指定された名前はlocation、主に や などの内部リダイレクト要求に使用されerror_pageますtry_files。
  • uri: 照合するリクエスト文字列。通常の文字列を使用することも、正規表現を含めることもできます。

優先順位と例

優先順位: 特定の識別子なし < ^~< =< 通常​​の一致 ( ~、~*、!~、!~*)

例：

location = / {
    # 精确匹配 /，主机名后面不能带任何字符串
    # http://abc.com [匹配成功]
    # http://abc.com/index [匹配失败]
}

location ^~ /img/ {
    # 以 /img/ 开头的请求，都会匹配上
    # http://abc.com/img/a.jpg [匹配成功]
    # http://abc.com/img/b.mp4 [匹配成功]
}

location ~* /Example/ {
    # 忽略 uri 部分的大小写
    # http://abc.com/test/Example/ [匹配成功]
    # http://abc.com/example/ [匹配成功]
}

location /documents {
    # 如果有正则表达式可以匹配，则优先匹配正则表达式
    # http://abc.com/documentsabc [匹配成功]
}

location / {
    # http://abc.com/abc [匹配成功]
}

リバースプロキシ

リバース プロキシは Nginx のコア機能の 1 つで、Nginx がクライアントからのリクエストをバックエンド サーバーに転送し、バックエンド サーバーからの応答をクライアントに返すことができるため、クライアントは Nginx と直接通信しているように感じられます。バックエンドサーバー。

画像.png

基本構成

Nginx をリバース プロキシとして構成するには、locationブロック内のディレクティブを使用する必要がありますproxy_pass。

location /some/path/ {
    proxy_pass http://your_backend_address;
}

共通コマンド

  • proxy_pass: バックエンドサーバーのアドレスを定義します。
  • proxy_set_header: クライアントからプロキシ サーバーに渡されるリクエスト ヘッダーを変更します。
  • proxy_hide_header: プロキシ サーバーから返された応答ヘッダーを非表示にします。
  • proxy_redirect:プロキシ サーバーから返された応答ヘッダーのLocationおよびRefreshヘッダー フィールドを変更します。

構成例

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

この構成では、example.comに送信されたすべてのリクエストは にプロキシされますlocalhost:8080。

予防

  1. proxy_passディレクティブを使用するときは、バックエンド サーバーが利用可能であることを確認してください。そうでない場合、Nginx はエラーを返します。
  2. proxy_set_headerバックエンド サーバーが正しい要求ヘッダーを確実に受信するために使用します。
  3. バックエンド サーバーと Nginx が異なるマシン上にある場合は、ネットワーク接続が安定していることを確認してください。

リバース プロキシは、Web サイトのパフォーマンスと信頼性を向上させるだけでなく、負荷分散、静的コンテンツのキャッシュ、メンテナンス、セキュリティなどのさまざまな目的にも使用できます。

負荷分散

複数のサーバーがある場合、プロキシ サーバーは、ルールに従って指定されたサーバーにリクエストを振り分けて処理します。

画像.png

ポリシー名 説明する 例
RR (ラウンドロビン) デフォルトの負荷分散方法は、時系列順に異なるバックエンド サーバーに 1 つずつ割り当てられます。 upstream web_servers { server localhost:8081; server localhost:8082; }
ホットスタンバイ プライマリ サーバーに障害が発生すると、トラフィックはバックアップ サーバーに転送されます。 upstream web_servers { server 127.0.0.1:7878; server 192.168.10.121:3333 backup; }
重み 事前に設定された重みに従ってリクエストを分散します。重みが高いサーバーほど、より多くのリクエストを受け取ります。 upstream web_servers { server localhost:8081 weight=1; server localhost:8082 weight=2; }
ip_ハッシュ クライアント IP アドレスのハッシュ結果に基づいてリクエストを分散し、特定のクライアント IP に対するリクエストが常に同じバックエンド サーバーに送信されるようにします。 upstream test { ip_hash; server localhost:8080; server localhost:8081; }
フェア（第三者） リクエストはバックエンド サーバーの応答時間に基づいて割り当てられ、応答時間が短いものが優先されます。 upstream backend { fair; server localhost:8080; server localhost:8081; }
url_hash (サードパーティ) リクエストされた URL のハッシュ結果に基づいてリクエストを分散し、同じ URL に対するリクエストが常に同じバックエンド サーバーに送信されるようにします。 upstream backend { hash_method crc32; hash $request_uri; server localhost:8080; server localhost:8081; }

これらの負荷分散戦略は、実際のアプリケーションのシナリオとニーズに応じて選択して組み合わせることができます。

動的分離と静的分離を構成する

動的と静的な分離は一般的な Web サーバー最適化戦略であり、主にサーバーの応答速度を向上させ、サーバーへの負荷を軽減します。Nginx では、動的と静的の分離は非常に簡単に実現できます。

画像.png

動的分離と静的分離の基本概念:

動的コンテンツと静的コンテンツの分離とは、動的コンテンツと静的コンテンツを別々に処理することを指します。静的コンテンツには通常、画像、CSS、JavaScript、HTML ファイルなどが含まれます。これらのコンテンツは頻繁に変更する必要はありません。PHP、ASP、JSP、サーブレットなどによって生成されたコンテンツなど、動的コンテンツは頻繁に変更されます。

Nginx 構成の動的および静的分離

  1. 静的コンテンツのエイリアスまたはルート ディレクトリを直接設定します。
location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
    root /path/to/static/files;
    expires 30d;  # 设置缓存时间
}

上記の構成では、すべての静的ファイルが/path/to/static/filesディレクトリに保存されます。expiresディレクティブは静的ファイルのキャッシュ時間を設定します。

  1. エイリアス alias を使用します。

静的ファイルがプロジェクトのメイン ディレクトリにない場合は、 を使用してalias静的ファイルの実際のパスを指定できます。

location /static/ {
    alias /path/to/static/files/;
}

この構成では、URL は/static/ファイル システムにマップされます/path/to/static/files/。

  1. エージェントの動的コンテンツ:

動的コンテンツの場合、Tomcat、uWSGI などのバックエンド アプリケーション サーバーにリクエストをプロキシする必要がある場合があります。

location / {
    proxy_pass http://backend_server_address;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

注意事項:

  • 404 エラーを回避するために、静的ファイル パスが正しく構成されていることを確認してください。
  • ディレクティブを使用してexpires静的コンテンツのキャッシュを設定すると、サーバーの負荷が軽減され、ページの読み込み速度が向上します。
  • 動的ファイルと静的ファイルを分離すると、サーバーの応答速度が向上するだけでなく、バ​​ックエンド サーバーの負荷も軽減されます。これは、静的ファイルは通常、バックエンド サーバーにプロキシする必要がなく、Nginx によって直接処理されるためです。 。

静的リソースの最適化

静的リソースの伝送効率を向上させるために、Nginx は次の 3 つの主要な最適化命令を提供します。

  • sendfile
  • tcp_nopush
  • tcp_nodelay

sendfileコマンド

sendfile効率的なファイル転送モードを有効にするために使用されます。システム カーネル の関数を呼び出すことによって実装されるためsendfile、ファイルの複数のコピーが回避され、ユーザー モードとカーネル モード間の切り替えが減り、静的ファイルの転送効率が向上します。

従来の静的リソース要求プロセス:

  1. クライアントはネットワーク インターフェイスを介してサーバーにリクエストを送信します。
  2. オペレーティング システムは、これらのリクエストをサーバー側アプリケーションに渡します。
  3. サーバー アプリケーションがリクエストを処理します。
  4. 処理が完了すると、オペレーティング システムはネットワーク アダプターを介して処理結果をクライアントに渡します。

画像.png

プロジェクト 説明する
文法 `ファイルを送信 オフ`
デフォルト値 sendfile off
構成の場所 http块、server块、location块

tcp_nopush および tcp_nolay 命令

tcp_nopush

sendfileがオンの場合にtcp_nopushも有効にできます。その主な目的は、ネットワーク データ パケットの伝送効率を向上させることです。

プロジェクト 説明する
文法 `tcp_noプッシュオン オフ`
デフォルト値 tcp_nopush off
構成の場所 http块、server块、location块

tcp_nodelay

keep-aliveこれは、接続が開いている場合にのみtcp_nodelay有効になります。その目的は、ネットワーク データ パケットのリアルタイム パフォーマンスを向上させることです。

プロジェクト 説明する
文法 `tcp_nodelay オン オフ`
デフォルト値 tcp_nodelay on
構成の場所 http块、server块、location块

tcp_nopush動作原理は、バッファを設定し、バッファがいっぱいになった場合にのみデータを送信することで、ネットワークのオーバーヘッドを大幅に削減できます。

静的リソース圧縮

データ送信プロセス中に、さらに最適化するために、Nginx は送信リソースを圧縮する gzip モジュールを導入します。これにより、データ送信量が削減され、送信効率が向上します。

画像.png

Nginx の静的リソース圧縮は、http ブロック、server ブロック、location ブロックで構成できます。関連する主なモジュールは次のとおりです。

  • ngx_http_gzip_module モジュール(組み込み)
  • ngx_http_gzip_static_module モジュール
  • ngx_http_gunzip_module モジュール

Gzip モジュール構成ディレクティブ

  1. gzip : gzip 関数をオンまたはオフにします。

    • 文法：gzip on | off
    • デフォルト値:gzip off
    • 設定場所: http ブロック、サーバー ブロック、ロケーション ブロック

  2. gzip_types : 応答の MIME タイプに基づいて gzip 圧縮を選択的に有効にします。

    • 文法：gzip_types mime-type
    • デフォルト値:gzip_types text/html
    • 設定場所: http ブロック、サーバー ブロック、ロケーション ブロック
    • 例：gzip_types application/javascript

  3. gzip_comp_level : Gzip 圧縮の程度を設定します。レベルは 1 ～ 9 です。

    • 文法：gzip_comp_level level
    • デフォルト値:gzip_comp_level 1
    • 設定場所: http ブロック、サーバー ブロック、ロケーション ブロック

  4. gzip_vary : "Vary:Accept-Encoding" 応答ヘッダーを伝送するかどうかを設定します。

    • 文法：gzip_vary on|off
    • デフォルト値:gzip_vary off
    • 設定場所: http ブロック、サーバー ブロック、ロケーション ブロック

  5. gzip_buffers : 要求された圧縮を処理するバッファの数とサイズ。

    • 文法：gzip buffers number size
    • デフォルト値:gzip_buffer 32 4k | 16 8K
    • 設定場所: http ブロック、サーバー ブロック、ロケーション ブロック

  6. gzip_disable : クライアントのブラウザ フラグに基づいて、gzip 関数を選択的にオンまたはオフにします。

    • 文法：gzip_disable regex
    • デフォルト値:gzip_disable -
    • 設定場所: http ブロック、サーバー ブロック、ロケーション ブロック
    • 例：gzip_disable "MSIE [1-6]."

  7. gzip_http_version : 異なる http プロトコル バージョンの gzip 機能を選択的にオンまたはオフにします。

    • 文法：gzip_http_version 1.0 | 1.1
    • デフォルト値:gzip_http_version 1.1
    • 設定場所: http ブロック、サーバー ブロック、ロケーション ブロック

  8. gzip_min_length : 応答コンテンツのサイズに基づいて gzip 関数を使用するかどうかを決定します。

    • 文法：gzip_min_length length
    • デフォルト値:gzip_min_length 20
    • 設定場所: http ブロック、サーバー ブロック、ロケーション ブロック

  9. gzip_proxied : nginx サーバーからバックグラウンド サーバーに返された結果を gzip 圧縮するかどうかを設定します。

    • 文法：gzip_proxied off | expired | no-cache | no-store | private | no_last_modified | no_etag | auth | any
    • デフォルト値:gzip_proxied off
    • 設定場所: http ブロック、サーバー ブロック、ロケーション ブロック

Gzip と sendfile の共存の問題

Gzip はアプリケーション内で圧縮を実行し、sendfile はアプリケーションのユーザー プロセスをバイパスして、システムのネットワーク デバイスを介して静的リソース ファイルを直接送信できます。2 つの間の競合を解決するために、Nginx はngx_http_gzip_static_moduleモジュールgzip_staticディレクティブを提供します。

画像.png

  • gzip_static : 静的ファイルを事前に圧縮します。
    • 文法：gzip_static on|off|always
    • デフォルト値:gzip_static off
    • 設定場所: http ブロック、サーバー ブロック、ロケーション ブロック

上記の構成により、Nginx は静的リソースを効果的に圧縮し、データ送信効率を向上させると同時に、sendfile 関数と併用して効率的なリソース送信を保証します。

クロスドメイン

Cross-Origin Resource Sharing (CORS) は、どの Web サイトがリソースにアクセスできるかを制御するセキュリティ ポリシーです。クロスドメインの問題は、フロントエンド アプリケーションとバックエンド API が異なるドメイン上にある場合によく発生します。Nginx は、応答ヘッダーを設定することで、この問題の解決に役立ちます。

画像.png

location / {
    # 其他配置...

    # 设置允许来自所有域名请求。如果需要指定域名，将'*'替换为您的域名。
    add_header 'Access-Control-Allow-Origin' '*';

    # 允许的请求方法。
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';

    # 允许的请求头。
    add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';

    # 允许浏览器缓存预检请求的结果，单位为秒。
    add_header 'Access-Control-Max-Age' 1728000;

    # 允许浏览器在实际请求中携带用户凭证。
    add_header 'Access-Control-Allow-Credentials' 'true';

    # 设置响应类型为JSON。
    add_header 'Content-Type' 'application/json charset=UTF-8';

    # 针对OPTIONS请求单独处理，因为预检请求使用OPTIONS方法。
    if ($request_method = 'OPTIONS') {
        return 204;
    }
}

注: 運用環境では、セキュリティ上の理由からこれを使用せず'Access-Control-Allow-Origin' '*'、代わりに正確なドメイン名を指定することをお勧めします。

アンチホットリンク

画像.png

アンチホットリンクとは、他の Web サイトが Web サイトのリソース (写真、ビデオなど) に直接リンクして、サーバーの帯域幅を消費することを防ぐことを指します。ngx_http_referer_moduleNginx は、ホットリンク防止機能の実装に使用される非常に便利なモジュールを提供します。

基本的なアンチホットリンク設定:

location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$ {
    valid_referers none blocked www.example.com example.com *.example.net;
    
    if ($invalid_referer) {
        return 403;
    }
}

上記の構成では次のようになります。

  • valid_referers法的なソースページが定義されています。none直接アクセス (ヘッダーなしのアクセス)をblocked示し、合法的なソース ドメイン名であり、表されているすべてのサブドメイン名は合法的なソースです。Refererwww.example.comexample.com*.example.netexample.net

  • $invalid_referervalid_referersソースがリストにない場合、変数は「true」になります。

  • ソースが違法な場合、サーバーは 403 Forbidden ステータス コードを返します。

元の画像の代わりに間違った画像を使用します。

403 エラーを表示したくないが、エラー画像 (例: 「外部リンクなし」画像) を表示したい場合は、次のように設定できます。

location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$ {
    valid_referers none blocked www.example.com example.com *.example.net;
    
    if ($invalid_referer) {
        rewrite ^/.*$ /path/to/error/image.jpg;
    }
}

上記の構成では、ホットリンクが検出されると、Nginx は要求された URL を書き換えて、間違った画像を指すようにします。

注意事項:

  • アンチホットリンク構成は検索エンジン クローラーに影響を与える可能性があるため、アンチホットリンク戦略を実装する場合は注意してください。

  • Web サイトで CDN を使用している場合は、CDN のサーバーもvalid_referersリストに含まれていることを確認してください。そうしないと、CDN が正しく機能しない可能性があります。

  • ホットリンク対策が正しく構成されていることを確認するには、運用環境で使用する前に、テスト環境で適切なテストを実施する必要があります。

組み込み変数

nginx 構成ファイルで使用できる組み込み変数は、ドル記号 $ で始まります。このうち、ほとんどの事前定義変数の値はクライアントによって送信され、保持されます。

変数名 説明する
$args リクエストラインのパラメータ、と同じ$query_string
$content_length リクエストヘッダーのコンテンツ長フィールド
$content_type リクエストヘッダーの Content-Type フィールド
$document_root 現在のリクエストのルート ディレクティブで指定された値
$host リクエスト行のホスト名、またはリクエストヘッダフィールドのホスト名 Host
$http_user_agent クライアントエージェント情報
$http_cookie クライアントのクッキー情報
$limit_rate 接続速度を制限する可能性のある変数
$request_method クライアントによって要求されたアクション (GET または POST など)
$remote_addr クライアントIPアドレス
$remote_port クライアントポート
$remote_user Auth Basic モジュールによって認証されたユーザー名
$request_filename 現在要求されているファイル パス
$scheme HTTP メソッド (http、https など)
$server_protocol リクエストで使用されるプロトコル (HTTP/1.0 や HTTP/1.1 など)
$server_addr サーバーアドレス
$server_name サーバーの名前
$server_port リクエストがサーバーに到達するポート番号
$request_uri リクエストパラメータを含む元のURI
$uri リクエストパラメータを含まない現在のURI
$document_uri と$uri同じ

これらの組み込み変数は nginx 設定に大きな柔軟性をもたらし、nginx がリクエストのさまざまな属性に基づいて決定と処理を行えるようにします。

おすすめ

転載: blog.csdn.net/2301_76869453/article/details/132920627
おすすめ
ランキング
Huaxia ERP にユーザー名とパスワードに依存する脆弱性が漏洩 (CNVD-2020-63964)
How to perform image recognition and face comparison in Vue
Linuxの意味2＞&1
端末装置とTTY、chvt、startxとコマンド
）（pandas.read_csvのdate_parserパラメータを利用する方法
プロジェクト設定はドメイン間でアクセス可能
SpringBoot2.xの基本：設定ファイルの読み込み順序と優先度のオーバーライド
Kubernetesシステムセキュリティ - アクセス制御
なぜダイハツAPPは、招待コード18818128に登録しました
フロントエンドが習得する必要があるネットワークの知識
アーカイブ
もっと
2024-05-21(36)
2024-05-20(5)
2024-05-19(0)
2024-05-18(30)
2024-05-17(6)
2024-05-16(24)
2024-05-15(5)
2024-05-14(9)
2024-05-13(8)
2024-05-12(27)

コードワールド

© 2018 codetd.com