2026年5月21日

Nginxのserver blockの書き方と設定手順（HTTP・HTTPS・WordPress対応）

Webサーバー・Nginx

Nginx の server block は、「どのドメイン（またはIPアドレスとポート）へのリクエストを、どう処理するか」を定義する設定の単位で、Apache のバーチャルホストに当たります。1台のサーバーで複数のサイトを動かすときは、サイトごとに server block を書きます。

この記事では、設定ファイルの置き場所、HTTP だけの基本形、有効化と構文チェックの手順、HTTPS の設定、WordPress（PHP-FPM）で使う場合の設定、リクエストがどの server block に振り分けられるかを順に説明します。設定例は2026年10月時点の Nginx 安定版（1.30）で nginx -t による構文チェックを通したものです。

設定ファイルの置き場所

server block を書くファイルの場所は、Nginx の入れ方によって違います。/etc/nginx/nginx.conf の http { … } の中にある include の行を見ると、どこが読み込まれるかを確認できます。

入れ方	置き場所	有効化の方法
Debian / Ubuntu の標準パッケージ	`/etc/nginx/sites-available/` に作成	`/etc/nginx/sites-enabled/` にシンボリックリンクを作る
RHEL 系（AlmaLinux など）の標準パッケージ、nginx.org の公式パッケージ	`/etc/nginx/conf.d/`	拡張子 `.conf` のファイルを置くだけで読み込まれる

以下では、ドメインを example.com、公開するファイルを /var/www/example.com/html に置く例で説明します。ドメインとパスは自分の環境に置き換えてください。設定ファイルの全体構造は Nginxの設定ファイルの構造も参照してください。

手順1：公開するファイルを用意する

sudo mkdir -p /var/www/example.com/html
echo 'Hello from example.com' | sudo tee /var/www/example.com/html/index.html

手順2：HTTP の server block を書く

まず HTTP（80番ポート）だけで動く基本形を書きます。Debian / Ubuntu なら /etc/nginx/sites-available/example.com、RHEL 系なら /etc/nginx/conf.d/example.com.conf に保存します。

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

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

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

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

項目	意味
`listen`	待ち受けるポート。`[::]:80` は IPv6 用。サーバーで IPv6 を無効にしている場合はこの行を外す
`server_name`	この server block が受け持つドメイン名。スペース区切りで複数書ける
`root`	公開するファイルのディレクトリ
`index`	URL がディレクトリを指したときに返すファイル
`access_log` / `error_log`	サイトごとにログを分けると、調査がしやすくなる
`try_files`	要求されたファイル、ディレクトリの順に探し、無ければ 404 を返す

手順3：有効化して構文チェックし、再読み込みする

Debian / Ubuntu では、sites-enabled にシンボリックリンクを作って有効にします。RHEL 系で conf.d に置いた場合、この操作は不要です。

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

設定を反映する前に、構文チェックをします。誤りがあるまま再読み込みすると、設定が反映されません。

sudo nginx -t

syntax is ok と test is successful が出たら、設定を再読み込みします。reload は処理中の接続を切らずに新しい設定に切り替えます。

sudo systemctl reload nginx

curl -H 'Host: example.com' http://サーバーのIPアドレス/ やブラウザでアクセスし、index.html の内容が返ることを確認します。エラーが出たときの読み方は Nginxの設定ファイルをテストする方法を参照してください。

手順4：HTTPS の server block を書く

HTTPS にするには、サーバー証明書が必要です。Let's Encrypt の certbot で取得する手順は certbotでNginxにSSL証明書を設定する方法で説明しています（certbot の --nginx オプションを使うと、server block への追記も自動で行われます）。ここでは、証明書が /etc/letsencrypt/live/example.com/ にある前提で、手で書く場合の形を示します。

# HTTP: すべて HTTPS へ転送する
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    return 301 https://example.com$request_uri;
}

# HTTPS: www 付きは www なしへ転送する
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name www.example.com;

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

    return 301 https://example.com$request_uri;
}

# HTTPS: 本体
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name example.com;

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

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

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

書くときの注意点は次のとおりです。

