WordPressでCloudflareを利用する際の推奨事項を設定してみた

Cloudflareを使って、Googleタグゲートウェイの設定は完了しました（多分）。

ただ、Cloudflare自体の設定もしっかりと行う必要があります。
なぜならCloudflareには、設定をしておかないと大きな問題につながりかねない特性があるためです。
今回は、下記のブログを参考にキャッシュルールの設定とWordPressのプラグインの追加を行った模様をまとめました。

※色々と検証してその結果を書いたところ随分長くなってしまいました^^;
取り急ぎ推奨事項の設定だけされたい方は「キャッシュルール設定方法」「Cloudflareのプラグインの追加方法」だけご覧いただければと思います。

Cloudflareのキャッシュルール設定をします

なぜこの設定を行う必要があるのか？

CloudflareのようなCDNのデメリットとして、キャッシュしてはいけないコンテンツのキャッシュが残ってしまうことがあるためです。
そもそも、CDNにコンテンツのキャッシュを残しておくことで、表示速度やWEBサーバー本体への負担をかけないという点がCDNであるCloudflareのメリットの一つですが、それが裏目に出てしまうことがあります。

例えば、WordPressのログイン後の管理画面をキャッシュしてしまうということもあるようです。
この場合、外部ユーザーが管理画面に触れてしまうので、セキュリティ上かなりよろしくありません。

そういったことがないように、ワードプレスのログイン画面と管理画面のキャッシュが残らないような設定が必要です。
これはCloudflareの管理画面から比較的簡単に行うことができます。

キャッシュルール設定方法

• Cloudflareの管理画面にログイン＞該当のドメインをクリック

1. Caching＞Cache Rules＞ルールを作成＞ルール名を入力
2. 「フィールド」を『URLパス』に、「オペレーター」を『次を含む』に、「値」にWordPressのログイン画面のURLのパスを入力
3. OR条件で、オペレーターまでは同様に設定し、「値」にWordPressの管理画面のURLのパスを入力
4. 「キャッシュの適格性」→『キャッシュをバイパスする』*を選択
5. 「ブラウザTTL」→『キャッシュをバイパスする』*を選択
6. 保存

「「ブラウザTTL」→『キャッシュをバイパスする』*を選択」はオリジンTTLを尊重するを選択しても良かったかもしれません。
ただ、ログイン画面と管理画面はどんな時でもキャッシュされる必要はないと思いましたので、バイパスするを選択しました。

*「キャッシュをバイパスする」とは、キャッシュに保存しないようにすることと同義と認識しています。違っていたら教えていただきたいです。。

参考記事

これで、ログインされた状態のページが他者に表示されることは無くなりました（多分、、）。
次にWordPressのプラグインを追加します。

WordPressにCloudflareのプラグインを追加します

なぜこの設定を行う必要があるのか？

冒頭に掲載したブログに、下記の便利な機能があり「プラグインの追加は必須」と記載されていたためです。
（うまくいっている人が「追加が必須」と言っているのだから何も考えずに追加するのです）。

インストールしなくても使えますが、記事を更新すると自動でCDNの関連ページをパージしてくれます。
また、CDNでWordPressを運用するにあたってWordPressの挙動を裏で自動的に変更しているようです。

管理者がログインしていたらCDNのキャッシュを使わないようにしてくれています。

記事やコメントが更新されたらCDNの関連するページを削除してくれます。

Cloudflareのプラグインの追加方法

通常のWordPressのプラグインを追加する方法と同じです。

• WordPressの管理画面にログイン＞プラグイン＞プラグインを追加
• 検索窓に「Cloudflare」と入力
• Cloudflareのプラグインを探す＞今すぐインストール＞有効化

次にこのプラグインの設定を行います（この設定が合っているかは自信なしです、、）。

• WordPress管理画面の「設定」＞Cloudflare

まず、HOME画面の一番上の項目「Apply Recommended Cloudflare Settings for WordPress」を設定しました。
項目名だけを読んでもあまり意味がわからなかったので、説明文をGoogle翻訳で日本語訳してみたところ、
「WordPressサイト向けにCloudflareが推奨する基本設定を適用します。これにより、基本的なセキュリティとパフォーマンス設定が推奨値に設定されます。」
ということでしたので、設定しておいてデメリットはなさそうです。

次に、その下の「Automatic Platform Optimization」です。
これはCloudflareの有料プランでしか設定できないもののようで、Cloudflareを有料化するつもりは今のところありませんでしたので、今回は設定を見送ります。

HOME画面一番下の、「Purge Cache」はCloudflareのキャッシュを全て削除できるボタンで、特に何かを設定するためのものではなさそうでしたので、これも設定は見送りました。

