宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
「nginxをインストールしたけど、設定ファイルの書き方がよくわからない」「Apacheとの違いが曖昧で、どちらをどう使えばいいか迷っている」

セミナーでもよくある質問です。nginxはApacheに比べてシンプルな構成でありながら、慣れないうちはどこに何を書けばいいか迷うことが多い。

この記事では、nginx のインストールから基本設定・バーチャルホスト・リバースプロキシまでを実践的に解説します。RHEL9 / Rocky Linux 9 / Ubuntu 24.04 での動作確認例を交えながら、現場で実際に使う設定パターンを紹介します。

この記事のポイント

・nginx -t で設定ファイルの構文チェックを必ず行う
・設定はすべて /etc/nginx/conf.d/ 配下に独立ファイルで管理する
・バーチャルホストで複数ドメインを1台のサーバーで処理できる
・リバースプロキシはproxy_passでアプリへ転送するだけ


nginxコマンドの使い方|インストールから設定・バーチャルホスト・リバースプロキシまで

「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

nginxとは何か|Apacheとの違いを押さえる

nginx(エンジンエックス)は、2004年にIgor Sysoev氏が公開したWebサーバーです。Apacheと並んでLinuxサーバーの定番ですが、内部の仕組みが大きく異なります。

Apacheは「プロセス(またはスレッド)ベース」でリクエストを処理します。接続ごとにプロセスを割り当てるため、同時接続数が増えるとメモリ消費が増大します。これが「C10K問題」として知られる課題です。

nginxは「イベント駆動(event-driven)」アーキテクチャを採用しています。少ないプロセス数で大量の同時接続を捌けるため、静的ファイル配信やリバースプロキシ用途で特に力を発揮します。

静的コンテンツの配信:nginxが有利(Apacheより高速・低メモリ)
動的コンテンツ(PHP等):どちらも対応可能(nginxはFastCGI経由)
設定ファイルの柔軟性:Apacheは.htaccessで分散管理が可能、nginxは集中管理が原則
モジュール追加:Apacheは動的ロード可、nginxはコンパイル時組み込みが基本

実務では「静的ファイルはnginx、動的処理はPHP-FPMやNode.jsにプロキシ」という構成が広く使われています。

nginxのインストール

1. RHEL9 / Rocky Linux 9 / AlmaLinux 9でのインストール

RHEL系ではAppStreamリポジトリからインストールできます。

# パッケージ確認 dnf module list nginx # インストール sudo dnf install -y nginx # バージョン確認 nginx -v

実行結果の例:

nginx version: nginx/1.20.1

インストール後、自動起動設定と起動を行います。

# 自動起動有効化 sudo systemctl enable nginx # 起動 sudo systemctl start nginx # 状態確認 sudo systemctl status nginx

2. Ubuntu 24.04でのインストール

sudo apt update sudo apt install -y nginx # Ubuntuはインストール時に自動起動が有効になっている場合が多い sudo systemctl enable nginx sudo systemctl start nginx

インストール後、ブラウザで `http://サーバーのIPアドレス` にアクセスすると「Welcome to nginx!」ページが表示されます。表示されない場合はfirewalldやufwでポート80が開放されているか確認してください。

Linux ポート確認の全コマンドでss・lsof・netstatを使ったポート状況の確認方法を解説しています。

nginxの設定ファイル構造を理解する

1. 設定ファイルの場所と役割

nginxの設定ファイルは `/etc/nginx/` 配下に集まっています。

/etc/nginx/ ├── nginx.conf # メイン設定ファイル(グローバル設定) ├── conf.d/ # サイト別設定ファイルの格納先(推奨) │ └── default.conf # デフォルトサーバー設定 ├── mime.types # MIMEタイプ定義 └── fastcgi_params # FastCGI共通パラメータ

`nginx.conf` の末尾近くに以下のような記述があり、`conf.d/` 配下の `.conf` ファイルをすべて読み込みます。

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

実務では `nginx.conf` は直接編集せず、`conf.d/` 配下に独立した `.conf` ファイルを作成するのが定石です。ファイルを無効にしたいときは拡張子を `.conf.disabled` に変えるだけで除外できます。

2. 設定ブロック(コンテキスト)の基本構造

nginx の設定は「コンテキスト(ブロック)」の入れ子構造で書きます。

