2026年7月12日
2026年7月12日
Nginxでサブドメインを設定する方法(DNS・server block・HTTPS化まで)
Nginx でサブドメインを使うには、DNS にサブドメインのレコードを追加し、Nginx にそのホスト名専用の server ブロックを1つ作るだけで済みます。この記事では、blog.example.com のようなサブドメインを1つ追加する基本手順から、意図しないサイトが表示される問題を防ぐ既定サーバーの設定、HTTPS 化、ワイルドカードで多数のサブドメインを扱う方法、WordPress を載せるときの注意点までを説明します。
全体の流れ
サブドメインの追加は次の4段階です。どこで止まっているかを切り分けやすいように、段階ごとに確認しながら進めます。
- DNS にサブドメインのレコードを追加し、サーバーの IP に向くことを確認する
- ドキュメントルートを作り、Nginx に server ブロックを追加する
- 構文チェックと再読み込みをして、HTTP で表示を確認する
- 証明書を取得して HTTPS 化する
1. DNS レコードを追加する
ドメインを管理している DNS サービスで、サブドメインのレコードを追加します。同じサーバーで動かすなら、blog という名前で A レコード(IPv4)を、IPv6 を使っているなら AAAA レコードも登録します。別のホスト名と同じ向き先にしたい場合は CNAME でも構いません。
反映を確認するには dig を使います。
dig +short blog.example.com A
dig +short blog.example.com AAAA
サーバーの IP が返れば準備完了です。何も返らない場合は、レコード名の入力ミス(blog.example.com.example.com のように二重になっているなど)や、ネームサーバーが別のサービスを向いていないかを確認してください。AAAA レコードが古いサーバーを向いたまま残っていると、IPv6 で接続する利用者や証明書の発行だけが失敗する、という分かりにくい症状になります。
2. server ブロックを追加する
公開するファイルの置き場所を作ります。
sudo mkdir -p /var/www/blog.example.com/html
echo 'blog ok' | sudo tee /var/www/blog.example.com/html/index.html
次に、サブドメイン用の設定ファイルを作ります。Debian・Ubuntu のパッケージでは /etc/nginx/sites-available/ に置いて sites-enabled/ にシンボリックリンクを張る方式、公式リポジトリ版や RHEL 系では /etc/nginx/conf.d/ に .conf で置く方式が一般的です。お使いの環境の nginx.conf で include されている場所を確認してください。
# /etc/nginx/sites-available/blog.example.com
server {
listen 80;
listen [::]:80;
server_name blog.example.com;
root /var/www/blog.example.com/html;
index index.html index.php;
access_log /var/log/nginx/blog.example.com.access.log;
error_log /var/log/nginx/blog.example.com.error.log;
location / {
try_files $uri $uri/ =404;
}
}
sudo ln -s /etc/nginx/sites-available/blog.example.com /etc/nginx/sites-enabled/
サブドメインごとにログファイルを分けておくと、あとでトラブルが起きたときにどのサイトの問題かをすぐに見分けられます。
3. 構文チェックと表示確認
sudo nginx -t
sudo systemctl reload nginx
DNS の反映を待たずに Nginx 側の設定だけを確かめたいときは、curl でホスト名を指定してサーバーに直接リクエストします。
curl -H "Host: blog.example.com" http://203.0.113.10/
# または名前解決ごと差し替える
curl --resolve blog.example.com:80:203.0.113.10 http://blog.example.com/
blog ok が返れば server ブロックは正しく選ばれています。メインサイトの内容が返ってくる場合は、server_name の綴りや、設定ファイルが include の対象に入っているかを確認します。
nginx -t で could not build server_names_hash, you should increase server_names_hash_bucket_size と出た場合は、長いホスト名や多数のサーバー名を扱うための領域が足りていません。http ブロックに server_names_hash_bucket_size 64; を追加すると解消することが多いです。
意図しないサイトが表示される問題を防ぐ
Nginx は、リクエストの Host ヘッダーに一致する server_name がないとき、そのポートの既定サーバー(default_server 指定がなければ最初に読み込まれた server ブロック)で応答します。このため、DNS だけ先に向けたサブドメインや、IP アドレス直打ちのアクセスで、メインサイトが表示されてしまうことがあります。検索エンジンに別のホスト名で同じ内容が登録される原因にもなるため、どこにも一致しないリクエストは拒否する既定サーバーを用意しておくのが安全です。
# /etc/nginx/sites-available/00-default
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
return 444;
}
sites-available 方式なら、このファイルも sites-enabled にリンクを張ります。444 は応答を返さずに接続を閉じる Nginx 独自の指定です。既存の default 設定ファイルにすでに default_server が書かれていると重複エラーになるので、どちらか一方にしてください。HTTPS 側でも同じことをしたい場合は、listen 443 ssl default_server; の server ブロックに ssl_reject_handshake on; を指定すると、証明書を用意せずに TLS の接続を拒否できます(比較的新しいバージョンで追加された指定なので、nginx -v で確認してください)。
4. HTTPS 化する
Let's Encrypt の Certbot を使う場合、Nginx プラグインがあれば次のコマンドで証明書の取得と server ブロックへの設定追加をまとめて行えます。
sudo certbot --nginx -d blog.example.com
このとき Certbot は HTTP 経由で所有確認をするので、手順1〜3が終わってサブドメインが 80 番ポートで応答している必要があります。証明書はサブドメインごとに発行するのが基本ですが、多数のサブドメインを1枚で扱いたい場合はワイルドカード証明書(*.example.com)を使います。ワイルドカード証明書は DNS-01 認証でしか取得できず、DNS サービスの API との連携が必要になる点に注意してください。
多数のサブドメインをまとめて扱う
server_name にはワイルドカードや正規表現も使えます。たとえばサブドメイン名に対応したディレクトリを自動で使うには、名前付きキャプチャを使います。
server {
listen 80;
server_name ~^(?<sub>[a-z0-9-]+)\.example\.com$;
root /var/www/sub/$sub;
}
一致の優先順位は、ワイルドカードを含まない正確な名前 → 先頭がワイルドカードの最長一致(*.example.com)→ 末尾がワイルドカードの最長一致 → 設定ファイルに書かれた順で最初に一致した正規表現、です。個別の server ブロックを用意したサブドメインは、正規表現やワイルドカードよりも優先されます。正規表現では、許可する文字を英小文字・数字・ハイフンに限定するなど、想定外のホスト名でディレクトリをたどられないようにしてください。
WordPress をサブドメインで動かす場合
サブドメインに別の WordPress を入れる場合は、上の server ブロックに PHP-FPM への受け渡しを追加し、データベースも別に用意します。サイトアドレスは WordPress の設定画面か、wp-config.php の WP_HOME と WP_SITEURL でサブドメインの URL に合わせます。
1つの WordPress で site1.example.com・site2.example.com のように複数サイトを運用したい場合は、マルチサイトのサブドメイン型を使います。この場合は Nginx 側でワイルドカードの server_name を設定し、DNS にもワイルドカードレコードを追加します。ログイン状態が保持されないといった Cookie まわりの問題が起きやすいため、本番に入れる前にステージング環境で試し、作業前にはファイルとデータベースをバックアップしてください。
この記事は Nginx の安定版と Certbot を前提にしています(2026年10月現在)。設定ファイルの置き場所はディストリビューションやパッケージによって異なります。
まとめ
- DNS に A/AAAA レコードを追加し、
digで向き先を確認してから Nginx の設定に進む - サブドメインごとに server ブロックとログファイルを分け、
nginx -t→reload→curlで確認する - どこにも一致しない Host には応答しない既定サーバーを用意し、意図しないサイトの表示を防ぐ
- HTTPS 化は
certbot --nginx -dで個別に。多数ならワイルドカード証明書(DNS-01)を検討する - WordPress を載せる場合は、別インストールかマルチサイトかを先に決める