次に、Settingsの項目に移動します。
設定項目を眺めると、「Image Optimization」「Web Application Firewall」「Image Optimization」はCloudflareを有料プランにする必要がありそうでしたので、この3つ以外の設定について検討していくことにします。

設定可能な項目の説明文をそれぞれ日本語訳すると下記の通りとなります。（Google翻訳めちゃくちゃ便利、、！）

項目	説明文（日本語訳）
Always Online™	サーバーがダウンした場合、Cloudflare はキャッシュから Web サイトの静的ページを提供します。
Auto Purge Content On Update	サイトの外観を更新すると、Cloudflare のキャッシュが自動的に消去されます。 注: この機能は、WordPress の自動プラットフォーム最適化 (APO) によって提供されています。APO をご利用の場合は、この設定を無効にしてください。
Development Mode	一時的にキャッシュをバイパスし、オリジンサーバーへの変更をリアルタイムで確認できるようにします。
Security Level	ウェブサイトのセキュリティ レベルを調整して、どの訪問者にチャレンジ ページを表示するかを決定します。
Automatic HTTPS Rewrites	自動 HTTPS 書き換えは、HTTPS で提供できる Web サイト上のすべてのリソースまたはリンクの「http」を「https」に変更することで、混在コンテンツを修正するのに役立ちます。

• 「Always Online™」は緊急時の避難経路を確保しておくための設定にイメージが近いと思いましたのでOnにしました。
• 「Auto Purge Content On Update」は外観（テーマファイルなど）を更新した際に、その変更がすぐにユーザー側にも反映されるようにした方が良いと考えてOnにしています。
• 「Development Mode」はちょっとよくわからなかったですが、helpを見たところ下記のように記載されており、Cloudflareからすると推奨事項ではなさそうに感じましたのでOffのままにしました。

開発モードがオンの場合、すべてのリクエストはオリジンサーバーに渡されます。これにより、ウェブサイトへのリクエストは一時的にキャッシュをバイパスし、キャッシュされたコンテンツへの変更を確認できます。

これは、変更をすぐに確認する必要がある場合に便利です。開発モードを有効にすると、3時間後に自動的にオフになります。

注: ウェブサイトに大きな変更を加える場合を除き、開発モードをオンにするのではなく、「個々のファイルを消去」オプションを使用することをお勧めします。開発モードではすべてのリクエストがオリジンサーバーに送信されるため、オリジンサーバーへのリクエストが増加すると、帯域幅とCPU使用率が一時的に増加するためです。

• 「Security Level」はhelpを読むと「中（Medium）」が推奨されていたため、デフォルトの「中（Medium）」を設定しました。
• 「Automatic HTTPS Rewrites」は、既にすべてのページのURLが「https」になっているため不要な機能だと思いましたが、Onにしておいて損はないと考え、Onにしました。

これで、プラグインの設定が完了です（おそらく）！！
Duolingoで英語の勉強を毎日やっていますが、全く歯が立ちませんでした笑
Google翻訳がある世界に生まれてよかった！

設定が反映されているかを検証します

ここまではぽちぽちボタンを押すだけでしたので、特につまづくポイントはありませんでした。
次に、正しく設定できていて、設定が反映されているかの検証が必要です。
今回の場合、下記2点を検証すれば設定がうまくいっていると言って良いのではないかと思います。

1. WordPressのログイン画面と管理画面のキャッシュが残らないようになっている
2. WordPressがログイン状態になっている場合、キャッシュが残らないようになっている

それぞれ検証していくのですが、ここで私はそもそもキャッシュが残っているかどうかの確認方法がわからないことに気づきます。
そのため、まずはキャッシュが残っているかどうかをどのように確認すればいいのかを調べました。

参考にしたブログはこちらです。

ネットワークって奥が深いですね。

こちらのブログによると、GoogleChromeの検証＞Network＞該当のファイルをクリック。
ヘッダー＞レスポンスヘッダー＞cache-controlの項目に「max-age=0」「no-store」という記載があれば、キャッシュが残らないように設定されていると考えて良さそうです。

それでは、まずはログイン画面を見ていきましょう。

キャッシュが残らないようになっていました！
続いて、ログイン後の管理画面を見てみると、、

こちらもキャッシュが残らないようになっています！
そのため、一つ目の検証項目（WordPressのログイン画面と管理画面のキャッシュが残らないようになっている）はクリアです。

続いて、WordPressのログイン状態になっている場合にキャッシュが残らないようになっているかどうかを検証します。
これは、ログイン状態とログアウト状態でcache-controlの記載が変わるかどうかを検証すれば良いはずです。

ログイン状態は、キャッシュが残らないようになっていましたが、ログアウト状態はcache-controlの項目がありませんでした。
そこで、自分のブログだけでなく、他の方のブログも検証してみたところ、同様にcache-controlはありませんでした。
そのため、よくわかっていませんが、これはこれでOKで、2つ目の検証項目（WordPressがログイン状態になっている場合、キャッシュが残らないようになっている）もクリアと考えて良いと思います。

