0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

nginx とは何か?特徴・仕組み・基本的な使い方を実例で解説

0
Posted at

はじめに

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 の場合)に書きます。中身は以下のようなブロック構造です。

/etc/nginx/nginx.conf
# グローバル設定
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 / 画像を公開します。

/etc/nginx/conf.d/static.conf
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 を置く構成です。

/etc/nginx/conf.d/proxy.conf
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: ロードバランサ

複数のアプリサーバに負荷を分散します。

/etc/nginx/conf.d/lb.conf
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 サーバ/リバースプロキシ/ロードバランサ
  • 設定は serverlocation のネスト構造で宣言的に書ける
  • 設定変更後は nginx -t で構文チェック → reload が鉄則
  • 静的配信、リバースプロキシ、ロードバランサ、HTTPS化 のいずれもシンプルに実装できる

次に学ぶべきこと

  • キャッシュproxy_cache)でアクセス急増に備える
  • レート制限limit_req_zone)で DoS 対策
  • WebSocket プロキシの設定(Upgrade ヘッダの取り扱い)
  • nginx Unit / OpenResty / Angie などの派生プロダクト

参考資料

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?