DevOpsナレッジハブ
DevOpsナレッジハブ

Nginx 仮想ホスト：1台のサーバーで複数のウェブサイトをホストする

Nginx 仮想ホスト（サーバーブロック）の力を解き放ち、単一のサーバーで複数のウェブサイトやサブドメインを効率的にホストしましょう。このガイドでは、ディレクトリのセットアップ、設定ファイルの作成、サーバーブロックの有効化、Nginx のテストを網羅した包括的で段階的なチュートリアルを提供します。サブドメイン、デフォルトのサーバーブロック、HTTPS 統合、専用ロギングのベストプラクティスを学びましょう。実践的な例と不可欠なトラブルシューティングのヒントは、マルチサイト Nginx ホスティングをマスターし、リソースの使用率を最適化し、ウェブサーバー管理を効率化するのに役立ちます。

37 ビュー

Nginx 仮想ホスト: 1台のサーバーで複数のウェブサイトをホストする

現代のウェブインフラストラクチャでは、単一のサーバーインスタンスから複数のウェブサイトやウェブアプリケーションを提供できる能力がしばしば求められます。これはリソースの利用効率を最適化するだけでなく、管理を簡素化し、運用コストを削減します。高いパフォーマンス、安定性、豊富な機能セット、そして低いリソース消費で知られるNginxは、これをサーバーブロックと呼ばれる機能（Apacheの世界では仮想ホストとも呼ばれます）を通じて実現します。

この包括的なガイドでは、単一のNginxサーバーから複数の異なるドメイン名またはサブドメインを効果的に管理および提供するために、Nginx仮想ホストを設定するプロセスを順を追って説明します。example.comとanothersite.orgをホストする場合でも、blog.example.comやshop.example.comのようなサブドメインを持つメインサイトをホストする場合でも、Nginxサーバーブロックをマスターすることは、システム管理者や開発者にとって基本的なスキルです。この記事の終わりには、マルチサイトホスティングのためにNginxサーバーを構成するための明確な理解と実践的な例が得られるでしょう。

Nginxサーバーブロック（仮想ホスト）の理解

Nginxのサーバーブロックは、Nginxの設定ファイル（nginx.confまたは含まれるファイル）内で定義される設定ディレクティブです。各serverブロックは特定の仮想ホストの設定を定義し、Nginxが特定のドメインまたはドメインセットのリクエストにどのように応答すべきかを指示します。Nginxはlistenディレクティブを使用してリッスンするIPアドレスとポートを指定し、server_nameディレクティブを使用して、このサーバーブロックが応答すべきドメイン名またはホスト名を識別します。

リクエストが来ると、NginxはHTTPリクエストのHostヘッダーを調べ、設定されたサーバーブロックのserver_nameディレクティブと比較します。その後、一致したサーバーブロックで定義されたコンテンツを提供します。server_nameが一致しない場合、Nginxは通常、デフォルトサーバーブロック（最初のserverブロック、または明示的にdefault_serverとマークされたもの）にフォールバックします。

事前準備

開始する前に、以下のものがあることを確認してください。

  1. Nginxのインストール: サーバーにNginxがインストールされ、実行されている必要があります。そうでない場合は、通常、システムのパッケージマネージャー（Ubuntu/Debianではsudo apt update && sudo apt install nginx、CentOS/RHELではsudo yum install nginxなど）でインストールできます。
  2. ドメイン名: ホストしたい少なくとも2つのドメイン名（例: example1.comとexample2.com）またはサブドメイン（例: blog.example.comとapp.example.com）が必要です。これらのドメインのDNS A/AAAAレコードは、サーバーのパブリックIPアドレスを指している必要があります。
  3. 基本的なディレクトリ構造: ウェブサイトのファイルがどこに配置されるかの計画。一般的な慣習は /var/www/yourdomain.com/html です。
  4. Sudo権限: Nginxの設定ファイルを変更するにはsudoアクセスが必要です。

ステップバイステップ設定ガイド

