上記画像は「WordPress」を「GCP」マルチリージョンのロードバランサーで運用する最終形です。
また「Google Cloud CDN」を挟み「GCPのVMインスタンス」と「Google Cloud Storage」利用し、サーバー負荷の軽減も行っています。
第8回は赤枠内、ロードバランサー用の「固定IPアドレス」をDNSへ「置き換え設定」したあと、WordPressのウェブサイトに「https」でアクセスできるようにするまでを行ないます。
GCPのロードバランサーを利用した「tokyo2020unofficial.com」の設定です。
ロードバランサーを利用していない「投票2020」の設定はこちらの目次です。
ロードバランサーはランニングコストが高いので一時休止しています。気分次第で記事は更新していきます。
第9回 【WordPress_Load_Balancing】 ロードバランサーでhttp→https化した後、301リダイレクト正規化し、リダイレクトループを回避する方法。
環境:Debian 9 php 7.0 Apache 2.4.25 MySQL 5.7 Cocoon
目的:ロードバランサー用の「http→https」301リダイレクト正規化
第8回までに、ロードバランサーでGoogleが管理するSSL証明書を取得し「https」でアクセスできるようにしました。
- 「第8回」の設定をすべて行なっても、このままではリダイレクトループによって、管理画面へのアクセスができなくなります。「第9回」と必ずセットで設定するようにしてください。
「第9回」では、
ロードバランサー用の「http→https」301リダイレクト正規化について書いていきます。
ロードバランサーの一連の説明の中で「WordPressのファイル編集」を初めて行ないますので、途中で参考リンクを見ながら行なってください。ファイル編集前には、必ずバックアップを取るようにしてください。
さらに「WordPressのファイル編集」行なう際には、自分のローカルPCに「WordPress設定ファイルデフォルト」フォルダを作成し、必ず保存してください。編集後の保存フォルダ「「WordPress設定ファイル編集後」も作成すると問題が起きた時に初期設定に戻すことが可能です。
改めて、今回は下記手順の一番最後「第9回」の部分です。
httpsでアクセスできるようになるまで。
- 第7回ロードバランサーの作成
- 第7回バックエンド
「第6回」までに作成した「admin インスタンスグループ」を配置。
- 第7回フロントエンド
ロードバランサーの「固定IPアドレス」取得
「GoogleのマネージドSSL証明書」取得
- 第8回Cloud DNS
ロードバランサーの「固定IPアドレス」を設定。
- 第8回ファイアウォールルール
ロードバランサー用にヘルスチェックのルートを設定。
- 第8回WordPress
一般設定「http」→「https」へ書き換え。
- 第9回「http→https」301リダイレクト正規化今回はこの部分です
リダイレクトループ回避のために2つのファイルを編集します。
- 「apache2.conf」
- 「wp-config.conf」
この条件が必要になります。
1.1 「http→https」301リダイレクト正規化
- ロードバランサーの環境で、通常の「http→https」301リダイレクト正規化を行なった場合、下記画面のようになります。
- 「このページは動作していません。リダイレクトが繰り返し行われました。」と表示されます。
- このままでは正常にリダイレクトが行われません。リダイレクトループの回避をする必要があります。
- 「wp-config.php」ファイルを編集する必要があります。
ベストプラクティスは「apache2.conf」を編集
「apache2.conf」or「.htaccess」のどちらかのファイルを編集します。
ベストプラクティスは「apache2.conf」を編集することです。(「apacheサーバー」のバージョンによっては「httpd.conf」の場合もあり。)
私は一連の流れでGCPの設定を書いています。ですが、Amazon Web Service「AWS」の公式に書いてあることが大変参考になりました。
「Apache公式」:
ELB の Classic Load Balancer で HTTP トラフィックを HTTPS にリダイレクトする方法を教えてください。
優先順位
- 「apache2.conf」または「httpd.conf」の存在する方のファイル。
- 「.htaccess」ファイル。
「Apache 2.4」の「Webサーバー」で動作しているので、一番最初に読み込まれるのは「apache2.conf」で、このファイルに「.htaccess」を読み込みなさいと記載されています。
ということは、どのページにアクセスしても、その順番が毎回行われるので、サーバーに負荷もかかりますし、ユーザー側も表示速度が遅いと感じられてしまいます。
もし「apache2.conf」または「httpd.conf」で動作しない場合には「.htaccess」を編集しますので、両方の編集方法を記載します。
もう一つの問題
「.htaccess」ファイルを正しく編集してもリダイレクトされない場合、ほとんどが、権限設定の問題です。このファイルを編集する方法はロードバランサーを利用していても一緒ですので「第7回 GCP WordPressの「apache2.conf」を編集する」を参考にしてください。
1.2 「apache2.conf」の保存場所①
- WinSCPを起動、ログインをクリックして、次へ。
1.3 「apache2.conf」の保存場所②
- 一番最上位のディレクトリ(フォルダ)の「ルート」にアクセスしします。
- 「etc」ディレクトリを開いて、次へ。
1.4 「apache2.conf」の保存場所③
- 「apache2」ディレクトリを開いて、次へ。
1.5 「apache2.conf」の保存場所④
- 「apache2.conf」を開き編集できるようにします。
- apacheサーバーのバージョンによっては「httpd.conf」の場合がありますがコードの編集方法は同じです。
- 次へ進みます。
1.6 「apache2.conf」の編集
- 下記画面、赤枠の部分が追記するコードです。
- 通常のリダイレクト正規化と比較した場合、「X-Forwarded-Proto ヘッダー」を使用します。どのような仕組みになっているのかは後述します。相当はまった部分ですので。
- 下記コードを追記するのは「apache2.conf」の一番上の1行目からです。
# httpからhttpsへリダイレクト正規化、※先に読み込むのはapache2。
<VirtualHost *:80>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R=301,L]
</VirtualHost>
1.7 「.htaccess」の保存場所①
- WinSCPを起動、ログインをクリックして、次へ。
1.8 「.htaccess」の保存場所②
- 「.htaccess」は隠しファイルになっている可能性が高いのでログインできたら、環境設定を変更します。
- 「オプション」「環境設定」をクリックして、次へ。
1.9 「.htaccess」の保存場所③
- 環境設定を開き「パネル」を選択します。
- 「一般」に「隠しファイルを表示する」という項目があるので「チェック」してOKをクリックして、次へ。
1.10 「.htaccess」の保存場所④
- 「/var/www/html」ディレクトリに「.htaccess」があると思います。
- 環境によっては、別の場所に保存されている可能性もあります。その時は下記画面右上「ファイル検索」をクリックし、ファイル名「.htaccess」、検索場所「/」で検索します。該当ディレクトリに存在します。
- 「.htaccess」を開き、次へ。
1.11 「.htaccess」の編集
- 下記画面、赤枠の部分が追記するコードです。
- 通常のリダイレクト正規化と比較した場合、「X-Forwarded-Proto ヘッダー」を使用します。どのような仕組みになっているのかは後述します。
- 下記コードを追記するのは「.htaccess」の一番上の1行目からです。
# httpからhttpsへリダイレクト正規化、※先に読み込むのはapache2。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R,L]
</IfModule>
1.12 「.htaccess」の編集②
- 全体を見るとこんな感じです。
注意すべき点が2つあります。
- 必ず、下記のように一番上に記載すること。
- 「.htaccess」は一番下に「何も記載されていない改行」入れること。
1行でも「改行」がされていないと「.htaccess」ファイルは動作しません。
- 下記画面でいうところの20行目です。
1.13 「X-Forwarded-Proto ヘッダー」
そもそもなぜ「ロードバランサー」や「CDN」を利用している時に「X-Forwarded-Proto ヘッダー」を付与するのか?
「http→https」301リダイレクト正規化を行なおうと、下記画面のように「http」通信でやり取りが行われている箇所と「https」通信で行われている箇所とが混在しているためです。
これが通常なら「負荷分散(Load Balancing)」の部分が「WordPress」になっているので、通常のリダイレクトで問題はありません。「ロードバランサー」や「CDN」を利用すると、その背後に「WordPress」が存在することになります。
「ロードバランサー」や「CDN」と背後にある「WordPress」は「http」で通信しています。
- 「ブラウザさん」が「http80」でアクセスしました。
- 「ロードバランサー」や「CDN」はそのまま「http80」で「WordPressさん」までお通します。
- 「WordPressさん」は「http80」でアクセスされたものを「https443に301リダイレクト正規化」します。(上記まででこの設定を行なったので)
- 「https443に301リダイレクト正規化」したものを「ブラウザさん」へ渡してほしいと「ロードバランサー」や「CDN」にお願いします。
- ところが「ロードバランサー」や「CDN」は「https443に301リダイレクト正規化」を理解していません。そのまま「http80」で「WordPressさん」までお通ししているので、とにかく決まりだから「http80」を受信したら「WordPressさん」へ再度突き返します。
- 「3-5」を繰り返してしまうためにリダイレクトループが発生してしまいます。「ブラウザさん」には「リダイレクトループの内紛」が起きていることだけは報告されます。
そこで、ヘッダーの登場です。
X-Forwarded-Proto ヘッダー
「http80」でアクセスされたものに合言葉「X-Forwarded-Proto ヘッダー」を付加して、「https443に301リダイレクト正規化」されたものを「ブラウザさん」に返却すると決めます。そうすると「ロードバランサー」や「CDN」は「ブラウザさん」へ渡す準備ができます。
「合言葉」で「山」と言われたら「川」と答えます。WordPressのコンテンツに「川」という合言葉を付ける作業をこれから行います。「wp-config.php」ファイルを編集します。
1.14 「wp-config.php」の保存場所①
- WinSCPを起動、ログインをクリックして、次へ。
1.15 「wp-config.php」の保存場所②
- 「/var/www/html」ディレクトリにあります。
- 「wp-config.php」を開き、次へ。
1.16 「wp-config.php」の編集
- 下記画面のコードを追記します。追記場所は下記画面を参考にしてください。色々なサイトでここに追記と書かれていますが、他の全く別の設定を行なった際に不具合が発生したのは、少し位置の違う場所に追記したことによるものだったからです。
- 何度か追記する場所を変更しましたが、経験上下記の場所が最適と判断しています。
/** CDNやロードバランサーのバックエンドサービスに、WordPressを配置している場合、リダイレクトループでWordPressにログインができなくなる。回避対応. */
/** httpsへ301リダイレクトする場合でも、この場所以外での記載は、301リダイレクトが行われない.(中途半端にリダイレクトループ回避のみはダメ). */
/** このコードはWordPress公式、「リバースプロキシの使用」. */
if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' ) {
$_SERVER['HTTPS']='on';
}
1.17 「http」でウェブサイトアクセス
- 独自ドメインのウェブサイトURL
「例、http://tohyo2020.org/」にアクセス。
「例、https://tohyo2020.org/」へ301リダイレクトされているかどうか確認してください。
1.18 「http」で管理画面アクセス
- 独自ドメインのWordPress管理画面URL
「例、http://tohyo2020.org/wp-admin/」にアクセス。
「例、https://tohyo2020.org/wp-admin/」へ301リダイレクトされているかどうか確認してください。
- 下記画面のように「https」になっていれば完璧です。リダイレクトループ回避完了です。
1.19 さいごに
「apache2.conf」で編集が可能なら、間違いなくこちらで編集して301リダイレクト正規化したほうが良いです。体感的に反応速度が上がったような気がします。
嬉しさのあまり体感速度が上がっているように感じていたらごめんなさい。
【コメント】 ※「メールアドレス不要」