2026年のリバースプロキシ選定。Nginx、Caddy、Traefikを実環境の負荷で比較して見えたこと

2026年7月19日 H.Ueda

今回は、Nginx vs Caddy vs Traefik in 2026 — I Ran All Three Under Real Production Load という記事を参考に、次世代のイングレスコントローラー選定における各プロキシの実力と運用上の勘所について整理してみます。

代表的な Web サーバのリバースプロキシに関する比較です。参考まで。

リバースプロキシやTLS終端の設定は、一度動いてしまえば普段は意識することの少ない「裏方」のような存在です。しかし、2026年3月に予定されているイングレスコントローラーのサポート終了（EOL）といった節目が近づくと、否応なしに移行計画を迫られることになります。

本記事では、ある物流系クライアントのEKS環境を舞台に、実際に6週間ずつ各プロキシを運用した際のデータをもとに、それぞれの特性を比較していきます。

検証環境のセットアップ

検証は、12のマイクロサービスが稼働するEKSクラスターで行われました。トラフィックはピーク時で分間約61,000リクエストに達し、WebSocketによるリアルタイム追跡や数MB単位のCSVエクスポートが混在する、かなりタフな環境です。

構成の概要を図示すると、以下のようなイメージになります。

flowchart TD
  User["ユーザー / クライアント"] -- "HTTPS (HTTP/2, HTTP/3)" --> NLB["AWS NLB (L4 Load Balancer)"]
  NLB -- "X-Forwarded-For 保持" --> Ingress["イングレスコントローラー<br>(Nginx / Caddy / Traefik)"]
  Ingress -- "サービスルーティング" --> Pods["マイクロサービス (12サービス)"]

  subgraph "Metrics & Management"
    Prom["Prometheus (メトリクス収集)"]
    Cert["cert-manager (TLS管理)"]
  end

  Ingress -.-> Prom
  Ingress -.-> Cert

3つのプロキシの比較結果

実際に運用して得られた、パフォーマンスと運用負荷の指標を以下の表にまとめました。

評価項目	Nginx (F5 NIC)	Caddy 2.11	Traefik
最大スループット	約46,000 req/s	約41,000 req/s	未詳（高い応答性）
p99 レイテンシ (オーバーヘッド)	約0.9ms	約1.2ms	約1.1ms
メモリ使用量 (1万接続時)	約120MB	約180MB	約160MB
新規ルート追加の所要時間	約23分	約9分	約4分 (習熟後)
主なメリット	圧倒的な処理能力と知見の豊富さ	TLS自動化の容易さと設定の簡潔さ	K8sネイティブな柔軟性と動的設定

1. Nginx (F5 NIC)：信頼と実績のパフォーマンス

Nginxは、やはり純粋なスループットにおいて他の追随を許さない強さを見せました。3つの中で最も低いレイテンシを記録しており、1ミリ秒を切るオーバーヘッドは非常に優秀だと言えます。

一方で、運用の手間という面では少し課題が残ります。新しいルートを追加する際、YAMLの記述やアノテーションの確認などに時間を要し、今回の検証ではPRの作成から反映まで平均して23分ほどかかっていました。昔ながらの「枯れた技術」としての安心感はありますが、設定変更のスピード感という点では、現代的なツールに一歩譲るかもしれません。

2. Caddy：運用の手軽さとモダンな機能

Caddyは、特にTLS周りの処理が非常にスマートです。設定ファイルがシンプルで読みやすく、新規ルートの追加もNginxの半分以下の時間で完了できました。

パフォーマンス面ではNginxに若干劣るものの、41,000 req/sという数値はほとんどの商用環境において十分すぎるスペックかと思います。Go言語製ということもあり、メモリ使用量はNginxよりやや高めに出る傾向がありますが、運用のストレスを減らしたいチームにとっては非常にバランスの良い選択肢になるのではないでしょうか。

3. Traefik：Kubernetesとの親和性

Traefikは、Rancher（RKE2）などのディストリビューションでデフォルト採用されるケースが増えており、今後さらに存在感を増していくと思われます。

特筆すべきは、一度ラベルの運用ルールが決まってしまえば、新しいサービスを公開するまでの時間が圧倒的に短い点です。検証ではわずか4分ほどでルート追加が完了していました。ただし、最初は独自のラベル規約やスキーマの理解に苦労する側面もあり、導入初期の学習コストはそれなりにかかると考えておいたほうが良さそうです。

パフォーマンスか、運用効率か

今回の検証を通じて感じたのは、「どのプロキシが最高か」という問いへの答えは、チームがどこに重きを置くかによって変わるということです。

極限のスループットを求める場合：Nginxが依然として最有力候補です。
TLS管理を楽にし、設定の可読性を上げたい場合：Caddyが使いやすいと思います。
Kubernetes環境で動的な変更を頻繁に行う場合：Traefikの柔軟性が活きてくるでしょう。

2026年のインフラ環境を見据えると、単に「リクエストを捌けるか」だけでなく、「設定変更のミスをどれだけ減らせるか」「証明書の更新で眠れない夜をどれだけ減らせるか」といった、運用面の安定性がより重視されるようになってきていると感じます。

実際、検証の最終段階でTraefikへの切り替えを行った際、設定の僅かな解釈の違いからヒヤリとする場面もありました。移行の際は、十分な並行運用期間を設け、トラフィックを段階的にシフトしていくのがやはり王道と言えそうです。

皆様の環境では、どのような基準でプロキシを選定されているでしょうか。今回の比較データが、これからのインフラ設計の一助になれば幸いです。

MicroArchitectures

H.Ueda

Programmer

ブログ