Nginxのインストール方法と初期設定（Ubuntu・RHEL系、WordPressを載せる前の準備）

Nginxは、UbuntuならOS標準のパッケージを apt install nginx、AlmaLinuxやRocky Linuxなどは dnf install nginx で入れられ、起動して80番ポートを開ければすぐに初期ページが表示されます。ただし、そのままの設定ではアップロードの上限が小さく、存在しないドメインへのアクセスにも最初のサイトが応答してしまいます。この記事では、パッケージの選び方、インストールから起動確認まで、そしてWordPressを載せる前に整えておきたい初期設定を説明します。

どのパッケージを使うか

Nginxの入手先は、大きく2つあります。

• OS標準のパッケージ: ディストリビューションが配布するもので、セキュリティ修正もOSの更新と一緒に届きます。バージョンはOSのリリース時点のものに固定され、新しい機能は入りません。
• nginx.orgの公式リポジトリ: Nginxの開発元が配布するもので、新しいバージョンを使えます。新機能や修正が早く入る「mainline」と、大きな修正だけを入れる「stable」の2系統があります。

WordPressを1台のサーバーで動かす用途なら、まずはOS標準のパッケージで十分です。HTTP/3など新しい機能が必要になった場合や、OS標準の版が古すぎる場合に公式リポジトリを検討します。公式リポジトリを使う場合は、署名鍵の登録手順がnginx.orgのドキュメント（Linux packages のページ）に載っているので、その時点の手順に従ってください（2026年10月現在）。なお、2つの入手先では設定ファイルの構成が少し異なります。この記事は、主にOS標準のパッケージを前提にしています。

インストールと起動

Ubuntu・Debian

sudo apt update
sudo apt install nginx
sudo systemctl enable --now nginx

Ubuntuでは、インストールと同時にNginxが起動する設定になっています。

RHEL系（AlmaLinux・Rocky Linuxなど）

sudo dnf install nginx
sudo systemctl enable --now nginx

enable --now は、今すぐ起動したうえで、サーバーの再起動後にも自動で起動するように登録する指定です。

起動の確認

systemctl status nginx
nginx -v
curl -I http://127.0.0.1/

active (running) と表示され、curl で HTTP/1.1 200 OK が返れば、Nginxは動いています。

起動に失敗して、エラーに bind() to 0.0.0.0:80 failed (98: Address already in use) と出る場合は、Apacheなどほかのソフトウェアが80番ポートを使っています。sudo ss -ltnp | grep ':80' でどのプロセスが使っているかを確認し、不要ならそちらを停止して自動起動を外します。

ファイアウォールを開ける

サーバー内からは表示できても、外部から開けないときは、ファイアウォールを確認します。

# Ubuntu（ufwを使っている場合）
sudo ufw allow 'Nginx Full'
sudo ufw status

# RHEL系（firewalldを使っている場合）
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

Nginx Full は、80番と443番の両方を開けるufwのプロファイルです。SSHで接続しているサーバーでufwを初めて有効にする場合は、先にSSHを許可しておかないと接続が切れるので注意してください。クラウドのサーバーでは、OSのファイアウォールとは別に、管理画面のセキュリティグループなどでも80番・443番を開ける必要があります。

設定ファイルの構成を把握する

Nginxの設定は /etc/nginx/nginx.conf が起点で、そこからほかのファイルを読み込む構成になっています。

• Ubuntu・Debian: サイトごとの設定を /etc/nginx/sites-available/ に置き、/etc/nginx/sites-enabled/ にシンボリックリンクを作って有効にします。初期状態では default というサイトが有効になっています。
• RHEL系・nginx.orgのパッケージ: /etc/nginx/conf.d/ にある .conf で終わるファイルがすべて読み込まれます。

実際にどのファイルが読み込まれているかは、すべての設定を展開して表示する nginx -T で確認できます。

sudo nginx -T | grep "# configuration file"

ドキュメントルートの初期値も環境によって異なり、Ubuntuでは /var/www/html、RHEL系では /usr/share/nginx/html です。Nginxの実行ユーザーは、Ubuntuでは www-data、RHEL系では nginx です。WordPressのファイルの所有者を決めるときに必要になるので、nginx.conf 先頭の user の行を確かめておきます。

初期設定で整えておく項目

設定ファイルを編集する前に、元の状態を保存しておきます。