2つの仮想ホスト、example1.comとexample2.comを設定しましょう。

ステップ1: ウェブサイトのディレクトリ構造を作成する

まず、各ウェブサイトのルートディレクトリを作成します。ここにHTML、CSS、JavaScript、その他の静的ファイルが格納されます。一般的な場所は/var/www/です。

sudo mkdir -p /var/www/example1.com/html
sudo mkdir -p /var/www/example2.com/html

# 所有権を自分のユーザーに設定（$USERを自分のユーザー名に置き換えてください）して編集を許可します
sudo chown -R $USER:$USER /var/www/example1.com/html
sudo chown -R $USER:$USER /var/www/example2.com/html

# ウェブサーバーの読み取り権限を設定します
sudo chmod -R 755 /var/www

次に、設定をテストするために、各ディレクトリに簡単なindex.htmlファイルを作成します。

/var/www/example1.com/html/index.htmlの場合：

<!-- /var/www/example1.com/html/index.html -->
<!DOCTYPE html>
<html>
<head>
    <title>Welcome to Example1.com!</title>
</head>
<body>
    <h1>Success! This is Example1.com.</h1>
    <p>This virtual host is working correctly.</p>
</body>
</html>

/var/www/example2.com/html/index.htmlの場合：

<!-- /var/www/example2.com/html/index.html -->
<!DOCTYPE html>
<html>
<head>
    <title>Welcome to Example2.com!</title>
</head>
<body>
    <h1>Success! This is Example2.com.</h1>
    <p>This virtual host is also working!</p>
</body>
</html>

ステップ2: Nginxサーバーブロック設定ファイルを作成する

Nginxは通常、/etc/nginx/sites-enabled/ディレクトリ内のサーバーブロック設定を読み込みます。これらのファイルは通常、/etc/nginx/sites-available/に格納されている設定へのシンボリックリンクです。この分離により、まだアクティブでない設定を保存したり、サイトを簡単に有効/無効にしたりできます。

example1.comの新しい設定ファイルを作成します。

sudo nano /etc/nginx/sites-available/example1.com.conf

以下の内容を追加します。

# /etc/nginx/sites-available/example1.com.conf
server {
    listen 80;
    listen [::]:80;

    root /var/www/example1.com/html;
    index index.html index.htm index.nginx-debian.html;

    server_name example1.com www.example1.com;

    location / {
        try_files $uri $uri/ =404;
    }

    access_log /var/log/nginx/example1.com_access.log;
    error_log /var/log/nginx/example1.com_error.log;
}

ディレクティブの説明:

  • listen 80;: Nginxはポート80（標準HTTP）でリッスンします。listen [::]:80;はIPv6用です。
  • root /var/www/example1.com/html;: このサーバーブロックのドキュメントルートを指定します。Nginxはここでファイルを検索します。
  • index index.html ...;: ディレクトリが要求されたときにNginxが提供すべきデフォルトファイル（例: example1.com/にアクセスした場合）を定義します。
  • server_name example1.com www.example1.com;: これは重要です。Nginxにexample1.comまたはwww.example1.comのリクエストに対してこのサーバーブロックの設定を使用するように指示します。
  • location / { ... }: 特定のURIのリクエストをどのように処理するかを定義するブロック。try_filesは直接ファイル（$uri）、次にディレクトリ（$uri/）を試行し、最後に404 Not Foundエラーを返します。
  • access_logとerror_log: この特定のサイトのために個別のログファイルを指定します。これはデバッグと分析を容易にするための良い習慣です。

次に、example2.comのためにも同様の設定ファイルを作成します。

sudo nano /etc/nginx/sites-available/example2.com.conf

以下の内容を追加します。

# /etc/nginx/sites-available/example2.com.conf
server {
    listen 80;
    listen [::]:80;

    root /var/www/example2.com/html;
    index index.html index.htm index.nginx-debian.html;

    server_name example2.com www.example2.com;

    location / {
        try_files $uri $uri/ =404;
    }

    access_log /var/log/nginx/example2.com_access.log;
    error_log /var/log/nginx/example2.com_error.log;
}

