【最新Ubuntu 26.04 LTS】サーバー構築入門 第6回：Nginxのインストールと爆速Webサーバーの構築

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
「Ubuntu 26.04 LTS サーバー構築入門」もいよいよ第6回。ここからがWebインフラエンジニアとしての腕の見せ所です。今回構築するのは、世界中のモダンなWebサービスを支えている最強のWebサーバー「Nginx（エンジンエックス）」です。

私たちが普段見ているWebサイト（HTMLや画像など）は、すべてWebサーバーというソフトウェアがブラウザ（ChromeやSafari）からのリクエストを受け取り、データを送り返すことで表示されています。その役割を担うソフトウェアとして、今回はNginxを採用します。

本記事では、Nginxのアーキテクチャの根幹から、Ubuntu 26.04におけるディレクトリ構造の理解、そして1つのサーバーで複数のドメインを運用する「サーバーブロック」の構築までを、プロの視点で徹底的に深掘りします。

---

1. なぜ今Nginxなのか？ イベント駆動アーキテクチャの秘密

インストールを始める前に、Nginxがなぜ世界中の巨大IT企業（Netflix、Netflix、Airbnbなど）で採用されているのか、その技術的な背景を理解しておきましょう。これを理解しているかどうかが、中級エンジニアの分かれ目になります。

1-1. Apacheの限界「C10K問題」

従来のApache（Prefork MPM）は、「1つのリクエストが来るたびに、1つのプロセス（またはスレッド）を立ち上げて対応する」という「プロセス駆動アーキテクチャ」を採用していました。これは非常に安定していますが、同時に1万人のアクセスが来ると、1万個のプロセスが立ち上がることになります。結果としてサーバーのメモリが枯渇し、システムがダウンしてしまいます。これを「C10K問題（クライアント1万台問題）」と呼びます。

1-2. Nginxの解答「イベント駆動アーキテクチャ」

対してNginxは、「イベント駆動アーキテクチャ（非同期ノンブロッキングI/O）」を採用しています。
Nginxは、ごく少数（CPUコア数と同じ数）の「ワーカープロセス」だけを起動します。1つのワーカープロセスは、ループ処理（イベントループ）を高速で回しながら、数千〜数万の接続を「同時並行」でさばきます。通信の待ち時間（クライアントからのデータ受信待ちなど）が発生しても、プロセスは止まらずに別のリクエストの処理を進めます。

比較項目	Nginx (イベント駆動)	Apache (プロセス駆動/Prefork)
メモリ消費量	非常に少ない（数万接続でも数MB〜数十MB）	アクセスに比例して激増する（1プロセス数MB〜）
静的ファイルの配信	圧倒的に高速	普通
動的処理（PHP等）	Nginx自体は処理できず、外部（PHP-FPM等）に丸投げする	モジュール（mod_php）を取り込んで自己完結できる
役割・立ち位置	リバースプロキシ、ロードバランサー、静的コンテンツ配信	何でもこなすオールラウンダーなWebサーバー

この特性から、現代のインフラでは「Nginxがフロント（入り口）に立ち、交通整理と静的ファイルの返却を超高速で行い、複雑な処理だけを裏側のアプリケーションサーバーにパスする」という構成が絶対的な標準となっています。

---

2. Ubuntu 26.04へのNginxインストールとUFWの連携

それでは、Ubuntu 26.04 LTSにNginxをインストールしていきましょう。Ubuntuの強力なパッケージマネージャー apt を使えば一瞬です。

2-1. Nginxのインストールコマンド

# リポジトリの最新化
sudo apt update

# Nginxのインストール
sudo apt install nginx -y

インストールが完了すると、自動的にNginxのサービスが起動し、OS再起動時の自動起動（enable）も設定されます。

2-2. systemctlによるステータス確認

sudo systemctl status nginx

Active: active (running) と表示されていれば、Nginxは正常に稼働しています。

2-3. ファイアウォール（UFW）へのNginxプロファイル適用

第3回で、私たちはUFWを使って不要なポートをすべて塞ぎました。現在はSSH（22番）しか開いていないため、このままでは外部からWebサイトを見ることができません。
UbuntuのUFWは非常に優秀で、Nginxをインストールした瞬間に「Nginx用の通信許可ルール（プロファイル）」を自動で用意してくれます。

