Apache と NGINX：WordPress に最適なウェブサーバーはどちらか

自分の VPS で WordPress を運用しているなら、Apache と NGINX のどちらでもサイトは問題なく配信できますが、両者は優先するものが違います。同時接続数が多い場合、静的ファイルの配信、そして任意で HTTP/3 を使いたい場合は、通常 NGINX のほうが既定の選択として優れています。WordPress のスタックが .htaccess や Apache 固有のモジュールに依存しているなら、Apache のほうが扱いやすくなります。

この Apache と NGINX の比較では、WordPress にとって重要な違いに絞って扱います。アーキテクチャ、PHP の処理方法、設定、HTTP/3、そして両方を動かすことが追加の複雑さに見合うかどうかです。LiteSpeed と Caddy は対象外です。

結論から言うと、自分で管理する WordPress VPS では既定で NGINX を選んでください。サイトやプラグインが .htaccess に強く依存しているなら Apache を選びます。両方を動かすのは、Apache 互換性を保ったまま前段に NGINX が必要な場合だけにしてください。

Apache とは

Apache は、米国の非営利団体 Apache Software Foundation（ASF）が開発・保守している、広く使われているオープンソースのウェブサーバーソフトウェアです。Apache HTTP Server や HTTPD という名前でも知られています。

Apache のダウンロードページ では、2026 年 6 月にリリースされた 2.4.68 が現行の安定版として示されています。

Apache HTTP Server はモジュール構成のオープンソースサーバーで、ディレクトリ単位の .htaccess ルール、複数のマルチプロセッシングモジュール（MPM）、リバースプロキシ、URL の書き換え、TLS、動的に読み込むモジュールを成熟した形でサポートしています。WordPress にとって最大の実務上の利点は、生の速度ではなく設定の互換性です。

この比較でとくに重要になる Apache の機能は、prefork・worker・event の各 MPM、.htaccess、HTTP/2、リバースプロキシと負荷分散、FastCGI のサポート、動的モジュール、URL の書き換え、そして TLS です。

NGINX とは

NGINX（"engine x"）は、Igor Sysoev が当初開発したオープンソースのウェブサーバー、リバースプロキシ、コンテンツキャッシュ、ロードバランサー、TCP/UDP プロキシ、メールプロキシです。worker プロセスはイベント駆動モデルを採用しており、接続あたりのコストを抑えたまま多数の同時接続をさばけるよう設計されています。

NGINX のダウンロードページ lists the 1.30.x stable branch and the 1.31.x mainline branch.

Apache と NGINX：WordPress にとって重要な違い

Apache と NGINX の違いがもっともはっきり出るのは、接続の扱い方、設定、PHP、そしてプロトコルのサポートです。Apache の挙動は使用する MPM に大きく左右され、NGINX はイベント駆動の worker プロセスを使います。

Apache と NGINX：アーキテクチャ

Apache のリクエスト処理モデルは、どの MPM を使うかで変わります。prefork はプロセスベースで、worker と event はスレッドを使います。NGINX はイベントループを中心に構成された worker プロセスを使います。そのため「プロセス駆動の Apache 対イベント駆動の NGINX」というおなじみの比較は、現在の Apache 2.4 構成には単純すぎます。

Apache の event MPM はアイドル状態の keep-alive 接続をリスナースレッドに渡せるため、接続ごとに worker スレッドを占有させずに済みます。同時接続数が非常に多い場面では依然として NGINX のほうが接続あたりのコストは低い傾向にありますが、アーキテクチャの差は prefork 時代の古い比較が示すよりずっと小さくなっています。

Apache と NGINX：パフォーマンス

NGINX の性能面での強みは、同時接続数が多い場面と静的ファイル中心のワークロードで現れます。イベント駆動の worker は、接続あたりのコストを比較的低く抑えたまま多数の接続を開いたままにできます。Apache の event MPM は、古い prefork 構成に比べてこの差をかなり縮めています。

WordPress の動的リクエストは事情が異なります。NGINX は通常、PHP を FastCGI、多くの場合 PHP-FPM に渡します。Apache も FastCGI 経由で PHP-FPM を使えますし、Apache モジュールとして PHP を動かすこともできます。

PHP が WordPress の処理を始めたあとは、プラグインのコード、データベースへのクエリ、オブジェクトキャッシュやページキャッシュ、PHP worker の数のほうが、前段のウェブサーバーより効いてくることがあります。あるプラグインが 1 リクエストごとに重いクエリを十数本投げているなら、Apache から NGINX に替えても根本の問題は解決しません。

