Nginx サーバーブロックによる複数サイトの効果的なホスティング方法

Nginxサーバーブロックは、一つのNginxインストール上で複数のドメインやWebサイトを独立した設定で公開できる「バーチャルホスト」方式です。例えば、同じVPS上でexample.com、blog.example.com、second-site.comなどにそれぞれ異なるルートディレクトリ、ログファイル、SSL証明書、PHP設定を割り当てられます。実際の手順は、各サイト用のディレクトリ作成、DNSレコードでドメインをサーバーIPに向ける、/etc/nginx/sites-availableに各サイト用の設定ファイルを作成、sites-enabledディレクトリにシンボリックリンクを張る、設定をテストし、Nginxサービスを再読み込みする流れです。

本ガイドでは、Nginxサーバーブロックを活用した複数サイトの運用を、実務レベルで管理・安全・高速・バックアップ・スケールの観点から解説します。特に、制作代理店、開発者、ECサイト運営者、複数ブランド管理企業、一台サーバーで複数プロジェクトを動かすシステム担当者向けの実践的な手順をまとめました。まだサーバーをお持ちでない場合は、VPSサーバーや、ドメイン管理についてはドメイン登録ページをご参照ください。

Nginxサーバーブロックとは？

Nginxサーバーブロックは、Nginxの設定ファイル内で「server」ブロックとして定義され、HTTP/HTTPSリクエストがどのサイトに割り当てられるかを決定する構成ユニットです。ApacheのVirtualHostと近い概念です。ユーザーがブラウザにドメインを入力すると、DNSがIPアドレスに変換し、NginxがリクエストのHostヘッダーでserver_nameに一致するブロックを動かします。

これにより、一つのIP・物理/仮想サーバー上で数十のサイトを並列公開できます。各サイトごとにルートディレクトリ、アクセスログ、エラーログ、リダイレクト、SSL証明書、キャッシュ方針、セキュリティルールを分離設定可能。例えば、コーポレートサイトは/var/www/corp/public、ブログは/var/www/blog/public、テスト環境は/var/www/staging/publicなどに分けられます。

Nginxはイベント駆動型アーキテクチャで高並列接続を省リソースで処理できるため、共有ホスティング、VPS、クラウドサーバー、高トラフィックアプリ基盤で人気です。複数サイト運用を安定させるには、ファイル権限、DNS設定、SSL導入、ログ分離など細部の設計が重要です。

Nginxサーバーブロックはどんな時に使う？

一台のサーバーで複数のウェブ資産を管理したい時、Nginxサーバーブロックが役立ちます。例えば、2つのコーポレートサイトや、数十のクライアント案件、サブドメイン、マイクロサービスなど。大切なのは、各プロジェクトを論理的に分離することです。

• 複数ドメインを同一VPSで公開したい場合。
• www有り無しを統一したカノニカルURLにリダイレクトしたい場合。
• サブドメインを異なるフォルダやアプリに紐付けたい場合。
• 各サイトに専用SSL証明書やセキュリティポリシーを設定したい場合。
• クライアントごとに独立したログでアクセス解析したい場合。
• Laravel、WordPress、静的HTML、Node.jsなど異種アプリを一台で運用したい場合。

例えば、デジタル制作会社が4GB RAMのVPSで8つの低トラフィックコーポレートサイトを公開することは技術的に可能ですが、各サイトごとのトラフィック、ディスク消費、PHPプロセス数、DB負荷、バックアップ頻度を計算する必要があります。高トラフィック/リソース分離が重要な場合は、より高性能なVPSやクラウド、マネージドホスティングが適しています。ウェブホスティングや法人ホスティングで比較できます。

事前準備と要件

本ガイドはUbuntuまたはDebian系Linuxサーバーを前提にしています。コマンドはディストリビューションによって多少異なりますが、基本原則は同じです。本番環境で作業する際は必ずバックアップを取ってください。不適切なNginx設定は全サイトの一時的な停止を招く場合があります。

技術的な事前準備

• rootまたはsudo権限を持つLinuxユーザーアカウント。
• Nginxサービスがインストール済みかつ稼働中であること。
• サーバーIPアドレスに向けた最低1つのドメイン。
• ファイアウォールで80, 443ポートが開放されていること。
• サイトファイル用の整理されたディレクトリ構造。
• SSL証明書（有効なもの、または無料Let’s Encryptも可）。
• PHPベースアプリ用にPHP-FPMがインストールされていること。

DNS側では、AレコードがドメインをIPv4に、AAAレコードがIPv6に向けます。www等のサブドメインにはCNAMEやAレコードが使われます。DNS伝播は数分から24時間程度。新規構築時はまずDNSレコードを用意し、その後Nginxサーバーブロックの設定へ進むと効率的です。

推奨ディレクトリ構造

