ウェブサーバーと HTTPS とは何か — Nginx がする仕事

届いたことと答えが決まったことは違う

前回、リクエストはどのコンピュータの何番の扉へ行くと述べた。だが扉の前まで来たからといって、何を受け取るかが決まるわけではない。

そのコンピュータの中にはフォルダも多く、動いているプログラムも複数ある。人がモニターで開くのと違い、リクエストには何を受け取るかが規則としてあらかじめ書かれていなければならない。

その規則を書いておき実際に執行するのがウェブサーバーだ。80 番の扉から来た要求にはこのフォルダのファイルを渡す。この住所への要求は中で動いているプログラムへ回し、その答えを代わりに返す。こうした文の集まりがウェブサーバーの設定である。

最も広く使われているのが Nginx で、エンジンエックスと読む。

443 番の扉から来た要求なら
  この証明書と鍵で暗号化された接続を結ぶ

  住所が /api で始まるなら
    中の 8000 番で動いているバックエンドへ回す

  それ以外の住所なら
    このフォルダにあるファイルをそのまま渡す

なぜ中へ回す必要があるのか

要求を受けて中のプログラムへ渡し、その答えを代わりに返す方式をリバースプロキシという。名前は難しいが、していることは仲介だ。

なぜ直接受けずに仲介を置くのか。バックエンドのプログラムはたいてい 8000 番のような内側のポートで動き、外へは開いていない。外へ開く扉は 443 番の一つにして、その中で住所によって振り分けるほうが管理が単純である。

この構造のおかげで一台のサーバーで複数のサービスを動かせる。住所が /api で始まればバックエンドへ、それ以外なら画面のファイルへ、という具合だ。前回サブドメインで振り分けると述べたのと同じことを、住所の経路でも行える。

HTTPS はこの層で決まる

HTTP はやり取りする内容がそのまま流れる。途中で誰かが見れば全部見える。HTTPS はその内容を暗号化して送る。アドレスバーの鍵アイコンがその印だ。

暗号化には証明書と鍵が要る。証明書はこのドメインが本当にこのサーバーのものだと第三者が保証する文書で、鍵はその暗号化に使う秘密の値である。どちらもサーバーのどこかにファイルとして置かれる。

そのファイルをどこから読みどの接続に適用するかを書く場所が、まさにウェブサーバーの設定だ。だから HTTPS は別個の技術ではなく、この層の設定項目として入ってくる。

証明書には有効期限がある。切れればブラウザが警告を出す。今は自動更新を仕込むのが基本だが、更新が失敗していたのに誰も気づかず期限日に表面化する話はいまだによくある。

デプロイサービスを使っても知っておく理由

Vercel や Railway のようなデプロイサービスを使えば、この設定を直接触ることはほとんどない。リポジトリをつなぐだけで証明書の発行も更新もやってくれる。

それでも知っておく理由は二つある。一つは自分でサーバーを借りて上げるとき、この層が丸ごと自分の担当になるからだ。もう一つは、問題が起きたときにどの層かを切り分けられなければならないからである。

502 や 504 という数字を見たなら、たいていこの層だ。門番は生きて応答しているのに、中のプログラムが答えないか、答えが遅すぎる状態である。画面がまったく出ないのとは原因が違う。前回の三つを全部確かめてもだめならここを見る。