リバースプロキシは、ウェブサーバーの前段に配備され、オリジンサーバーに到達する前にすべてのリクエストを受け取ります。フォワードプロキシと同様の動きをしますが、ユーザーやクライアントが使用するフォワードプロキシとは異なり、リバースプロキシは、ウェブサーバーにより使用されます。通常、リバースプロキシはウェブサーバーのパフォーマンス、セキュリティ、信頼性を高めるために使用されます。

例えば、サーバーA上にexample.comドメインで稼働するWordPressでないサイトを構成し、異なるサーバーB上にexample.com/blogで稼働するWordPressを使用したブログを構成できます。これには、プライマリサイトのサーバーAにリバースプロキシを追加して、ブログへのリクエストを別のサーバー（KinstaのようなWordPress専用マネージドクラウドサーバーなど）にリダイレクトします。

今回の記事では、リバースプロキシサーバーの基礎と仕組み、主なメリット、WordPressサイトの高速化とセキュリティを確保する利用方法をご紹介します。

リバースプロキシとは

リバースプロキシサーバーを理解するには、まずはじめにその役割を知り、関連するすべての用語に慣れる必要があります。

通常、ドメイン名を入力したり、リンクをクリックしてウェブを閲覧すると、ブラウザやデバイスはサイトのサーバーに直接接続し、リソースのダウンロードを始めます。

通常のインターネットでの閲覧
通常のインターネットでの閲覧

閲覧するサイトから自分のIPアドレスを匿名化したい場合は、プロキシサーバーを利用して、まずすべてのリクエストをプロキシサーバーに送ります。プロキシサーバーは、リクエストをDNSリゾルバに転送した後、オリジンサーバーからサイトのリソースをダウンロードします。

その後、ブラウザやデバイスにリソースを伝えます。これを「フォワードプロキシ」と呼びます。

フォワードプロキシの動作
フォワードプロキシの動作

サイトからは、フォワードプロキシがリクエストを発信したように見えるため、発信元はサイトから完全に隠されます。

また、フォワードプロキシは、ユーザーのプライバシーを保護するだけでなく、主に地理的なコンテンツ制限の回避にも使用されます。例えば、自分の住んでいる地域でブロックされている動画を視聴したい場合、その動画が視聴可能なIPアドレスを持つフォワードプロキシを使用することで視聴できます。

フォワードプロキシは、仮想プライベートネットワーク（VPN）とほぼ同じ働きをしますが、それぞれ独自のユースケースを持つ別個の技術です（一部重なる部分もあります）。

リバースプロキシサーバーとフォワードプロキシサーバーの比較

リバースプロキシサーバーは、オリジンサーバーの前段で動作し、匿名性を維持し、セキュリティを強化します。これはユーザーやクライアントがフォワードプロキシを使用する目的と同じです。リバースプロキシにより、ユーザーやクライアントは、オリジンサーバーと直接通信しないことが保証されます。

リバースプロキシサーバーの動作
リバースプロキシサーバーの動作

フォワードプロキシとリバースプロキシの違いはわずかですが、動作は異なります。

両者の機能は重複しないため、一緒に動かすことができます。一般に、ユーザーやクライアントはフォワードプロキシを使用し、オリジンサーバーはリバースプロキシを使用します。

フォワードプロキシサーバーとリバースプロキシサーバーの比較
フォワードプロキシサーバーとリバースプロキシサーバーの比較

サーバー管理者はリバースプロキシの動作を制御できるため、これを利用して多くの有用な機能を有効にできます。

この記事の後半で、リバースプロキシの利点を挙げます。

リバースプロキシの必要性

多くの企業、特に大企業では、独自のニーズに合わせたオーダーメイドのサイトを構築しており、WordPressでは運用していません。例えば、銀行や保険のサイトなどが該当します。

また、WordPressをはじめとする追加ソフトウェアをインストールできない外部サービスでサイトを稼働している場合もあります。通常、このケースは中小規模の小売業者で多く、ShopifyなどのECプラットフォームを利用しています。

しかし、WordPressは強力なCMS機能を備えるため、オーダーメイドのサイトを持った大企業を含む、多くの企業が、WordPressを使用してブログを運営したいと考えるかもしれません。

この問題を回避する一つの方法として、メインサイトのサブドメインにWordPressをインストールし、ユーザーがメインサイトとブログを簡単に切り替えられるようなナビゲーションメニューを構成する方法があります。

しかし、サブドメインは独自ドメインとして動作するため、サイトのSEOに影響を与える可能性があります。Googleはサブドメインとサブディレクトリを同等に扱いますが、検索エンジンランキングのためにサイトを最適化する場合、サブドメインでの稼働は、サブディレクトリでの稼働よりも手間がかかります。

