Nginx
Nginxでできること
Webサーバーとしての利用
静的ファイル（HTML、CSS、JS、画像など）の配信
LaravelやReact、VueなどのSPAの配信
WordPressなどPHPアプリケーションの配信（PHP-FPMと連携）
リバースプロキシ
アプリケーションサーバー（例：Laravel + PHP-FPM、Node.js）へのリクエストを中継
複数のアプリケーションをホスト（例：ポート8000 → 80への変換）
セキュリティやパフォーマンス向上に有効
ロードバランサ
複数のアプリケーションサーバーへの負荷分散
ラウンドロビン、IPハッシュなどの方式に対応
高可用性の構築に利用される
HTTPS対応（SSL/TLS）
Let’s Encryptなどを使った無料SSLの導入が可能
HTTP → HTTPSへのリダイレクト
SSL証明書の管理と設定
キャッシュ機能
ブラウザキャッシュやプロキシキャッシュによる高速化
静的ファイルやAPIレスポンスのキャッシュ制御
Redisと連携したキャッシュ戦略にも対応
セキュリティ機能
IP制限、認証（Basic認証）、Rate Limit（アクセス制限）
WAF（Web Application Firewall）と連携可能（ModSecurityなど）
バッドリクエストやボットのブロック
URLリライト・リダイレクト
rewriteディレクティブでのURL変換
SEO対応やルーティング調整に便利
旧URL → 新URLへの301/302リダイレクト
バーチャルホストの管理
複数のドメインやサブドメインに対応
ドメインごとの設定ファイルを分離可能（例：/etc/nginx/sites-available/）
WebSocketの中継
WebSocket通信をリバースプロキシで中継可能
ゲームやチャットアプリなどのリアルタイム通信に対応
アクセスログとエラーログの記録
access.log / error.log によるリクエスト・エラーの記録
ログ解析や監視ツールと連携可能（GoAccess、Grafanaなど）
リバースプロキシ
リバースプロキシとは、フロント（入り口）としてリクエストを受け取り、裏側の別サーバー（アプリ、APIなど）に 転送する 仕組みです。
基本構成（最小構成）
server {
# ポート80（HTTPの標準ポート）で待ち受ける
listen 80;
# example.com というドメインからリクエストが来た時にlocationの処理を行う
# ルートパス（例: http://example.com/）
server_name example.com;
location / {
# リクエストを localhost:3000 に転送します。
# つまり、ポート3000で動作しているバックエンドアプリ（たとえばNode.js、LaravelのVite、Reactなど）に中継します。
proxy_pass http://localhost:3000;
}
}
バックエンドアプリ（Node.js, Laravel, etc）にリダイレクト
location / {
# リクエストを localhost:3000 に転送します。
# つまり、ポート3000で動作しているバックエンドアプリ（たとえばNode.js、LaravelのVite、Reactなど）に中継します。
proxy_pass http://localhost:8000;
# リクエスト元のホスト名を渡す(例えばHost: www.example.comという意味）
# この設定はバーチャルホスト（複数のサイトを1つのサーバーで運用） をするために必要不可欠です。アプリケーションによっては、ドメイン名を使って処理を切り替えることがあるため、正しく伝える必要があります。マルチドメイン処理など。
# Host ヘッダーはクライアントが自由に書き換えられるので、Hostヘッダーインジェクション や オープンリダイレクトの脆弱性 に注意が必要です。
proxy_set_header Host $host;
# クライアント（ユーザー）の実際のIPアドレスを、ヘッダー X-Real-IP に入れてバックエンドに伝えます。
# LaravelやExpressでは、アクセスログやセキュリティ対策で本当のアクセス元IPを知ることが重要だからです。
proxy_set_header X-Real-IP $remote_addr;
# これはプロキシ経由でのアクセス履歴を残すための設定
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Hostヘッダーインジェクション や オープンリダイレクトの脆弱性の対策 proxy_set_header X-Real-IP $remote_addr;の必要性の詳しい説明 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; の必要性の詳しい説明
パスごとに異なるアプリに振り分ける
location /api/ {
proxy_pass http://localhost:4000/;
# API系のリクエストはNode.jsへ
}
location / {
proxy_pass http://localhost:8000/;
# その他はLaravelへ
}
HTTPS対応（SSL証明書付き）でリバースプロキシ
server {
listen 443 ssl;
server_name example.com;
# SSL証明書（公開鍵）ファイルのパス
ssl_certificate /etc/nginx/ssl/example.com.crt;
# 秘密鍵（プライベートキー）のファイルパス
ssl_certificate_key /etc/nginx/ssl/example.com.key;
location / {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
# クライアント（ユーザー）のアクセスプロトコル（http または https）をバックエンドのアプリケーションに伝えるためのものです。
proxy_set_header X-Forwarded-Proto $scheme;
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;の必要性とLaravelなどでの設定 SSL 証明書を発行する方法
WebSocket対応のプロキシ設定
location /ws/ {
proxy_pass http://localhost:6001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}
キャッシュ制御付き（静的ファイル除外など）
この設定で、バックエンド(Laravel)などのレスポンスを一時的にキャッシュして高速化できます。
静的ファイルはNginxが直接配信し、アプリ側の負荷を大きく減らせます。
http {
# キャッシュ領域の定義（httpブロック内）。
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=100m inactive=1h use_temp_path=off;
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
# レスポンスをNginxのキャッシュ（名前：my_cache）に保存するよう指定。キャッシュは別途設定必要（上でやっている）
proxy_cache my_cache;
# ステータス200（成功）のレスポンスを 1分間キャッシュ。
proxy_cache_valid 200 1m;
# アプリがエラー・タイムアウト・更新中の場合、古いキャッシュでもOKとして返すことで、ダウン時でも対応しやすく。
proxy_cache_use_stale error timeout updating;
}
# キャッシュを適用するファイルの拡張子を指定
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
# ブラウザに「このファイルは30日間再読み込み不要」と指示してキャッシュを効かせる。
expires 30d;
# アクセスログを出さない（静的ファイルはアクセスが多いので、ログを減らしてパフォーマンス向上）。
access_log off;
# 静的ファイルは /var/www/html 以下から直接読み込む（Node.jsなどを通さずNginxが直接配信）。
root /var/www/html;
}
}
}
proxy_cache_pathの設定値の解説。
プロキシキャッシュの他にも、以下などがある。
・FastCGIキャッシュ（fastcgi_cache）
PHPなどをFastCGIで動かす際、バックエンドの処理結果をキャッシュ
・マイクロキャッシュ（microcaching）
非常に短い期間（数秒）だけキャッシュし、アクセス集中に耐える
・ブラウザキャッシュ（Expires/Cache-Control）
クライアント（ブラウザ）に静的ファイルなどをキャッシュさせる
・キャッシュ制御（no_cache、bypass）
Cookieや条件付きでキャッシュを使わない／使わせない設定
特定IPのみプロキシ通す（ホワイトリスト）
# /admin で始まるURLへのアクセスに対して適用
# 例えば：http://example.com/admin や http://example.com/admin/login などが対象。
location /admin {
# アクセス許可リスト（ホワイトリスト）。192.168.1.0 から 192.168.1.255 の範囲（CIDRで指定）に含まれるIPからのアクセスは許可されます。
allow 192.168.1.0/24;
# 上記の allow に該当しない全てのアクセスを拒否します。
# 192.168.1.0/24 以外のIPから /admin にアクセスしようとすると 403 Forbidden になります。
deny all;
proxy_pass http://localhost:8000;
}
以下の用途で使用される。
・管理者用のダッシュボード
管理画面をインターネットに公開せず、社内IPのみ許可することでセキュリティを高める
・開発中のシステム
管理系URLを一時的に制限して、公開しない
・社内向けAPI
一部のエンドポイントだけ社内専用にしたい時など
上記の設定方法は以下。
ロードバランサとして使う（複数サーバー）
# upstream は、Nginxが複数のバックエンドサーバーへリクエストを分配するためのグループ定義です。
# この例では、同じマシン上の2つのアプリケーション（8000番と8001番）をバックエンドにしています。
# backend はこのグループの名前で、あとで proxy_pass で使います。
upstream backend {
server 127.0.0.1:8000;
server 127.0.0.1:8001;
}
server {
listen 80;
location / {
# リクエストを upstream backend で定義したサーバー群へ転送します。
# このとき、Nginxが自動的にどちらかのポート（8000 or 8001）を選んでリクエストを送ります。
proxy_pass http://backend;
proxy_set_header Host $host;
}
}
負荷分散方式を変更したい場合
upstream backend {
# least_conn は「現在接続数が少ない方」に振る設定です。
least_conn;
server 127.0.0.1:8000;
server 127.0.0.1:8001;
}
サーバーの重み（負荷配分）を調整したい場合：
upstream backend {
# 8000の方に3倍多くリクエストが行くようにします。
server 127.0.0.1:8000 weight=3;
server 127.0.0.1:8001 weight=1;
}
ロードバランサーのエラー処理やヘルスチェックの設定を行うことで、落ちているサーバーにリクエストが飛ばないようにしたり、エラー時にフェイルオーバーする構成を作れます。
URLリライト・リダイレクト
URLリライト（rewrite）とリダイレクト（redirect）は、アクセスされたURLを別のURLに変更したり、他の場所に転送するために使われます。
アクセスログとエラーログの記録と監視
セキュリティ
IP制限、認証（Basic認証）、Rate Limit（アクセス制限）
WAF（Web Application Firewall）と連携可能（ModSecurityなど）
バッドリクエストやボットのブロック
Discussion