# nginx.conf の基本構造(簡略版) # グローバルコンテキスト(worker_processesなど) worker_processes auto; events { worker_connections 1024; } http { # HTTP全体の共通設定 server { # バーチャルホスト1つ分の設定 listen 80; server_name example.com; location / { # パスに対する処理 root /var/www/html; index index.html; } } }

events:接続数などのイベント処理設定
http:HTTPに関するすべての設定を包括するブロック
server:バーチャルホスト1つ分の設定(複数書ける)
location:URLパスパターンに対する処理の定義

3. 設定の構文チェックと再読み込み

設定ファイルを変更したら、必ず `nginx -t` で構文チェックを行ってからリロードします。

# 構文チェック(エラーがなければ successful と表示) sudo nginx -t # 設定の再読み込み(プロセスを停止せずに設定反映) sudo systemctl reload nginx # または nginx コマンドで直接リロード sudo nginx -s reload

実行結果の例(成功時):

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

nginx -t が通ってからリロードというルールは必ず守ってください。構文エラーがある状態でリロードを実行すると、nginxが既存設定を使い続けることもあり、変更が反映されたつもりになるというトラブルを防げます。

バーチャルホストの設定

1台のサーバーで複数のドメインを処理するのがバーチャルホストです。nginxでは `server` ブロックを複数書くことで実現します。

1. 基本的なバーチャルホスト設定

`/etc/nginx/conf.d/example.conf` を新規作成します。

server { listen 80; server_name example.com www.example.com; root /var/www/example.com/html; index index.html index.htm; access_log /var/log/nginx/example.com.access.log; error_log /var/log/nginx/example.com.error.log; location / { try_files $uri $uri/ =404; } }

ドキュメントルートを作成してテストします。

# ドキュメントルートの作成 sudo mkdir -p /var/www/example.com/html # テスト用HTMLを配置 echo '<h1>Welcome to example.com</h1>' | sudo tee /var/www/example.com/html/index.html # 構文チェックとリロード sudo nginx -t && sudo systemctl reload nginx

2. HTTPSバーチャルホストの基本設定

