リバースプロキシについて

リバースプロキシとはWebサーバの構築・運用技術の1つで、espar を導入するサイトのCMS側で動的要素を含む場合に必要となる設定です。以下に、espar におけるリバースプロキシの役割について解説します。

静的化サイト特有の課題とリバースプロキシ

espar では、CMSで構築されたサイトを静的化して espar 公開用サーバにホスティングしています。これにより一般閲覧者によるサイトアクセスがCMS側に届くことはなく、原則 epsar 公開用サーバ側のみで処理を完結させられることになっています。詳しくはesaprについてをご覧下さい。

この構成には以下の二大メリットがあります。

• CMS本体側(上図の左端WordPress)にアクセスが届かなくなるためセキュリティが向上する
• 原則espar公開サーバ側(上図のStatic Web Server)が静的応答するため応答速度が高速化する

しかし、サイトの一部でCMS側に直接アクセスが届いて欲しいパスが存在する場合があります。それらは動的要素と呼ばれ、具体例として問い合わせフォームがあげられます。

多くの問い合わせフォームの実装では、送信・確認ボタンが押された瞬間にCMS側のPHPプログラムやプラグインが動作することが期待されています。(PHP等のプログラムで入力値のチェックやメール送信処理を行うため)

問い合わせフォームのあるページは静的化させただけでは動作しなくなるため、確認/送信ボタンが押された瞬間に限りespar公開サーバ側で処理をせず、CMS側にボタンがクリックされたことを知らせて代わりに処理を行なって貰う必要があります。リバースプロキシは、これを実現するための技術です。

espar導入サイトにおけるリバースプロキシと考え方

リバースプロキシの設定をするということは、espar 公開サーバ側に「穴を開ける」ことを意味します。

設定をしたパスに限定されますが、CMSサーバをそのままインターネットに露出した状態にするのと実質変わらないため、安全性と高速性が犠牲になるデメリットがあることに留意しなければなりません。リバースプロキシのメリット・デメリットを並べると以下の通りです。

メリット	CMS単体でサイト公開する時と同じように実装ができる。 使い慣れた手法がそのまま使えるので楽。考慮することも少ない
デメリット	静的化のメリットである安全性と高速応答が享受できない

CMSを使ったWebサイトで、安全性と高速性を理論上最高レベルで達成する方法は、

• 静的化を行ない
• 別サーバにホスティングし
• 閲覧者からのアクセス応答を別サーバ側で完結させ
• 閲覧者からのアクセスがCMS側に一切届かなくてもサイト全体を機能させる

という4つをサイト内の全てのURLで満たすことです。

リバースプロキシを設定するとこれを満たせなくなります。しかし、この4項目を全てのURLで満たす(つまりリバースプロキシの設定が100%無くせる理想系。完全静的サイトと呼びます)に到達できることは極めて稀であり、サイト内に数百・数千とあるURLのうち1,2個のURLは「穴を開ける」必要があることが大半です。実際、espar導入済みサイトで完全静的サイトとなっている例はそれほど多くはありません。

これは、静的化技術がまだ一般的とは言えないこと、Webサイトが複数サーバで機能する構成も一般的ではないこと、制作担当者様がリバースプロキシのような高度なWebサーバ技術に触れる機会が少ないこと、等が理由で完全静的サイト前提のCMS構築が比較的困難だからだと思われます。

espar導入時のリバースプロキシ設定

上述の背景をふまえ、esparを新規導入頂く際にはリバースプロキシが必要なパスを半自動で抽出し、初期構築時から弊社で設定を行うようにしています。理想論を掲げリバースプロキシを不要とするようCMS側改修の依頼や提案をすることは原則ありません。既存サイトへのespar導入でも、新サイトやリニューアルなどの新規構築サイトにesparを導入頂く場合でも変わりません。

基本的にどのようなサイトでも機能するように設定致しますが、リバースプロキシの設定が必要なパスがサイト内の広範囲に及んでしまい、そもそも espar を導入する意味がないと判断されるサイトについては、設定如何の前にその旨をお伝えします。例えば以下のようなサイトが該当します。

• リアルタイムに在庫表示反映が必要なECサイト
• サイト全体でログインを必要とする会員サイト
• 常にページアクセスの度にCMS側のPHPプログラムの動作が必要なサイト

このようなサイトではほぼ全てのURLでリバースプロキシの設定が必要となるため、一般的に(espar に限らず)静的化ソリューションを導入することは不適切であると言えます。

リバースプロキシの設定追加

有償で新たなリバースプロキシ設定をお受けすることが可能です。以下の手順で手続きをお願い致します。

1. CMS側で機能実装して頂く
2. CMS側だけでまず1の実装した機能が完全に動作することを確認して頂く
3. esparテスト環境を使って実際に静的化をして頂く
4. 1で実装し2で確認したが静的化すると機能しないことを確認して頂く(つまりリバースプロキシが必要)
5. 弊社に4のパスをルート相対パスでお知らせ頂く
6. 4で頂いたパスについて、まずesparテスト環境でリバースプロキシを設定させて頂く(弊社)
7. 4で機能しなかったものが機能するようになっていることを確認頂き結果をご連絡頂く
8. 6で行なった設定と同じ設定をespar本番環境で設定させて頂く(弊社)
9. espar本番環境で静的化を実施頂く