ステップ3: サーバーブロックを有効にする

これらの設定を有効にするには、sites-availableディレクトリからsites-enabledディレクトリへのシンボリックリンクを作成します。これにより、Nginxが起動時にこれらのファイルを含めるようになります。

sudo ln -s /etc/nginx/sites-available/example1.com.conf /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/example2.com.conf /etc/nginx/sites-enabled/

ステップ4: Nginxの設定をテストする

リロードする前に、Nginxの設定に構文エラーがないかテストすることが重要です。これにより、タイプミスによるNginxの再起動失敗を防ぐことができます。

sudo nginx -t

成功を示す、以下のような出力が表示されるはずです。

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

エラーが表示された場合は、該当する設定ファイルを修正し、sudo nginx -tを再度実行してパスするまで繰り返してください。

ステップ5: Nginxを再起動する

Nginxを再起動またはリロードして、新しい設定を適用します。reloadは、アクティブな接続をドロップせずにNginxが新しい設定をロードできるようにするため、一般的に推奨されます。

sudo systemctl reload nginx
# または、reloadが機能しない場合、または新規インストールの場合:
sudo systemctl restart nginx

ステップ6: DNSレコードを更新する

example1.com、www.example1.com、example2.com、www.example2.comのDNS AレコードがすべてNginxサーバーのIPアドレスを指していることを確認してください。正しいDNSエントリがないと、ブラウザはウェブサイトを見つける場所を知りません。

DNSの伝播が完了した後（数分から数時間かかることがあります）、ウェブブラウザでhttp://example1.comとhttp://example2.comにアクセスできるようになり、それぞれのindex.htmlページが表示されるはずです。

高度なシナリオとベストプラクティス

サブドメインのホスティング

サブドメイン（例: blog.example.com、shop.example.com）のホスティングは、独立したドメインのホスティングとまったく同じように機能します。サブドメインをserver_nameとする新しいサーバーブロックを定義するだけです。

blog.example.comの例：

# /etc/nginx/sites-available/blog.example.com.conf
server {
    listen 80;
    listen [::]:80;

    root /var/www/blog.example.com/html;
    index index.html;

    server_name blog.example.com;

    location / {
        try_files $uri $uri/ =404;
    }
}

ディレクトリ（/var/www/blog.example.com/html）を作成し、index.htmlを作成し、シンボリックリンクを作成してNginxをリロードすることを忘れないでください。

デフォルトサーバーブロック

サーバー上の他のどのserver_nameディレクティブにも一致しないドメイン名のリクエストをキャッチするデフォルトサーバーブロックを用意しておくことは良い習慣です。これにより、不明なリクエストがNginxが見つける「最初の」仮想ホストによって提供されるのを防いだり、汎用的な「サイトが見つかりません」ページを提供したりできます。

通常、nginx.confまたはsites-enabledの最初のserverブロックは暗黙的にデフォルトです。default_serverを使用して明示的に設定できます。

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;
    # アンダーバー`_`は、実際の要求と一致しない架空のドメイン名です。
    # localhostを使用することもできます。

    root /var/www/default_site/html;
    index index.html;

    location / {
        return 444; # 未知のホストに対してNginx固有の444エラー（応答なし）を返します
        # または、汎用的なランディングページを提供します:
        # try_files $uri $uri/ =404;
    }
}

警告: default_serverブロックを定義する場合、指定されたlistenポートのserverブロックのうち、default_serverフラグを持つものが1つだけであることを確認してください。そうしないと、Nginxは警告をログに記録します。

HTTPS（SSL/TLS）による仮想ホストの保護

本番環境のウェブサイトでは、HTTPSの有効化が不可欠です。これにはSSL/TLS証明書（例: Certbotを使用したLet's Encrypt経由）の取得と、ポート443で証明書を使用してリッスンするようにNginxを設定することが含まれます。

