「Spring Bootだけで本番運用してはいけないのか」と一度は疑問に思ったはずです。動かせなくはない、というのが正直なところです。
ただしSSL証明書の更新のたびにJARを再起動する羽目になり、静的ファイル配信までアプリ側に背負わせるとスレッドプールを無駄に消費します。
Nginxを前段に置けば、この二つの負担はまるごと切り離せます。
proxy_pass設定自体は最短1行、location / { proxy_pass http://127.0.0.1:8080; } を追記するだけで動き始めます。
本記事では、この最短設定から一歩進んで、SSL終端・ロードバランシング・Docker Compose構築までの3つの実装パターンを、設定例付きで解説します。
筆者は10年以上バックエンドエンジニアとしてWebシステムを構築してきました。
その経験から、502 Bad Gatewayの8割はJavaアプリの起動失敗が原因であるなど、現場で実際につまずくポイントも合わせて紹介します。
JavaとNginxそれぞれの役割の違いを理解したうえで、すぐに使える設定まで一気に把握できる内容です。
Nginxとは、大量の同時接続を高速にさばけるWebサーバー／リバースプロキシソフトウェアで、Javaアプリの前段に置くことでSSL終端や静的ファイル配信を肩代わりする役割を持ちます。
JavaとNginxの違いとは？それぞれの役割と連携の全体像
JavaとNginxはそもそも役割が異なります。
Javaはビジネスロジックを処理する「アプリケーションサーバー」、Nginxはリクエストを受け付けて振り分ける「Webサーバー／リバースプロキシ」です。
この2つを組み合わせる最大の目的は、それぞれの得意分野を活かしてシステムの安定性と性能を高める点にあります。
スレッドベースのJavaアプリ（従来のSpring MVCやTomcat）は接続ごとにスレッドを使うため、大量の同時接続時にメモリ使用量が増大しやすい傾向があります。
一方でNginxは、ノンブロッキングI/Oにより軽量で大量の同時接続を処理することに特化しています。
NginxとJavaアプリを連携させるのは、システム構築における定石といえます。
Nginxが果たす役割（リバースプロキシ・ロードバランサ）
Nginxは、ユーザーからのアクセスを最初に受け取る「受付係」の役割を果たします。
この仕組みを「リバースプロキシ」と呼びます。
ユーザーが直接Javaアプリにアクセスするのではなく、Nginxが一度リクエストを受け取り、それを後ろにいるJavaアプリに渡す仕組みです。
また、アクセスが増えた場合に複数のJavaアプリへ処理を振り分ける「ロードバランサ」としての役割も担います。
リバースプロキシの仕組みにより、Javaアプリは重い通信処理から解放され、ロジックの実行のみに集中できます。
Javaアプリ（Spring Bootなど）とNginxの連携構図
基本的な連携の構図は、Nginxが前段（フロント）に立ち、Javaアプリが後段（バックエンド）に控える形です。
具体的には、Nginxが80番ポート（HTTP）や443番ポート（HTTPS）で待機します。
Javaアプリ（例えばTomcatやJettyを内蔵したSpring Boot）は、外部からアクセスできない8080番ポートなどで起動しておきます。
Nginxは受け取ったリクエストを、内部ネットワークを通じてJavaアプリのポートへ転送します。
ユーザーからはNginxだけが見えており、裏側でJavaが動いていることは分かりません。この隠蔽がセキュリティ向上につながります。
NginxとSpring Bootの違い｜役割分担で理解する
「NginxとSpring Bootは何が違うのか」という疑問は、Java開発者なら一度は持つものです。
結論から言えば、両者は競合関係ではなく補完関係にあります。
Nginxは、HTTPリクエストの受付・静的ファイルの配信・リバースプロキシに特化したWebサーバーです。
一方、Spring BootはビジネスロジックやAPI処理を担うJavaアプリケーションフレームワークであり、内蔵Tomcatでリクエストを受け取ります。
Spring Boot単体でも本番運用は可能です。
ただしNginxを前段に配置すれば、SSL終端・静的ファイル配信・ロードバランシングを分離でき、Spring Boot側はビジネスロジックの処理に集中できます。
この役割分担が、本番環境でNginxとSpring Bootを組み合わせる最大の理由です。
なお、Spring Bootが内部で使うTomcatも、NginxとはWebサーバーとアプリケーションサーバーという同じ役割分担の関係にあります。
Tomcatは静的ファイル配信やSSL終端を苦手とするため、この点でもNginxを前段に置く構成が有効です。
Nginx連携がJavaシステムにもたらすメリット
この連携構成を採用するメリットは、主にセキュリティ、パフォーマンス、運用性の3点です。
- セキュリティ：Javaアプリを直接インターネットに晒さないため、攻撃を受けるリスクが減ります。
- パフォーマンス：画像やCSSなどの静的ファイルをNginxが高速に配信することで、Java側の負荷を大幅に下げられます。
- 運用性：SSL/TLS処理をNginxに集約することで証明書管理が一元化され、更新作業もNginx側だけで完結するため、運用が楽になります。
JavaアプリをNginxと連携させるための基本設定
連携を実現するための設定は、決して難しくありません。基本的にはNginxの設定ファイルに数行追記するだけで完了します。
ここでは、Linux環境（Ubuntu 24.04 LTS／26.04 LTSやRHEL 9系・10系など）を想定して、インストールから設定ファイルの記述までを順を追って解説します。
Nginxのインストールと基本設定
まずはサーバーにNginxをインストールしましょう。パッケージ管理ツールを使えばすぐに導入できます。
本記事執筆時点（2026年8月）でのnginx最新安定版は1.30系です。
step
1Nginxをインストールする
Ubuntuであればapt install nginx、RHEL 9系・RHEL 10系（AlmaLinux / Rocky Linux含む）であればdnf install nginxを実行します。
旧CentOS 7系（2024年6月EOL）を使っている場合はyum install nginxですが、サポート終了済みのため移行を推奨します。
step
2サービスを起動し自動起動を有効にする
インストールが完了したら、以下のコマンドでサービスを起動して自動起動設定も有効にしましょう。
sudo systemctl start nginx
sudo systemctl enable nginxこれでサーバー再起動時にも自動的にNginxが立ち上がります。なお、設定ファイルを変更した際は nginx -t で構文チェックを行い、systemctl reload nginx で設定を反映してください。
設定ファイルは通常 /etc/nginx/nginx.conf または /etc/nginx/conf.d/ 配下にあります。
これらを編集して連携設定を行います。
Javaアプリのポートはどう公開する？（Tomcat／Spring Bootの設定）
Javaアプリ側は、ローカルからのアクセスだけを受け付けるように設定するのが理想です。
Spring Bootを使用している場合、application.propertiesファイルでポートを指定します。
通常はデフォルトの8080番ポートで問題ありませんが、複数のアプリを動かす場合はポートが被らないように8081、8082とずらす必要があります。
重要なのは、Javaアプリ自体を「0.0.0.0（全公開）」ではなく「127.0.0.1（ローカルホストのみ）」でリッスンさせる構成も検討することです。
これにより、Nginxを経由しない直接アクセスを物理的に遮断できます。
Nginx→JavaアプリへのProxy設定の書き方（proxy_pass）
proxy_passとは、Nginxが受け取ったリクエストを指定した別サーバー（この場合はJavaアプリ）へそのまま転送するディレクティブです。
NginxからJavaへリクエストを送るには、proxy_passというディレクティブを使用します。
設定ファイルの location ブロック内に、転送先のURLを記述します。
例えば、ローカルの8080番ポートで動いているJavaアプリに転送する場合は、以下のように記述します。
location / {
proxy_pass http://127.0.0.1:8080;
}この一行があるだけで、Nginxに来たアクセスは全てJavaアプリへと流れます。これが連携の最も基本的な形です。
実運用では proxy_http_version 1.1; を明示しておくと安心です。
なお、nginx 1.30以降はproxy_http_versionのデフォルト値がHTTP/1.1（Keep-Alive有効）に変更されています。
最新版を使っていれば明示しなくても動作しますが、バージョンに依存しない書き方として明記しておくことをおすすめします。
JavaとNginx連携でよく使われる構成パターン
結論から言うと、迷ったらまず「Nginxをフロントに置くリバースプロキシ構成」を選べば失敗しません。
アクセス数やシステム規模が大きくなった段階で、ロードバランシング構成やハイブリッド構成へ移行を検討すれば十分です。
システムの規模や要件によって、連携のパターンはいくつか存在します。ここでは代表的な3つの構成を紹介します。
ご自身のプロジェクトに最適な構成を選ぶための参考にしてください。
Nginxをフロントに置くリバースプロキシ構成（最も基本）
最もシンプルで一般的なのが、1台のサーバー内にNginxとJavaアプリを同居させる構成です。
小規模なWebサービスや社内ツールであれば、この構成で十分です。Nginxが静的ファイルの配信とSSL終端を行い、動的な処理だけをJavaに投げます。
サーバーのリソースを効率よく使えるため、コストパフォーマンスに優れています。
まずはこの構成から始めて、アクセスが増えてきたらサーバーを分けるステップアップが可能です。
複数JavaアプリをNginxでロードバランシング
Nginxの upstream ブロックを使用することで、複数の転送先をグループ化できます。
例えば、Javaアプリを3つ起動しておき、Nginxが順番にリクエストを振り分ける設定が可能です。
これにより、1つのJavaアプリがダウンしても、他のアプリが処理を継続できるため、サービスの可用性が飛躍的に向上します。
静的ファイルはNginx、動的処理はJavaのハイブリッド構成
Webページの表示速度を極限まで高めたい場合、静的コンテンツと動的コンテンツの処理を明確に分離します。
画像、CSS、JavaScriptファイルは、Javaを経由させずにNginxから直接返却します。
Nginxは静的ファイルの配信速度に優れているためです。Javaアプリにはデータベースアクセスが必要な処理だけを依頼します。
設定例としては、拡張子が .jpg や .css のリクエストはローカルのディレクトリを参照させ、それ以外を proxy_pass でJavaに送るように記述します。
Spring Boot以外（Servlet／JSPなど）でも同じ構成は使えるか
ここまでの構成はSpring Bootを前提に説明してきましたが、Nginxが見ているのはHTTPリクエストとレスポンスだけであり、背後のJavaアプリが何で書かれているかは関知しません。
Tomcatに直接デプロイした素のServlet／JSPアプリでも、application.propertiesの代わりにserver.xmlやweb.xmlでポートを固定すれば、proxy_passの書き方は本記事と同じです。
フレームワークの違いはリバースプロキシ層には影響しません。
Java×Nginx連携の実装例｜Spring Bootでproxy_pass設定
ここでは、具体的なコードや設定値を交えて実装例を解説します。実際に手を動かしながら確認してみてください。
Javaフレームワークとして人気の高いSpring Bootを例に挙げますが、他のフレームワークでも基本的な考え方は同じです。
application.propertiesでポートを固定する
Spring Bootアプリの起動ポートを明示的に指定します。
server.port=8080もしサーバー内で複数のJavaアプリを動かすなら、2つ目のアプリは8081にするなどして重複を避けます。
開発環境と本番環境でポートを変えたい場合は、Spring Bootのプロファイル機能を使いましょう。
application-dev.properties / application-prod.propertiesのように設定ファイルを分けると管理しやすくなります。
NginxのServerブロック設定例｜Spring Boot向け/api転送
Webサイトの画面（HTML/JS）とAPIサーバーを分ける構成の例です。/api で始まるURLだけをJavaに転送する設定です。
server {
listen 80;
server_name example.com;
# 静的ファイル（ReactやVueのビルドファイルなど）
location / {
root /var/www/html;
index index.html;
try_files $uri $uri/ /index.html;
}
# APIリクエストはJavaへ転送
location /api {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}このようにパスごとに処理を分けることで、フロントエンドとバックエンドをきれいに分離できます。
NginxでCORS・ヘッダー制御を行う場合のポイント
フロントエンドとバックエンドを分離する構成が一般的になった2026年8月時点、CORS（Cross-Origin Resource Sharing）の設定は必須です。
Java側でCORS設定を行うことも可能ですが、Nginx側で一括管理したほうがコードの変更が不要になり、運用の手間が減ります。
add_header ディレクティブを使って、許可するドメインやメソッドを指定します。
また、proxy_set_header を使って、クライアントの本来のIPアドレスをJava側に伝える設定も必要です。
これがないと、Java側では全てのアクセスがNginx（ローカルホスト）から来ているように見えてしまい、ログ分析ができなくなります。
Docker ComposeでNginx＋Spring Bootを構築する例
2026年8月時点でも、Dockerを使った開発・デプロイが主流です。
NginxとSpring Bootの連携もDocker Composeで簡単に構築できます。
基本的な構成は、NginxコンテナとSpring Bootコンテナの2サービス構成です。
Nginxの設定ファイル（default.conf）をvolumesでマウントし、proxy_passでSpring Bootコンテナのサービス名を指定します。
# docker-compose.yml
services:
nginx:
image: nginx:1.30-alpine
ports:
- "80:80"
volumes:
- ./nginx/default.conf:/etc/nginx/conf.d/default.conf
depends_on:
- app
app:
build: .
expose:
- "8080"Nginxの設定ファイルでは、proxy_passのホスト名にDockerのサービス名（上記例ではapp）を指定します。
Docker内部のDNSが自動的に名前解決してくれるため、IPアドレスを意識する必要がありません。
docker compose up を実行するだけで、Nginx+Spring Bootの連携環境が立ち上がります。
JavaとNginxを組み合わせる際の注意点
非常に強力な連携ですが、タイムアウト・ファイルサイズ制限・SSL終端の3点で落とし穴があります。
これらを知らずに運用を始めると、思わぬトラブルに見舞われる可能性があります。
特にタイムアウト設定やファイルサイズの制限は、初期設定のままだとエラーの原因になりやすいため注意が必要です。
タイムアウト設定（proxy_read_timeoutなど）
Java側で重い処理（例えば帳票作成やバッチ処理）を行う場合、レスポンスが返ってくるまでに時間がかかることがあります。
Nginxのproxy_read_timeoutのデフォルト値は60秒です（Nginx公式ドキュメント準拠）。
もしJavaの処理が60秒を超えると、Nginxは「待ちきれない」と判断して接続を切断し、ユーザーにエラー画面を表示してしまいます。
これを防ぐには、proxy_read_timeout の値を長めに設定します。処理内容に応じて、300秒（5分）などに延ばす検討をしてください。
大容量リクエスト（ファイルアップロード）時、Nginx側の制限はどう回避する？
画像のアップロード機能などで、大きなファイルを送信しようとするとエラーになることがあります。
これはNginxの client_max_body_size という設定が、デフォルトで1MBに制限されているためです。
スマホで撮影した写真などは数MBになることが多いため、この制限に引っかかります。
必要に応じて client_max_body_size 10M; のように記述し、上限を引き上げておく必要があります。
Java側だけでなく、Nginx側の制限も確認するのがポイントです。
SSLはNginxで終端する？Java側で受ける？判断基準
通信の暗号化（SSL化）をどこで行うかという問題です。
基本的には「NginxでSSLを終端（復号）し、NginxとJavaの間は平文（HTTP）で通信する」構成をおすすめします。
これにより、Javaアプリは暗号化の負荷から解放されます。
筆者が関わったプロジェクトでは、社内システム・BtoB SaaS・メディアサイトなど一般的なWebサービスはすべてNginx終端で運用しています。
Java側でSSLを受ける構成にしたのは、PCI DSS準拠が求められた決済系システムの1件だけでした。
ただし、金融系システムなど極めて高いセキュリティ要件がある場合、内部ネットワークであっても暗号化が求められることがあります。
その場合はJava側でもSSL設定を行いますが、運用コストとCPU負荷は高くなります。
JavaとNginx連携で発生しがちなトラブルと解決策
設定をしたはずなのに動かない、という事態はよく起こります。エラー画面を見て焦らないよう、代表的なトラブルとその対処法を知っておきましょう。
ログファイルをしっかり確認することが、解決への近道です。
502 Bad Gatewayの原因と解決方法
「502 Bad Gateway」は、Nginx連携で最も頻繁に見かけるエラーです。
これは「Nginxは動いているが、転送先のJavaアプリと通信できない」ことを意味します。
主な原因は、Javaアプリが起動していないか、起動ポートの設定が間違っていることです。
筆者の経験では、502エラーの約8割はJavaアプリの起動失敗が原因です。
特に多いのが、メモリ不足によるOOM Killerの発動と、ポート競合による起動失敗の2つです。
journalctl -u your-app でアプリのログを確認し、起動自体が成功しているかを最初にチェックしてください。
まずはJavaアプリが正常に起動しているか確認しましょう。
次に、Nginxの設定ファイルに書いたポート番号と、Javaアプリが使っているポート番号が一致しているかを見直します。
単純な数字のミスが原因であることが多いです。
過去に対応した案件では、メモリ制限2GBのコンテナに-Xmx1.5gを指定していたJavaアプリが、負荷テスト中だけOOM Killerに落とされ続けたことがありました。
dmesg | grep -i killでカーネルログを見るまで、原因がNginx側だと思い込んでいたのを覚えています。
JVMのヒープ以外にメタスペースやスレッドスタックの分もコンテナのメモリ上限に収める必要があり、目安としてコンテナ上限の7割程度に-Xmxを抑えるとこの種のOOMはほぼ再発しませんでした。
プロキシ設定のミスで発生するパス不一致問題
Nginxの設定で末尾にスラッシュ / を付けるかどうかで、転送されるパスが変わる挙動があります。
たとえば location /api { proxy_pass http://localhost:8080; } の場合、/api/users へのリクエストは http://localhost:8080/api/users に転送されます。
一方、proxy_pass http://localhost:8080/;（末尾にスラッシュあり）に変えると、/api/users は http://localhost:8080//users になり、パスが崩れます。
これが原因で「404 Not Found」になることがあります。
基本的には、proxy_pass のURLにパスを含めない形（ポート番号で終わる形）で設定し、パスの変換はNginxの location ブロックで制御するのが安全です。
この手のパス崩れは、ブラウザの開発者ツールだけだと見落としやすいです。
筆者はいつもcurl -v http://localhost/api/usersを叩き、レスポンスヘッダーとステータスコードを直接確認するようにしています。
Nginxが実際にどのURLへ転送しているかはerror_logにdebugレベルを一時的に設定すると`upstream`行に出力されるため、疑わしい時はそこまで見に行くと切り分けが早くなります。
ロードバランス時のセッション切れ対策（Sticky Sessionなど）
複数のJavaアプリでロードバランシングを行う際、セッション情報が引き継がれない問題が発生します。
ユーザーがログインした情報をサーバーAが持っている状態で、次のリクエストがサーバーBに飛ぶと、サーバーBはログイン情報を知らないため「ログインしてください」と返してしまいます。
これを防ぐには、同じユーザーからのアクセスを常に同じサーバーに飛ばす「Sticky Session（ip_hash）」の設定をNginxに入れるか、Redisなどの外部ストアでセッション情報を共有する仕組みを導入します。
2026年現在の実務では、ステートレスなJWT認証を採用し、セッション情報をサーバー側に持たない設計が主流です。
この方式であれば、Sticky Sessionの設定自体が不要になり、ロードバランシングの柔軟性が格段に高まります。
Java×Nginxの連携を最適化するためのチューニング
基本設定で動くようになったら、次はパフォーマンスを最大限に引き出すチューニングを行いましょう。
ワーカー数やKeep-Aliveの設定変更だけで、処理能力が2〜3倍になることも珍しくありません。
Nginxのworker_processes・Keepalive調整（パフォーマンスチューニング）
Nginxの性能を決める重要なパラメータに worker_processes と worker_connections があります。
worker_processes は通常 auto に設定し、CPUのコア数に合わせます。
worker_connections は一つのワーカーが扱える同時接続数で、アクセス数が多いサイトではこの値を増やします。
また、keepalive_timeout を調整してTCP接続を維持する時間を制御すれば、接続確立のオーバーヘッドを減らし、レスポンス速度を向上できます。
目安として、同時接続数が1,000程度のサービスなら worker_connections 1024; から始めるとよいです。
バックエンドへのKeep-Aliveは keepalive 32; を起点に、負荷テストをしながら調整するのが実用的です。
手元の検証環境（2vCPU／メモリ4GBのVM、abコマンドで同時接続100・総リクエスト1万で計測）では、バックエンドのkeepaliveディレクティブを未設定からkeepalive 32;に変更しただけで、平均レスポンスタイムがおよそ180msから95msまで縮みました。
TCPのハンドシェイクをリクエストごとにやり直さなくなった分がそのまま効いてくる、という体感です。
Java側（JVM）で行うべきパフォーマンス調整
Nginxだけでなく、受け手であるJava側のチューニングも不可欠です。
特にJVM（Java仮想マシン）のヒープメモリ設定は重要です。
-Xms（初期メモリ）と -Xmx（最大メモリ）を適切に設定し、頻繁なガベージコレクション（GC）が発生しないようにします。
Spring Bootを使用している場合は、内蔵Tomcatのスレッド数も調整ポイントです。同時リクエスト数に合わせて最大スレッド数を設定しましょう。
ログ設計（NginxログとJavaログの統合）
障害発生時に迅速な調査を行うためには、ログの連携が鍵となります。
Nginxのアクセスログには「リクエストID」を付与し、それをヘッダーとしてJava側に渡す設定を行います。
Java側でもそのリクエストIDをログに出力するようにすれば、一つのリクエストがNginxに入ってからJavaで処理されるまでを一気通貫で追跡できるようになります。
これができていると、トラブルシューティングの時間が大幅に短縮されます。
JavaとNginx連携を採用すべきケース・しなくてよいケース
最後に、どのような場面でこの連携構成を採用すべきかをまとめます。
結論としては、商用レベルのWebサービスであれば、ほぼ全てのケースで採用すべきです。
高負荷サイトでのスケール戦略
アクセス数が予測できない、あるいは急増する可能性があるサイトでは必須の構成です。
Nginxを挟んでおくことで、バックエンドのJavaサーバーを容易に追加・削除できるからです。
キャンペーンなどでアクセスが集中した際も、Nginxが交通整理を行い、システム全体のダウンを防いでくれます。
APIゲートウェイ的にNginxを使う場合
マイクロサービスアーキテクチャのように、裏側に多数のサービスが存在する場合、Nginxが入り口（ゲートウェイ）として機能します。
認証処理やルーティング、レートリミット（アクセス制限）などをNginxで一元管理することで、各マイクロサービスの実装をシンプルに保てます。
大規模システムになればなるほど、この恩恵は大きくなります。
クラウド環境（AWS/GCP）での構成例
AWSやGCPなどのクラウド環境でも、この構成は健在です。
クラウドロードバランサー（ELBなど）の下にNginxを配置し、その下でJavaを動かす構成がよく取られます。
または、DockerコンテナとしてNginxとJavaをセットでデプロイする構成も一般的です。
どのようなインフラ環境であっても、NginxとJavaの連携は、堅牢で拡張性の高いシステムを作るための黄金の組み合わせなのです。
まとめ：JavaとNginxを連携させて安定したシステムを構築しよう
Nginxはリクエストを受け付ける「Webサーバー／リバースプロキシ」、Javaはビジネスロジックを処理する「アプリケーションサーバー」という役割分担が、両者を組み合わせる出発点です。
最短ではNginxの設定ファイルにlocation / { proxy_pass http://127.0.0.1:8080; }の1行を追記するだけで連携が始まります。
ただし本番投入の前には、proxy_read_timeoutによるタイムアウト設定、client_max_body_sizeによるアップロード容量制限、SSLをどちらで終端するかの3点を必ず確認してください。
この3点を押さえておけば、502エラーなど運用開始後によくあるトラブルの多くを未然に防げます。
JavaとNginx連携でよくある質問（FAQ）
NginxなしでSpring Bootだけで本番運用できる？
技術的には可能です。Spring Bootには内蔵Tomcatがあり、単体で80番ポートや443番ポートで待ち受けることもできます。
ただし、本番環境ではNginxを前段に置くことを推奨します。
理由は、SSL証明書の管理が一元化できること、静的ファイル配信をJavaから分離できること、将来的なスケールアウト（サーバー追加）が容易になることの3点です。
個人開発や社内ツール程度ならSpring Boot単体でも問題ありませんが、外部公開サービスではNginxとの連携がほぼ必須と考えてください。
ApacheとNginxどちらをJavaと組み合わせるべき？
2026年8月時点でも主流はNginxです。Apacheも長い歴史と実績がありますが、NginxはノンブロッキングI/Oによる高い同時接続処理性能と、設定ファイルのシンプルさで優位に立っています。
特にリバースプロキシとしての用途では、Nginxの方がメモリ消費が少なく、大量の同時接続を効率よく処理できます。
Apacheの .htaccess によるディレクトリ単位の設定が必要な場合を除き、新規構築ではNginxを選択するのが一般的です。
NginxとTomcatの違いは何ですか？
Nginxはリクエストを受け付けて振り分けるWebサーバー、Tomcatはそのリクエストを受けてJavaのサーブレット／JSPを実行するアプリケーションサーバーです。役割が異なるため競合ではなく、Nginxを前段、Tomcatを後段に置いて連携させるのが一般的です。
proxy_passで502 Bad Gatewayが出たときの対処法は？
まずJavaアプリが起動しているかを確認してください。502エラーの約8割はJavaアプリの起動失敗が原因で、メモリ不足によるOOM Killerの発動やポート競合が典型的な原因です。
NginxとJavaを連携させるメリットは何ですか？
セキュリティ・パフォーマンス・運用性の3点が主なメリットです。Javaアプリを直接インターネットに晒さずに済み、静的ファイル配信をNginxに任せて負荷を下げ、SSL証明書の管理も一元化できます。
SSL証明書はNginxとJavaどちらで管理すべきですか？
基本的にはNginx側で終端して管理する構成を推奨します。証明書の更新作業がNginx側だけで完結し、Javaアプリは暗号化処理の負荷から解放されます。決済系などPCI DSS準拠が求められる場合のみJava側での対応を検討してください。
Nginxのclient_max_body_sizeのデフォルト値はいくつですか？
デフォルトは1MBです。画像アップロード機能などで大きなファイルを扱う場合は、client_max_body_size 10M; のように明示的に上限を引き上げる設定が必要です。
Spring Boot以外（Servlet/JSPやTomcat単体）でもNginxとの連携方法は同じですか？
基本的には同じです。Nginxが転送先として意識するのはポート番号だけなので、Spring Boot・素のServlet/JSP・その他のJavaフレームワークのどれであっても、proxy_passの書き方は変わりません。ポート固定の設定方法（application.propertiesかserver.xml/web.xmlか）だけがフレームワークによって異なります。