複数サイト管理で最も多いミスは、全ファイルを一つのディレクトリに乱雑に格納することです。短期的には簡単に見えますが、保守・バックアップ・デバッグ時に大きな時間ロスになります。より良い方法は、各ドメインごとにトップディレクトリを設け、その下にpublic, logs, backups等のサブディレクトリを用意することです。

例えば、/var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public, /var/www/site2.com/logsのような構造です。Nginxのrootはpublicディレクトリを直接指定しましょう。こうすることで、.env等の機密ファイルやバックアップがWeb経由で直接アクセスされません。

各サイトフォルダにテスト用index.htmlを置き、サイト名を記載するとサーバーブロックの動作確認が速やかに行えます。本番環境では、これらのディレクトリは通常www-dataユーザーか、デプロイ用特別ユーザーが所有します。ディレクトリ755、ファイル644が静的サイトでは基本。WordPress等で書き込みが必要なuploads等は個別に検討しましょう。

ステップバイステップ：Nginxサーバーブロックの作成

以下の手順はsite1.comを例にしています。同様の方法で2つ目、3つ目のサイトにも展開可能。各サイトでserver_name, root, logファイルを固有化することがポイントです。

1. サイト用ディレクトリを作成

まずウェブファイル格納ディレクトリを作成します。例：sudo mkdir -p /var/www/site1.com/public。テスト用に/var/www/site1.com/public/index.htmlを作成し、「site1.com テストページ」などサイト固有の文言を記載できます。

所有者設定はsudo chown -R www-data:www-data /var/www/site1.comで調整。デプロイユーザーが異なる場合はグループ権限も調整。全員書き込み可能な777は避けましょう。これは不正アップロード等のリスクを高めます。

2. サーバーブロック設定ファイルを作成

Nginxでは、非アクティブ設定を/etc/nginx/sites-availableに保管し、アクティブ化時に/etc/nginx/sites-enabledへシンボリックリンクを張るのが一般的です。例：/etc/nginx/sites-available/site1.com。

基本的なHTTPサーバーブロック例：
server {
  listen 80;
  server_name site1.com www.site1.com;
  root /var/www/site1.com/public;
  index index.html index.htm;
  access_log /var/log/nginx/site1.com.access.log;
  error_log /var/log/nginx/site1.com.error.log;
  location / { try_files $uri $uri/ =404; }
}

listen 80はHTTPトラフィックを受け、server_nameはどのドメインがこのブロック対象か指定、rootはウェブファイルの場所、indexはデフォルトファイル。try_filesはファイル・ディレクトリがなければ404を返します。静的サイトには十分な設定です。

3. サイトを有効化する

設定を有効化するにはシンボリックリンクを作成します：
sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com
この方法はファイルコピーより安全。設定変更時もリンク先が最新になります。

デフォルトNginxページがサイトより優先される場合は、/etc/nginx/sites-enabled/defaultリンクを削除できます。ただし自サイトのサーバーブロックが正しく動作することを事前確認しましょう。

4. 設定をテストし、Nginxを再読み込み

変更毎にsudo nginx -tで構文チェック。成功したらsudo systemctl reload nginxでサービスを無停止再読み込み。reloadはrestartより安全で、既存接続をスムーズに管理します。

テスト失敗時はエラーメッセージにファイル名・行番号が示されます。セミコロン忘れ、{}ミス、ディレクトリパス誤り、server_name競合などが典型的な原因。修正せずに再読み込みしてはいけません。

2つ目・3つ目のサイト追加方法

複数サイト運用の利点は、初回設定が正しければ以降の手順が繰り返しやすいことです。site2.comの場合は/var/www/site2.com/publicを作成し、/etc/nginx/sites-available/site2.com設定ファイルを作成、rootやlogをsite2.comに変更、シンボリックリンク、Nginxテストを行います。

site2.com用の基本設定例：
server {
  listen 80;
  server_name site2.com www.site2.com;
  root /var/www/site2.com/public;
  index index.html;
  access_log /var/log/nginx/site2.com.access.log;
  error_log /var/log/nginx/site2.com.error.log;
  location / { try_files $uri $uri/ =404; }
}

各サイト独立ログは実運用で非常に重要です。例えば、あるサイトだけ404が増えたらすぐ原因特定できます。トラフィック解析、ボット攻撃、リンク切れ、パフォーマンス問題もサイト単位で監視可能です。

SSL・HTTPSの設定ポイント

2026年のSEO基準ではHTTPSは信頼性・技術品質の証。ブラウザはHTTPサイトを「安全でない」と表示し、決済・会員登録・フォーム・管理画面のあるサイトはSSL必須。複数サイト運用時は各ドメインに正しい証明書を設定しましょう。SSL証明書についてはSSL証明書もご覧ください。