Apache と NGINX：HTTP/3 と QUIC のサポート

HTTP/3 はプロトコルの現行バージョンで、TCP ではなく QUIC の上で動きます。自分のサイトでそれを提供できるかどうかは前段のウェブサーバー次第であり、この比較の中で両者の差がはっきり開く唯一の項目です。

NGINX はバージョン 1.25.0 以降、HTTP/3 モジュールを同梱しています。既定ではビルドされず、ビルド時に --with-http_v3_module パラメータが必要です。

NGINX の HTTP/3 モジュールのドキュメント は、このモジュールを今も「experimental, caveat emptor applies」と記しています。

Apache 2.4 は HTTP/3 や QUIC のネイティブモジュールを同梱しておらず、標準で備えるプロトコルのサポートは mod_http2 までです。

サイト運営者にとっての実務的な帰結はこうです。標準的な Apache 2.4 の構成では HTTP/3 を提供できません。本番環境で現実的な選択肢は、Apache の前段に置いた HTTP/3 対応のリバースプロキシや CDN で HTTP/3 を終端することです。どうしてもこのプロトコルを使いたいなら、Apache の前に NGINX を置き、クライアントとの接続を NGINX に終端させる方法があります。これは後述の構成そのものです。

Apache と NGINX：セキュリティ

Apache と NGINX のどちらかが一律に「より安全」ということはありません。どちらも成熟したプロジェクトでセキュリティ保守も活発であり、本番環境の安全性は、パッチ適用、有効にしているモジュール、TLS の設定、アクセス制御、レート制限、そしてサーバーの背後にあるアプリケーションのほうに大きく左右されます。

意味のある比較は、どちらが勝ちかではなく、攻撃面と設定についてのものです。使っていないモジュールやエンドポイントは無効化し、サーバーにパッチを当て続け、その背後の WordPress スタックを堅牢にしてください。

Apache と NGINX：設定

Apache のディレクトリ単位の .htaccess ファイル は、AllowOverride が許可していれば機能します。WordPress にとっては便利で、サーバー全体の設定に手を入れずにリライトルールを変更できます。

この手軽さには代償があります。 Apache 自身のドキュメント では、root 権限がある場合はルールをサーバー本体の設定に置くことを推奨しています。.htaccess ファイルはリクエストのたびに読み取られ、有効にするとパフォーマンス面とセキュリティ面の双方で考慮すべき点が増えるためです。

NGINX に .htaccess に相当する仕組みはありません。設定は一元管理されるため、WordPress がサーバーレベルのリライトルールを勝手に書き込むことはできません。パーマリンクのルールやプラグイン固有のサーバーディレクティブは、管理者が NGINX の設定に追加したうえで再読み込みする必要があります。

Apache と NGINX：モジュールと拡張性

Apache は動的共有オブジェクト（DSO）のサポートが成熟しており、モジュールを個別にコンパイルして LoadModule で読み込めます。NGINX も load_module による動的モジュールに対応していますが、標準外のサードパーティ製モジュールを使う場合は、インストール済みの NGINX のバージョンやビルド構成とのバイナリ互換性がより重要になります。

したがって、あまり一般的でないサードパーティ製モジュールに依存しているなら Apache に分があります。ただし一般的な WordPress ホスティングでは、その差は .htaccess、PHP の扱い、すでに使っているツール類ほど重要にはなりません。

Apache と NGINX：対応プラットフォーム

Apache は Linux、Windows、macOS、そして多くの Unix 系システムで動作します。NGINX も主要なプラットフォームで利用できますが、Windows 向けのネイティブビルドには大きな制約があります。NGINX は Windows 版を今もベータと位置づけており、高い性能やスケーラビリティを期待すべきではないとし、実際に処理を行う worker は 1 つだけだと明記したうえで、UDP と QUIC には対応していません。本番で NGINX を運用するなら、Unix 系のオペレーティングシステムが現実的な選択です。

Apache と NGINX：リクエストの処理

Apache は通常、リクエストの URL を DocumentRoot 以下のファイルシステム上のパスに対応づけますが、設定システムによって URI ベースのロケーションやリライト、プロキシのルールを適用することもできます。NGINX はまず server ブロックを選び、次に location ブロックを、おもにリクエストの URI から選んだうえで、ファイルを返すか上流にリクエストを渡すかを決めます。