# UFWに登録されているアプリケーションプロファイルの一覧を確認
sudo ufw app list

出力の中に、以下の3つが含まれているはずです。

• Nginx HTTP: 80番ポート（暗号化なし）のみを開放
• Nginx HTTPS: 443番ポート（暗号化あり）のみを開放
• Nginx Full: 80番と443番の両方を開放

Webサイトを公開するためには最終的にHTTPS（SSL）が必須となるため、両方を開放する Nginx Full を適用します。

# Nginxの通信を許可
sudo ufw allow 'Nginx Full'

# UFWのステータスを確認
sudo ufw status

ここでブラウザを開き、サーバーのIPアドレス（例：http://192.168.1.100 またはグローバルIP）にアクセスしてみてください。「Welcome to nginx!」という画面が表示されれば、インターネットの世界とあなたのサーバーが無事につながった証拠です！

---

3. Nginxのディレクトリ構造と設定ファイルの読み解き方

「Welcome to nginx!」の画面が出たからといって満足してはいけません。プロのエンジニアは、Nginxの設定ファイルがどこにあり、どのような構造で読み込まれているかを完全に把握しています。
Ubuntu（Debian系）におけるNginxの設定ファイル群は、すべて /etc/nginx/ ディレクトリ配下に収められています。

3-1. 主要なディレクトリとファイルの役割

ファイル / ディレクトリ	役割と解説
nginx.conf	Nginxの「大元（親）」となる設定ファイル。ワーカープロセス数やログの出力形式、全体のパフォーマンス設定などが書かれています。
sites-available/	各Webサイト（ドメイン）ごとの設定ファイルを保存しておく「保管庫」。ここに置いただけではNginxには認識されません。
sites-enabled/	実際にNginxに「適用（有効化）」させる設定ファイルを置くディレクトリ。後述するシンボリックリンクを使って設定を有効化します。
conf.d/	全サイトで共通して使いたい設定（セキュリティ設定の部品など）を置いておくディレクトリです。
snippets/	conf.d と似ていますが、必要なサイトだけが include コマンドで呼び出して使うための「設定の破片」を置く場所です。

3-2. nginx.conf の「include」の魔法

なぜこんなにファイルが分かれているのでしょうか？ /etc/nginx/nginx.conf の中身を覗いてみると、その答えがわかります。

cat /etc/nginx/nginx.conf

ファイルの後半に、以下のような記述があります。

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

これは「この大元の設定ファイルの中に、指定したディレクトリの中にあるファイルをすべて合体（インクルード）させて読み込め」という命令です。
これにより、設定ファイルが数千行のスパゲッティ状態になるのを防ぎ、「Aというサイトの設定はAのファイルに書く」という美しいモジュール化が実現されているのです。

---

4. サーバーブロック（バーチャルホスト）による複数サイト運用

1台のサーバーで、www.example.com と blog.linuxkoubou.com のように、複数の異なるドメイン（Webサイト）を運用する技術を、Apacheでは「バーチャルホスト」と呼びますが、Nginxでは「サーバーブロック（Server Blocks）」と呼びます。

4-1. ドキュメントルートの作成

まずは、WebサイトのHTMLファイルなどを置く場所（ドキュメントルート）を作成します。Ubuntuの作法に従い、/var/www/ の下にドメイン名のディレクトリを作ります。

# ドメイン名「example.com」用のディレクトリを作成（-pで親ディレクトリも作成）
sudo mkdir -p /var/www/example.com/html

# ディレクトリの所有者を現在のユーザー（またはwww-data）に変更する
sudo chown -R $USER:$USER /var/www/example.com/html

# 権限（パーミッション）を正しく設定する
sudo chmod -R 755 /var/www/example.com

4-2. テスト用HTMLファイルの作成

作成したディレクトリに、接続テスト用の index.html を配置します。

nano /var/www/example.com/html/index.html

以下の簡単なHTMLを記述して保存します。

<html>
  <head><title>Welcome to example.com!</title></head>
  <body>
    <h1>Success! The example.com server block is working!</h1>
  </body>
</html>

---

5. 実践：ドメインごとの設定ファイル（server句）の記述方法

HTMLの準備ができたら、Nginxに「このドメインにアクセスが来たら、このディレクトリのファイルを表示しろ」というルールを教え込みます。

