リバースプロキシを使用して、あるサブディレクトリからWordPressウェブサイトを読み込みながら、ルートドメインから別のウェブサイトを読み込むことができます

リバースプロキシは、特定のサブディレクトリへのリクエストを別のサーバーに送信するようサーバーに誘導するウェブサーバーに追加された一連のルールでできたものです。

まず、リバースプロキシの用途をよりよく理解するための例を確認してみましょう。例えば、example.comというWordPressでないウェブサイトがあるが、そのブルグのエンジンとしてWordPressを使用したいとします。さらに、そのブログをexample.com/blogにしたくて、KinstaなどのマネージドWordPressホスティング会社を使ってホスティングしたいとします。

これを実現するには、example.comをホスティングするウェブサーバーで/blogサブディレクトリへのすべてのリクエストをWordPressベースの/blogウェブサイトをホスティングする別のウェブサーバーに転送するようウェブサーバーに誘導するリバースプロキシルールを設定する必要があります。

リバースプロキシアドオン

Kinstaでは、リバースプロキシを使用してサブディレクトリからWordPressを読み込むことまたは、ウェブサイトのサブディレクトリが外部サーバーを指すように設定することも利用可能になっています。ただし、リバースプロキシの設定とサポートは難しく、リバースプロキシを使用するウェブサイトが標準のWordPressインストールよりもかなり多量のサポートを必要としている場合が多いです。

このため、Kinstaに設定やサポートを求められたリバースプロキシごとに、月額料金50ドルのかかるアドオンが請求されます。

また、リバースプロキシの初期設定には最大1営業日かかります。 場合によっては、非標準のユースケースでリバースプロキシが適切に機能するために、Kinstaのサポートチームとのさらなる問い合わせが必要になる場合があります。

リバースプロキシのユースケース

Kinstaには、リバースプロキシのユースケースが3種類あります。これらのユースケースを理解するには、最初にメインサイトとプロキシサイトの2つの用語を定義する必要があります。

  • メインサイトは、ルートドメインで読み込まれるウェブサイトです。
  • プロキシサイトは、サブディレクトリからリバースプロキシ経由で読み込まれるウェブサイトです。

上記の例に戻ると、example.comがメインサイトになり、example.com/blogがプロキシサイトになります。

上記の定義を理解した上で、Kinstaでのリバースプロキシのユースケースの3種類を次に示します。

  • メインサイトとプロキシサイトの両方がKinstaでホスティングされている:メインサイトであるexample.comとプロキシサイトであるexample.com/blogは両方ともKinstaでホスティングされています。そうすると、example.comで一つのWordPressインストールを使用し、example.com/blogでもう一つの独立したWordPressインストールを使用することができます。
  • プロキシサイトがKinstaでホスティングされている:メインサイトであるexample.comがKinstaでホスティングされていないが、プロキシサイトであるexample.com/blogはKinstaでホスティングされています。そうすると、example.com/blogを使用するWordPressインストールがKinstaでホスティングされていても、メインサイトが他社でホスティングされます。
  • メインサイトがKinstaでホスティングされている:メインサイトであるexample.comがKinstaでホスティングされているが、プロキシサイトであるexample.com/blogはKinstaでホスティングされていません。そうすると、example.comを使用するWordPressインストールがKinstaでホスティングされていても、ブログのサブディレクトリが他社でホスティングされます。

それでは、各オプションの詳細を確認しましょう。特に、各おプシンに対するKinstaのサポートの範囲についてご説明します。

リバースプロキシサーバーの一例

リバースプロキシサーバーの一例

メインサイトとプロキシサイトの両方がKinstaでホスティングされている

両方のウェブサイトがKinstaでホスティングされている場合、Kinstaのサポートチームは、メインサイトの必要なリバースプロキシルールと、プロキシサイトがリバースプロキシを経由して読み込まれるようになることが設定できます。メインサイトとプロキシサイトの両方が同じデータセンターを使用する必要があることをご了承ください。 さらに、Kinstaがウェブサイトを移動するため、リバースプロキシの設定中に短いダウンタイムが発生する可能性があります。

このシナリオにおけるお客様の責任範囲を以下の通りとします。

  • 両方のウェブサイトをKinstaの環境に移行すること(または、ウェブサイトに対するKinstaへの移行のマイグレーション申請書を送信すること)
  • Kinstaのサポートチームにドメイン構成の明確な情報を提供すること
  • リバースプロキシの設定ごとに約1営業日がかかることを了承すること

このシナリオにおけるKinstaの責任範囲を以下の通りとします。

  • メインサイトの必要なリバースプロキシルールを設定すること
  • プロキシサイトをリバースプロキシをを経由してして読み込まれるように設定すること

プロキシサイトのみがKinstaでホスティングされている

注:プロキシサイトのみがKinstaでホスティングされている場合、プロキシサーバーのIPアドレスを提供していただく上で、ヘッダーが当社の標準であるNginxリバースプロキシルールにリスト化されているようにプロキシサーバーを設定する必要があります。そうしないと、当社の分析システムが適切に機能しなくて、プロキシサーバーのIPアドレスがブラックリストに登録されることがあります。

プロキシサイトのみがKinstaでホスティングされている場合、リバースプロキシはメインサイトをホスティングするサーバー上で設定する必要があるため、リバースプロキシ自体の設定はKinstaが対応できません。このシナリオにおけるKinstaの責任範囲はプロキシサイトをリバースプロキシをを経由してして読み込みできる状態にする設定に限定されます。