証明書を取得した後、典型的なHTTPSサーバーブロックは次のようになります。

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name example1.com www.example1.com;

    root /var/www/example1.com/html;
    index index.html;

    ssl_certificate /etc/letsencrypt/live/example1.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example1.com/privkey.pem;

    # その他のSSL設定（暗号スイート、プロトコルなど）を含める
    include /etc/nginx/snippets/ssl-params.conf;
    include /etc/nginx/snippets/force-ssl.conf; # オプション: HTTPからHTTPSへのリダイレクト

    location / {
        try_files $uri $uri/ =404;
    }
}

# オプション: このドメインのHTTPからHTTPSへのリダイレクト
server {
    listen 80;
    listen [::]:80;
    server_name example1.com www.example1.com;
    return 301 https://$host$request_uri;
}

すべてのトラフィックをHTTPSの対応するものにリダイレクトすることだけを目的とした個別のHTTPサーバーブロックを持つことが一般的です。

各サイトのロギング

例に示したように、各仮想ホストに個別のaccess_logとerror_logファイルを割り当てることはベストプラクティスです。これにより、結合されたログを調べることなく、個々のウェブサイトの問題のデバッグやトラフィックの分析が大幅に容易になります。

設定ファイルの構造

大規模なデプロイメントでは、Nginxの設定ファイルを次のように整理することを検討してください。

  • nginx.conf: メイン設定、conf.d/*.confとsites-enabled/*を含みます。
  • conf.d/: 一般的なサーバー全体のセッティング（例: Gzip、キャッシング）。
  • snippets/: 再利用可能なNginx設定スニペット（例: SSLパラメータ、一般的なlocationブロック）。
  • sites-available/: 各ウェブサイトの個々のserverブロック。
  • sites-enabled/: sites-available/内のアクティブな設定へのシンボリックリンク。

一般的な問題のトラブルシューティング

  • 403 Forbidden エラー: これは通常、Nginxがウェブサイトのファイルやディレクトリへの読み取りアクセス権を持っていないことを意味します。ファイルとディレクトリの権限を再確認してください（例: sudo chmod -R 755 /var/www/yourdomain.com/html。Nginxユーザー（通常はwww-dataまたはnginx）がそれらを読み取れることを確認します）。
  • 404 Not Found エラー: サーバーブロックのrootディレクティブが正しいディレクトリを指していること、およびindex.htmlファイルがその場所にあることを確認してください。また、try_filesが正しく設定されていることも確認してください。
  • 間違ったサイトが読み込まれる: これはしばしばserver_nameディレクティブの問題を示しています。server_nameがアクセスしようとしているドメイン名（www.やサブドメインを含む）と正確に一致していることを確認してください。DNSレコードも確認してください。
  • Nginxの起動/リロードに失敗する: Nginxをリロードまたは再起動する前に、必ずsudo nginx -tを使用して設定をテストしてください。エラーメッセージは、構文エラーが発生した行とファイルを特定します。
  • DNSの問題: IPアドレスでサイトにアクセスできるのにドメイン名でアクセスできない場合、それはほぼ確実にDNSの問題です。digまたはnslookupを使用して、ドメインのAレコードが正しいサーバーIPを指していることを確認してください。

結論

Nginx仮想ホスト（サーバーブロック）は、単一のサーバーで複数のウェブサイトをホストするための強力で柔軟な方法を提供します。適切なlisten、server_name、root、locationディレクティブを使用してserverブロックを正しく設定することで、多様なウェブプロパティを効率的に管理できます。このアプローチはリソースを節約するだけでなく、サーバー管理を一元化します。

このガイドで概説された基本的な知識と実践的な手順により、Nginxサーバーで複数のドメインを設定および管理できるようになりました。設定は常にテストし、サイトをHTTPSで保護し、堅牢で保守可能なウェブ環境のためにロギングとディレクトリ構造のベストプラクティスに従うことを忘れないでください。ここから、リバースプロキシ、ロードバランシング、キャッシングなどのNginxの機能をさらに探求して、ウェブサーバーのパフォーマンスと信頼性を向上させることができます。