色々といじってみました

設定自体は完了しましたが、せっかくなので色々といじってみてどんな変化があるのかを検証してみます。
まずは、キャッシュのルール変更をしてみます。
『「/post/」がURLに含まれた時に、キャッシュが保存される期間を1日にする』ルール設定を追加するかどうかでどのような挙動になるか検証しました。

	プラグイン有効	プラグイン無効
キャッシュ保存ルール設定あり × ログイン&管理画面のキャッシュ削除ルール設定なし	A ・ログイン&管理画面はキャッシュされない ・「/post/」のページ └ログアウト状態：Cloudflareにルール設定した期間キャッシュされる └ログイン状態：Cloudflareにルール設定した期間キャッシュされる	E ・ログイン&管理画面はキャッシュキャッシュされない ・「/post/」のページ └ログアウト状態：Cloudflareにルール設定した期間キャッシュされる └ログイン状態：Cloudflareにルール設定した期間キャッシュされる
キャッシュ保存ルール設定なし × ログイン&管理画面のキャッシュ削除ルール設定なし	B ・ログイン&管理画面はキャッシュされない ・「/post/」のページ └ログアウト状態：「cf-cache-status」が「DYNAMIC」になる* └ログイン状態：キャッシュされない	F ・ログイン&管理画面はキャッシュされない ・「/post/」のページ └ログアウト状態：「cf-cache-status」が「DYNAMIC」になる* └ログイン状態：キャッシュされない
キャッシュ保存ルール設定あり × ログイン&管理画面のキャッシュ削除ルール設定あり	C ・ログイン&管理画面はキャッシュされない ・「/post/」のページ └ログアウト状態：Cloudflareにルール設定した期間キャッシュされる └ログイン状態：Cloudflareにルール設定した期間キャッシュされる	G ・ログイン&管理画面はキャッシュされない ・「/post/」のページ └ログアウト状態：Cloudflareにルール設定した期間キャッシュされる └ログイン状態：Cloudflareにルール設定した期間キャッシュされる
キャッシュ保存ルール設定なし × ログイン&管理画面のキャッシュ削除ルール設定あり	D ・ログイン&管理画面はキャッシュされない ・「/post/」のページ └ログアウト状態：「cf-cache-status」が「DYNAMIC」になる* └ログイン状態：キャッシュされない	H ・ログイン&管理画面はキャッシュされない ・「/post/」のページ └ログアウト状態：「cf-cache-status」が「DYNAMIC」になる* └ログイン状態：キャッシュされない

Cloudflareにルール設定した期間キャッシュされた場合、レスポンスヘッダーにこのように記述されます。
86,400秒は24時間ですので、「キャッシュが保存される期間を1日にする」というルール設定が反映されていますね。

*「cf-cache-status」が「DYNAMIC」になる場合、レスポンスヘッダーには↓このように記述されます。
「DYNAMIC」は、キャッシュされなかったことを意味しているようです。

プラグイン有効パターンでキャッシュ保存ルールを設定すると、ログイン状態でも該当のページに対して設定したルールが生きていました。
このことから、プラグインよりもCloudflareで設定したルールが優先されるようです。
そのうえで、どんなパターンでもログイン&管理画面はキャッシュされないようになっていることがわかりました。
！？！？
じゃあ、キャッシュ削除ルール設定とプラグイン追加は必要ないのでは、、？
と思いましたが、ちょっともう私には、再度色々と調査、検証する気力がありませんでした。。。
推奨された設定は行ったし、実際に検証も行って問題なさそうなので、今回は一旦これでいいことにします！

まとめ

最後はややぐだぐだになりましたが、設定を進めていく過程でキャッシュについて理解が深まりまたし、CDNの導入時に気を付けるべき点も腹落ちしました。
また、レスポンスヘッダーの見方やその内容について、今回初めて興味を持って調べたことで、高度な内容でしたが今後サーバー周りの設定をする時にこの知識が活かせそうです。

ちょうど、アニメの「薬屋のひとりごと」を見ていて、こんなセリフがありました。
「世の中不思議なことはほとんどない。不思議というなら、それは、知らないだけだ。」（猫猫）
自分にとって未知の領域であるサーバー周りの設定に踏み込んで、調査や実践をしている最中でしたので、このセリフが沁みました。
猫猫のセリフの「不思議」は「わからない」に言い換えられると思うのですが、わからないことがあった時、それはただ知らないだけなのだと実感します。
単に自分が知らないだけで、自分や周りの方々に迷惑をかけないよう、知るための努力をこれからも積み重ねていきたいと思いました。

参考にしたブログ