サイトでブログを運営する2つのアプローチ
サイトでブログを運営する2つのアプローチ

Googleは、サブドメインとサブディレクトリを同等に扱うことを再確認していますが、一部のSEO専門家はこれに納得していません。また、サイトのSEOに影響しないとしても、単純にサブディレクトリで稼働するサイトの方がメンテナンスは容易です。

そこでリバースプロキシを使用して、別のサーバーで稼働するサイトのブログにリクエストをリダイレクトできます。例えば、メインのサイトを自社サーバーで安全に運用し、KinstaのようなWordPress専用マネージドクラウドサーバーでWordPressブログを別個に稼働できます。

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

リバースプロキシを利用する主な利点の1つが、この1つのドメイン名での2つの異なるサイトの統一です。企業ブランドはサイトを整理してプロフェッショナルなイメージを保ち、信頼性を確保できます。

リバースプロキシを使用する利点

上の使用例以外にも、リバースプロキシには多くの利点があります。以下のセクションでその主な利点を説明します。

負荷分散

1日のユニーク訪問者数が数百万人に上るサイトでは、オリジンサーバー1台ですべての受信トラフィックを処理できません。このような場合、対応策として多数のサーバーで構成されたサーバープールに、トラフィックを賢く分散できます。通常は、すべてのサーバーが同じコンテンツを提供して単一障害点を排除し、サイトの信頼性を高めます。

リバースプロキシはこの設定に最適です。オリジンサーバーに到達する前に受信トラフィックを受け取り、オリジンサーバーが過負荷になったり、完全に故障した場合でも、サイトの機能に影響を与えることなく、他のサーバーにトラフィックを分散できます。

また、リバースプロキシは、受信したリクエストを、特定の機能に最適化された個々のサーバに送信することもできます。リバースプロキシは、すべてのサーバでのレスポンスを収集し、クライアントに返信します。

一般的なリバースプロキシは、主に負荷分散（ロードバランシング）の目的で使用されるため、「ロードバランサー」とも呼ばれます。

GSLB（広域負荷分散）

GSLB（広域負荷分散、Global Server Load Balancingの略）は、世界中に戦略的に配置した多くのサーバーにサイトのトラフィックを分散する、高度な負荷分散手法です。一般的には、クライアントサーバー間の最速転送時間に基づいてリバースプロキシがサーバーノードを選択する、エニーキャストルーティング技術で実行されます。

広域負荷分散は、サイトの信頼性やセキュリティを大幅に向上するだけでなく、レイテンシーや読み込み時間を短縮し、ユーザーエクスペリエンスを向上します。また、Spoon Feedingのような他のネットワーク最適化技術と併用することで、オリジンサーバーの計算資源をさらに解放します。

広域負荷分散は、サーバー上で手動で設定することもできますが、通常はCloudflareやKeyCDN（Kinsta CDNにも採用）などの専用CDNによって処理されます。Kinstaでは、高性能なサーバーインフラ上のロードバランサーを介して、プラットフォームでホストされているすべてのサイトを配信しています。

セキュリティの強化

リバースプロキシは、オリジンサーバーのIPアドレスやその他の特性を隠蔽します。このため、サイトのオリジンサーバーの匿名性は高く維持され、大幅にセキュリティを向上できます。

リバースプロキシは、メインのサーバーに到達する前にすべてのトラフィックを受信するため、攻撃者やハッカーが、サイトにDDoS攻撃などのセキュリティ的な脅威を与えることが難しくなります。

一般的なサイバー攻撃に対して、厳格なファイアウォールを使用し、より強固なセキュリティでリバースプロキシを保護できます。リバースプロキシがインストールされていない場合、マルウェアの除去や緩和作業の開始は困難になります。

HAProxyのようなリバースプロキシは、Basic HTTPアクセス認証を有効にしていないウェブサーバにこれを追加できます。また、リバースプロキシを利用して、様々な種類のリクエストに対する集中認証を追加できます。

強力なキャッシュ

リバースプロキシはウェブアクセラレーションの目的でも使用できます。静的コンテンツと動的コンテンツの両方をキャッシュすることでオリジンサーバーの負荷を軽減し、結果的にサイトを高速化します。

例えば、オリジンサーバーが米国にあり、欧州のユーザーがサイトにアクセスした場合、欧州のリバースプロキシサーバーからキャッシュ済みのサイトを提供できます。オリジンサーバーよりもリバースプロキシの方がユーザーに近いため、サイトの読み込み時間は短くなり、優れたパフォーマンスを発揮します。

