Nginx vs Apache vs Caddy — Webサーバーの選び方【2026年】
本記事はアフィリエイト広告（A8.net）を含みます。価格・仕様は2026年6月時点の目安です。最新は各公式サイトでご確認ください。
TL;DR
Webサーバーを選ぶとき、Nginx・Apache・Caddyの3択で迷う場面があります。結論だけ先に示します。
- 共有ホスティングやWordPress環境: Apacheが最も枯れていて、
.htaccessによる柔軟な設定が使えます。 - 高トラフィックのリバースプロキシ・静的ファイル配信: Nginxが実績・エコシステムともに豊富です。
- VPS一台で手早くHTTPSまで通したい: Caddyが自動HTTPSで設定量を大幅に減らせます。
3つとも現役のプロダクションソフトウェアです。「何を優先するか」で選ぶものが変わります。以下で各サーバーの特徴と判断基準を整理します。
3つのWebサーバーの位置づけ
Nginx — 高速・軽量・リバースプロキシの定番
Nginxは2004年にIgor Sysoevが「C10K問題（同時接続1万件）」への対応を念頭に開発したWebサーバーです。現在はNginx, Inc.（F5傘下）が開発を主導しています。
イベント駆動モデルを採用しているため、多数の接続を少ないプロセス数で捌く設計になっています。静的ファイルの配信とリバースプロキシの2つの用途で特に広く使われています。
設定は nginx.conf と server ブロックの組み合わせで記述します。細かな制御が可能な一方、.htaccess のようなディレクトリ単位の上書きはできません。設定はすべてメインファイル（またはその include）に書き、変更のたびに reload が必要です。
Apache — 最も歴史が長く共有ホスティングの標準
Apache HTTP Serverは1995年から存在する最古参のWebサーバーです。Apache Software Foundationがメンテナンスしています。共有ホスティング環境のほぼ全てでApacheが使われているのは、.htaccess ファイルによる「ディレクトリ単位の設定上書き」がホスティング事業者にとって扱いやすいためです。
プロセスモデル（prefork）またはスレッドモデル（worker、event）を選べます。モジュールシステムが充実しており、mod_rewrite（URLリライト）、mod_php（PHP直接実行）、mod_ssl（HTTPS）など、長年の実績があるモジュールが揃っています。
WordPressや古いCMSが「Apache推奨」としているのも、これらのモジュールと .htaccess との組み合わせを前提とした設計が多いためです。
Caddy — 自動HTTPSと設定の簡潔さを重視した後発
Caddyは2015年に登場したGoで書かれたWebサーバーです。公式サイトにある通り、設計思想の中心は「デフォルトでHTTPS」にあります。設定ファイル（Caddyfile）にドメイン名を書くだけで、起動時にLet’s EncryptまたはZeroSSLから証明書を自動取得し、更新も自動で行います。Certbotなどの外部ツールが不要です。
Caddyfile の記法はNginxの設定より平易で、リバースプロキシの典型的な設定ならば数行で済みます。ただし、Nginxのような細粒度のチューニングや、Apacheのような豊富なモジュールエコシステムはまだ持ちません。2026年現在、個人〜中小規模のVPSでの利用実績が着実に増えています。
比較表 — 用途・設定・エコシステム
| 観点 | Nginx | Apache | Caddy |
|---|---|---|---|
| HTTPS | Certbot等で設定（自動更新は別途タイマー） | mod_ssl + Certbot等 | 設定にドメインを書くだけで自動取得・更新 |
| 設定ファイル | nginx.conf + server ブロック（全て集中管理） | httpd.conf + .htaccess（分散可） | Caddyfile（最も短く書ける） |
| ディレクトリ単位の設定上書き | 不可（location ブロックに統一） | 可（.htaccess） | 不可 |
| リバースプロキシ | 定番・実績豊富 | 可能（mod_proxy）だが主用途ではない | デフォルト動作が親切で設定が短い |
| 静的ファイル配信 | 高効率・大規模実績あり | 問題なく使える | 問題なく使える |
| モジュール/拡張 | 豊富（ただしコンパイル時組込みが多い） | 非常に豊富（mod_* が多数） | プラグインあり・まだ成熟段階 |
| WordPress/古いCMS | fastcgi_pass でPHP-FPMに渡す構成 | mod_php / .htaccess と相性が良い | PHP-FPMに渡す構成は可 |
| 設定の学習コスト | 中（明示的で読みやすいが量が増える） | 中〜高（分散するほど追いにくくなる） | 低（短く書けるが機能の把握に慣れが要る） |
| 大規模・高負荷の実績 | 豊富 | ある（ただし高並列はNginxが主流） | 増加中・大規模事例はまだNginxより少ない |
| ライセンス | BSD-like | Apache License 2.0 | Apache License 2.0 |
用途別の選択
共有ホスティングやWordPress環境
Apacheを選びます。理由は2つです。
- 多くの共有ホスティングがApacheを前提として構築されており、
.htaccessの書き換えルールがそのまま動きます。 - WordPressの
Permalinks設定やプラグインの一部が、ApacheのURL書き換えルール（.htaccessのmod_rewrite）を前提として生成されます。
VPS上にWordPressを自分で建てる場合でも、これまでApacheで運用してきた設定資産がある、または参考にする記事が多い、という理由でApacheを選ぶのは合理的です。
高トラフィックの本番環境・リバースプロキシ
Nginxを選びます。1台のVPSで複数のアプリをドメイン別に振り分けるリバースプロキシの用途では、Nginxが最も整備された選択肢です。細かいキャッシュ制御、ロードバランシング、ストリーミング、WebSocket転送などを設定ベースで制御できます。
NginxをリバースプロキシとしてVPSに設定する具体的な手順はNginxリバースプロキシ入門を参照してください。
VPS一台で手早くHTTPSを通したい
Caddyを選びます。「とにかく早くHTTPSで公開したい」「証明書の更新を意識したくない」という場合、Caddyの自動HTTPSが最も工数を下げます。Certbotを別途セットアップして更新タイマーを確認する、という手順がまるごと不要になります。
設定例を示します。2つのアプリをドメインで振り分け、HTTPSも自動で通す Caddyfile です。
app.example.com {
reverse_proxy 127.0.0.1:3000
}
blog.example.com {
reverse_proxy 127.0.0.1:8080
}Nginxで同じことをする場合と比べると、proxy_set_header 群の明示、Certbotの発行コマンド、更新タイマーの確認が不要になります。個人開発・検証環境・小規模サービスには十分な選択肢です。
リバースプロキシ用途での3つの違い
リバースプロキシとして使う場合に、設定の差が最も目立ちます。
Nginx のリバースプロキシ設定（最小例）
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;
}
}proxy_set_header を明示的に書く必要があります。書かないとアプリ側でクライアントのIPやプロトコルを正しく取れません。WebSocketを使う場合は Upgrade / Connection ヘッダの転送と proxy_http_version 1.1 の追加も必要です。詳細はNginxリバースプロキシ入門で解説しています。
Apache のリバースプロキシ設定（mod_proxy 使用）
<VirtualHost *:80>
ServerName app.example.com
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:3000/
ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>mod_proxy と mod_proxy_http を有効化する必要があります（a2enmod proxy proxy_http）。ProxyPreserveHost On で Host ヘッダを転送します。Apacheもリバースプロキシとして動作しますが、この用途での採用事例はNginxほど多くありません。
Caddy のリバースプロキシ設定（Caddyfile）
app.example.com {
reverse_proxy 127.0.0.1:3000
}X-Forwarded-For などのヘッダ付与とWebSocketアップグレードはCaddyがデフォルトで行います。HTTPSも自動です。設定量が最も少ない一方、細かい挙動を制御するには Caddyfile のディレクティブを調べる必要があります。
HTTPS設定の比較
3つの差が最もわかりやすく出る箇所です。
Nginx: Certbotの --nginx プラグインで自動化できます。証明書の取得・設定書き換え・80→443リダイレクトの追記まとめてやってくれますが、Certbot自体のインストールとタイマーの確認は別途必要です。Let’s Encryptの詳細はLet’s Encrypt無料SSL証明書の取得と自動更新で解説しています。
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com
sudo certbot renew --dry-run # 更新動作の確認Apache: mod_ssl と Certbot の --apache プラグインを使います。手順はNginxと概ね同じです。
sudo apt install certbot python3-certbot-apache
sudo certbot --apache -d app.example.comCaddy: 追加の手順はありません。Caddyfile にドメインを書いてCaddyを起動すれば、証明書の取得と更新が自動で行われます。ポート80と443の両方をCaddyが管理する必要があるため、他のサーバーと共存させる場合は注意が必要です。
実践: どのVPSで試すか
3つのWebサーバーとも、Ubuntu / Debian 系のVPSに apt install nginx / apt install apache2 / Caddy公式の手順でインストールできます。ConoHa VPSとXserver VPSは国内で実績のある選択肢です。
- ConoHa VPS: 時間課金で「試して消す」使い方がしやすいです。Webサーバーの検証や設定の学習に向いています。
- Xserver VPS: 月額課金で長期運用に向きます。WordPressや複数サービスを同居させる本番環境として使いやすい構成です。
最初は小さいプランで1つのWebサーバーを動かし、設定と挙動を確認してから本番に使うのが安全です。
まとめ
| 用途 | 推奨 | 理由 |
|---|---|---|
| 共有ホスティング・WordPress | Apache | .htaccess との親和性・CMS前提の設定資産が活きる |
| リバースプロキシ・高トラフィック本番 | Nginx | 実績・エコシステム・細かいチューニングの自由度 |
| VPS一台で素早くHTTPS | Caddy | 自動HTTPS・設定が短い・Certbot不要 |
| 静的ファイル配信のみ | Nginx または Caddy | どちらも問題なし。既存のVPS構成に合わせる |
| 既存のNginx資産がある | Nginx | 設定を流用できる・学習コストが最小 |
3つとも2026年現在も活発にメンテナンスされているサーバーです。「どれが最も優れているか」ではなく、「自分の構成で何が要るか」で選ぶのが実用的な判断基準です。迷うときは、構成がシンプルならCaddy、既存資産があるかリバースプロキシを本格的に使うならNginx、共有ホスティングや既存CMS環境ならApacheから始めると判断しやすいです。
