ApacheとNginxの違いを実務目線で理解する：Webサーバーの役割と選び方
ApacheとNginxは、どちらもブラウザから来たHTTPリクエストを受け取り、HTML、画像、CSS、PHPアプリなどを返すためのWebサーバーです。違いを一言で言うなら、Apacheはサイト単位・ディレクトリ単位の柔軟な設定に強く、Nginxは静的ファイル配信やリバースプロキシ構成で使いやすい、という見方が実務では役に立ちます。
WordPressや一般的なWeb制作では、Apacheなら.htaccessでリダイレクトやURL書き換えを触る場面が多く、Nginxならnginx.confやサイト設定ファイルでPHP-FPMや別アプリへリクエストを流す場面が多くなります。
この記事では、2026年7月時点の公式情報を前提に、Apache HTTP Server 2.4系とNginx stable/mainline系を対象に整理します。
- Apacheは、共有サーバーやWordPress運用で
.htaccessに触れる機会が多い - Nginxは、静的ファイル配信、リバースプロキシ、PHP-FPM連携でよく使われる
- どちらが常に上ではなく、管理できる範囲、既存環境、アプリ構成で選び方が変わる
- 初心者がまず見るべきポイントは「どの設定ファイルが効いているか」と「リクエストがどこへ流れているか」
Webサーバーは何をしているのか
Webサーバーの基本役割は、ブラウザから届いたリクエストを受けて、返すべきファイルやアプリの結果を選ぶことです。
たとえば、ユーザーが次のURLを開いたとします。
https://example.com/about/
このときWebサーバーは、ざっくり次のような判断をします。
example.com宛てのアクセスか確認する/about/に対応するファイルやアプリ処理を探す- 必要ならPHP、Node.js、別のサーバーなどへ処理を渡す
- 結果をHTTPレスポンスとしてブラウザへ返す
- アクセスログやエラーログを残す
静的なHTMLサイトなら、Webサーバーはファイルをそのまま返すだけで済みます。WordPressのようなPHPアプリでは、WebサーバーがPHP実行環境へ処理を渡し、生成されたHTMLを受け取って返します。
ここがポイント: ApacheとNginxの違いは「どちらがWebページを表示できるか」ではなく、「設定の置き場所、リクエストのさばき方、周辺ツールとのつなぎ方」に出ます。
Apacheの基本：.htaccessまで含めて理解する
Apacheは、サイト運用者がディレクトリ単位で設定を変えやすいWebサーバーとして、共有サーバーやWordPressで今もよく見かけます。
Apache HTTP Serverの現行ドキュメントは2.4系で、公式ダウンロードページでは2026年6月8日リリースの2.4.68が最新安定版として案内されています。実際のサーバーではLinuxディストリビューション側のパッケージ版を使うことも多いため、手元のバージョンは次のように確認します。
apache2 -v
# または環境によって
httpd -v
出力例です。
Server version: Apache/2.4.68 (Unix)
Server built: Jun 8 2026 00:00:00
Apacheでよく触る設定
Apacheでは、主に次の場所に設定があります。ファイル名やディレクトリはOSや配布パッケージで変わります。
- サーバー全体の設定:
httpd.conf、apache2.conf - サイトごとの設定:
sites-available/example.confなど - ディレクトリごとの設定:
.htaccess - ログ:
access.log、error.log
初心者が混乱しやすいのは.htaccessです。Apache公式ドキュメントでは、.htaccessはメイン設定を直接編集せずに、ディレクトリ単位で設定を変える仕組みとして説明されています。ただし、デフォルトではAllowOverride Noneの場合があり、その場合.htaccessは無視されます。
.htaccessの最小例
WordPressやリダイレクト設定でよく見る形は、URLを書き換える設定です。たとえば、古いページを新しいページへ移すなら次のように書けます。
# .htaccess
Redirect 301 /old-page/ /new-page/
期待される動きは次の通りです。
入力: https://example.com/old-page/
出力: https://example.com/new-page/ へ 301 リダイレクト
Apacheで.htaccessが効かないときは、まずサイト設定側でAllowOverrideが許可されているかを見ます。
<Directory "/var/www/html">
AllowOverride FileInfo
Require all granted
</Directory>
ここでAllowOverride Noneになっていると、.htaccessに正しい設定を書いても反映されません。逆に、許可されていないディレクティブを書くとHTTP 500になることがあります。その場合はブラウザより先にApacheのエラーログを確認します。
Nginxの基本：設定ファイルで流れを決める
Nginxは、設定ファイルでリクエストの流れを明示し、静的ファイル配信や別サーバーへの中継を組み立てるWebサーバーです。
Nginx公式の初心者向けガイドでは、Nginxは1つのmaster processと複数のworker processで動き、workerが実際のリクエスト処理を担当すると説明されています。設定ファイルは一般的に/etc/nginx/nginx.confや配下のサイト設定に置かれます。
バージョン確認は次の通りです。
nginx -v
出力例です。
nginx version: nginx/1.30.3
2026年7月時点の公式ダウンロードページでは、stable versionとして1.30.3、mainline versionとして1.31.2が案内されています。実務では、OS標準パッケージ、公式リポジトリ、Dockerイメージなどで導入元が分かれるため、実サーバーの値を確認してから設定例を当てはめます。
Nginxでよく触る設定
Nginxでは、.htaccessのようにサイト内ディレクトリへ設定ファイルを置いて自動反映する運用ではなく、サーバー設定側にserverやlocationを書きます。
server {
listen 80;
server_name example.com;
root /var/www/html;
index index.html index.php;
location / {
try_files $uri $uri/ =404;
}
}
この例では、example.comへのHTTPアクセスを受け、/var/www/html配下のファイルを探します。存在しなければ404を返します。
設定を変更したら、構文チェックと再読み込みを行います。
nginx -t
nginx -s reload
公式ガイドでも、設定変更はreloadまたはrestartするまで適用されないと説明されています。Nginxでは、編集しただけで反映されない点に注意が必要です。
ApacheとNginxの違いを比較する
初心者が最初に押さえるべき違いは、設定の置き場所とリクエスト処理の考え方です。
| 観点 | Apache | Nginx |
|---|---|---|
| 代表的な用途 | 共有サーバー、WordPress、既存PHPサイト | 静的配信、リバースプロキシ、PHP-FPM連携 |
| 設定の特徴 | メイン設定に加えて`.htaccess`でディレクトリ単位の設定ができる | `nginx.conf`や`server`/`location`でリクエストの流れを書く |
| 設定反映 | メイン設定は再読み込みが必要。`.htaccess`はリクエスト時に読まれる | 設定変更後に構文チェックとreloadが必要 |
| 初心者が見る場面 | リダイレクト、パーマリンク、アクセス制限、HTTP 500 | リバースプロキシ、静的ファイル、PHP-FPM、502エラー |
| 注意点 | `.htaccess`の許可範囲とパフォーマンス、権限に注意 | `location`の優先順位、`proxy_pass`の末尾スラッシュ、reload忘れに注意 |
WordPressではどう違うか
WordPressでは、Apache環境だとパーマリンク設定やリダイレクトで.htaccessが話題になりやすいです。管理画面からパーマリンクを保存したとき、Apache用の書き換えルールが.htaccessへ書かれる構成があります。
Nginx環境では、WordPressが.htaccessを使って設定を差し込む前提ではなく、Nginx側のlocationやtry_filesでルーティングします。たとえば次のような考え方です。
location / {
try_files $uri $uri/ /index.php?$args;
}
入力例です。
https://example.com/sample-post/
期待される流れです。
1. 実ファイル /sample-post/ があるか探す
2. なければ /index.php に渡す
3. WordPressが投稿URLとして解釈する
この違いを知らないまま「WordPressだから.htaccessを編集すればよい」と考えると、Nginx環境では変更が何も効かずに詰まります。
リバースプロキシで見るNginxの使いどころ
Nginxを理解するうえで重要なのが、リバースプロキシです。これは、ブラウザからのアクセスをNginxが受け、裏側の別アプリや別ポートへ渡す構成です。
たとえば、Node.jsアプリがlocalhost:3000で動いているとします。外部にはNginxだけを見せ、NginxからNode.jsへ転送するなら次のように書けます。
server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
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;
}
}
確認にはcurlが便利です。
curl -I http://app.example.com/
出力例です。
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html; charset=utf-8
proxy_passは、Nginx公式ドキュメントで別サーバーへリクエストを渡すディレクティブとして説明されています。実務では、PHP-FPM、Node.js、Pythonアプリ、Docker上のコンテナへ流す入口としてよく使います。
proxy_passでつまずきやすい点
Nginxのproxy_passでは、末尾スラッシュの有無やlocationの書き方で、裏側へ渡るURIが変わることがあります。
location /api/ {
proxy_pass http://127.0.0.1:3000/;
}
このような設定では、/api/usersが裏側で/usersとして扱われる場合があります。一方、URIを付けない書き方では元のリクエストURIがそのまま渡るケースがあります。
設定例をコピーするときは、次の3点をセットで確認してください。
locationが/api/なのか/apiなのかproxy_passのURL末尾に/があるか- 裏側のアプリが期待しているパスは
/usersか/api/usersか
ここを曖昧にすると、Nginx側は200を返しているのにアプリ側で404になる、という切り分けしにくい状態になります。
よくある失敗と確認ポイント
ApacheとNginxでエラーの出方は違いますが、最初に見る場所は共通しています。設定ファイル、構文チェック、ログ、実際のレスポンスの順で確認すると、原因を絞りやすくなります。
Apacheで.htaccessが効かない
よくある原因は、.htaccessの内容ではなく、Apache本体側で.htaccessを読む許可がないことです。
確認ポイントは次の通りです。
- 対象ディレクトリに
AllowOverride Noneが指定されていないか - 使いたいディレクティブに必要なOverrideカテゴリが許可されているか
.htaccessを置いたディレクトリが、実際のDocumentRoot配下か- HTTP 500が出ているなら
error.logに構文エラーが出ていないか
Apache公式ドキュメントでは、.htaccessを許可するとリクエストごとに探索・読み込みが発生するため、メイン設定に書けるならそちらを推奨する、と説明されています。共有サーバーのようにメイン設定を触れない場合に、.htaccessが実用上の選択肢になります。
Nginxで設定を変えたのに反映されない
Nginxでは、設定ファイルを保存しただけでは反映されません。まず構文を確認します。
nginx -t
成功例です。
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
その後、再読み込みします。
nginx -s reload
systemd環境なら次の形を使うこともあります。
sudo systemctl reload nginx
反映されない場合は、編集したファイルがnginx.confからincludeされているか、別のserverブロックが優先されていないかを確認します。
502 Bad Gatewayが出る
Nginxの前段構成でよく見るのが502です。これは、Nginxが裏側のPHP-FPMやNode.jsアプリへ接続できないときに出ることがあります。
確認する順番は次の通りです。
- 裏側のアプリやPHP-FPMが起動しているか
proxy_passやfastcgi_passのホスト名・ポート・ソケットパスが正しいか- ファイアウォールやコンテナネットワークで接続が遮られていないか
- Nginxの
error.logにconnect() failedなどが出ていないか
このエラーは「Nginxが壊れた」というより、Nginxから見た接続先が応答していない、という切り分けで見ると早いです。
どちらを選ぶべきか
新規構築で迷うなら、まずアプリの構成と運用者が触れる範囲を見ます。
Apacheが合いやすいのは、次のような場面です。
- 共有サーバーで
.htaccessを使う前提がある - WordPressや既存PHPサイトの運用でApache向け情報が多い
- ディレクトリ単位のリダイレクトやアクセス制限をサイト運用者が触る
- 既存環境がApacheで、移行理由が明確ではない
Nginxが合いやすいのは、次のような場面です。
- 静的ファイルを効率よく配信したい
- Node.js、Python、PHP-FPMなど複数のバックエンドへ振り分けたい
- Dockerやクラウド環境でリバースプロキシを入口にしたい
- 設定をサーバー管理者側で一元管理したい
実務では、Nginxを前段に置き、裏側でApacheやアプリサーバーを動かす構成もあります。重要なのは、名前で選ぶことではありません。リクエストがどこで受けられ、どの設定で書き換えられ、どのアプリへ渡るのかを追えることです。
最初に覚える確認コマンド
実作業では、概念より先に状態確認が必要になります。最低限、次のコマンドを覚えておくと切り分けがしやすくなります。
# Apacheのバージョン確認
apache2 -v
httpd -v
# Apacheの設定構文チェック
apachectl configtest
# Nginxのバージョン確認
nginx -v
# Nginxの設定構文チェック
nginx -t
# ヘッダーだけ確認
curl -I https://example.com/
curl -Iの出力では、HTTPステータス、Serverヘッダー、リダイレクト先などを確認できます。
HTTP/2 301
location: https://www.example.com/
server: nginx
ただし、Serverヘッダーは非表示または書き換えられている場合があります。表示だけで構成を断定せず、管理できるサーバーなら設定ファイルとプロセスを確認してください。
まとめ：見るべき分岐点
ApacheとNginxは、どちらもWebサーバーですが、初心者が実務で迷う場所はかなり違います。
.htaccessを編集する話なら、まずApache環境か確認するproxy_pass、fastcgi_pass、502エラーが出るなら、Nginxから裏側への接続を確認する- WordPressのパーマリンク問題は、Apacheなら
.htaccess、Nginxならtry_filesやPHP-FPM連携を見る - 設定変更後は、Apache/Nginxとも構文チェックとログ確認を習慣にする
次に見るべき分岐点は、運用しているサイトが「Apache単体」「Nginx単体」「Nginx前段＋裏側アプリ」のどれに当たるかです。ここが分かると、リダイレクト、404、500、502の調査で見るファイルとログが一気に絞れます。