VarnishとNginx FastCGIは、ウェブコンテンツのキャッシュに使用されるリバースプロキシの代表例です。

Kinstaをご利用の場合は、キャッシュについて心配する必要はありません。キャッシュに関する処理はすべて自動で行われ、さらにエッジキャッシュのような高度な機能も標準で利用できます。

優れた圧縮性能

サーバーからのレスポンスは、多くの帯域幅を使用します。クライアントに送信する前にサーバーのレスポンスをgzipなどで圧縮すると、必要な帯域幅が減り、ネットワーク上でのサーバーのレスポンスが速くなります。

リバースプロキシは、オリジンサーバーとクライアントの間に位置するため、サーバーのレスポンスを圧縮するのに最適です。

最適化されたSSLの暗号化

クライアントごとのSSL/TLSリクエストの暗号化と復号は、オリジンサーバーに非常に大きな負荷を掛けます。リバースプロキシは、この作業を代行することで、オリジンサーバーのリソースを、コンテンツの提供など他の重要な作業に充てられます。

また、SSL/TLSの暗号化、復号をオフロードすることで、オリジンサーバーから地理的に離れたクライアントのレイテンシーを軽減できるメリットもあります。

また、特殊なSSL/TLSアクセラレーションハードウェアを備えたリバースプロキシを選ぶことで、この作業をさらに最適化できます。この種のリバースプロキシは、「SSL/TLSターミネーションプロキシ」と呼ばれます。Varnishのような一部のサーバはSSL/TLSプロトコルをサポートしないため、SSL/TLSターミネーションリバースプロキシは、これらを通過するトラフィックの安全性の確保に役立ちます。

A/Bテストの改善

ほとんどのA/Bテストツールでは、外部のJavaScriptライブラリを使用して機能を読み込む必要があります。しかし、サードパーティのスクリプトを読み込むと、ページのロードが遅くなり、ユーザーにぎこちない印象を与えます。

代わりにリバースプロキシを使用して、サーバレベルで2つの独立したフローを作成できます。例えば、Nginxのsplit_clientsやsticky routeメソッドを使用して、トラフィックのリダイレクトを制御できます。

リバースプロキシを使用したA/Bテストの実行については、NginxやfreeCodeCampの解説を参考にしてください。

トラフィックの監視とログ取得

リバースプロキシは、通過するすべてのリクエストを捕捉します。そのため、トラフィックを監視し、ログを取得するセントラルハブとして使用できます。複数のウェブサーバーを使用してサイトのすべてのコンポーネントを稼働している場合も、リバースプロキシを使えば、サイトからのすべての送受信データを簡単に監視できます。

おすすめのリバースプロキシ

W3Techsによると、約83％のサイトはリバースプロキシサービスを使用していません。

サイトで使用されるリバースプロキシの統計（出典：W3Techs.com）
サイトで使用されるリバースプロキシの統計（出典：W3Techs.com）

上に挙げたリバースプロキシを使用している17％のサイトのほとんどはCDNです。これは、多くのリバースプロキシが、安全性のためにデフォルトで存在を隠しているためです。したがって、W3Techsのようなサイト監視サービスに頼っても、どのリバースプロキシが人気かを調べることはできません。

Kinstaの調査と経験では、現在使用されている最も人気のリバースプロキシは以下のとおりです。

Nginx

Nginxは、オープンソースのウェブサーバですが、リバースプロキシとしても機能します。サイトのサーバーとして使用される以外に、最も広く使用されているリバースプロキシおよび負荷分散ソリューションの1つです。Netcraftによると、2019年12月には4億7,900万台以上のウェブサーバーがNginxを使用しており、ウェブサーバーの市場シェアではトップです。

全サイトにおけるウェブサーバーのシェア
全サイトにおけるウェブサーバーのシェア（出典：Netcraft）

Nginxには、これまで説明してきたリバースプロキシのメリットに加えて、さまざまな利点があります。サイトのパフォーマンス、セキュリティ、信頼性、スケーラビリティの向上に役立ちます。Nginxは設定ファイルを使用して構成でき、稼働中でも設定を再読み込みできます。Kinstaでは、Nginxリバースプロキシを有料アドオンで利用可能です。

さらに、商用製品であるNginx Plusを利用すれば、APIベースの構成オプションや大企業サイトに適した、その他の機能も利用できます。

KinstaはすべてのサイトをNginxで稼働しています。Review SignalのTop Tier Web Hostingステータスにおいて、Kinstaは比較対象のすべてのカテゴリでランクインしています。Nginxを使用する他の企業には、MaxCDN、Cloudflare、Netflixがあります。