SSL は listen 443 ssl; で有効にする：古い記事にある ssl on; は Nginx 1.15.0 で非推奨になり、1.25.1 で削除されました。現在の Nginx で書くと unknown directive "ssl" というエラーで起動しません。また、listen 80; の server block に ssl on; を書く形は、80番ポートで HTTPS を待ち受けることになり、通常のアクセスが失敗します。
HTTP/2 の書き方はバージョンで違う：http2 on; は Nginx 1.25.1 以降の書き方です。nginx -v で確認し、1.25.1 より古い場合は http2 on; の行を外し、listen 443 ssl http2; と書きます。1.25.1 以降で listen … http2 と書くと、非推奨の警告が出ます。詳しくは NginxでHTTP/2を有効にする方法を参照してください。
ssl_certificate には中間証明書を含むファイルを指定する：Let's Encrypt なら cert.pem ではなく fullchain.pem です。cert.pem を指定すると、一部の環境で証明書エラーになります。
TLS のバージョン：2026年10月時点の公式ドキュメントでは、ssl_protocols の既定値は TLSv1.2 TLSv1.3 です。nginx.conf や古い設定から引き継いだファイルに ssl_protocols TLSv1 TLSv1.1 …; のような行があれば、TLSv1.2 TLSv1.3 に直します。

書き換えたら、手順3と同じく sudo nginx -t と sudo systemctl reload nginx を実行します。

WordPress（PHP-FPM）で使う場合

WordPress を動かす場合は、本体の server block の index と location を次のように変えます。PHP の処理は PHP-FPM に渡します。

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name example.com;

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

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

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    # .htaccess や .git などのドットファイルを返さない（.well-known は除く）
    location ~ /\.(?!well-known/) {
        deny all;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }

    location ~* \.(css|js|png|jpe?g|gif|svg|webp|ico|woff2?)$ {
        expires 30d;
        access_log off;
    }
}

try_files $uri $uri/ /index.php?$args; で、実在しない URL を WordPress の index.php に渡します。これでパーマリンク設定の「投稿名」などが動きます。
fastcgi_pass のソケットのパスは環境で違います。Debian / Ubuntu では /run/php/ の下に php8.3-fpm.sock のような名前で、RHEL 系の標準パッケージでは /run/php-fpm/www.sock が一般的です。ls /run/php/ /run/php-fpm/ で実際の名前を確認します。
正規表現の location は、書いた順に評価され、最初に一致したものが使われます。ドットファイルを拒否する location を先頭に置いているのはそのためです。
expires 30d; は CSS や画像をブラウザに30日キャッシュさせる設定です。ファイルを更新しても古いものが表示される場合は、WordPress がファイルの URL に付けるバージョン番号（?ver=）が変わっているかを確認します。

PHP-FPM の設定やチューニングは NginxとPHP-FPMの設定方法で説明しています。

どの server block が選ばれるか

1つのサーバーに複数の server block があるとき、Nginx は次の順にリクエストの行き先を決めます。

リクエストを受けたIPアドレスとポートに一致する listen を持つ server block に絞り込みます。
その中から、リクエストの Host ヘッダーと server_name が一致するものを選びます。
どれにも一致しない場合は、そのポートの 既定の server block が使われます。既定は、listen に default_server を付けたもの、付けていなければそのポートで最初に読み込まれた server block です。

設定していないドメイン名や IP アドレス直打ちのアクセスが、意図しないサイトに届くのを防ぐには、何も返さない既定の server block を用意します。return 444; は、応答を返さずに接続を閉じる Nginx 独自の指定です。

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444;
}

Debian / Ubuntu では、最初から有効になっている /etc/nginx/sites-enabled/default に default_server が付いています。同じポートに default_server が2つあると nginx -t がエラーになるので、上の設定を追加する場合は、default のリンクを削除する（sudo rm /etc/nginx/sites-enabled/default）か、どちらか一方から default_server を外します。

うまく動かないときの確認

nginx -t がエラーになる：エラーメッセージにファイル名と行番号が出ます。unknown directive "ssl" なら ssl on; が残っています。
別のサイトや Nginx の初期ページが表示される：server_name の綴り、シンボリックリンクの有無、default_server の重複を確認します。sudo nginx -T で、実際に読み込まれている設定全体を表示できます。
403 Forbidden になる：root のディレクトリに index で指定したファイルがあるか、Nginx の実行ユーザーがファイルを読めるかを確認します。
502 Bad Gateway になる（WordPress）：PHP-FPM が起動しているか、fastcgi_pass のソケットのパスが合っているかを確認します。

まとめ

server block はサイトごとの設定の単位です。Debian / Ubuntu は sites-available に書いて sites-enabled にリンク、RHEL 系や公式パッケージは conf.d/*.conf に置きます。
反映前に sudo nginx -t、反映は sudo systemctl reload nginx です。
HTTPS は listen 443 ssl; で有効にします。ssl on; は現在の Nginx では使えません。HTTP/2 は 1.25.1 以降なら http2 on; です。
WordPress では try_files $uri $uri/ /index.php?$args; と PHP-FPM への fastcgi_pass を設定します。
振り分けは listen → server_name → default_server の順に決まります。