sudo cp -a /etc/nginx /root/nginx-backup-$(date +%Y%m%d)

そのうえで、nginx.conf の http ブロックの中を中心に、次の項目を確認します。Ubuntuでは、/etc/nginx/conf.d/ に新しいファイルを作って書くと、パッケージの更新で nginx.conf が置き換わる際の衝突を避けられます。

# /etc/nginx/conf.d/00-basic.conf（httpブロックの中で読み込まれる）
server_tokens off;
client_max_body_size 64m;

• **worker_processes**: nginx.conf の先頭にあり、多くのパッケージでは auto（CPUのコア数に合わせる）になっています。特別な理由がなければそのままで構いません。
• **server_tokens off**: エラーページや応答ヘッダーにNginxのバージョン番号を出さないようにします。これだけで攻撃を防げるわけではありませんが、余計な情報を出さないための基本の設定です。
• **client_max_body_size**: 受け付けるリクエストの大きさの上限で、既定は1MBです。このままだと、WordPressで1MBを超える画像やプラグインをアップロードしたときに 413 Request Entity Too Large になります。PHP側の upload_max_filesize と post_max_size も、同じくらいの値にそろえます。

すでに同じディレクティブが別の場所に書かれていると、nginx -t で directive is duplicate というエラーになります。その場合は、どちらか一方にまとめてください。

知らないドメインへの応答を止める

Nginxは、リクエストの Host ヘッダーに一致するサイトが見つからないとき、そのポートの既定のサイト（default server）で応答します。既定のサイトを決めていないと最初に読み込まれたサイトが使われるため、IPアドレスで直接アクセスされたときや、無関係なドメインを向けられたときに、自分のWordPressサイトが表示されてしまいます。

これを避けるには、どのサイトにも一致しないリクエストを受け止める既定のサイトを用意し、接続を閉じる設定にします。

# /etc/nginx/conf.d/default-drop.conf（Ubuntuでは sites-enabled/default を外してから）
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444;
}

444 はNginx独自の値で、応答を返さずに接続を閉じます。Ubuntuの初期状態の default サイトにも default_server が付いているため、両方を残すと重複のエラーになります。sudo rm /etc/nginx/sites-enabled/default でリンクだけを外してください（sites-available の元ファイルは残ります）。RHEL系では、nginx.conf の中に初期ページ用の server ブロックが書かれていることがあります。版によっては default_server が付いているので、nginx -T で確かめ、付いていれば外すか、そのブロックをコメントにします。HTTPSの既定のサイトは証明書が必要になるため、サイトごとの設定と合わせて別の記事で説明しています。

設定の確認と反映

設定を変えたら、文法を確認してから再読み込みします。

sudo nginx -t && sudo systemctl reload nginx

nginx -t で syntax is ok と test is successful が表示されたときだけ、再読み込みが実行されます。reload は処理中の接続を切らずに設定を入れ替えるので、運用中のサーバーでも使えます。設定に誤りがあるまま restart すると、Nginxが起動できずにサイトが止まるため、いつも -t を先に通すようにします。

エラーや動作の確認には、ログを使います。

sudo tail -n 30 /var/log/nginx/error.log

RHEL系でSELinuxが有効な場合、ドキュメントルートを独自の場所にしたり、Nginxからほかのサーバーへ転送したりすると、権限があっても拒否されることがあります。そのときは /var/log/audit/audit.log に拒否の記録が残るので、ファイルのラベルやSELinuxの設定（httpd_can_network_connect など）を確認します。SELinuxを無効にして済ませるのは避けてください。

ここまでで、Nginxの土台は整いました。次は、サイトごとの設定（server block）を作り、PHP-FPMと連携させてWordPressを動かします。

まとめ

• Nginxは、まずOS標準のパッケージで入れ、新しい機能が必要になったらnginx.orgの公式リポジトリを検討します。
• systemctl enable --now nginx で起動と自動起動の登録を行い、80番の競合とファイアウォールを確認します。
• 設定ファイルの構成はディストリビューションによって異なるため、nginx -T で実際に読み込まれているファイルを確かめます。
• WordPress向けには client_max_body_size を広げ、server_tokens off で余計な情報を出さないようにします。
• 一致するサイトがないリクエストは、default_server と return 444 で受け止めます。変更後は nginx -t を通してから reload します。

• Nginxでバーチャルホスト（server block）を設定する
• NginxとPHP-FPMを連携させる方法