SSL証明書がある場合(Let's Encrypt等)は443ポートも設定します。

server { listen 80; server_name example.com www.example.com; # HTTPはHTTPSにリダイレクト return 301 https://$host$request_uri; } server { listen 443 ssl; server_name example.com www.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; access_log /var/log/nginx/example.com.access.log; error_log /var/log/nginx/example.com.error.log; location / { try_files $uri $uri/ =404; } }

DNS設定でドメインのAレコードがサーバーIPを向いていることも確認しておきましょう。Linux DNS 設定の基本を参考にどうぞ。

リバースプロキシの設定

リバースプロキシは「クライアントからのリクエストをnginxが受け取り、バックエンドのアプリサーバーへ転送する」仕組みです。Node.js、Python(Gunicorn)、Java(Tomcat)など、任意のバックエンドアプリの前段に置けます。

1. 基本的なリバースプロキシ設定

例として、ローカルの8080番ポートで動くアプリへプロキシする設定です。

server { listen 80; server_name app.example.com; access_log /var/log/nginx/app.example.com.access.log; error_log /var/log/nginx/app.example.com.error.log; location / { proxy_pass http://127.0.0.1:8080; # 必須ヘッダー設定 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # タイムアウト設定 proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 60s; } }

`proxy_set_header` の3行は必ず入れてください。バックエンドアプリがクライアントの本来のIPアドレスを取得するために必要です。これを省くと、アプリのログがすべてnginxのIP(127.0.0.1)になってしまいます。

2. upstreamを使ったロードバランシング

複数のバックエンドサーバーへ負荷分散するには `upstream` ブロックを使います。

upstream app_backend { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; # keepalive接続でパフォーマンス向上 keepalive 32; } server { listen 80; server_name app.example.com; location / { proxy_pass http://app_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_version 1.1; proxy_set_header Connection ""; } }

デフォルトはラウンドロビン(順番に分散)です。`weight=2` を追加すると重み付け分散ができます。

よく使う設定パラメータ一覧

# worker設定(nginx.conf のグローバル) worker_processes auto; # CPUコア数に自動設定 worker_rlimit_nofile 65535; # オープンできるファイルディスクリプタ数 # gzip圧縮(http ブロック内) gzip on; gzip_types text/plain text/css application/json application/javascript; gzip_min_length 1024; # クライアントタイムアウト(http/server ブロック内) client_body_timeout 12s; client_header_timeout 12s; send_timeout 10s; keepalive_timeout 65s; # ファイルアップロードサイズ制限 client_max_body_size 10m; # バッファサイズ client_body_buffer_size 128k; client_header_buffer_size 1k;

トラブルシュート・エラー対処

1. 502 Bad Gatewayが出た場合

リバースプロキシ構成でよく見るエラーです。原因の多くはバックエンドアプリへの接続失敗です。

確認手順:

バックエンドの起動確認:アプリが実際に起動しているか `systemctl status` で確認
ポート確認:`ss -tlnp | grep 8080` でバックエンドがリッスンしているか確認
エラーログの確認:`tail -f /var/log/nginx/error.log` でエラー詳細を確認

# nginxエラーログのリアルタイム確認 sudo tail -f /var/log/nginx/error.log # バックエンドのポート確認 ss -tlnp | grep 8080

2. 403 Forbiddenが出た場合

ドキュメントルートのファイルパーミッションが原因のことが多いです。

# nginxの実行ユーザー確認 grep "^user" /etc/nginx/nginx.conf # → user nginx; や user www-data; など # ドキュメントルートのパーミッション確認 ls -la /var/www/example.com/html/ # nginxユーザーがアクセスできるよう修正する例 sudo chown -R nginx:nginx /var/www/example.com/html/ sudo chmod -R 755 /var/www/example.com/html/

SELinuxが有効な環境(RHEL9系)では、パーミッションが正しくてもSELinuxコンテキスト不一致で403になる場合があります。

# SELinuxコンテキストを確認 ls -Z /var/www/example.com/html/ # httpd_sys_content_t を付与 sudo chcon -Rt httpd_sys_content_t /var/www/example.com/html/

3. nginx -t でエラーが出た場合

`nginx -t` の出力をよく読むとエラー箇所と行番号が示されます。

# エラー出力例 nginx: [emerg] "location" directive is not allowed here in /etc/nginx/conf.d/example.conf:15 nginx: configuration file /etc/nginx/nginx.conf test failed

よくある原因:
セミコロンの抜け:各ディレクティブの末尾に `;` が必要
ブロックの括弧の対応ミス:`{` と `}` の数が合っていない
変数名のタイポ:`$request_uri` を `$requets_uri` とスペルミス

`nginx -t` の結果で行番号が指摘されているので、その行前後を重点的に確認してください。

4. ポートが競合している場合

80番や443番ポートをすでにApacheや他のプロセスが使っている場合、nginxが起動できません。

# 80番ポートを使っているプロセスを確認 sudo ss -tlnp | grep ':80' # または sudo lsof -i :80

Apacheが動いていた場合は `sudo systemctl stop httpd` で停止してからnginxを起動します。Apache タイムアウト設定の詳細でApacheの基本操作も確認できます。

nginxコマンド早見表

やりたいこと コマンド
nginxのバージョンを確認する nginx -v
設定ファイルの構文チェックをする sudo nginx -t
nginxを起動する sudo systemctl start nginx
nginxを停止する sudo systemctl stop nginx
設定を再読み込みする(プロセス継続) sudo systemctl reload nginx
nginxを再起動する sudo systemctl restart nginx
自動起動を有効にする sudo systemctl enable nginx
nginxの状態を確認する sudo systemctl status nginx
アクセスログをリアルタイム確認する sudo tail -f /var/log/nginx/access.log
エラーログをリアルタイム確認する sudo tail -f /var/log/nginx/error.log
ロードされているモジュールを確認する nginx -V 2>&1 | grep -- --with

本記事のまとめ

nginx の基本を整理しておきます。

設定ファイルの管理:nginx.conf は直接触らず、conf.d/ 配下にサイトごとのファイルを作る
変更のたびに nginx -t:構文チェックを通過してからリロードするのが鉄則
バーチャルホスト:server ブロックを複数書くことで1台のサーバーで複数ドメインを処理できる
リバースプロキシ:proxy_pass でバックエンドへ転送し、X-Real-IP など必須ヘッダーを必ず付ける
トラブルの初動:nginx -t のエラーメッセージ→エラーログ→ポート競合の順に確認する

nginx はシンプルな構成でありながら、リバースプロキシやロードバランシングまで対応できる汎用的なWebサーバーです。設定ファイルの書き方に慣れてしまえば、Apacheよりもすっきりした構成でサーバーを管理できます。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
▼ 無料のLinuxサーバー構築入門マニュアルを受け取る >>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。