リバースプロキシ。

先週はリバースプロキシと格闘した一週間。
結局使わない方向にしたのだけど、折角格闘したので覚え書いておく。

これまで意識してこなかったのだけど、リバースプロキシの実装には大きく2パターンあるみたい。
1つが「パスベース」の実装で、もう一つが「バーチャルホストベース」の実装。

■パスベース

ドメインは一緒で、特定パスへのアクセスのみフロントエンドサーバがリバースプロキシとして動作。

■バーチャルホストベース

フロンドエンドサーバへの処理要求とバックエンドサーバへの処理要求とでドメインを分ける*1。

で、今回格闘の原因となったのが前者のパスベースによるリバースプロキシの実装。
そもそもリバースプロキシ自体はレスポンスボディの面倒を見てくれない*2。
例えば上記のパスベースの図のように、「/backend」へのアクセスがバックエンドサーバの「/」になる構成だとして、バックエンドが返送するHTMLドキュメントに以下の記載があったとする*3。

<link rel="stylesheet" href="/style.css">

するとクライアントから見たCSSのパスは「http://www.example.com/style.css」となるんだけど、当然ながらこれではバックエンドサーバに処理が行かない。

考えてみれば至極当然なのだけれど、延々と格闘していたという。
パスベースでリバースプロキシを実装する時は、ここでいうバックエンドサーバの作り方を考えないと行けないという教訓を得たのでまあ良しとしよう。

ちなみに今回は、

• バックエンドサーバが出来合いで手が入れられない
• グローバルIPが余ってた
• そもそもの実装理由も、公開に当たって適当なURLをつける必要があっただけ*4

だったので、リバースプロキシを使わずサブドメインで対応することに。

何はともあれ、めでだしめでたし。

*1:厳密にはドメインは同じでポートを分ける方法もこれに入るのだろうけど、ここでは割愛。

*2:干渉しないという表現の方が正しいのかも。

*3:最終的に返送するのは勿論リバースプロキシ（図中の※の部分）。

*4:既にあるWebサイトURLのサブディレクトリ的な形でつけようとしていた。