例えば、サイト https://www.example.com/ でCMS側で新たに問い合わせフォームのページ https://www.example.com/form/ というページを追加した場合、上記の手順5では /form/ をお知らせください。手順6 にて /form/ へのアクセスはCMS側に直接届くようにリバースプロキシを設定します。(つまりespar公開サーバ側に穴を開けます)

2.の事前確認は「必ず」行なって下さい。CMS側で完全に動作しない場合、静的化しても動作しません。

リバースプロキシで追加できない設定

リバースプロキシ先として指定できるサーバは、静的化対象となるCMSサーバのみ となります。リバースプロキシをCMSサーバ以外の任意サーバに向けることはできませんので注意して下さい。具体的な例として以下のようなケースが該当します。

1. espar を導入したサイト https://www.example.com/ がある
2. 新たに https://www.example.com/page/ というページを作ることになった
3. しかし当該のページ /page/ は静的化元のCMS上で制作するわけではない
4. 既存の別サーバ(やSaaS)のURL https://test.biz/example/ というページを https://www.example.com/page/ としてユーザに見せたいと考えている

上記のような背景・要件を満たすためのリバースプロキシ設定依頼はお請けできません。これは、対象ページが正しく機能するかどうかをリバースプロキシ先ごとに都度検証・設定する必要があるからです。

リバースプロキシは、「設定さえすれば、そのページを自サイトのページとして見せられる」という単純なものではありません。以下に、一筋縄ではいかない典型例を示します。

1. https://test.biz/page/ (A) を https://www.example.com/page/ (B) として見えるようリバースプロキシ設定した
2. (A) のHTML中に <img src="/images/hoge.png"> といったルート相対パスで画像参照があった
3. https://www.example.com/ サイト内にもまた /images/hoge.png というリソースが既に存在し静的化対象となっていた

このような状況で https://www.example.com/page/ をブラウザ表示した時に、ページは想定どおりに表示されるでしょうか？

答えはNOです。なぜなら ページ内容のHTMLはリバースプロキシ設定により (A) 側にあるHTMLである一方で、HTML中の <img> タグ中に記載ある /images/hoge.png は、https://test.biz/images/hoge.png ではなく https://www.example.com/images/hoge.png になるからです。

このような事象を避ける為、リバースプロキシを向ける先を(元より想定されている)CMS側以外に向けるには多くの検証や設定調整が必要となります。以上が、設定不可とさせて頂いている理由です。やむを得ず必要な場合は、別料金でご対応は可能ですので担当者にお知らせ下さい。

リバースプロキシが必要となる例や判断方法

リバースプロキシが必要になる例として以下のものがあります。

実装種別	説明	WordPressでの例
問い合わせフォーム	submitボタン送信時のパス(具体的には form タグの action 値)で、CMS側のプログラムが発動する必要があります	ContactForm7, MW WP Form
リダイレクト	301や302等のHTTPステータス応答制御をCMS側で行いたい場合に必要となります。設定されるパスが予測不能なため、本機能に対応するには全パスをリバースプロキシ設定する必要があります。静的化ソリューションを導入する意味がなくなる可能性が極めて高いです。なお、espar導入サイトでのリダイレクトは、その旨ご依頼を頂いて espar 公開サーバ側に弊社が設定いたします(有償/約1営業日)	Redirection
FAQ	質問(Q)に対する回答(A)を非同期通信でCMS本体から取得する実装の場合には必要となります。	Ultimate FAQ

上記以外も含め、esparの新規導入時には弊社でリバースプロキシの必要有無やパス抽出を行いますが、導入後の追加についてはお客様または制作会社様にて確認をお願いしています。

CMSのバージョンや、使用するプラグイン、実装するプログラムのPHPソースコード等から弊社が判断することはできかねます。

サイトにおけるそれぞれの挙動や役割は制作側が把握している筈であり弊社には判断が難しいこと、またesparが低価格の月額サービスで都度個別案件の個別機能を調査できないことが主な理由です。ご了承ください。 ただし有償での調査対応は可能です。必要な場合は、弊社担当にお知らせください。

リバースプロキシの設定を回避する方法

上述の通り、CMSで構築したサイトの安全性と高速性を理論上最高レベルに引き上げるには、

• 静的化を行ない
• 別サーバにホスティングし
• 閲覧者からのアクセス応答を別サーバ側で完結させ
• 閲覧者からのアクセスがCMS側に一切届かなくてもサイト全体を機能させる

の4つをサイト内の全パスで満たす必要があります。しかし、この条件を満たせない要素としてしばしば登場するのが「問い合わせフォーム」と「サイト内検索」です。これら要素が必要なサイトでも、上記4項目を満たし続けられるよう弊社では以下ツールの使用を推奨しています。

	ツール名	開発元	説明
問い合わせフォーム	espar form	feedtailor	PHPやCMSやプラグインが不要で、JavaScriptのみで問い合わせフォームを動作させる仕組み。Google Analytics のような埋め込みコードを貼り付けてフォームのhtmlコードを調整するだけでフォームが動作する。espar 導入サイトに限らず静的化サイトを対象に提供
サイト内検索	algoria	algoria	JavaScriptで実装ができ静的サイトでもサイト内検索が機能する高速検索エンジン。React や Vue 等のコンポーネントもあり

espar form の採用をご検討頂く場合、弊社担当にその旨をお知らせください。

HTML/CSS/JavaScript の基本技術をお持ちであることが前提ですが、基礎的な知識だけで簡単に問い合わせフォームをどうさせることができます。サイト内検索のための algoria の技術サポートは一切行なっておりませんのでご了承ください。