Nginx設定の習得:必須ディレクティブの解説
最もよく使うNginxディレクティブ(http、server、location、proxy_pass、try_files、gzip、TLS、サービスリロード)を理解しましょう。
Nginx設定の習得:必須ディレクティブの解説
各ディレクティブがどこに配置できるかを理解すれば、Nginxの設定はずっと簡単に感じられます。proxy_pass、root、try_filesのルールが誤ったコンテキストにあると、Nginxは設定を拒否したり、意図しない方法でリクエストを処理したりする可能性があります。
このガイドでは、静的ファイルの提供、アプリのリバースプロキシ、圧縮の有効化、変更の安全なリロードを行う際に触れる必須ディレクティブについて説明します。
Nginx設定の構造
Nginxの設定ファイルは通常、Linuxパッケージでは/etc/nginx/にあります。メインファイルは一般的に/etc/nginx/nginx.confで、/etc/nginx/conf.d/からファイルをインクルードすることがよくあります。DebianおよびUbuntuパッケージは一般的にsites-available/とsites-enabled/を使用しますが、他の多くのディストリビューションでは使用しません。
設定は階層的で、ブロックまたはディレクティブに整理されています。主なブロックは以下の通りです:
events:接続処理を設定します。http:HTTP全体の設定と仮想サーバーを含みます。server:ポートとホスト名の仮想サーバーを定義します。location:リクエストURIのマッチング方法を選択します。
ディレクティブはキーと値のペアで、Nginxの動作を制御します。グローバルに設定することも、ブロック内にネストすることもできます。
必須ディレクティブの解説
httpブロック
httpブロックは、HTTPトラフィックにグローバルに適用される設定を囲みます。ここでウェブサーバーの共通設定を定義します。
include:このディレクティブは他の設定ファイルをインクルードすることを可能にし、設定をモジュール化するのに役立ちます。異なるウェブサイトやアプリケーションの設定を分離するためによく使用されます。http { include mime.types; default_type application/octet-stream; # conf.dディレクトリからサーバー設定をインクルード include /etc/nginx/conf.d/*.conf; }log_format:Nginxのアクセスログとエラーログのカスタムログ形式を定義します。詳細なログ記録と分析に不可欠です。http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log; # ... その他のhttpディレクティブ }sendfile:カーネルがファイルをディスクから直接クライアントに送信できるようにすることで、ファイル転送を最適化し、ユーザースペースをバイパスします。パフォーマンスのためにonに設定します。http { sendfile on; # ... }tcp_nopushとtcp_nodelay:これらはHTTPレスポンスのTCP動作を調整します。tcp_nopushはパケット送信を最適化するためにsendfileと一緒によく使用され、tcp_nodelayはキープアライブ接続の遅延を回避するのに役立ちます。http { tcp_nopush on; tcp_nodelay on; # ... }
serverブロック
各serverブロックは仮想サーバーを定義し、Nginxが同じサーバー上の異なるドメイン名やIPアドレスに対するリクエストを処理できるようにします。
listen:サーバーが着信接続をリッスンするIPアドレスおよび/またはポートを指定します。server { listen 80; listen [::]:80; server_name example.com www.example.com; # ... }server_name:サーバーの名前を定義します。Nginxはこれを使用して、着信リクエストのHostヘッダーと照合します。server { listen 80; server_name mydomain.org *.mydomain.org; # ... }root:ドキュメントルートを設定します。NginxはリクエストURIをこのディレクトリに追加してファイルパスを構築します。server { listen 80; server_name localhost; root /var/www/html; index index.html index.htm; # ... }index:ディレクトリがリクエストされたときに提供するデフォルトファイルを指定します。server { # ... index index.html index.htm default.html; # ... }error_page:特定のHTTPステータスコードに対するカスタムエラーページを定義します。server { # ... error_page 404 /404.html; location = /404.html { root /usr/share/nginx/html; internal; } # ... }
locationブロック
locationブロックはリクエストURIを照合し、Nginxがそれらをどのように処理するかを決定するために使用されます。ここでアプリケーションの異なる部分のルーティングを設定します。
URIの照合:ロケーションは正確な文字列、プレフィックス、または正規表現に一致します。完全一致は
=、正規表現は~または~*、プレーンプレフィックスはURIプレフィックスで一致します。location /images/ { # /images/で始まるリクエストのディレクティブ } location = /favicon.ico { # /favicon.icoの完全一致 } location ~ \.php$ { # .phpで終わるファイルの正規表現一致 }proxy_pass:リクエストをアップストリームサーバーに転送します。末尾のスラッシュに注意してください。Nginxが一致したプレフィックスを書き換える方法が変わるためです。location /api/ { proxy_pass http://backend-service: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; proxy_set_header X-Forwarded-Proto $scheme; }alias:ロケーションを、元の完全なURIを追加せずにファイルシステムパスにマッピングします。メインドキュメントルートの外部に保存された静的アセットによく使用されます。location /static/ { alias /var/www/app/assets/; }aliasを使用する場合、ディレクトリマッピングのためにロケーションとパスの両方に末尾のスラッシュを含めてください。aliasは一致したロケーションプレフィックスをエイリアスパスに置き換えますが、rootはURIをルートパスに追加します。try_files:指定された順序でファイルの存在を確認し、最初に見つかったものを提供するか、指定されたコード/URIを返します。location / { try_files $uri $uri/ /index.html; }これはシングルページアプリケーションで一般的です。リクエストされたファイルまたはディレクトリが存在しない場合、Nginxは
index.htmlを提供し、クライアント側ルーターがパスを処理できるようにします。
セキュリティとパフォーマンスのディレクティブ
ssl_certificateとssl_certificate_key:HTTPSを設定するために不可欠です。これらのディレクティブはSSL証明書と秘密鍵ファイルを指定します。server { listen 443 ssl; server_name secure.example.com; ssl_certificate /etc/letsencrypt/live/secure.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/secure.example.com/privkey.pem; # ... その他のSSL設定 }gzip:選択したレスポンスタイプに対してgzip圧縮を有効または無効にします。テキストアセットの転送サイズを削減することが多いですが、ほとんどの画像など、すでに圧縮されているファイルの圧縮は避けてください。http { gzip on; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; # ... }expires:静的アセットのキャッシュヘッダーを制御します。フィンガープリントされたファイルには長いキャッシュ有効期間を使用し、デプロイ間で同じURLを維持するファイルには短い有効期間を使用します。location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 30d; add_header Cache-Control "public"; }
一般的なNginxコマンド
Nginxを管理し、設定変更を適用するために、これらのコマンドを頻繁に使用します:
設定のテスト:Nginx設定ファイルの構文エラーをチェックします。
sudo nginx -t設定のリロード:アクティブな接続を切断せずに、Nginx設定をグレースフルにリロードします。
sudo systemctl reload nginx # または sudo service nginx reloadNginxの再起動:Nginxサービスを停止してから起動します。
sudo systemctl restart nginx # または sudo service nginx restartステータスの確認:Nginxサービスの現在のステータスを表示します。
sudo systemctl status nginx # または sudo service nginx status
最小限の動作例
この例では、シングルページアプリをディスクから提供し、APIリクエストをアプリサーバーにプロキシします:
server {
listen 80;
server_name example.com;
root /var/www/example.com;
index index.html;
location /api/ {
proxy_pass http://127.0.0.1:3000/;
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_set_header X-Forwarded-Proto $scheme;
}
location / {
try_files $uri $uri/ /index.html;
}
}
リロードする前に毎回sudo nginx -tを実行してください。この習慣により、構文エラーがダウンタイムになる前にキャッチできます。
まとめ
Nginxのほとんどのミスは、コンテキストとパスの処理に起因します。HTTP全体の設定はhttpに、ホスト固有のルールはserverに、URIルーティングはlocationに配置し、リロード前にnginx -tですべての変更をテストしてください。