ApacheとTomcatは、どちらもApache Software Foundationが開発するオープンソースのサーバーソフトウェアです。名前が似ているため混同されがちですが、受け持つ処理が違います。Apache HTTP ServerはHTMLや画像を返し、リクエストを別のサーバーへ転送するWebサーバーです。TomcatはJavaで書かれたサーブレットやJSPを実行するサーブレットコンテナです。この記事では両者の違いを比較表で整理したうえで、Apacheのmod_proxyでTomcatへ転送する設定、AJPで連携している既存環境の締め方、WebLogicやJBoss（WildFly）との違いまでを、2026年11月時点の公式ドキュメントに沿って解説します。
まとめ｜Apacheは前段で配信と転送を担い、TomcatはJavaの処理を担う
- Apache HTTP Serverは静的ファイルの配信、TLSの終端、アクセス制限、後段への転送を受け持つWebサーバーです。
- TomcatはServletやJSPを実行するサーブレットコンテナで、HTTPの受け付けも単体でこなせます。
- 連携の方式は新規なら
mod_proxy_httpによるHTTP転送を選び、AJPは既存環境でだけsecretとアドレスを締めて使い続けます。 - Tomcatの前段に置くApacheで
X-Forwarded-Protoを付け、Tomcat側のRemoteIpValveで受けると、アプリが正しいクライアントIPとHTTPSを認識します。 - WebLogicやJBossはEJBやJMSまで含むJakarta EE全体を実装したサーバーで、Tomcatはその一部のWeb層だけを実装しています。
Tomcatそのものの仕組みと系列の選び方はTomcatとは何かを解説した記事にまとめています。
ApacheとTomcatの違いを処理対象・言語・設定ファイルの比較表で確認する
Apache HTTP ServerはC言語製のWebサーバーで静的配信と転送を担う
Apache HTTP Server（httpd）はC言語で書かれたWebサーバーです。公式サイトによると、2026年11月時点の最新安定版は2026年10月1日公開の2.4.69です。機能の大半はモジュールとして分かれており、転送はmod_proxy、TLSはmod_ssl、URLの書き換えはmod_rewriteが担います。PHPなどの言語は別のモジュールや外部プロセスで動かせますが、Javaのサーブレットを実行する機能は持っていません。前段側の脆弱性と更新手順はApache HTTP Server 2.4の脆弱性まとめで扱っています。
TomcatはJava製のサーブレットコンテナでHTTPの受け付けも単体でこなす
TomcatはJavaで書かれ、JVMの上で動きます。公式の版対応表では、2026年11月時点の最新版は11.0.27、10.1.61、9.0.123で、それぞれServlet 6.1、6.0、4.0を実装しています。必要なJavaは順に17以降、11以降、8以降です。TomcatはHTTPコネクタを内蔵しているため、Apacheを置かなくても8080番ポートでブラウザからのリクエストに応答できます。
| 観点 | Apache HTTP Server | Tomcat |
|---|---|---|
| 分類 | Webサーバー | サーブレットコンテナ |
| 実装言語 | C言語 | Java |
| 主な処理 | 静的配信・転送・TLS | Servlet・JSPの実行 |
| 既定の待ち受け | 80番・443番 | 8080番 |
| 主な設定ファイル | httpd.conf | server.xml・web.xml |
| 2026年11月の最新版 | 2.4.69 | 11.0.27 |
表のとおり、両者は競合する製品ではありません。Apacheが外からの通信を受け止め、Javaの処理が要るリクエストだけをTomcatへ渡す。この前後の分担で組み合わせるのが典型的な構成です。
リクエストがApacheからTomcatへ渡る流れと応答元を確認する方法
Apacheが静的ファイルを返しJavaの処理だけをTomcatへ転送する流れ
ブラウザからhttps://www.example.com/app/loginへリクエストが届くと、まずApacheがTLSを復号します。次にURLのパスを設定と照合し、/static/配下の画像やCSSなら、応答元はApache自身のディスクです。/app/配下ならTomcatの8080番ポートへHTTPで転送し、Tomcatがサーブレットを実行して作ったHTMLをApacheが受け取ってブラウザへ返します。
この流れでは、ブラウザが直接つながる相手はApacheだけです。Tomcatのポートを外部から届かない位置に置けるので、公開面をApacheに集約できます。一方で、Tomcatから見たリクエストの送り元はApacheになるため、クライアントのIPアドレスやHTTPSかどうかをヘッダーで引き継ぐ設定が要ります（次章で扱います）。
ポートの待ち受けとcurlの応答で前段と後段の担当を見分ける手順
既存のサーバーでどちらが何を返しているか分からないときは、待ち受けポートと応答を順に確かめます。次のコマンドはLinuxでの例です。
# 1) 待ち受けポートとプロセスを確認する（80/443=httpd、8080=HTTP、8009=AJPが典型）
sudo ss -ltnp | grep -E ':(80|443|8080|8009)\b'
# 2) httpdで読み込まれている転送系モジュールを確認する
apachectl -M | grep -E 'proxy|jk'
# 3) 前段経由と後段直のヘッダーを比べる（同じパスで差が出るかを見る）
curl -sI https://www.example.com/app/
curl -sI http://127.0.0.1:8080/app/2でproxy_ajp_moduleやjk_moduleが出たら、AJPで連携している環境です。3で前段経由と後段直の応答ヘッダーを比べると、Set-Cookieのパスやリダイレクト先のLocationに内部のホスト名やポートが漏れていないかも同時に確認できます。Tomcatの版そのものの調べ方はTomcatのバージョン確認方法を参照してください。
mod_proxy_httpでApacheからTomcatへHTTP転送を設定する
ApacheからTomcatへの転送設定は、VirtualHostの中に記述する形です。
静的ファイルを「!」で除外しアプリのパスだけをTomcatへ送る設定例
Apache側ではmod_proxyとmod_proxy_httpを読み込み、ProxyPassで転送先を指定します。mod_proxyの公式ドキュメントによると、転送しないパスは値に「!」を書いて除外し、その除外は一般的なProxyPassより前に書く必要があります。設定は上から評価され、最初に一致した規則が使われるためです。
<VirtualHost *:443>
ServerName www.example.com
# mod_ssl の証明書設定は省略
# 静的ファイルはApacheが直接返す（除外は先に書く）
Alias /app/static /var/www/app-static
ProxyPass /app/static !
# それ以外の /app 配下をTomcatへ転送する
ProxyPass /app http://127.0.0.1:8080/app connectiontimeout=5 timeout=60
ProxyPassReverse /app http://127.0.0.1:8080/app
# mod_proxy は X-Forwarded-Proto を付けないため mod_headers で明示する
RequestHeader set X-Forwarded-Proto "https"
</VirtualHost>ProxyPassReverseは、Tomcatが返すリダイレクトのLocationヘッダーに含まれる内部のURLを、外向きのURLへ書き戻す指定です。ProxyPreserveHostは既定でOffで、公式ドキュメントも通常はOffのままでよいとしています。Tomcatから見えるホスト名は、次のどちらかの方法で前段に合わせます。
RemoteIpValveでクライアントのIPとHTTPSをTomcat側に正しく渡す
公式ドキュメントによると、mod_proxy_httpはProxyAddHeadersが既定でOnのため、X-Forwarded-For、X-Forwarded-Host、X-Forwarded-Serverの3つを自動で付けます。ただし受け取ったTomcatは、何もしなければヘッダーを読まず、送り元を127.0.0.1、通信をHTTPとして扱う。ログのIPが全部同じになったり、HTTPSのページでHTTPへのリダイレクトが起きたりするのはこのためです。
Tomcat側ではValveの設定リファレンスにあるRemoteIpValveをserver.xmlのHost要素の中に置きます。既定でX-Forwarded-ForとX-Forwarded-Protoを読みます。
<!-- server.xml の Host 要素内 -->
<Valve className="org.apache.catalina.valves.RemoteIpValve"
internalProxies="127.0.0.1/32"
remoteIpHeader="X-Forwarded-For"
protocolHeader="X-Forwarded-Proto" />
<!-- 外部からの直アクセスを防ぐため HTTP コネクタはループバックで待ち受ける -->
<Connector port="8080" address="127.0.0.1" protocol="HTTP/1.1"
connectionTimeout="20000" />internalProxiesは信頼する前段のアドレスです。既定値はプライベートアドレス帯をすべて含み、同ドキュメントも「すべてのローカルネットワークを信頼する前提」と注意書きしています。同じネットワークに他の利用者がいる環境では、前段のアドレスだけに絞ってください。正規表現での指定はTomcat 12で削除予定の非推奨になっているため、例のようにCIDRで書きます。もう1つの方法は、Tomcatのプロキシ設定ガイドのとおりConnectorにproxyNameとproxyPortを固定で書く方式です。ホスト名が1つに決まっているならこちらでも足ります。
タイムアウトとmod_proxy_balancerで複数台のTomcatへ振り分ける
先の設定例のconnectiontimeoutはTomcatへの接続確立を待つ秒数、timeoutは応答データを待つ秒数です。timeoutを書かなければProxyTimeout、さらに未指定ならTimeoutの値が使われます。帳票の生成など時間のかかる処理があるパスだけ、個別のProxyPassで長めに取ります。
Tomcatを2台以上に増やすときに使うのは、mod_proxy_balancerです。mod_proxy_balancerの公式ドキュメントによると、振り分けの方式は別モジュールが提供するため、mod_lbmethod_byrequestsなども合わせて読み込みます。セッションを同じTomcatへ戻すには、各Tomcatのserver.xmlのEngineにjvmRouteを付け、Apache側のrouteと揃えます。
# httpd.conf（Apache側）
<Proxy "balancer://tomcats">
BalancerMember "http://10.0.1.11:8080" route=node1
BalancerMember "http://10.0.1.12:8080" route=node2
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass /app balancer://tomcats/app stickysession=JSESSIONID|jsessionid
ProxyPassReverse /app balancer://tomcats/app
# server.xml（1台目のTomcat。2台目は jvmRoute="node2"）
<Engine name="Catalina" defaultHost="localhost" jvmRoute="node1">TomcatはjvmRouteの値をセッションIDの末尾に「.node1」の形で付けます。Apacheが同じTomcatへ転送する際の判断材料は、この末尾の部分です。どちらかのTomcatが止まるとそのTomcatのセッションは失われるため、ログイン状態を保ちたいならセッションの複製か外部ストアへの保存を別に検討します。
AJPで連携している既存環境を確認しsecretとアドレスを締める手順
Ghostcat以降に変わったAJPコネクタの既定値と起動しない原因
AJPは、ApacheとTomcatの間で使われてきた専用の通信方式です。mod_proxy_ajpの公式ドキュメントによると、AJP13は性能のために選ばれたパケット単位のバイナリ形式で、ajp://で始まるURLで転送先を指定します。
2020年2月24日に公表されたCVE-2020-1938（通称Ghostcat）は、AJPのポートに届く相手がWebアプリ内の任意のファイルを読めてしまう脆弱性でした。Tomcat 9のセキュリティ情報によると、9.0.31で修正され、同時にAJPコネクタの既定構成が強化されています。現行のAJPコネクタの設定リファレンスでは、addressの既定はループバックアドレス、secretRequiredの既定はtrueです。secretを設定しないとAJPコネクタは起動しません。古いserver.xmlを流用して版を上げたあとに8009番が開かなくなったら、まずこの2つを疑ってください。
mod_proxy_ajpとTomcatのsecret一致設定とHTTP移行
AJPを使い続ける場合は、Tomcat側のsecretとApache側のsecretを同じ値にします。Apache側でsecretを指定できるのは、公式ドキュメントによるとhttpd 2.4.42以降です。
<!-- server.xml（Tomcat側）：前段と同じホストならループバックで待ち受ける -->
<Connector protocol="AJP/1.3" address="127.0.0.1" port="8009"
secret="前段と同じ値を設定する" />
# httpd.conf（Apache側）
ProxyPass "/app" "ajp://127.0.0.1:8009/app" secret=前段と同じ値を設定する前段と後段が別のホストなら、addressをTomcatのプライベートアドレスにし、8009番をファイアウォールで前段からだけ通します。secretRequired="false"にして起動させる対処は、信頼できるネットワークに限るよう公式ドキュメントが求めています。
判断としては、AJPは既存環境の延命にとどめ、改修の機会にHTTP転送へ移します。2026年10月にもAJPの応答処理に関わる脆弱性が修正されており、系列ごとの修正版はApache Tomcatの脆弱性一覧で確認できます。HTTP転送へ移す作業は、前章のProxyPassの書き換えとRemoteIpValveの追加で済み、アプリの改修は通常要りません。
WebLogicやJBossとTomcatの違いをJakarta EEの対応範囲で比べる
サーブレットだけのTomcatとEJBやJMSまで持つアプリケーションサーバー
「Tomcatの違い」で比べられるもう1つの相手が、WebLogicやJBossです。こちらはApache HTTP Serverと違い、Tomcatと同じ後段のJava実行環境にあたります。差は実装している仕様の範囲です。TomcatはJakarta EEのうちServlet、Pages（JSP）、WebSocketなどWeb層の仕様だけを実装しています。WebLogicやJBoss（WildFly）は、トランザクション、EJB、JMS（メッセージング）、JPA（永続化）まで含む仕様群を1つのサーバーで提供します。
この違いが効くのは移行のときです。EJBやJMSを使うアプリはTomcatへそのまま載せられず、Spring Frameworkなどへの置き換えが要ります。逆に、Servletと画面だけで作られたアプリなら、WebLogicからTomcatへ移しても動く可能性が高い。
WebLogic 15.1.1とWildFly 42の対応EE版とライセンス
| 観点 | Tomcat 11.0 | WildFly 42 | WebLogic 15.1.1 |
|---|---|---|---|
| 提供元 | Apache財団 | WildFlyプロジェクト | Oracle |
| 実装範囲 | Web層の仕様のみ | EE 11全体 | EE 9.1全体 |
| パッケージ名 | jakarta | jakarta | jakarta |
| ライセンス | Apache License 2.0 | OSS | 商用ライセンス |
| 有償サポート版 | なし（外部事業者） | JBoss EAP | 製品に付属 |
WildFly 42のリリース告知（2026年10月22日）によると、WildFly 42はJakarta EE 11のPlatform、Web Profile、Core Profileに対応し、Java SE 17と21で互換性を確認しています。JBoss EAPは、このWildFlyを基にRed Hatが有償サポートを付けて提供する製品です。WebLogic 15.1.1の新機能の解説では、15.1.1がJakarta EE 9.1、前の14.1.2がJakarta EE 8に対応するとしています。14.1.2以前はjavaxのパッケージ名を使うため、15.1.1やTomcat 10以降へ移すときはjavaxからjakartaへの移行が先に必要です。WebLogicの修正版は四半期ごとのOracleのCPUで配布され、直近の内容はOracle CPUの解説にまとめています。
Apacheの前段配置とWebLogicやJBossからTomcatへの移行判断
前段のApacheを省きTomcat単体やロードバランサー直結で運用する条件
判断を言い切ります。クラウドのロードバランサーがTLSを終端し、静的ファイルをCDNから配る構成なら、Apacheは置きません。Apacheが担うはずだった役割を前段のサービスがすでに受け持っているため、間にApacheを挟んでも設定とログの置き場所が増えるだけです。この場合もTomcat側のRemoteIpValveは必要で、internalProxiesをロードバランサーのアドレス帯に合わせます。
Apacheを置くのは次の場合です。1台のサーバーでPHPなど他言語のアプリと同居させる。既存の.htaccessやmod_rewriteの書き換え規則を引き継ぐ必要がある。オンプレミスでTLSの終端や認証をWebサーバー側に集約する運用が決まっている。新規に前段を置くなら、Apacheと同じ役割はnginxでも担えます。版の追い方はnginxの最新バージョンの解説を参照してください。Spring Bootで実行可能jarを作る構成では、Tomcatはアプリに内蔵されるため、外部Tomcatの設置自体が要りません（Spring Bootの組み込みTomcat）。
WebLogicやJBossからTomcatへ移す判断と移さずに残すべきシステム
WebLogicやJBossからTomcatへの移行を勧めるのは、アプリがServlet、JSP、Spring Frameworkの範囲で作られ、EJBやJMS、分散トランザクションを使っていない場合です。ライセンス費用とサーバーの保守の両方が軽くなります。
見送るのは、EJBやJMSで業務処理の中核が組まれている、複数のデータベースをまたぐトランザクションをサーバーに任せている、といった場合です。Tomcatへ移すとこれらを作り直すことになり、移行ではなく再開発の規模になります。その場合は同じJakarta EE全体を実装したWildFlyやJBoss EAPへの乗り換えのほうが改修は小さく済む。当社では、既存のJava資産の調査から構成の見直し、作り直しまでをフルスクラッチ開発として請けています。
よくある質問
ApacheとTomcatの違いと連携について、よく寄せられる質問をまとめました。
ApacheとTomcatは同じ会社の製品ですか？
どちらもApache Software Foundationが開発するオープンソースのソフトウェアで、Apache License 2.0で配布されています。「Apache」は財団の名前でもあるため、単に「Apache」と書かれた場合はApache HTTP Serverを指すのが一般的です。Tomcatの正式名称はApache Tomcatです。
Tomcatだけで本番運用しても問題ありませんか？
可能です。TomcatはHTTPとHTTPSの両方に単体で応答できます。ただし80番や443番のポートで直接待ち受けるには権限の扱いに注意が要るため、クラウドのロードバランサーやWebサーバーを前段に置き、Tomcatは8080番のままにする構成が一般的です。インストールと初期設定の堅牢化はTomcatのインストール手順で扱っています。
mod_jkとmod_proxy_ajpはどちらを使えばよいですか？
新規ならどちらも選ばず、mod_proxy_httpによるHTTP転送を使います。既存環境でAJPを残す場合、mod_proxy_ajpはhttpdに標準で含まれ、mod_proxyと同じ書式で設定できます。mod_jkは別途ビルドと配布が要る分、版上げの手間が増える仕組みです。
ApacheとTomcatは同じサーバーに入れるべきですか？
小規模なら同じサーバーで構いません。その場合はTomcatの待ち受けを127.0.0.1に限ると、外部から8080番へ直接届かなくなります。アクセスが増えてTomcatを複数台にする段階で、Apacheを別のサーバーへ分け、mod_proxy_balancerで振り分けます。
Tomcatのバージョンを上げるとApache側の設定も変わりますか？
HTTP転送なら、Apache側の設定は通常変わりません。AJPで連携していて9.0.31より前の版から上げる場合は、Tomcat側のsecretとaddressの既定値が変わったため、Apache側にもsecretの追記が要ります。系列ごとのサポート期限はTomcatのバージョン一覧とサポート期限で確認できます。
関連記事
- Apache Tomcatとは？サーブレットコンテナの仕組みとApacheとの違い・対応Java版・インストール手順：Tomcatの内部構造と系列の選び分け
- Tomcatのインストール手順｜Ubuntuのtar.gz＋systemd・Windowsサービス・Docker公式イメージと初期設定の堅牢化【11.0.27】：後段のTomcatを立てる手順
- Tomcatのバージョン一覧とサポート期限【2026年10月】最新版11.0.27、9.0系は2027年3月末終了・9.1系は2030年末まで：系列ごとの終了予定
- Apache Tomcatの脆弱性一覧【2026年10月】最新版11.0.27・10.1.61・9.0.123とCVE-2026-59083ほかの影響確認・対応手順：AJPを含む脆弱性の影響確認
- Apache HTTP Server 2.4の脆弱性まとめ｜CVE-2026-33523ほか2.4.67〜2.4.69の該当判定と更新手順【2026年10月】：前段のApacheの更新
- Spring Bootの組み込みTomcat｜tomcat.versionでの版上げ・server.*設定・Jetty切替・WAR化の手順【4.1.2対応】：外部Tomcatを置かない構成