基本的なリバースプロキシとしてのNginxの設定はシンプルです。また、Nginxは様々なディレクティブを提供し、要求に合わせてサーバのリバースプロキシをカスタマイズできます。詳細な方法については、後のセクションで説明します。また、Kinstaのお客様には、Kinstaで稼働するサイトでリバースプロキシを使用する方法を同じセクションでご紹介します。

Varnish

Varnishは、キャッシュエンジンを内蔵したオープンソースのHTTPリバースプロキシです。Varnishは、主に動的コンテンツを提供する高トラフィックのサイト向けに設計されています。また、Varnishはロードバランサー、ウェブアプリファイアウォール（WAF）、エッジ認証認可サーバーとしても利用できます。

Varnishは、最新のLinuxやFreeBSDで動作し、主にNginxやApacheウェブサーバーの前段に使用されます。Varnishのパワフルで柔軟性の高いVarnish Configuration Language（VCL）では、HTTPリクエスト処理、キャッシュ、1つ以上のウェブサーバへの接続など、様々な機能を定義できます。

このため、多くのCDNでは、コンテンツを迅速に配信する主要な基盤としてVarnishを使用しています。

Varnishはまた、Edge Side Includes（ESI）もサポートします。これは、あるウェブページのセクションを他のウェブページで再利用するための言語です。サイトの様々なページで繰り返し同じコンテンツを使用する場合、ESIは頻繁に使用されるセクションをキャッシュすることで、サイトのページ読み込み時間を短縮できます。

Varnishは様々なモジュール（VMOD）で拡張できます。WordPressのリバースプロキシとしてVarnishを設定する方法については、Varnishの公式チュートリアルをご覧ください。

Apache Traffic Server

Apache Traffic Serverは、オープンソースのキャッシュプロキシサーバーです。高速でスケーラブルな機能が人気です。元々は、Yahoo!が開発した商用製品でしたが、オープンソース化し、メンテナンスのため、Apache Foundationに寄贈されました。

Comcast、Akamai、LinkedIn、Yahoo、Appleなどの主要なコンテンツネットワークやCDNが自社テクノロジーの強化に、Apache Traffic Serverを使用しています。

また、HTTPサーバーデーモンであるApache HTTP Server（Apache httpd）を使用しても、ウェブサーバーにリバースプロキシを設定できます。基本的なウェブサーバーとしての役割以外にも、静的コンテンツや動的コンテンツをユーザーに提供できます。この記事の後半では、Apacheをリバースプロキシとして設定する方法をご紹介します。

HAProxy

HAProxyは、オープンソースのリバースプロキシおよびロードバランサーです。HAProxyは、Linuxディストリビューションやクラウドプラットフォームを含む、既存のほとんどのウェブサーバーアーキテクチャと統合できるように設計されています。Nginxと同様に、イベント駆動型のI/Oモデルを採用し、複数のワーカープロセスにリクエストを分割できます。

HAProxyは、HTTPリクエストに対して、高負荷時にも非常に優れたパフォーマンスを発揮します。Airbnb、Reddit、Instagram、Stack Overflow、Tumblr、GitHub、Imgurなど、インターネット上でもトラフィックの多いサイトが、効率的なサイトの配信にHAProxyを使用しています。

HAProxyの実装方法については、この記事の範囲を超えるため説明しませんが、仕組みについては公式ドキュメントをご参照ください。

注）TraefikとEnvoyは、HAProxyに代わるオープンソース製品です。どちらも高性能なリバースプロキシとロードバランサーで、多くの高度な機能を備えています。

その他の人気の高いリバースプロキシには、AWS Elastic Load Balancer、GLBC、DigitalOcean Load Balancer、Google Cloud Load Balancerがあります。現在、使用されている主なリバースプロキシとロードバランサーのリストについては、Stackshare.ioをご覧ください。

WordPressサイトでのリバースプロキシ

Kinstaでのサーバーサービスを含むWordPressサイトのリバースプロキシの利用には、主に3つのユースケースがあります。

「メインサイト」と「プロキシサイト」のロード
「メインサイト」と「プロキシサイト」のロード

現在、WordPressサイトで最もよく使われているリバースプロキシはNginxのため、ここでもNginxを例に説明します。ただし、同じ基本原則は、他のリバースプロキシにも当てはまります。

リバースプロキシのインストール、設定、サポートは簡単ではありません。このため、Kinstaでは、リバースプロキシごとに設定をサポートするサブスクリプション型アドオンを月額50ドルで提供しています。詳細については、Kinstaのカスタマーサポートにお問い合わせください。