Let’s Encryptの場合はCertbotで各ドメイン毎に証明書を取得できます。certbot --nginx -d site1.com -d www.site1.comコマンドでNginx設定が自動編集されHTTPSブロックが追加されることも。ただし自動編集後は必ず内容確認を。リダイレクトや重複ブロック問題が起きる場合もあります。

HTTPS設定時は通常、80番ポートのトラフィックを443へ恒久リダイレクトします。301リダイレクトはSEOのカノニカル選択シグナル。www有無を統一し、全バリエーションを一つのカノニカルURLに集約。例えばhttps://site1.comのみを使う場合は、HTTP/HTTPSのwwwトラフィックも非wwwへリダイレクトし、重複コンテンツリスクを避けます。

PHP・WordPressサイト用サーバーブロック

静的HTMLサイトは簡単ですが、WordPressやLaravel等のPHPアプリではPHP-FPMと連携が必要。index.phpを定義し、PHPリクエストを適切なソケットに渡します。例：UbuntuでPHP 8.3なら/run/php/php8.3-fpm.sock。バージョンはサーバー構成により異なります。

PHPサイト設定例：
server {
  listen 80;
  server_name wordpress-site.com www.wordpress-site.com;
  root /var/www/wordpress-site.com/public;
  index index.php index.html;
  location / { try_files $uri $uri/ /index.php?$args; }
  location ~ php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
  }
}

WordPressではパーマリンク対応のためtry_files $uri $uri/ /index.php?$argsが重要。さらにxmlrpc.php制限、wp-login.phpのレートリミット、uploadsフォルダ内でのPHP禁止などセキュリティ対策も検討しましょう。複数WordPressサイトを同一VPSで運用する際は、各サイトごとに独立DB、DBユーザー、定期アップデート方針を徹底。管理性重視ならWordPressホスティングもおすすめです。

NginxサーバーブロックとApache VirtualHostの比較

NginxとApacheは異なるアーキテクチャで同じ目的を達成します。どちらも一台で複数サイトが可能。選択はアプリ要件・管理慣習・パフォーマンス期待値によります。

.htaccess依存のアプリではApacheが楽ですが、高トラフィック・リバースプロキシ・キャッシュ・モダンな運用にはNginxが強力。両者を組み合わせてNginxリバースプロキシ＋Apacheバックエンド構成も可能です。

セキュリティのベストプラクティス

一台のサーバーで複数サイトを運用するとコスト効率は高まりますが、セキュリティ責任も増します。一つのサイトの脆弱性が他サイトに波及しないよう、分離・最小権限を徹底しましょう。

• 各サイトごとに独立DBとDBユーザーを作成
• Webルートはpublicディレクトリだけに限定
• バックアップ、.env、.git、config、SQLファイルはWeb公開外で管理
• SSL証明書は定期更新し、HTTPSリダイレクトを強制
• UFW等のファイアウォールを使い、必要なポートのみ開放
• NginxやOSのアップデートは定期実施
• 各サイト用に独立access_log・error_logを保存
• 管理画面にはIP制限や追加認証を導入
• 777等の広域権限は避ける

さらに、X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Content-Security-Policy等のセキュリティヘッダーも有効です。ただしContent-Security-Policyは誤設定するとスクリプトやスタイルが動かなくなる場合があるため、まずテスト環境で確認を。セキュリティ詳細はウェブサイトセキュリティ記事もご参照ください。

パフォーマンス・SEO最適化ポイント

Nginxサーバーブロックは公開だけでなく、パフォーマンスやSEO品質にも直結します。リダイレクトの多重化、カノニカル設定ミス、gzip/brotli圧縮不足、大型ログファイル、キャッシュ設定不足はサイト速度低下の要因となります。Googleのページ体験指標はユーザー視点。速く、安全、安定したサイトが高評価を得やすいです。

まず各ドメインごとに単一カノニカルURLを決定。HTTP→HTTPS、www→非www（または逆）へのリダイレクトは一回で完了させましょう。例えば、http://site.com→http://www.site.com→https://www.site.com→https://site.comのような多段階は避け、単一301で目的地へ誘導。

静的ファイルにはcache-controlヘッダーを設定。画像・CSS・JS等はブラウザキャッシュ期間を設け、頻繁に更新されるファイルはファイル名バージョンやクエリストリングで管理。gzip圧縮はHTML, CSS, JS, JSON等に有効で帯域消費を抑えます。高トラフィックサイトではNginx microcache, FastCGI cache, CDN導入も検討。CDNやグローバル配信要件はCDNとは記事を参考に。

ログ管理・監視の重要性