この違いは設定の書き方に影響しますが、それ自体が NGINX のほうがデータ転送が速いことの証拠になるわけではありません。

NGINX と Apache の早見比較

ここまでの観点に沿って両サーバーがどう並ぶかを、プロトコルのサポートと各サーバーの現行バージョンとあわせてまとめます。

Apache と NGINX を併用する

はい、両方動かせます。よくあるハイブリッド構成では、クライアントに面したリバースプロキシとして NGINX を前に、Apache をその後ろに置きます。NGINX は TLS と HTTP/2 を終端でき、実験的な HTTP/3 モジュールをビルドして有効にすれば HTTP/3 も終端できます。さらに、一部の静的ファイルは自分で返しつつ、アプリケーションへのリクエストは Apache に転送できます。

重要な注意点は、どちらがルールを持つのかという点です。NGINX が直接返したリクエストは Apache に届かないため、Apache の .htaccess ルールはそのリクエストには適用されません。二つの設定は、リライト、キャッシュ、クライアント IP の受け渡し、TLS の挙動、そしてどのパスをどちらのサーバーが担当するかについて、食い違わないようにする必要があります。

その代償として、ウェブサーバーを 2 つ動かすことになります。整合させ続けなければならない設定が 2 つ、追いかけるべき更新サイクルが 2 つ、そしてリクエストが想定外の応答を返したときに調べる場所がもう 1 つ増えます。小規模なサイト 1 つなら、この負担は得られる利点を上回るのが普通です。プラグインが頼っている .htaccess の挙動を保ったまま、HTTP/3 や静的ファイルのより速い配信がほしくなったときに、ようやく見合ってきます。

NGINX は Apache より簡単か

どちらかが常に簡単ということはありません。設定を一箇所にまとめたい人、server ブロックを自分で書くのが苦にならない人にとっては NGINX のほうが簡単です。一方、WordPress やサードパーティ製プラグインが .htaccess ルールを前提にしている場合は Apache のほうが簡単です。そのルールはサーバー全体の設定を変えずにディレクトリ単位で効くからです。

自分で管理するサーバーでは、「簡単かどうか」は結局、いま使っているスタックがどちらの設定モデルを前提にしているかで決まります。

NGINX ではなく Apache を選ぶのはどんなときか

WordPress のスタックが .htaccess に依存している場合、プラグインやコントロールパネルのツールが Apache のリライトディレクティブを前提にしている場合、あるいは特定の Apache モジュールが必要な場合は、Apache を選んでください。すでに十分に動いている既存サイトで Apache を使い続けるのも妥当です。ベンチマーク上の理論的な差のためだけにウェブサーバーを乗り換えるのは、混乱に見合わないことがほとんどです。

Apache ではなく NGINX を選ぶのはどんなときか

同時接続が多く見込まれる場合、静的配信やリバースプロキシの層を強くしたい場合、設定を一元管理したい場合、あるいは HTTP/3 を有効にする選択肢を残したい場合は NGINX を選んでください。WordPress でのトレードオフは、リライトルールやプラグイン固有のサーバーディレクティブが、WordPress が .htaccess に書き込めるものではなく、管理者の作業になることです。

NGINX vs Apache：WordPress に最適なウェブサーバーはどちら？

NGINX を選びましょう。自分で管理するサーバー上の WordPress サイトなら、こちらのほうが既定として優れています。同時接続が多いときの接続コストが低く、静的ファイルの配信が効率的で、必要なら HTTP/3 も使えます。

例外は .htaccess で、これは無視できません。.htaccess が有効なら WordPress は Apache 用のリライトルールを書き込めますが、NGINX のサーバー設定を書き換えることはできません。プラグインがリライト、セキュリティ、キャッシュのディレクティブを前提にしている場合は、そのプラグインの NGINX 向け手順か、server ブロックに書く同等のルールが必要で、そのうえで NGINX の再読み込みが要ります。この運用上の責任を負いたくないなら、WordPress には Apache のほうが手軽です。通常のトラフィックのサイトでは、性能の頭打ちを招くのはウェブサーバー自体よりも、PHP、データベース、キャッシュの挙動である可能性のほうが高いでしょう。

