リバースプロキシを設定する方法(NginxおよびApacheのステップバイステップ)
公開: 2020-08-14リバースプロキシはWebサーバーの前に配置され、オリジンサーバーに到達する前にすべての要求を受信します。 フォワードプロキシと同様に機能しますが、この場合、ユーザーやクライアントではなくプロキシを使用するWebサーバーです。 リバースプロキシは通常、Webサーバーのパフォーマンス、セキュリティ、および信頼性を強化するために使用されます。
たとえば、サーバーAのexample.com
ドメインでホストされているWordPress以外のサイトを持ち、サーバーBでホストされているexample.com/blog
URLのWordPressでブログを実行することができます。これは、サーバーBのリバースプロキシを追加することで実現できます。プライマリサイトをホストしているサーバー。 ブログへのリクエストを別のサーバー(KinstaなどのマネージドWordPressホストなど)にリダイレクトするようにリバースプロキシを構成できます。
この記事では、リバースプロキシサーバーの基本、それらがどのように機能するか、それらの主な利点は何か、そしてそれらを使用してWordPressサイトを高速化および保護する方法を学習します。
興奮した? はじめましょう!
リバースプロキシとは何ですか?
リバースプロキシサーバーとは何かを理解するには、まずその役割を理解し、関連するすべての用語に精通する必要があります。
ドメイン名を入力するかリンクをクリックして通常どおりWebを閲覧すると、ブラウザ/デバイスはWebサイトのサーバーに直接接続し、そのリソースのダウンロードを開始します。

アクセスしたWebサイトのIPアドレスを匿名化する場合は、プロキシサーバーを使用して最初にすべての要求を送信できます。 リクエストをDNSリゾルバーに転送してから、元のサーバーからWebサイトのリソースをダウンロードします。
その後、それらのリソースをデバイスに渡します。 これはフォワードプロキシと呼ばれます。

リクエストがフォワードプロキシから発信されていると見なされるため、Webサイトから完全に隠されています。
ユーザーのプライバシーを強化することは別として、フォワードプロキシは主に地理的なコンテンツの制限を回避するために使用されます。 たとえば、お住まいの地域でブロックされているビデオを視聴する場合は、ビデオを表示できるIPアドレスを持つ転送プロキシを使用できます。
フォワードプロキシは、仮想プライベートネットワーク(VPN)とほぼ同じように機能しますが、独自のユースケースを持つ別個のテクノロジーです(ただし、重複する場合があります)。
リバースプロキシサーバーとフォワードプロキシサーバー
リバースプロキシサーバーは、ユーザー/クライアントがフォワードプロキシを使用して匿名性を実現するのと同じように、匿名性を維持し、セキュリティを強化するためのオリジンサーバーのフロントとして機能します。 これにより、ユーザーやクライアントがオリジンサーバーと直接通信しないようになります。

フォワードプロキシとリバースプロキシの違いはわずかですが、動作が異なります。
それらの機能の間に重複がないので、両方が一緒に働くことができます。 通常、ユーザー/クライアントはフォワードプロキシを使用しますが、オリジンサーバーはリバースプロキシを使用します。

サーバー管理者はリバースプロキシの動作を制御できるため、これを使用して多くの便利な機能を有効にすることができます。
この投稿の後半で、そのすべての利点をリストします。
なぜリバースプロキシを使用するのですか?
多くの企業、特に大企業は、独自のニーズに合わせてカスタマイズされ、WordPressで実行されていない特注のWebサイトを使用しています。 いくつかの例には、銀行や保険のWebサイトが含まれます。
その他の場合、企業は、外部ソフトウェア(WordPressなど)のインストールを許可しない外部サービスでサイトをホストする場合があります。 通常、これらはShopifyなどのeコマースプラットフォームを使用している中小規模の小売業者です。
WordPressには堅牢なCMS機能があるため、特注のWebサイトを持つ大企業を含む多くの企業は、WordPressを使用してブログをホストすることを好む場合があります。
この問題を回避する1つの方法は、メインWebサイトのサブドメインにWordPressをインストールし、ユーザーがメインWebサイトとブログを簡単に切り替えられるようにナビゲーションメニューを構成することです。
サブドメインは一意のドメインとして動作するため、サイトのSEOに影響を与える可能性があります。 Googleはサブドメインとサブディレクトリの両方を同等に扱いますが、サブディレクトリでホストされている場合よりもサブドメインでホストされている場合は、検索エンジンのランキングに合わせてWebサイトを最適化するのにより多くの労力がかかります。