5-1. 設定ファイルの作成

設定ファイルは、必ず「保管庫」である sites-available の中に作成します。

sudo nano /etc/nginx/sites-available/example.com

以下のプロフェッショナルな設定テンプレートを記述します。

server {
    # 80番ポート（IPv4とIPv6の両方）で待ち受ける
    listen 80;
    listen [::]:80;

    # このサーバーブロックが反応するドメイン名を指定
    server_name example.com www.example.com;

    # ドキュメントルートの指定（先ほど作成したディレクトリ）
    root /var/www/example.com/html;

    # デフォルトで読み込むファイル名の優先順位
    index index.html index.htm index.nginx-debian.html;

    # URLごとの挙動（ルーティング）
    location / {
        # リクエストされたURIのファイルを探し、なければディレクトリを探し、それでもなければ404エラーを返す
        try_files $uri $uri/ =404;
    }

    # セキュリティ向上のため、隠しファイル（.htaccessなど）へのアクセスを禁止
    location ~ /\.ht {
        deny all;
    }
}

---

6. シンボリックリンクによるスマートな設定の有効化・無効化

コウ君の言う通り、sites-available に置いただけではNginxは読み込んでくれません。大元の nginx.conf が読み込むのは sites-enabled ディレクトリの中身だからです。

6-1. シンボリックリンクの作成

設定ファイルを直接コピーするのではなく、Linuxの「シンボリックリンク（Windowsのショートカットのようなもの）」を作成して配置するのがUbuntuの絶対的な作法です。

# ln -s [リンク元(実体)] [リンク先(ショートカット)]
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

なぜショートカットを作るのでしょうか？それは、もしWebサイトに不具合が起きて一時的に閉鎖したい場合、実体ファイルを消さずにショートカット（シンボリックリンク）だけを削除すれば、即座にサイトを無効化できるからです。これがスマートなインフラ管理術です。

6-2. 構文チェックとNginxの再読み込み

設定を反映させる前に、絶対にやらなければならない儀式があります。それは「構文テスト」です。

# Nginxの設定ファイルに文法エラーがないかテストする神コマンド
sudo nginx -t

nginx: configuration file /etc/nginx/nginx.conf test is successful と表示されれば完璧です。

テストに合格したら、設定を反映させます。ここで restart を使ってはいけません。

# reload（再読み込み）を使う
sudo systemctl reload nginx

restart はNginxのプロセスを完全に一度殺してしまうため、その瞬間にアクセスしていたユーザーの通信が切断されます。一方 reload は、現在処理中の通信は最後まで終わらせつつ、新しいアクセスから順次新しい設定を適用させる「無停止反映」が可能です。本番環境では絶対に reload を使ってください。

---

7. Nginxをリバースプロキシとして使う（Node.jsやPythonとの連携）

現代のWeb開発において、HTMLをそのまま置くことは減ってきました。バックエンドで動いているNode.js、Python（Django/FastAPI）、Go言語などのアプリケーションとNginxを連携させるのが主流です。
この際、Nginxはフロントに立って通信を受け止め、裏側で動いているアプリ（例えばポート3000番で動いているNode.js）へ通信を横流しする「リバースプロキシ」として働きます。

7-1. リバースプロキシの設定方法

先ほどの server ブロックの中の location / の中身を以下のように書き換えます。

server {
    listen 80;
    server_name api.example.com;

    location / {
        # 裏側のアプリ（ポート3000）へ通信を転送する
        proxy_pass http://localhost:3000;

        # 転送する際に、クライアントの本当のIPアドレスなどの情報をヘッダーに付与して渡す
        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;
    }
}

なぜバックエンドアプリを直接インターネットに公開せず、わざわざNginxを挟むのでしょうか？
それは、Nginxが「SSL（HTTPS）の暗号化の解除」「DDoS攻撃からの保護」「静的ファイル（画像など）の高速キャッシュ」を肩代わりしてくれるため、バックエンドアプリは「純粋なプログラムの処理」だけに専念できるようになり、システム全体のパフォーマンスが劇的に向上するからです。

---

8. プロが教えるNginxパフォーマンスチューニングの極意

