はじめに

「うちではNginxをリバースプロキシで利用してて、変なアクセス切ったりしてる。あとSSL終端もNginxなんだよね」

数ヶ月前、構成図を見ながら先輩がドヤ顔で言い放ったこの言葉。
当時の私は「……なるほどですね！（何ひとつ分からない）」と引きつった笑顔で返すことしかできませんでした。「リバースプロキシ？ SSL終端？呪文かな？」と本気で思っていた、あの悲しい記憶。

しかし、実際に自分でサーバーを立ててNginxを触ってみた今、あの呪文の本当の意味と、なぜ実務でNginxが「デフォルト構成」として君臨しているのかがようやく理解できました。

今回は、当時の私と同じように「先輩のNginx語録」に震えている初心者の方に向けて、呪文の意味を分かりやすく翻訳・解説します！

先輩の呪文その1：「Nginxをリバースプロキシで利用してる」

(イメージ：すべてのアクセスを最前線で受け止めるNginx)

これってどういう意味？

一言でいうと、Nginxを「受付係・交通整理係」として使っているという意味です。

実務のWebサービスでは、裏側でGoやNode.js、Pythonなどの「アプリケーション本体」が動いています。
しかし、インターネットからのアクセス（ユーザー）を、直接そのアプリに触らせることはしません。

ユーザー → Nginx → アプリ

外部からのアクセスは、すべてNginxが一度受け止めます。
Nginxがリクエストの内容を見て、「あ、これはアプリ側に渡すね」「画像だから自分の持ってるファイルを返すね」と交通整理（＝ルーティング）をしてくれる。これがリバースプロキシの役割です。
Nginxという強力な「境界線」を設けることで、アプリは自分本来の仕事（データの処理など）に集中できるんです。

先輩の呪文その2：「変なアクセス切ったりしてる」

これってどういう意味？

一言でいうと、Nginxを「最強の門番」として使い、入口で攻撃や迷惑客をブロックしているという意味です。

先ほど「Nginxがすべてのアクセスを一度受け止める」と言いました。これがセキュリティ上、めちゃくちゃ強いんです。
例えばNginxの設定ファイル（nginx.conf）を少し書くだけで、次のようなことができます。

IP制限: 「社内のIPアドレスからのアクセスしか通さないよ」
特定パスの制限: 「/admin へのアクセスは、Basic認証を通った人だけ！」
レート制限: 「1秒間に100回もリクエスト送ってくるやつは、DoS攻撃とみなして遮断！」
Bot弾き: 「User-Agentを見て、質の悪いクローラーは無視」

これらをアプリ側に届く前に止めるのが最大のポイントです。
アプリのコードの中に「もしIPが〜だったら…」という防御ロジックを書かなくて済みますし、アプリ側の負荷も上がりません。Nginxが最前線で切り捨ててくれるからです。

先輩の呪文その3：「SSL終端なんだよね」

これってどういう意味？

当時の私が一番「？？？」となった言葉ですが、一言でいうと「HTTPSの暗号化を解く面倒な作業は、ぜんぶ最前線のNginxで終わらせる（終端する）」という意味です。

通信の流れを見ると一目瞭然です。

(HTTPS通信)                (HTTP通信)
ユーザー ⇄ [暗号化/複合化] ⇄ Nginx ｜HTTP｜ ⇄ アプリ

ブラウザ〜 Nginx間：HTTPSでバッチリ暗号化して通信する。
Nginx 〜アプリ間：平文（普通のHTTP）で通信する。

「え、アプリまで暗号化しなくていいの？」と思うかもしれませんが、Nginxとアプリは同じサーバー内（あるいは安全な内部ネットワーク内）にいるため、暗号化しなくても基本的には安全です。

この構成の何が嬉しいかというと、アプリ側は「SSL証明書の管理」や「暗号化の計算（TLS）」を一切考えなくてよくなるんです。
証明書の更新時期が来ても、いじるのはNginxの設定だけ。アプリのコードや設定には一切触れずに済みます。エンジニアにとって、これはとんでもないメリットです。

全て繋がった！実務の「超・王道構成」とは

先輩の言っていた3つの呪文をまとめると、現場のサーバー構成図はこうなります。

[ Internet ]
     ↓ (HTTPSでアクセス)
+-------------------+
|      Nginx        | ← ここで全部やる！
| ・リバースプロキシ|
| ・アクセス制御    |
| ・SSL終端         |
+-------------------+
     ↓ (安全なHTTPアクセス)
+-------------------+
| アプリケーション  | ← ロジックに集中！
| (Node, Go, Py...) |
+-------------------+
     ↓
+-------------------+
|  データベース     |
| (PostgreSQL etc)  |
+-------------------+

これこそが、現在のWeb開発における「実務のデフォルト（王道）構成」です。

おわりに：この仕組みが分かると見える世界

「呪文」の意味が分かった今、トラブルが起きた時の見え方が劇的に変わりました。

「画面が真っ白に？…待てよ、エラーログを見るべきはNginx側か？アプリ側か？」と切り分けができる。
「特定のIPだけ弾きたい？じゃあアプリ側を修正するより、Nginxでサクッと弾いたほうがシンプルだな」と設計できる。
「SSL証明書の期限が切れる！……でもNginxだけ触ればいいから余裕だね」と判断できる。

あの時、笑顔で誤魔化していた自分に教えてあげたいです。「お前、数ヶ月後にはNginxの設定ファイル書いてニヤニヤしてるぞ」と。

この記事が、どこかで当時の私のように「先輩のNginx語録」に怯えている誰かの助けになれば幸いです！