2026年10月6日

Nginxのnginx.conf基本設定を解説：構造・継承の規則と最初に見直す項目

Webサーバー・Nginx

nginx.conf は「コンテキスト（ブロック）の入れ子」と「上位の設定が下位に引き継がれる規則」さえ押さえれば、読むのも直すのも難しくありません。この記事では、メインの設定ファイルがどう組み立てられているか、どのディレクティブをどのブロックに書くのか、継承でつまずきやすい点、そして WordPress を載せる前に見直しておきたい基本項目と、変更を安全に反映する手順までを説明します。

個別サイトの server ブロックの書き方は別記事で扱うため、ここでは nginx.conf 本体と http ブロック全体に効く設定に絞ります。

nginx.conf の場所と読み込まれ方

パッケージでインストールした Nginx では、多くの場合 /etc/nginx/nginx.conf がメインの設定ファイルです。ただしビルド方法によって場所は変わるため、次のコマンドで実際に使われているパスを確かめるのが確実な近道です。

nginx -V 2>&1 | tr ' ' '\n' | grep conf-path
# 出力例: --conf-path=/etc/nginx/nginx.conf

メインファイルには全設定が書かれているわけではなく、include で別ファイルを取り込む構成が一般的です。代表的なのは次の2通りです。

Debian・Ubuntu 系: sites-available/ にサイトごとの設定を置き、有効にするものだけ sites-enabled/ にシンボリックリンクを張る。nginx.conf の http ブロックに include /etc/nginx/sites-enabled/*; がある
nginx.org 公式パッケージや RHEL 系: conf.d/*.conf を読み込む。ファイル名が .conf で終わらないと読まれない

「設定を書いたのに効かない」という相談の多くは、そのファイルがそもそも include されていないことが原因です。読み込まれた結果の全体は sudo nginx -T で一覧表示できるので、迷ったらまずこれで確認します。

コンテキストの入れ子構造

nginx.conf は次のような階層になっています。

# main コンテキスト（ファイルの最上位）
user  www-data;
worker_processes  auto;
error_log  /var/log/nginx/error.log warn;
pid        /run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout  65;

    server {
        listen 80;
        server_name example.com;

        location / {
            root /var/www/example.com;
        }
    }
}

それぞれの役割は次のとおりです。

main: プロセス全体に関わる設定。実行ユーザー（user）、ワーカー数（worker_processes）、エラーログ、PID ファイルなど
events: 接続の扱い。1ワーカーあたりの同時接続数（worker_connections）など
http: HTTP サーバーとしての共通設定。MIME タイプ、ログ形式、圧縮、タイムアウトなど
server: 1つのサイト（ホスト名とポートの組み合わせ）
location: URL のパスごとの処理

ディレクティブには「書いてよいコンテキスト」が決まっています。たとえば worker_processes を http の中に書くと、nginx -t が「directive is not allowed here」というエラーを返します。公式ドキュメントの各ディレクティブの説明にある「Context:」の欄が、書ける場所の一覧です。

user に指定する名前はディストリビューションで異なります（Debian 系は www-data、公式パッケージや RHEL 系は nginx が多い）。PHP-FPM のプールのユーザーやファイルの所有者と揃っていないと、アップロードやキャッシュ書き込みで権限エラーが出ます。

継承の規則と add_header の落とし穴

上位のコンテキストに書いた設定は、下位で同じディレクティブを書かない限り引き継がれます。http に client_max_body_size 64m; と書けば全サイトに効き、特定の server や location で書き直せばそこだけ上書きされます。

注意が要るのは、同じディレクティブを複数行書いて積み上げる種類のものです。代表が add_header で、下位のブロックで1つでも add_header を書くと、上位で定義したヘッダーはその下位ブロックではすべて無効になります。

server {
    add_header X-Content-Type-Options "nosniff" always;

    location /assets/ {
        # ここで add_header を書いたため、上の nosniff はこの location では送られない
        add_header Cache-Control "public, max-age=2592000";
    }
}

セキュリティヘッダーを server に書いたのに一部の URL で付いていない、という現象はたいていこれです。下位ブロックにも同じヘッダーを書き直すか、共通部分を別ファイルにして include で各所に読み込むと管理しやすくなります。なお Nginx 1.29 系では、この挙動を変える add_header_inherit が追加されたとされますが、使える版かどうかは手元の nginx -v と公式ドキュメントで確認してください（2026年10月現在）。

proxy_set_header や fastcgi_param も同じ性質を持ちます。location で1つ追加しただけで上位の設定が消える点を覚えておくと、原因不明の不具合をかなり減らせます。

最初に見直しておきたい基本項目

インストール直後の既定値でも動きますが、WordPress を載せるなら次の項目は一度確認しておくと後で困りません。値はサーバーの規模に合わせて調整する前提の例です。

http {
    # バージョン番号をエラーページや Server ヘッダーに出さない
    server_tokens off;

    # アップロード上限（PHP の upload_max_filesize / post_max_size と揃える）
    client_max_body_size 64m;

    # 静的ファイル配信の効率化
    sendfile   on;
    tcp_nopush on;

    keepalive_timeout 65;

    # テキスト系の圧縮
    gzip on;
    gzip_comp_level 5;
    gzip_min_length 1024;
    gzip_types text/css application/javascript application/json image/svg+xml;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" $request_time';
    access_log /var/log/nginx/access.log main;

    include /etc/nginx/conf.d/*.conf;
}

それぞれの理由を補足します。

worker_processes auto; は CPU コア数に合わせてワーカーを起動します。固定値にする特別な理由がなければ auto で十分です
client_max_body_size の既定値は 1MB と小さく、超えると「413 Request Entity Too Large」になります。メディアのアップロードやプラグインの ZIP 導入で失敗する典型的な原因です
gzip_types に text/html を書く必要はありません。HTML は常に圧縮対象で、書くと重複の警告が出ます
log_format に $request_time を加えておくと、遅いリクエストを後からログで探せます

worker_connections は「1ワーカーが同時に持てる接続数」で、上限はファイルディスクリプタ数にも縛られます。大きくするなら worker_rlimit_nofile や OS 側の上限も合わせて見直す必要があります。

変更を安全に反映する手順

設定変更は、バックアップ、文法チェック、再読み込みの順で行います。

# 1. 変更前に設定一式を退避
sudo cp -a /etc/nginx /etc/nginx.bak-$(date +%Y%m%d)

# 2. 文法チェック（読めない証明書やファイルも検出される）
sudo nginx -t

# 3. 成功したときだけ再読み込み
sudo nginx -t && sudo systemctl reload nginx

reload は稼働中の接続を切らずに新しい設定へ切り替えます。もし新しい設定に誤りがあっても、マスタープロセスは古い設定のまま動き続け、エラーは error.log に記録されます。一方 restart は全プロセスを止めて起動し直すため、設定に誤りがあると Nginx が止まったままになります。普段の変更は reload を使い、restart はモジュール追加など必要な場面に限るのが安全です。

本番で大きく構成を変えるときは、同じ OS とバージョンのステージング環境で先に試し、curl -I でヘッダーや応答コードを確かめてから本番に適用してください。

まとめ

nginx.conf は main・events・http・server・location の入れ子で、ディレクティブごとに書ける場所が決まっている
実際に読み込まれた設定は sudo nginx -T で確認でき、include 漏れの発見に役立つ
上位の設定は下位に引き継がれるが、add_header などは下位で1つ書くと上位分が消える
client_max_body_size、server_tokens、gzip、ログ形式は早めに見直しておく
変更は「バックアップ → nginx -t → reload」の順で、本番の前にステージングで確認する