インストール直後のNginxでも十分に速いですが、大規模なトラフィックを捌くためのチューニングポイントをいくつか紹介します。これらは大元の /etc/nginx/nginx.conf に記述します。

8-1. ワーカープロセスの最適化

# サーバーのCPUコア数を自動で検知して、最適な数のプロセスを立ち上げる
worker_processes auto;

events {
    # 1つのプロセスが同時に受け付ける最大コネクション数
    worker_connections 1024;
    # 複数のリクエストを同時に受け入れる
    multi_accept on;
}

これにより、CPUコア数 × 1024 の同時接続（例えば4コアなら4096同時接続）を捌けるようになります。さらに大規模にする場合は、OS側のファイルディスクリプタ上限（ulimit）を引き上げる必要があります。

8-2. Gzip圧縮による通信量の削減

テキストデータ（HTML、CSS、JavaScriptなど）をサーバー側で圧縮（Zip化）してからブラウザに送り、ブラウザ側で解凍させることで、通信速度を劇的に高めます。

http {
    gzip on;
    gzip_comp_level 5;  # 圧縮レベル（1〜9。5くらいがCPU負荷と圧縮率のバランスが良い）
    gzip_min_length 256; # 圧縮を適用する最小サイズ
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
}

8-3. クライアントのアップロード制限（セキュリティ対策）

デフォルトでは1MB以上のファイル（画像など）をアップロードしようとするとNginxがエラー（413 Request Entity Too Large）を返します。これを緩和します。

http {
    # 最大アップロードサイズを50MBに引き上げ
    client_max_body_size 50m;
}

---

9. AIを活用したセキュアなNginx設定ファイルの自動生成

Nginxの設定は、リバースプロキシ、SSL証明書、セキュリティヘッダーなどが絡むと非常に複雑になります。ここでもインフラエンジニアの相棒であるAI（Gemini等）をフル活用しましょう。

9-1. Nginx設定ファイル生成用プロンプト

「あなたはシニアWebインフラエンジニアです。
Ubuntu 26.04環境のNginxにおいて、以下の要件を満たすサーバーブロック設定（/etc/nginx/sites-available/ 用）を生成してください。

【要件】
1. ドメインは app.example.com
2. バックエンドは同一サーバー内のポート8080で動くNode.jsアプリへリバースプロキシする。
3. WebSocketsの通信（Upgradeヘッダー）にも完全対応させること。
4. X-Frame-Options や X-XSS-Protection などのモダンなセキュリティヘッダーを付与すること。
5. ログは /var/log/nginx/app.example.com.access.log に出力すること。
6. 設定項目の各行に、初心者向けの詳しい日本語コメントを記述すること。」

このプロンプトをAIに投げることで、WebSocketsの通信に必要な proxy_set_header Upgrade $http_upgrade; などの忘れがちな難解な設定を、一瞬で正確に生成してくれます。AIが出力した結果を必ず nginx -t でテストするルーティンを守れば、設定ミスでサイトが落ちることはありません。

---

総まとめ：最速のWebインフラを手に入れる

第6回の講座、本当にお疲れ様でした！

今回は、イベント駆動アーキテクチャというNginxの強さの秘密から始まり、Ubuntuにおけるディレクトリ構造の正しい理解、シンボリックリンクを使ったエレガントな設定管理、そしてリバースプロキシやパフォーマンスチューニングといった、即戦力となるインフラ構築術を学びました。

Apacheの呪縛から解き放たれ、Nginxを自在に操れるようになったあなたのサーバーは、数万人のアクセスが押し寄せても涼しい顔で捌き切る、真のエンタープライズ級のポテンシャルを手に入れました。

しかし、今の状態はまだ「HTTP（暗号化なし）」での通信です。現代のWebにおいて、暗号化されていないサイトはブラウザから「危険」というレッテルを貼られてしまいます。
次回以降の応用編として、このNginxに「Let’s Encrypt」を使った無料のSSL証明書を組み込み、HTTPS化および最新プロトコルであるHTTP/2やHTTP/3に対応させるステップへと進んでいきます。

そして次回の第7回は、いよいよ現代インフラの最終兵器「Dockerの導入とコンテナ運用」です。Ubuntu 26.04の強みを最大限に活かし、システムを「コンテナ化」してポータビリティと開発効率を爆発的に高める方法を徹底解説します。お楽しみに！