1. メインサイトとプロキシサイトを同じサーバー上で稼働する

メインサイトとプロキシサイトの両方を同じサーバー上で稼働する場合、メインサイトはWordPressの上で動かし、プロキシサイトを別のWordPressの上で動かすことができます。

両方のサイト、およびその共用ウェブサーバーにアクセスできる場合、メインサイトにリバースプロキシのルールを設定しプロキシサイトをリバースプロキシから読み込むように設定できます。

メインサイトとプロキシサイトの両方をKinstaで稼働している場合には、Kinstaカスターマーサポートに対してリバースプロキシの設定を依頼可能です。必要な手順は以下のとおりです。

  • メインサイトとプロキシサイトの両方が、Kinstaで稼働していることを確認します。サイトをKinsta環境に移行するには、手動、または移行申請を行なってください。
  • Kinstaのサポートチャットを開き、ドメイン構成をご説明ください。リバースプロキシの設定には約1営業日かかります。
  • 依頼を受けると、Kinstaのエンジニアがメインサイト上に関連するリバースプロキシのルールを設定し、リバースプロキシを介してプロキシサイトを読み込むように設定します。

Kinstaで使用している標準的なNginxリバースプロキシディレクティブは以下のとおりです。リバースプロキシを介してサブディレクトリのサイトを読み込みます。

location ^~ /subfolder/ {
proxy_pass http://subfolder.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;
}

上のコードでは、プレースホルダー /subfolder/ を実際のサブディレクトリ名（例：/blog/, /shop/）で置き換えてください。さらに、 http://subfolder.domain.com サブドメインは、プロキシサイトに向かうリバースプロキシを指すために使用されるURLと一致する必要があります。

location ディレクティブには、キャレットとチルダ記号（^~）が含まれています。Nginx が定義した文字列を見つけた場合、それ以上の検索を中止し、ここに記載したディレクティブを使用します。Nginxのリバースプロキシディレクティブに関する詳細についてはこちらのドキュメントをご覧ください。

次に、リバースプロキシを介してロードするプロキシサイトを設定する必要があります。以下は、プロキシサイトの設定時に、Kinstaが使用する標準的な手順です。

  • プロキシサイトがロードされるパスにサブディレクトリを作成します。プロキシサイトのファイルはすべてこのサブディレクトリに移動されます。
  • ウェブサーバーの構成ファイルを更新して、新しいサブディレクトリをプロキシサイトのルートディレクトリとして定義します。また、各受信リクエストのリクエストURIからサブディレクトリを削除するリライトルールを追加します。
  • プロキシサイトのデータベース内のすべてのURLを、本番サイトのURLと一致するように更新します（例：example.com/blog)。
  • プロキシサイトの wp-config.php ファイルを編集し、$_SERVER['HTTP_HOST'] の定義をメインサイトのURLに向けます。
  • めに、wp-config.php ファイルで厳密なルールを定義する必要があります。

注）プロキシサイトは、プロキシサイトをロードするサブディレクトリと重複するURLを作成できません。例えば、プロキシサイト example.com/blog は example.com/blog/blog 」というページやディレクトリを作成できません。

2. プロキシサイトのみを自分のサーバー上で稼働する

プロキシサイトとそのウェブサーバーにしかアクセスできない場合は、メインサイトのサーバー管理者にリバースプロキシのルールを設定してもらう必要があります。

それには、上の説明と同じ手順を踏む必要がありますが、この場合は、2つの異なるサーバーでルールを構成する必要があります。

プロキシサイトをKinstaで稼働する場合、リバースプロキシを指すドメインをサイトに追加してください。通常、サブドメインがこの目的に適しています（例：blog.example.com）。サブディレクトリのリンク（例：example.com/blog）を介してプロキシサイトをロードします。

Kinstaでプロキシサイトを設定した後、Kinstaカスタマーサポートに連絡して、リバースプロキシを介してプロキシサイトをロードするように設定します。このとき、訪問者数を正しくカウントするように設定するには、サーバーの実IPアドレスが必要です。特定のプロバイダー（例：AWS CloudFront）などの動的IPの制限により、静的IPを提供できない場合、Kinstaの契約プランは、同等の帯域幅ベースの契約プランに変更されます。

最後に、お客様のサーバーでのリバースプロキシの設定ですが、これはサーバー管理者のみが対処できるため、Kinstaサポートの範囲外となります。

3. メインサイトのみを自分のサーバーで稼働する

メインサイトとそのウェブサーバーにしかアクセスできない場合は、リバースプロキシを設定し、外部サーバーからプロキシサイトをロードするようにルールを設定する必要があります。リバースプロキシを介してプロキシサイトをロードするためのインストールと設定は、2番目のサーバーの管理者の責任です。