このシナリオにおけるお客様の責任範囲を以下の通りとします。

  • プロキシサイトをKinstaの環境に移行すること(または、ウェブサイトに対するKinstaへの移行のマイグレーション申請書を送信すること)
  • リバースプロキシにより用される予定のあるウェブサイトにドメインを追加すること。プロキシサイトにアクセスするには、リバースプロキシに指し先のドメインを設定する必要があります。 この目的にはサブドメインが使用されることが多いです。たとえば、blog.example.comは、example.com/blogで読み込まれるリバースプロキシとして使用されます。
  • Kinstaのサポートチームにドメイン構成の明確な情報を提供すること
  • プロキシサイトがリバースプロキシをを経由してして読み込まれるように構成するには約1営業日がかかることを了承すること
  • プロキシサイトの設定が完了した上で、メインサイトがホスティングされているサーバー上にリバースプロキシを作成すること

前述のように、このシナリオにおけるKinstaの責任範囲はプロキシサイトをリバースプロキシをを経由してして読み込みできる状態にする設定に限定されます。

メインサイトのみがKinstaでホスティングされている

メインサイトのみがKinstaでホスティングされている場合、Kinstaの責任範囲はプロキシサイト(他社でホスティング)を読み込むためのリバースプロキシの設定に限定されます。Kinstaは、本記事に記載されている標準のリバースプロキシルールを追加します。お客様のご希望があればルールがカスタマイズできます。

このシナリオにおけるお客様の責任範囲はプロキシサイトをリバースプロキシをを経由してして読み込みできる状態に設定して、プロキシサイトの適切な読み込みができない場合にリバースプロキシルールの調整を当社に要求することです。

プロキシサイトの使用制限

Kinstaでは、リバースプロキシについて以下の使用制限があります。

まず、Kinstaはマルチサイトのリバースプロキシをを経由してしての使用をサポートしていないことをご了承ください。

さらに、リバースプロキシをを経由してして読み込まれるウェブサイトのバックアップを復元するか、ステージングサイトを公開すると、プロキシサイトが適切に読み込まれないようになる可能性があります。プロキシサイトをご利用の場合、上記の対策をトラフィックの少ない時間帯に予定し、実行する前にKinstaのサポートチームに相談することをお勧めします。

Kinstaでは、プロキシサイトをご利用の場合、ステージングをテスト環境として使用した方がベストです。ステージングでのテストが完了した後、ステージングを本番サイトに公開するのではなく、本番サイトにも同じ変更を加えた方が最もしやすい手順でしょう。また、プロキシサイトのバックアップの復元は、変更を手動でロールバックできない場合のみの緊急対策にした方が良いでしょう。

上記の使用制限のため、バックアップを復元したり、ステージングサイトを定期的に本番サイトに公開したりする場合は、プロキシサイトの使用をお勧めしません。

プロキシサイトの検討する価値のある代替案の一つは、WordPressサブディレクトリのマルチサイトインストールです。

メインサイトのリバースプロキシ構成

リバースプロキシをを経由してしてサブディレクトリを読み込む場合、メインサイトには2つの重要な注意事項があります。

  • 対象のサブディレクトリごとにリバースプロキシルールを追加する必要があります。
  • 上記のサブディレクトリに対するすべてのリクエストがプロキシサイトに転送されるため、メインサイトはこれらのサブディレクトリを一切使用できません。

Kinstaがリバースプロキシを経由してウェブサイトを読み込むために使用する標準のNginxリバースプロキシルールは下記のとおりです。

location ^~ /subdirectory/ {
  proxy_pass http://subdirectory.domain.com;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
}

/subdirectory/プレースホルダーの代わりに実際のサブディレクトリが使用されます。または、http://subdirectory.domain.comがプロキシサイトでリバースプロキシの指し先のドメインと一致するように変更されます。

プロキシサイトの構成

リバースプロキシを経由してウェブサイトを読み込むには、次の変更を行う必要があります。

  • サーバーのディレクトリパスに、ウェブサイト該当のサブディレクトリに移動したすべてのファイルの読み込みに使用されるサブディレクトリと一致するサブディレクトリを追加する必要があります。
  • ウェブサイトのルートを新しいサブディレクトリにするようにウェブサーバーの構成を更新する必要があります。さらに、各着信要求の要求のURIからサブディレクトリを削除するようにサーバー構成に書き換えを追加する必要があります。
  • プロキシサイトのデータベースのすべてのURLは、本番サイトのURL(example.com/blogなど)と一致するように更新する必要があります。
  • ウェブサイトのwp-config.php fileファイルは、メインサイトのURL(今回の例ではexample.com)を指す$_SERVER['HTTP_HOST']定義で更新する必要があります。
  • ウェブサイトがhttpsを使用して読み込まれるように強制される場合、リダイレクトループが発生しないように、wp-config.phpに追加の定義を追加する必要があります。

必須の書き換えルールのため、プロキシサイトでは、プロキシサイトが読み込まれるサブディレクトリのURLを複製するURLを作成しない方がいいことにご注意ください。たとえば、example.com/blogのプロキシサイトでは、example.com/blog/blogというページやディレクトリを作成しないでください。

まとめ

Kinstaではリバースプロキシをご利用いただけます。当社のインフラストラクチャのこのようなご利用の実績があります。ただし、リバースプロキシの使用がもたらす追加の技術的な複雑さと、Kinstaのステージングシステムとバックアップシステムの使用に対する影響を理解しておくことが重要です。

リバースプロキシがお客様の現在のニーズの最適なソリューションであると思われる場合は、MyKinsta のチャット機能を利用して、Kinstaのサポートチームまでお問い合わせください。


このチュートリアルが面白かった方なら、当社のサポートも大好きでしょう。Kinstaのすべてのホスティングプランには、ベテランのWordPress開発者とエンジニアによる24時間365日のサポートが付いています。フォーチュン500のお客様をサポートしているチームとチャットしませんか。当社のプランをご確認ください。