ここまでの話の前提はひとつです。サーバーが自分のもので、自由に変えられること。マネージド WordPress ホスティングではウェブサーバーはホスティング事業者が決めるので、この問いの答えは要するに「事業者がすでに使っているもの」になります。この比較は、自分のマシンに root 権限を持つ人に向けたものです。

Apache と NGINX のどちらが動いているかを確かめる方法

自分の VPS であれば、動いているサービスを直接確認してください。

systemctl status nginx
systemctl status apache2   # Debian/Ubuntu
systemctl status httpd     # RHEL/Fedora-family systems

自分の管理下にない外部サイトの場合、HTTP レスポンスの Server ヘッダーは手がかりにはなりますが、決定的ではありません。リバースプロキシや CDN がオリジンではなく自分自身のサーバーソフトウェアを表示することがありますし、このヘッダーは隠したり書き換えたりもできます。

VPS で Apache か NGINX を動かす

VPS が自分のものなら、どちらのサーバーも問題なく動かせます。マシンのサイズは Apache や NGINX 単体ではなく、WordPress のスタック全体に合わせて選んでください。PHP の worker、データベース、キャッシュ、トラフィック、バックグラウンド処理のほうが、ウェブサーバーよりリソースを食うのが普通です。

どちらのサーバーを選んでも、設定、アップデート、TLS、バックアップ、監視はあなたの責任です。両方動かせば設定も更新経路もひとつずつ増えるので、ハイブリッド構成は明確な理由があるときだけにしてください。

Cloudzy の NGINX VPS は完全な root 権限を持つ自己管理型の Linux VPS なので、サーバーの設定は自分の手に残ります。

当社マーケットプレイスの Apache HTTP Server イメージ も同じようにワンクリックでインストールできるので、どちらか一方でも両方でも、立ち上げるのにソースからのコンパイルから始める必要はありません。

読む

VPSでのCaddy対Nginx：設定ファイルの比較

よくある質問

Apache は NGINX より優れているのか

どちらかが常に優れているということはありません。高い同時接続数、静的ファイルの配信、リバースプロキシ、HTTP/3 を重視するなら、通常は NGINX のほうが既定として有力です。WordPress のスタックが .htaccess や Apache 固有のモジュールに依存しているなら、たいてい Apache のほうが簡単です。

NGINX が Apache より速いのはなぜか

NGINX は各 worker のイベントループの中で多数の接続を扱えるため、同時接続が多いときでも接続あたりのコストを低く保てます。Apache の event MPM も接続を非同期に処理するので、その差は prefork 時代の古い比較が示すほど大きくはありません。WordPress では、PHP やデータベースへのクエリ、キャッシュのほうが、ウェブサーバー間の違いより効いてくることがあります。

WordPress には Apache と NGINX のどちらを使うべきか

自分で管理する WordPress VPS なら、server ブロックのルールを自分で面倒みるのが苦にならない限り、NGINX は有力な既定の選択です。.htaccess や、Apache のリライトルールを前提としたプラグインに頼っていて、手作業のサーバー設定を減らしたいなら Apache を選んでください。

NGINX が広く使われているのはなぜか

NGINX は、同時接続が多い状況でも効率的なリクエスト処理に加えて、リバースプロキシ、ロードバランシング、キャッシュ、FastCGI のサポート、TLS の終端を併せ持っています。そのため、主となるウェブサーバーとしても、前段のプロキシとしても役立ちます。

Apache が今も使われているのはなぜか

Apache が今も広く使われているのは、モジュールのエコシステム、.htaccess のサポート、成熟したツール群、幅広いプラットフォーム対応、そして Apache を前提に組まれたホスティングやコントロールパネルのワークフローとの相性によるものです。

Apache と apache2 の違いは何か

Debian と Ubuntu では、apache2 が Apache HTTP Server のパッケージ名でありサービス名です。RHEL や Fedora 系のシステムでは、同じサービスを httpd と呼ぶのが一般的です。別々のウェブサーバーではなく、どちらも Apache HTTP Server を指します。現在の Apache の安定ブランチは 2.4 で、最新リリースは 2.4.68 です。

Apache は HTTP/3 に対応しているのか

標準では対応していません。Apache HTTP Server 2.4 には HTTP/3 や QUIC のモジュールが同梱されておらず、付属するプロトコルのサポートは HTTP/2 までです。本番で HTTP/3 が必要なら、Apache の前に置いた HTTP/3 対応のリバースプロキシや CDN で終端できます。