メインサイトをKinstaで稼働している場合、Kinstaのカスタマーサポートへ連絡できます。サポートチケットを作成して、この記事の前半で挙げた標準的なリバースプロキシのルールを追加できます。また、必要に応じて、このルールに追加のカスタマイズを加えられます。

このケースでは、リバースプロキシを介したプロキシサイトの適切なロードに関する設定は、すべてご自身の責任となります。

リバースプロキシとしてのNginxの設定方法

サイトの稼働にKinstaを利用しておらず、自分でサーバーを管理している場合は、自身でリバースプロキシを設定し、プロキシサイトを指すように設定する必要があります。

ウェブサーバーのOSによって、Nginxのインストール方法は異なります。Linuxディストリビューションの場合は、そのバージョンに応じて、様々なNginxパッケージを使用できます。

以下の例では、プライマリサイトをexample.comドメインにインストールし、プロキシWordPressサイトをblog.domain.comサブドメインにインストールします。どちらもUbuntu 18.04上で動作するApacheウェブサーバを使用します。ここでは、メインサーバーにリバースプロキシとしてNginxをインストールして設定します。

1. Nginxをインストールする

まず、サーバーのターミナルにSSHでアクセスします。次に、apt-get コマンドを使用してディストリビューションのパッケージリストを更新し、ウェブサーバーにNginxをインストールします。

sudo apt update
sudo apt install nginx

2. リクエストをプロキシするようにNginxを設定する

次に、Apacheで稼働するドメインへのリクエストをプロキシするようにNginxを設定します。これには、新しいバーチャルホストファイルを作成します。ここではnanoエディターを使用してコードを追加しますが、お好きなコードエディターを使用してください。

sudo nano /etc/nginx/sites-available/example.com.conf

次に、Nginxのディレクティブを設定します。以下のserver {...}とlocationブロックを追加して、リクエストをApacheに転送します。

