はじめに
Web サーバといえば Apache か nginx(エンジンエックス)の二強と言われて久しいですが、近年は nginx が主流になりつつあります。リバースプロキシやロードバランサとしても広く使われており、現代的な Web インフラを学ぶうえで避けては通れない技術です。
本記事では、「nginx とは何か」という概要から、インストール、設定ファイルの読み方、典型的なユースケース(静的配信・リバースプロキシ・ロードバランサ)までを実例で解説します。
対象読者
- Web サーバを触り始めたばかりの方
- Apache は使ったことがあるが nginx は未経験の方
- Docker や Linux で簡単な Web 環境を構築したい方
この記事で分かること
- nginx の特徴と Apache との違い
- 設定ファイル(
nginx.conf)の基本構造 - 静的ファイル配信、リバースプロキシ、ロードバランサの設定方法
- 起動・停止・設定リロードのコマンド
- よくあるエラーと対処法
動作環境
| 項目 | バージョン |
|---|---|
| nginx | 1.24 以上(最新の stable 推奨) |
| OS | Ubuntu 22.04 / macOS 14 / Docker 環境 |
nginx とは何か
nginx は、ロシアの Igor Sysoev 氏が 2004 年に公開したオープンソースの Web サーバ/リバースプロキシ/ロードバランサです。当時の主流だった Apache が抱えていた C10K 問題(同時接続が1万を超えるとパフォーマンスが落ちる問題)を解決する目的で開発されました。
主な特徴
- イベント駆動・非同期 I/O: 1プロセスで多数の接続をさばけるため、メモリ消費が少なく高速
- 静的コンテンツの配信が爆速: 同じハードウェアで Apache の数倍のスループットが出ることも
- リバースプロキシ/ロードバランサとしても優秀: アプリケーションサーバの前段に置く用途で広く採用
- 設定ファイルが宣言的で読みやすい: ネストされたブロック構造
- モジュール設計: 必要な機能だけビルドできる(ただし通常はパッケージマネージャ経由で導入)
Apache との違い(ざっくり)
| 観点 | Apache | nginx |
|---|---|---|
| 並行処理モデル | プロセス/スレッドベース | イベント駆動(非同期) |
| 同時接続耐性 | 中程度 | 非常に高い |
| 静的配信性能 | 良 | 優秀 |
.htaccess |
あり | なし(設定はメインの conf に集約) |
| 動的処理 | mod_php 等で内蔵実行可 | 別プロセス(PHP-FPM 等)に委譲 |
「Apache が劣っている」わけではなく、得意分野が違います。例えば共有ホスティングのように .htaccess でユーザーごとに設定を変えたい用途では Apache が依然として強いです。
インストール
Ubuntu / Debian
sudo apt update
sudo apt install nginx
sudo systemctl enable --now nginx
ブラウザで http://localhost/ を開くと「Welcome to nginx!」が表示されれば成功です。
macOS(Homebrew)
brew install nginx
brew services start nginx
デフォルトでは http://localhost:8080/ で起動します。
Docker
最も再現性が高く、おすすめの方法です。
docker run --name my-nginx -p 8080:80 -d nginx:1.24
http://localhost:8080/ にアクセスして動作確認できます。
設定ファイルの基本構造
nginx の設定は /etc/nginx/nginx.conf(Ubuntu の場合)に書きます。中身は以下のようなブロック構造です。
# グローバル設定
worker_processes auto;
events {
worker_connections 1024;
}
http {
# MIME タイプの読み込み
include /etc/nginx/mime.types;
default_type application/octet-stream;
# ログ設定
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
# 個別サイトの設定を取り込む
include /etc/nginx/conf.d/*.conf;
}
ブロック(コンテキスト)の種類
| ブロック | 役割 |
|---|---|
| グローバル(最外側) | プロセス数など nginx 全体の動作 |
events |
コネクション処理の挙動 |
http |
HTTP 全般の設定 |
server |
1つの仮想ホスト(ドメイン or ポート単位) |
location |
URL パターンごとの設定 |
設定変更後は 必ず構文チェックしてからリロード します。
sudo nginx -t # 構文チェック
sudo systemctl reload nginx # 無停止で反映
restart ではなく reload を使うと、稼働中の接続を切らずに設定を反映できます。本番環境では reload が基本です。
ユースケース 1: 静的ファイルを配信する
最もシンプルな使い方です。/var/www/example 配下の HTML / CSS / 画像を公開します。
server {
listen 80;
server_name example.com;
root /var/www/example;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
ポイント:
-
try_files $uri $uri/ =404は「ファイル → ディレクトリ → 404」の順で探す定型句 -
rootで公開ディレクトリを指定するとそれ以下が公開される
ユースケース 2: リバースプロキシ
Node.js / Python / Go などのアプリケーションサーバを localhost:3000 で動かし、その前段に nginx を置く構成です。
server {
listen 80;
server_name app.example.com;
location / {
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;
}
}
なぜリバースプロキシを置くか:
- HTTPS 終端を nginx に集約できる
- 静的ファイルだけ nginx で直接配信して高速化できる
- アプリを再起動しても 502 を一瞬で済ませる(接続維持)
- WAF・レート制限・ロギングを一元化できる
proxy_set_header Host $host; を忘れると、アプリ側に 127.0.0.1 がホスト名として渡り、リダイレクトURLが壊れることがあります。
ユースケース 3: ロードバランサ
複数のアプリサーバに負荷を分散します。
upstream backend {
# least_conn; # 最少接続数のサーバへ振り分け(任意)
server 10.0.0.11:3000 weight=2;
server 10.0.0.12:3000;
server 10.0.0.13:3000 backup; # 他がダウンしたときのみ使う
}
server {
listen 80;
server_name api.example.com;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
}
}
主な振り分けアルゴリズム:
| ディレクティブ | 挙動 |
|---|---|
| 既定(記述なし) | ラウンドロビン |
least_conn |
接続数が最も少ないサーバへ |
ip_hash |
クライアント IP からハッシュで固定(セッション維持に有用) |
ユースケース 4: HTTPS 化(Let's Encrypt + Certbot)
Ubuntu の例です。certbot が自動で nginx の設定を書き換えてくれます。
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
90日ごとの自動更新も systemd のタイマーで設定されるため、初回以外は基本ノーメンテです。
証明書の自動更新は sudo certbot renew --dry-run で動作確認できます。本番投入前に必ず実行しておきましょう。
よくある問題と対処法
エラー1: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
原因: 80 番ポートを別プロセス(多くは Apache)が使っている。
対処:
sudo ss -ltnp | grep ':80 ' # 使用しているプロセスを確認
sudo systemctl stop apache2 # 例:Apache を止める
sudo systemctl disable apache2
sudo systemctl restart nginx
エラー2: 502 Bad Gateway
原因: 上流のアプリサーバ(proxy_pass 先)が落ちている、もしくはポートが間違っている。
対処:
sudo tail -n 50 /var/log/nginx/error.log # エラーの詳細を確認
curl -v http://127.0.0.1:3000 # アプリサーバが応答するか確認
エラー3: nginx: [emerg] "server" directive is not allowed here
原因: server ブロックを http の外に書いている。
対処: 必ず http { ... } の中、または http 内から include した別ファイルに記述する。
まとめ
本記事では nginx の概要と典型的な使い方を解説しました。
- nginx は イベント駆動で高速 な Web サーバ/リバースプロキシ/ロードバランサ
- 設定は
server→locationのネスト構造で宣言的に書ける - 設定変更後は
nginx -tで構文チェック →reloadが鉄則 - 静的配信、リバースプロキシ、ロードバランサ、HTTPS化 のいずれもシンプルに実装できる
次に学ぶべきこと
-
キャッシュ(
proxy_cache)でアクセス急増に備える -
レート制限(
limit_req_zone)で DoS 対策 -
WebSocket プロキシの設定(
Upgradeヘッダの取り扱い) - nginx Unit / OpenResty / Angie などの派生プロダクト