Googleは、サブドメインとサブディレクトリの両方を同等に扱うことを再確認しましたが、一部のSEO専門家はそれに同意しません。 また、サイトのSEOに影響を与えない場合でも、サブディレクトリでホストされているサイトの方が保守が簡単です。
そのため、リバースプロキシを使用して、別のサーバーでホストされているサイトのブログにリクエストをリダイレクトできます。 たとえば、銀行はメインのWebサイトをサーバー上で安全にホストできますが、WordPressを利用したブログをKinstaなどのマネージドWordPressホスト上で個別にホストすることもできます。

1つのドメイン名で2つの異なるサイトを統合することは、リバースプロキシを使用する主な利点の1つです。 これは、ブランドがサイトを整理され、専門的に保ち、信頼性を維持するのに役立ちます。
リバースプロキシを使用する利点
上記のユースケースに加えて、リバースプロキシには他の多くの利点もあります。 以下のセクションでは、それらの主な利点のいくつかについて説明します。
負荷分散
単一のオリジンサーバーでは、毎日数百万のユニークビジターがいるWebサイトのすべての着信トラフィックを処理することはできません。 このような場合、多くのサーバーのプール間でトラフィックをスマートに分散できます。 通常、すべてのサーバーが同じコンテンツをホストして単一障害点を排除し、Webサイトの信頼性を高めます。
リバースプロキシは、オリジンサーバーに到達する前に着信トラフィックを受信できるため、これを設定するための優れた方法です。 オリジンサーバーが過負荷になるか完全に障害が発生した場合、サイトの機能に影響を与えることなく、トラフィックを他のサーバーに分散できます。
リバースプロキシは、着信要求を複数のサーバーに送信することもでき、各サーバーは最適化された特定の機能を実行します。 リバースプロキシは、すべてのサーバーから応答を収集し、それらをクライアントに配信できます。
一般的なリバースプロキシのほとんどは主に負荷分散に使用されるため、ロードバランサーとも呼ばれます。
グローバルサーバー負荷分散(GSLB)
GSLBは、世界中に戦略的に配置された多くのサーバー間でWebサイトのトラフィックを分散するための高度な負荷分散方法です。 これは通常、クライアントとサーバー間の最速の移動時間に基づいてリバースプロキシがサーバーノードを選択するエニーキャストルーティング技術を介して行われます。
GSLBは、サイトの信頼性とセキュリティを大幅に向上させるだけでなく、遅延と読み込み時間を短縮し、それによってユーザーエクスペリエンスを向上させます。 GSLBをSpoonFeedingなどの他のネットワーク最適化手法とともに使用して、オリジンサーバーの計算リソースをさらに解放することができます。
サーバーでグローバルサーバー負荷分散を手動で設定できますが、通常はCloudflareやKeyCDN(Kinsta CDNにも電力を供給します)などの専用CDNによって処理されます。 Kinstaは、GoogleCloudPlatformを搭載したロードバランサーを介してホストされているすべてのウェブサイトにサービスを提供します。
強化されたセキュリティ
リバースプロキシは、オリジンサーバーのIPアドレスやその他の特性を隠す可能性があります。 したがって、Webサイトのオリジンサーバーは匿名性をより適切に維持し、セキュリティを大幅に向上させることができます。
リバースプロキシはメインサーバーに到達する前にすべてのトラフィックを受信するため、攻撃者やハッカーはDDoS攻撃などのセキュリティ脅威でWebサイトを標的にすることが難しくなります。
厳格なファイアウォールを使用して、一般的なサイバー攻撃に対するセキュリティを強化してリバースプロキシを強化できます。 リバースプロキシがインストールされていないと、マルウェアを削除したり、削除を開始したりすることは困難です。
HAProxyのようなリバースプロキシは、それが有効になっていないWebサーバーに基本HTTPアクセス認証を追加できます。 リバースプロキシを使用して、さまざまなタイプの要求に集中認証を追加することもできます。
強力なキャッシング
静的コンテンツと動的コンテンツの両方をキャッシュすることにより、Webアクセラレータの目的でリバースプロキシを使用できます。 これにより、オリジンサーバーの負荷を軽減し、Webサイトを高速化できます。
たとえば、オリジンサーバーが米国にあり、ヨーロッパのユーザーがWebサイトにアクセスした場合、ヨーロッパのリバースプロキシサーバーからキャッシュされたバージョンのサイトを提供できます。 リバースプロキシはオリジンサーバーよりもユーザーに近いため、Webサイトの読み込みにかかる時間が短くなり、優れたパフォーマンスを発揮します。
VarnishとNginxFastCGIは、Webコンテンツのキャッシュに使用されるリバースプロキシの代表的な例です。 サイトがKinstaでホストされている場合は、Kinstaがすべてのキャッシングのレッグワークを処理するため、キャッシングについて心配する必要はありません。
優れた圧縮
サーバーの応答は多くの帯域幅を消費します。 サーバーの応答をクライアントに送信する前に(gzipなどで)圧縮すると、必要な帯域幅の量を減らし、ネットワークを介したサーバーの応答を高速化できます。
リバースプロキシは、オリジンサーバーとクライアントの間にあるため、サーバーの応答を圧縮するのに理想的です。
最適化されたSSL暗号化
各クライアントのSSL/TLS要求の暗号化と復号化は、オリジンサーバーにとって非常に負担になる可能性があります。 リバースプロキシはこのタスクを引き受けて、コンテンツの提供などの他の重要なタスクのためにオリジンサーバーのリソースを解放できます。
SSL / TSL暗号化と復号化をオフロードするもう1つの利点は、オリジンサーバーから地理的に離れているクライアントの遅延を減らすことです。
このタスクをさらに最適化するために、専用のSSL/TLSアクセラレーションハードウェアを備えたリバースプロキシを選択することもできます。 このようなリバースプロキシは、SSL/TLSターミネーションプロキシと呼ばれます。 Varnishなどの一部のサーバーはSSL/TSLプロトコルをサポートしていないため、SSL/TSLターミネーションリバースプロキシはそれらを通過するトラフィックを保護するのに役立ちます。
より良いA/Bテスト
ほとんどのA/Bテストツールでは、外部のJavaScriptライブラリを使用して関数をロードする必要があります。 ただし、サードパーティのスクリプトを読み込むと、ページの読み込み時間が遅くなり、ユーザーのエクスペリエンスが不安定になる可能性があります。
代わりに、リバースプロキシを使用して、サーバーレベル自体で2つの別個のフローを作成できます。 たとえば、Nginxのsplit_clients
またはsticky route
メソッドを使用して、トラフィックのリダイレクトを制御できます。
NginxとfreeCodeCampのチュートリアルを参照して、リバースプロキシを使用したA/Bテストの実行について詳しく知ることができます。
トラフィックの監視とロギング
リバースプロキシは、それを通過するすべての要求をキャプチャします。 したがって、トラフィックを監視およびログに記録するための中央ハブとしてそれらを使用できます。 複数のWebサーバーを使用してWebサイトのすべてのコンポーネントをホストしている場合でも、リバースプロキシを使用すると、サイトからのすべての着信データと発信データを簡単に監視できます。
最も人気のあるリバースプロキシ
W3Techsによると、Webサイトのほぼ83%は、監視するリバースプロキシサービスを使用していません。