server {
listen      80;
server_name example.com www.example.com;
index       index.php;
root        /var/www/example.com/public    # fallback for index.php
location / {
try_files $uri $uri/ /index.php?$query_string;
}location /blog {
proxy_pass http://blog.domain.com;proxy_http_version                 1.1;
proxy_cache_bypass                 $http_upgrade;

# Proxy headers
proxy_set_header Upgrade           $http_upgrade;
proxy_set_header Connection        "upgrade";
proxy_set_header Host              $host;
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;
proxy_set_header X-Forwarded-Host  $host;
proxy_set_header X-Forwarded-Port  $server_port;

# Proxy timeouts
proxy_connect_timeout              60s;
proxy_send_timeout                 60s;
proxy_read_timeout                 60s;
}

上のコードでは、Apacheサーバーによって提供されるサブディレクトリexample.com/blogのリンクを定義しています。proxy_passディレクティブに、プロキシサイトのパブリックIPアドレス（またはURL）を設定していることを確認してください。この例でプロキシサイトは、サブドメインblog.domain.comで稼働しています。

注）変更を加える前にまず、プロキシサイトがインストールされ、サービスを提供できる状態にあることを確認してください。

ここで使用されているすべてのリバースプロキシディレクティブの詳細については、Nginxのディレクティブの詳細なインデックスをご覧ください。

3. 作成した仮想ホストファイルを保存する

次に、/etc/nginx/sites-availableディレクトリと/etc/nginx/sites-enabledディレクトリの両方にあるexample.com.confという名前のファイルにシンボリックリンクを作成して、新しい仮想ホストを有効化します。

sudo ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled/example.com.conf

4. Nginxにエラーがないかテストする

最後に、Nginxに構成エラーがないかどうかをテストします。

sudo nginx -t

エラーがなければ、Nginxを再読み込みして変更を反映します。

sudo systemctl reload nginx

Nginxがリバースプロキシとして動作するように設定できました。これを確認するには、phpinfo()関数を使用して、プロキシサイトにアクセスした際に読み込まれるPHP変数をチェックします。

PHP変数SERVER_SOFTWAREとDOCUMENT_ROOTから、バックエンドでApacheがこのドメインを提供していることがわかります。また、PHP変数 HTTP_X_REAL_IPとHTTP_X_FORWARDED_FORからは、このリクエストの転送に、Nginxがリバースプロキシとして使用されたことを確認できます。

Nginxで稼働するWordPressサイトを高速化するには、fastcgi_cacheモジュールとngx_cache_purgeモジュールを使用します。最初のfastcgi_cacheモジュールはサイトをキャッシュし、2番目のngx_cache_purgeモジュールは特定のイベントに基づいて（例：WordPressの投稿やページの公開、編集）、キャッシュを自動的に削除します。

Nginx Cache Controllerプラグインを使用すると、WordPressの管理画面からNginxのプロキシサーバーキャッシュを直接制御できます。WordPressマルチサイトを利用している場合は、Nginx Helperプラグインを使用して同じ操作を実行できます。

NginxとWordPressの連携方法の詳細については、Nginxのメインドキュメント や NginxのWordPress設定方法をご覧ください。

リバースプロキシとしてのApacheの設定方法

ここでは、example.comとblog.domain.comの2つのサイトが稼働しているとします。このとき、最初のサイトexample.com/blogは、WordPressであってもなくても構いませんが、2番目のサイトblog.domain.comはWordPressである必要があります。これは、ルートドメインのブログを example.com/blogサブディレクトリのリンクにロードするためです。

1. Apacheの設定を開始する

Apacheを構成します。SSHでサーバのターミナルを開き、Apacheのプロキシモジュールを有効にします。

sudo a2enmod proxy proxy_http ssl

このコマンドを実行すると、ほとんどの場合、Apacheは再起動され、新しく定義されたディレクティブを再読み込みます。

2. リバースプロキシを作成する

次に、メインサーバーのバーチャルホストファイルを編集して、リバースプロキシを作成します。以下のコードを追加します。

<VirtualHost *>
DocumentRoot /var/www/app/public
SSLProxyEngine On    ProxyRequests off
ProxyPass /blog http://blog.domain.com
ProxyPassReverse /blog  http://blog.domain.com
</VirtualHost>

ProxyPassディレクティブは、指定されたパスのリバースプロキシを作成します。ProxyPassReverseディレクティブは、このリバースプロキシを経由して送られてくるHTTPレスポンスヘッダを捕捉し、Apacheサーバに合わせて書き換えます。

3. wp-config.phpファイルを編集する

ファイルを保存した後、wp-config.phpファイルを編集し、「編集が必要なのはここまで」と書かれた行の直前に以下のコードを追加します。

# ProxyPass Settings
# overrides the variables below to ensure that any
# request to /blog/* subdirectory is taken care of properly
$_SERVER['REQUEST_URI'] = '/blog' . $_SERVER['REQUEST_URI'];
$_SERVER['SCRIPT_NAME'] = '/blog' . $_SERVER['SCRIPT_NAME'];
$_SERVER['PHP_SELF'] = '/blog' . $_SERVER['PHP_SELF'];

4. WordPressサイトのデータベースを更新する

最後に、WordPressサイトのデータベースを更新して、サブディレクトリのリンク/blogの設定値を追加する必要があります。次のSQLクエリを実行してください。

UPDATE wp_options SET option_value = 'https://www.example.com/blog' WHERE option_name IN( 'siteurl', 'home' );

これで、https://www.example.com/blogにアクセスすると、サブドメイン（http://blog.domain.com）で稼働しているWordPressサイトが読み込まれます。URLを変更する必要はなく、引き続きWordPressを使用して、サイトの閲覧、書き込み、編集、管理を行えます。

リバースプロキシの制限

  • リバースプロキシは、通過するすべてのトラフィックを読み取ったり変更したりできるため、重大なセキュリティリスクを伴います。リバースプロキシを介してHTTPSトラフィックを転送する場合、通過するデータを復号化してから再暗号化する必要があります。つまり、SSL/TLS証明書の秘密鍵を保持する必要があります。そのため、悪意のある第三者にリバースプロキシが侵害されると、パスワードを記録されたり、サイトにマルウェアを仕込まれたりする可能性があります。
  • 自分やユーザーがメインサーバーに直接アクセスできない場合、リバースプロキシを使用することで単一障害点が生じる可能性があります。たとえば、複数のドメインを配信するためのフロントエンドとしてリバースプロキシを使用している場合、リバースプロキシに障害が発生すると、すべてのドメインが同時にオフラインになる可能性があります。
  • Cloudflareなどのサードパーティ製リバースプロキシを利用する場合、サイトの機密情報をそのサービスに預けることになります。信頼できるサービスであっても、それが将来的にどのような結果につながるかを予測することはできません。
  • リバースプロキシ経由で読み込まれるサイトでは、バックアップを復元したり、ステージングサイトを本番環境に反映したりすると、プロキシされているサイトが正常に読み込まれなくなる可能性があります。

CDNとリバースプロキシの選択

CDNはリバースプロキシの発展型であり、構成やメンテナンスのほとんどをサードパーティが行います。CDNは、使用者側にはほとんど労力をかけずに、WordPressサイトのパフォーマンスを劇的に向上します。

CDNは、コンテンツをキャッシュしてユーザーに素早く提供するだけでなく、オリジンサーバーの負荷を軽減し、帯域コストの削減、追加のセキュリティレイヤーの提供、サイトのSEOの向上、サイトの拡張性の向上などの効果があります。

CDNがもたらすメリットの多くは、リバースプロキシが提供するメリットと同じであることがわかります。では、CDNとリバースプロキシのどちらを選ぶべきなのでしょうか。

どちらか一方だけを選ぶ必要はありません。すでにリバースプロキシを導入している場合でも、CDNを使用することで速度やパフォーマンスの向上が期待できます。両者のキャッシュはうまく組み合わせて使用できます。また、動的コンテンツやECサイトなど、リクエスト処理に特別な要件がある場合でも、CDNまたはリバースプロキシから渡されるカスタムヘッダーを使用して簡単に設定できます。

リバースプロキシに関するよくある質問

リバースプロキシについて理解を深めるのに役立つ、よくある質問をいくつかご紹介します。

リバースプロキシの目的は何ですか？

外部サイトの場所を隠し、メインドメインの一部であるかのように見せることです。たとえば、大学には学生が成績を確認するためのログインページがあるとします。このシステムはWordPress上ではなく、大学構内に設置されたサーバー上で成績管理ソフトウェアを使って運用されているかもしれません。学生にhttps://123.123.123.123/~students/gradeing_software/some/long/url/へアクセスするよう案内する代わりに、リバースプロキシを使用すれば、https://university.edu/gradesからアクセスできるようになります。実際には別のプラットフォームでホストされていても、メインサイトの一部であるかのように見せることができます。

CDNはリバースプロキシですか？

リバースプロキシはCDNとは異なります。CDN（コンテンツデリバリネットワーク）は、訪問者に近い場所からサイトのコンテンツを配信することで、表示速度の向上を図る仕組みです。

ロードバランサーはリバースプロキシですか？

異なるものです。ロードバランサーは、トラフィックを複数のサーバーに分散するための仕組みです。たとえば、アクセス数が非常に多いサイトでは、ロードバランサーを使用して複数のウェブサーバーにトラフィックを分散できます。各ウェブサーバーには同じサイトファイルのコピーがあり、ロードバランサーが受信したトラフィックを各サーバーに振り分けることで、1台のウェブサーバーですべてのトラフィックを処理する必要がなくなります。1台のウェブサーバーが1分あたり1万件のアクセスを処理でき、ロードバランサーの背後に2台のウェブサーバーがある場合、理論上は1分あたり2万件のアクセスを処理できます。

APIゲートウェイはリバースプロキシですか？

異なるものです。APIを使用すると、サイトを管理するためにUIにログインすることなく、プラットフォーム上でさまざまな操作を実行できます。たとえばAPIを利用すれば、WordPress管理画面にログインすることなく、WordPressサイトに新しいブログ記事を投稿できます。

リバースプロキシは必要ですか？

ケースバイケースです。すべてのサイトにリバースプロキシが必要なわけではありませんが、先ほどの大学の例では利用するメリットがあります。ほかにも、FordやChevroletなどの自動車メーカーが、メインサイトとは別の車両構成・カスタマイズプラットフォームを「車をカスタマイズする」機能として提供する場合などが考えられます。たとえば、https://carbuildingplatform.com/ford/build/customcar/ではなく、https://ford.com/buildmycarのようなURLを使用することで、外部のプラットフォームで提供されている機能をメインサイトの一部であるかのように見せることができます。

まとめ

WordPressは非常に柔軟性に優れています。ブログやECサイト、さらには学習管理システム（LMS）としても利用できます。ほとんどの場合、独自の要件に合わせてWordPressをカスタマイズすることが可能です。

ただし、追加のサイトをホストするために、別のドメインやセカンダリサーバーを使用しなければならない場合もあります。前述のとおり、大規模な企業サイトで異なる技術スタックを使用する場合や、既存のWordPress以外のサイトにWordPressブログを立ち上げる場合などがこれに該当します。

リバースプロキシはどちらのケースでも役立ちます。メインのサイトを手放して一から作り直すことなく、WordPressを最大限に活用できます。

Salman Ravoof

独学のウェブ開発者、ライター、クリエイターでもあり、大の無料オープンソースソフトウェア（FOSS）好き。その他の好きなものは、科学、哲学、写真、芸術、猫、そして食。詳しい仕事情報はウェブサイトおよびXアカウントで公開している。