複数サイト運用時、ログ管理は問題解決の鍵です。独立ログはどのサイトで何が起こったか明確に把握できます。access_logは訪問者リクエスト、error_logは設定ミス・権限・ファイル不在・アップストリームエラーを記録。502 Bad GatewayはPHP-FPMやバックエンド接続問題。403 Forbiddenは権限やindexファイル不足。404 Not Foundはパス・リライト・DNS後の誤root設定が原因となります。

ログファイルの無制限肥大化を防ぐため、logrotate設定を確認。小規模なら日次・週次ローテーションで十分。高トラフィックなら集中ログ収集・メトリクス監視・アラートも検討。ディスク満杯はNginxログ書き込み停止、DB停止、サイト接続不能の原因となるため、ディスク使用量の閾値監視が有効です。

よくあるミスと迅速な解決策

Nginxサーバーブロック運用時、どのプロジェクトでも遭遇しやすい典型的ミスがあります。事前に把握しておくと設計・構築時間が大幅短縮できます。

• ドメインが誤サイトを表示：server_name競合やdefaultブロックを確認
• 403 Forbidden：rootディレクトリ、ファイル権限、indexファイル有無を確認
• 404 Not Found：rootパス・try_files設定を見直し
• 502 Bad Gateway：PHP-FPMサービス稼働とソケットパスを確認
• SSL証明書が誤サイト用：443のserver_nameと証明書ファイルをチェック
• リダイレクトループ：HTTP-HTTPSやwwwリダイレクト設定を簡素化
• Nginx reload不可：sudo nginx -tの出力で行番号・構文エラーを修正

経験豊富な管理者は「DNS→Nginx設定→rootフォルダ→権限→構文テスト→ログ」の順で問題切り分けします。この流れを守ると冷静に迅速な解決が可能です。

本番環境用チェックリスト

公開前に以下チェックリストで各サイトを総点検しましょう。特にクライアント案件納品時はこの項目を記録することで高いプロフェッショナル基準を維持できます。

• ドメインのA/AAAAレコードが正しいIPに向いている
• www有無のカノニカルURL選定済み
• HTTPトラフィックはHTTPSへ301リダイレクト
• SSL証明書が有効・自動更新も設定済み
• 各サイトごとにroot・ログファイルを分離指定
• Nginx設定はsudo nginx -tで検証済み
• バックアップ計画・リストアテストも完了
• ファイル権限は最小権限原則遵守
• ファイアウォールは必要ポートのみ開放
• 公開後15分以上エラーログ監視済み

このリストは一見簡単ですが、実案件ではダウンタイムリスクを大幅に減らします。SSL更新・DNS確認・ログ監視は特に見落としやすい点です。

まとめ

Nginxサーバーブロックは、一台のサーバー上で複数サイトを整理・安全・高パフォーマンスで運用する基本手法です。適切なディレクトリ構成、分離設定ファイル、明確なリダイレクトルール、HTTPS活用、ログ分離、定期テストで複数サイト管理は大変効率的になります。小規模ポートフォリオから多数クライアント案件まで同じ原則が適用可能です。

新規プロジェクト公開時は、まずドメイン・サーバーリソース・SSL要件を明確化し、上記チェックリストでNginx設定を一つずつ構築しましょう。より管理しやすい基盤を求める場合は、Hostragonsのホスティングパッケージ、VPSサーバー、SSL証明書ソリューションもご検討ください。

よくある質問

Nginxサーバーブロックで何サイトまでホスティング可能？

技術的にはNginxで多数サイトを同一サーバーで運用できますが、CPU・RAM・ディスク・トラフィック・DB負荷・PHP-FPMキャパシティが制限要因です。低トラフィック静的サイトなら数十サイトも可能ですが、重いWordPressやECサイトでは少数運用が安全です。

各サイトごとにSSL証明書が必要ですか？

はい。各ドメインやサブドメインをHTTPSで公開する場合、証明書が必要です。個別証明書、SAN/Wildcard証明書も選択可能。重要なのはNginxの443サーバーブロックで正しい証明書ファイルを正しいドメインに割り当てることです。

Nginxサーバーブロックでサブドメイン公開は可能？

可能です。blog.site.comやpanel.site.comなどサブドメイン用にserver_nameを指定し、独立したrootディレクトリやバックエンドアプリへ割り当てられます。DNS側では該当サブドメインのA/CNAMEレコード設定が必要です。

sites-availableとsites-enabledの違いは？

sites-availableは利用可能な設定ファイルの保管場所、sites-enabledは実際に有効な設定を含みます。通常はsites-enabledにsites-availableへのシンボリックリンクを張り、サイトのON/OFF管理が容易になります。

誤サイトが表示される場合、原因は？

主な原因は、DNSが誤IPへ向いている、server_name誤り、default Nginxブロックがリクエストを受けている、443側で誤SSLブロックが動いている等です。まずDNSレコード、nginx -t出力、sites-enabledのリンク、access_logを確認しましょう。