リバースプロキシの設定方法（NginxとApacheでの設定手順）

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

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

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

リバースプロキシとは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

負荷分散

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

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

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

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

広域負荷分散（GSLB）

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

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

広域負荷分散は、サーバー上に手動で設定できますが、通常はCloudflareやKeyCDN（Kinsta CDNのベースです）などの専用CDNを使用します。Kinstaでは、Google Cloud Platformのロードバランサーを介して、ご契約のすべてのウェブサイトにサービスを提供しています。

セキュリティの強化

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

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

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

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

強力なキャッシュ

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

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

VarnishとNginx FastCGIは、ウェブコンテンツのキャッシュに使用されるリバースプロキシの代表例です。なお、Kinstaでサイトを稼働している場合、お客様に代わってすべてのキャッシュに関する作業を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％のウェブサイトはリバースプロキシサービスを使用していません。

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

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

Nginx

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

Nginxは上述したリバースプロキシの利点に加え、ウェブのパフォーマンス、セキュリティ、信頼性、スケーラビリティを向上する追加機能を提供します。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をインストールして設定します。

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

sudo apt update
sudo apt install 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のディレクティブの詳細なインデックスをご覧ください。

バーチャルホストファイルを保存します。次に、新しいバーチャルホストを有効にします。 example.com.conf と /etc/nginx/sites-available の両方のディレクトリにファイル /etc/nginx/sites-enabled のシンボリックリンクを作成してください。

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

次に、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の投稿やページの公開、編集）、キャッシュを自動的に削除します。

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

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

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

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

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

sudo a2enmod proxy proxy_http ssl

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

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

<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サーバに合わせて書き換えます。

ファイルを保存した後、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'];

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

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

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

リバースプロキシの制限

• リバースプロキシは、通過するすべてのトラフィックを読み取って変更できるため、重大なセキュリティリスクとなります。HTTPSトラフィックをリバースプロキシ経由で渡す場合、リバースプロキシはデータの復号と再暗号化を行います。すなわち、リバースプロキシはSSL/TLS証明書の秘密鍵を所有する必要があります。そのため、悪意のある第三者がリバースプロキシに侵入した場合、パスワードのログへの保存や、ウェブサイトへのマルウェアの注入が可能です。
• ユーザがメインサーバに直接アクセスできない場合、リバースプロキシの使用は単一障害点となります。例えば、前段にリバースプロキシを配備して複数のドメインにサービスを提供する場合、リバースプロキシが停止すると、すべてのドメインが同時にオフラインになります。
• Cloudflareなどのサードパーティのリバースプロキシに依存する場合、サイトの機密情報を外部に渡すことになります。信頼できる会社ですが、将来、何があるかは予測できません。
• リバースプロキシを介したウェブサイトで、バックアップの復元やステージングサイトの公開を行うと、プロキシサイトが正常にロードできなくなる場合があります。
• リバースプロキシを介したWordPressマルチサイトのロードは、複数の要因により複雑で、メンテナンスが困難です。このため、Kinstaではリバースプロキシを介したWordPressマルチサイトの使用をサポートしていません。ただし、プロキシサイトの代替として、スタンドアロンのWordPressサブディレクトリ型マルチサイトを使用できます。

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

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

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

見てきたように、CDNが提供するメリットは、リバースプロキシが提供するメリットとほとんど同じです。であれば、リバースプロキシよりもCDNを選択すべきでしょうか、あるいはその逆でしょうか。

1つに絞らなければならない理由はありません。すでにリバースプロキシを導入している場合も、CDNを利用すれば、スピードとパフォーマンスの向上が期待できます。両方のキャッシュレイヤは賢く、もし独自のリクエスト処理が必要であれば（例：動的コンテンツ、EC）、CDNまたはリバースプロキシから渡されるカスタムヘッダーを使って簡単に構成できます。

まとめ

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

しかし、サイトを追加するにあたって、異なるドメインやセカンダリサーバを使用しなければならない場合もあります。たとえば、前述のように、大企業のサイトで異なる技術スタックが使用されている、あるいは、既存のWordPressではないサイトで、WordPressのブログを立ち上げようとしている場合です。

リバースプロキシはこのような問題を解決します。メインのウェブサイトを放棄して最初からやり直すことなく、WordPressを最大限に活用できます。