リバースプロキシ(上記にリストされている)を使用する17%のWebサイトのうち、ほとんどがCDNであることに気付くでしょう。 これは、ほとんどのリバースプロキシが、安全対策としてデフォルトでその存在を隠しているためです。 したがって、W3TechsのようなWebサイト監視サービスを利用して、どのリバースプロキシが最も人気があるかを見つけることはできません。
私たちの調査と経験から、今日使用されている最も人気のあるリバースプロキシは次のとおりです。
Nginx
Nginxは、リバースプロキシとしても機能するオープンソースのWebサーバーです。 Webサイトのホストに使用されるほか、最も広く使用されているリバースプロキシおよび負荷分散ソリューションの1つでもあります。 Netcraftによると、2019年12月に4億7900万を超えるWebサーバーがNginxを使用しており、Webサーバーの市場シェアのリーダーとなっています。

Nginxは、上記で説明したすべてのリバースプロキシの利点に加えて、さらに多くの利点を提供します。 Webのパフォーマンス、セキュリティ、信頼性、およびスケーラビリティが向上します。 Nginxは、ホットリロード可能な構成ファイルを使用して構成できます。 Kinstaでは、Nginxリバースプロキシは、使用できるいくつかのプレミアムアドオンの1つです。
ただし、商用製品であるNginx Plusを使用して、大企業のWebサイトに適したAPIベースの構成オプションやその他の機能にアクセスすることもできます。
KinstaはNginxですべてのWebサイトを強化しています。 競合するすべてのカテゴリで、レビューシグナルのトップティアWebホスティングステータスにランクインしています。Nginxを使用する他の主要企業には、MaxCDN、Cloudflare、Netflixなどがあります。
Nginxを基本的なリバースプロキシとして設定するのは簡単です。 Nginxは、要件に応じてサーバーのリバースプロキシをカスタマイズするためのさまざまなディレクティブも提供します。 これを行う方法については、後のセクションで説明します。 Kinstaをご利用の場合は、同じセクションで、KinstaでホストされているWebサイトにリバースプロキシを使用する方法も学習します。
ワニス
Varnishは、キャッシュエンジンが組み込まれたオープンソースのHTTPリバースプロキシです。 これは主に、動的コンテンツを提供するトラフィックの多いWebサイト向けに設計されています。 また、Varnishをロードバランサー、Webアプリファイアウォール(WAF)、およびエッジ認証および承認サーバーとして使用することもできます。
LinuxおよびFreeBSDのすべての最新バージョンで動作し、主にNginxまたはApacheWebサーバーのフロントとして使用されます。 Varnishの強力で柔軟性の高いVarnishConfigurationLanguage(VCL)を使用すると、HTTP要求の処理、キャッシュ、1つ以上のWebサーバーへの接続などのさまざまな機能を定義できます。
このため、多くのCDNは、コンテンツを迅速に配信するための主要な基盤としてワニスを使用しています。
Varnishは、あるWebページのセクションを他のWebページで再利用するのに役立つ言語であるEdge Side Includes(ESI)もサポートしています。 Webサイトがさまざまなページで繰り返しコンテンツを多数使用している場合、ESIは、頻繁に使用されるセクションをキャッシュすることにより、サイトのページの読み込み時間を短縮するのに役立ちます。
さまざまなモジュール(VMOD)を使用してVarnishを拡張できます。 ワニスの公式チュートリアルにアクセスして、ワニスをWordPressのリバースプロキシとして設定する方法を学びましょう。
Apacheトラフィックサーバー
Apache Traffic Serverは、オープンソースのキャッシングプロキシサーバーです。 高速でスケーラブルな機能で人気があります。 Yahoo!が開発した商品でした。 ずっと前ですが、彼らはそれをオープンソースにし、メンテナンスのためにApacheFoundationに寄付しました。
Comcast、Akamai、LinkedIn、Yahoo、Appleなどのいくつかの主要なコンテンツネットワークとCDNは、ApacheTrafficServerを使用してテクノロジーを強化しています。
HTTPサーバーデーモンであるApacheHTTPServer( Apache httpd )を使用して、Webサーバーにリバースプロキシを設定することもできます。 基本的なWebサーバーとして機能するだけでなく、静的および動的なコンテンツをユーザーに提供するのにも役立ちます。 この記事の後半で、Apacheをリバースプロキシとして設定する方法を学習します。
HAProxy
HAProxyは、オープンソースのリバースプロキシおよびロードバランサーです。 Linuxディストリビューションやクラウドプラットフォームなど、ほとんどの既存のWebサーバーアーキテクチャと統合するように設計されています。 Nginxと同様に、HAProxyはイベント駆動型I / Oモデルを使用し、複数のワーカープロセス間でのリクエストの分割をサポートします。

HTTPリクエストの場合、HAProxyは高負荷でも非常に優れたパフォーマンスを発揮します。 Airbnb、Reddit、Instagram、Stack Overflow、Tumblr、GitHub、Imgurなど、インターネット上で最もトラフィックの多いWebサイトのいくつかは、HAProxyを使用してWebサイトを効率的に配信しています。
HAProxyの実装方法について説明することはこの記事の範囲を超えていますが、HAProxyのドキュメントを参照して、HAProxyがどのように機能するかを理解することができます。
注: TraefikとEnvoyは、HAProxyに代わる他の2つのオープンソースです。 これらは、高性能のリバースプロキシであり、多くの高度な機能を備えたロードバランサーです。
その他の一般的なリバースプロキシには、AWS Elastic Load Balancer、GLBC、DigitalOcean Load Balancer、Google CloudLoadBalancerがあります。 現在使用されている上位のリバースプロキシとロードバランサーの完全なリストについては、Stackshare.ioをご覧ください。
リバースプロキシ:WordPressサイトのユースケース
Kinstaでホストされているサイトを含め、WordPressサイトにリバースプロキシを使用する場合の主な使用例は3つあります。

Nginxは、今日WordPressサイトで使用されている最も人気のあるリバースプロキシであるため、この例ではNginxのみを使用します。 ただし、同じ基本原則が他のリバースプロキシにも適用されます。
リバースプロキシは、多くの場合、インストール、構成、およびサポートが困難です。 このため、Kinstaは、セットアップの支援が必要なリバースプロキシごとに月額50ドルのアドオンサブスクリプションを提供しています。 詳細については、Kinstaのサポートチームにお問い合わせください。
1.同じサーバーでホストされているメインサイトとプロキシサイト
メインサイトとプロキシサイトの両方が同じサーバーでホストされている場合、メインサイトはWordPressインストールで実行できますが、別のWordPressインストールはプロキシサイトに電力を供給します。
サイトとその共有Webサーバーの両方にアクセスできるため、メインサイトのリバースプロキシルールを設定してから、リバースプロキシからロードするようにプロキシサイトを構成できます。
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
//subfolder.domain.comサブドメインは、リバースプロキシをプロキシサイトに向けるために使用されるURLと一致する必要があります。
location
ディレクティブには、caretおよびtilde記号( ^〜 )が含まれており、定義された文字列が見つかった場合は、それ以上一致するものの検索を停止し、ここにリストされているディレクティブを使用する必要があることをNginxに通知します。 Nginxのリバースプロキシディレクティブの詳細については、ドキュメントをご覧ください。
次に、リバースプロキシを介してロードするようにプロキシサイトを構成する必要があります。 プロキシサイトを構成するためにKinstaが実行する標準的な手順は次のとおりです。
- プロキシサイトのロード元のパスにサブディレクトリを作成します。 プロキシされたすべてのWebサイトのファイルがこのサブディレクトリに移動されます。
- Webサーバーの構成ファイルを更新して、プロキシされたサイトのルートディレクトリとして新しいサブディレクトリを定義します。 さらに、各着信リクエストのリクエストURIからサブディレクトリを削除するために、書き換えルールを追加する必要があります。
- プロキシされたサイトのデータベース内のすべてのURLを、ライブサイトのURL(
example.com/blog
など)と一致するように更新します。 - プロキシされたサイトの
wp-config.php
ファイルを$_SERVER['HTTP_HOST']
定義で編集し、メインサイトのURLをポイントします。 - SSL証明書を使用している場合は、リダイレクトループを回避するために、
wp-config.php
ファイルで厳密なルールを定義する必要があります。
注:プロキシされたサイトは、プロキシされたサイトがロードされるのと同じサブディレクトリを複製するURLを作成できません。 たとえば、example.com / blogのプロキシサイトでは、 example.com/blog
/ blog/ example.com/blog/blog
にページやディレクトリを作成できません。
2.サーバーでホストされているプロキシサイトのみ
プロキシされたサイトとそのWebサーバーにしかアクセスできない場合は、メインサイトのサーバー管理者に連絡して、リバースプロキシルールを設定するように依頼する必要があります。
あなたのサイトに超高速で安全で開発者に優しいホスティングが必要ですか? KinstaはWordPress開発者を念頭に置いて構築されており、豊富なツールと強力なダッシュボードを提供します。 私たちの計画をチェックしてください
これを行うには、上記と同じ手順に従う必要がありますが、この場合、2つの異なるサーバーでルールを構成する必要があります。
Kinstaを使用してプロキシサイトをホストするには、リバースプロキシを指すドメインをサイトに追加します。 通常、サブドメインはこの目的(例: blog.example.com
)に適しており、サブディレクトリリンク(例: example.com/blog
)を介してプロキシされたサイトをロードします。
Kinstaでプロキシサイトを設定した後、Kinstaサポートチームに連絡して、リバースプロキシを介してロードするようにプロキシサイトを構成できます。 現時点では、訪問を正しくカウントする方法でセットアッププロセスを完了するために、サポートチームはサーバーの実際のIPを必要とします。 特定のプロバイダー(AWS CloudFrontなど)からの動的IP制限のために静的IPを提供できない場合、プランは代わりに同等の帯域幅ベースのプランに変換されます。
最後に、サーバーにリバースプロキシを設定することは、サーバー管理者のみが処理できるため、Kinstaサポートの範囲外です。
3.サーバーでホストされているメインサイトのみ
メインサイトとそのWebサーバーにしかアクセスできない場合は、リバースプロキシを設定し、外部ホストからプロキシされたサイトをロードするようにそのルールを構成する必要があります。 リバースプロキシを介してロードするようにプロキシサイトをインストールおよび構成するのは、セカンダリサーバーの管理者の責任です。
メインサイトをKinstaでホストすると、Kinstaのサポートチームにアクセスできるようになります。 彼らと一緒にサポートチケットを発行して、この記事で前述した標準のリバースプロキシルールを追加できます。 必要に応じて、これらのルールに追加のカスタマイズを追加することもできます。
このシナリオでは、リバースプロキシを介して適切にロードするようにプロキシサイトを構成する責任があります。
Nginxをリバースプロキシとして設定する方法
KinstaがWebサイトをホストしておらず、サーバーを管理している場合は、リバースプロキシを自分で設定し、プロキシされたサイトを指すように構成する必要があります。
Webサーバーのオペレーティングシステムに応じて、Nginxのインストール方法を変えることができます。 Linuxディストリビューションの場合、Linuxディストリビューションのバージョンに基づいてさまざまなNginxパッケージを使用できます。
以下の例では、プライマリサイトをexample.com
ドメイン名にインストールし、プロキシされたWordPressサイトをblog.domain.com
サブドメインにインストールしています。 どちらもUbuntu18.04で実行されているWebサーバー上のApacheを利用しています。 Nginxをメインサーバーにリバースプロキシとしてインストールして構成します。
まず、SSH経由でサーバーの端末にアクセスします。 次に、 apt-get
コマンドを使用してディストリビューションのパッケージリストを更新し、WebサーバーにNginxをインストールします。
sudo apt update sudo apt install nginx
次に、ApacheでホストされているドメインのリクエストをプロキシするようにNginxを設定する必要があります。 これを行うには、新しい仮想ホストファイルを作成します。 ここでは、 nanoエディターを使用してコードを追加していますが、任意のコードエディターを使用できます。
sudo nano /etc/nginx/sites-available/example.com.conf
次に、次のserver {...}
とlocation
ブロックを追加して、リクエストをApacheに転送するようにNginxディレクティブを設定します。
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
ディレクティブでプロキシされたWebサイトのパブリックIPアドレス(またはURL)を使用していることを確認してください。 私の場合、プロキシされたWebサイトはblog.domain.com
サブドメインでホストされています。
注:変更を加える前に、プロキシされたWebサイトがインストールされ、提供できる状態になっていることを確認してください。
ここで使用されているすべてのリバースプロキシディレクティブの詳細については、Nginxのディレクティブの詳細なインデックスを参照してください。
仮想ホストファイルを保存します。 次に、 /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
その後、構成エラーがないかNginxをテストします。
sudo nginx -t
エラーがない場合は、Nginxをリロードして変更を適用します。
sudo systemctl reload nginx
これで、リバースプロキシとして機能するようにNginxを正常に設定できました。 これを確認するには、phpinfo()関数を使用して、プロキシサイトにアクセスしたときに読み込まれたPHP変数を確認します。
SERVER_SOFTWARE
およびDOCUMENT_ROOT
変数の下で、Apacheがバックエンドでこのドメインを提供していることがわかります。 ただし、 HTTP_X_REAL_IP
およびHTTP_X_FORWARDED_FOR
PHP変数は、Nginxがリクエストを転送するためのリバースプロキシとして使用されたことを確認します。
fastcgi_cacheモジュールとngx_cache_purgeモジュールを使用すると、Nginxを介したWordPressサイトの提供を高速化できます。 最初のモジュールはサイトをキャッシュしますが、2番目のモジュールは特定のイベント(WordPressの投稿/ページの公開や編集など)に基づいてキャッシュを自動的に削除します。
Nginx Cache Controller WordPressプラグインを使用して、WordPress管理ダッシュボードから直接Nginxのプロキシサーバーキャッシュを制御できます。 WordPressマルチサイトインストールを使用している場合は、NginxHelperプラグインを使用して同じことを行うことができます。
NginxとWordPressの操作方法の詳細な概要については、NginxのメインドキュメントとNginxWordPressセットアップガイドをご覧ください。
Apacheをリバースプロキシとして設定する方法
始める前に、 example.com
とblog.domain.com
で2つのWebサイトが稼働していることを確認してください。 最初のWebサイトはWordPressサイトである場合とそうでない場合がありますが、2番目のWebサイトは、主にルートドメインのブログ( example.com/blog
サブディレクトリリンク)をロードするために使用されるため、WordPressサイトである必要があります。
SSH経由でサーバーのターミナルを開き、Apacheのプロキシモジュールを有効にして、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' );
これで、 https://www.example.com/blog
URLにアクセスし、URLを変更せずにhttp://blog.domain.com
サブドメインでホストされているWordPressサイトをロードできるようになります。 引き続きWordPressを使用して、サイトの閲覧、作成、編集、および管理を行うことができます。
リバースプロキシの制限
- リバースプロキシは、通過するすべてのトラフィックを読み取って変更できるため、重大なセキュリティリスクをもたらします。 HTTPSトラフィックをリバースプロキシ経由で渡す場合は、渡すデータを復号化して再暗号化する必要があります。 これは、SSL/TLS証明書の秘密鍵を所有している必要があることを意味します。 したがって、悪意のあるパーティがリバースプロキシを侵害する可能性がある場合、そのパーティはパスワードを記録し、マルウェアをWebサイトに挿入する可能性があります。
- あなたまたはあなたのユーザーがメインサーバーに直接アクセスできない場合、リバースプロキシを使用すると単一障害点につながる可能性があります。 たとえば、複数のドメインにサービスを提供するためのフロントとしてリバースプロキシを使用している場合、その停止により、すべてのドメインが同時にオフラインになる可能性があります。
- サードパーティのリバースプロキシ(Cloudflareなど)に依存している場合は、サイトの機密情報をサードパーティに渡します。 彼らは信頼されていますが、それが何につながるかを予測することはできません。
- リバースプロキシを介してロードされるWebサイトでバックアップを復元したり、ステージングサイトをライブでプッシュしたりすると、プロキシされたサイトのロードが適切に停止する可能性があります。
CDNとリバースプロキシのどちらを選択するか
CDNは、ほとんどの構成と保守がサードパーティによって処理される高度な形式のリバースプロキシです。 彼らはあなたの側からのわずかな努力であなたのWordPressサイトに驚くべきパフォーマンス上の利点を提供することができます。
CDNは、コンテンツをキャッシュしてユーザーに迅速に提供するだけでなく、オリジンサーバーの負荷を軽減し、帯域幅のコストを削減し、セキュリティの追加レイヤーを提供し、サイトのSEOを強化し、Webサイトの拡張を支援します。
CDNによって提供される利点のほとんどは、リバースプロキシによって提供されるものと同じであることに気付くでしょう。 では、リバースプロキシではなくCDNを選択する必要がありますか、またはその逆ですか?
1つだけで解決しなければならない理由はありません。 リバースプロキシがすでにインストールされている場合でも、CDNを使用することで速度とパフォーマンスが向上します。 どちらのキャッシュも適切にレイヤー化されており、独自のリクエスト処理のニーズ(動的コンテンツ、eコマースなど)がある場合は、CDNまたはリバースプロキシによって渡されるカスタムヘッダーを使用して簡単に構成できます。
概要
WordPressは非常に柔軟性があります。 ブログ、eコマースサイト、さらには学習管理システムとして使用できます。 ほとんどの場合、独自の要件に合わせてWordPressをカスタマイズできます。
ただし、追加のサイトをホストするために、別のドメインまたはセカンダリサーバーを使用する必要がある場合があります。 前に説明したように、大企業のサイトにさまざまなテクノロジースタックを使用したり、既存の非WordPressサイトにWordPressブログを立ち上げたりしたことが原因である可能性があります。
リバースプロキシは、これらの両方の場合に役立ち、メインのWebサイトをあきらめて最初からやり直すことなくWordPressを最大限に活用するのに役立ちます。