サーバー「カラフルボックス」つまりcPanelなサーバーにて、Cloudflareを使っています。
カラフルボックス内の有料オプションの「ColorfulBox CDN」ではなく、自分で設置・設定したCloudflareです。

たまに冒頭の画像のように Please wait while your request is being verified… と表示されます。
こうなるとCloudflareのキャッシュをクリアしないとサイトが正常に表示できません。

今回この Please wait while your request is being verified… を解決できましたので、記事にしました。

Please wait while your request is being verified… の解決策を書く前に、状況を少し説明します。

状況

私はCloudflareアカウントが2つあります。

【CloudflareアカウントA】
WordPressが2サイト

【CloudflareアカウントB】
WordPressが5サイト
Laravelが2サイト

【事例紹介】2つのCloudflareアカウント、9サイトのWAF設定方針 にあるように、【CloudflareアカウントB】のWAF設定は少し複雑です。
※今のWAF設定は2番目と3番目を入れ替えてあります。理由は覚えてないです。m(_ _)m

少し前に【CloudflareアカウントA】の2サイトを

• シンレンタルサーバー(Xserverとほぼ同じ)から【CloudflareアカウントB】と同じカラフルボックスに変更した

つまりサーバー移行しました。

サーバー移行に伴い上記2サイトのキャッシュ系プラグインを「W3 Total Cache」から「LiteSpeed Cache」に変更して微調整しました。

私の場合、 Please wait while your request is being verified… が発生するのは【CloudflareアカウントB】のサイトのうち確か2サイトで、毎回必ずではなく発生したりしなかったりです。
一度発生するとCloudflareのキャッシュをクリアしないと解決できませんでした。

サーバー移行以前も含めて、【CloudflareアカウントA】では一度も Please wait while your request is being verified… は発生したことがありません。

かなり試行錯誤しましたが解決できました。

解決策は7つあり、私は【解決策その6】で解決できました。

以下、順番に説明します。

【解決策その1】サーバーのcPanelにて、ModSecurityを「無効」 → 「有効」にしてみる

サーバーのcPanelにログインして、「ModSecurity」をクリック

↓
「すべてのドメインに対して ModSecurity が有効になっています。 ドメインの ModSecurity は無効にできます。」の「無効」をクリック

↓
いったん無効になっているので、「有効」をクリックして再度有効に戻します。

【解決策その1】だけで解決できた！ と書いてある国内ブログもありましたが、私の場合はダメで再発しました。
試しにやってみて数日様子見してみてください。

【解決策その2】サーバーのcPanelにて、ModSecurityを「無効」 にする

【解決策その1】の手順において、

• すべてのドメインに対して ModSecurity が有効になっています。 ドメインの ModSecurity は無効にできます。

の「無効」をクリックして有効に戻さなければ全サイトでModSecurity無効のままになりますが、今回私が色々調査した限りでは、 Please wait while your request is being verified… が表示されるのは

• サーバー側のModSecurityに主な原因があるのではなくCloudflare側(あるいはCloudflare内の設定)に原因の根本がある

ような気がしますので、【解決策その2】はちょっと違う気がします。

【解決策その3】Cloudflareを「一時停止」or「開発者モード」にする

Cloudflareを「一時停止」あるいは「開発者モード」にすれば100％確実に解決できると思いますが、それではCloudflareを設置した意味がありませんので、【解決策その3】はオススメしません。

Cloudflareを「一時停止」するには、Cloudflareの管理画面の「概要」にて、右側の1番下にある「高度な操作」で「Cloudflare を一時停止する」をクリックするだけです。

Cloudflareを「開発者モード」にするには、同じくCloudflareの管理画面の「概要」にて、右側の真ん中付近にある「クイック アクション」で開発モードをチェックONするだけです。

【解決策その4】サーバーのサポートに問い合わせして対応してもらう

サーバーのサポートに問い合わせして、可能であればModSecurityにて自分のCloudflareのIPアドレスを除外してもらいます。

問い合わせする前に、自分のCloudflareのIPアドレスを確認しておく必要があります。

• 自分のCloudflareのDNS(ネームサーバー)を確認する
• CloudflareのDNS(ネームサーバー)を正引きする

ことでIPアドレスが分かります。
※必要なIPアドレスは2つです。

自分のCloudflareのDNS(ネームサーバー)の値を確認する

自分のCloudflareのDNS(ネームサーバー)は、Cloudflare管理画面の「DNS」 → 「レコード」にて、Cloudflare ネームサーバーの下にある2つのほにゃらら.ns.cloudflare.com がそうです。

• ほにゃらら-1.ns.cloudflare.com
• ほにゃらら-2.ns.cloudflare.com

この2つをメモしておきます。

CloudflareのDNS(ネームサーバー)を正引きする

先ほどメモした2つのDNS(ネームサーバー)の値

• ほにゃらら-1.ns.cloudflare.com
• ほにゃらら-2.ns.cloudflare.com

のIPアドレスを調べます。
これを正引きといいます。

正引きは以下のサイトの「ドメイン/IP検索 」で確認できます。 ↓

サーバー監視【無料】

インターネット経由でサーバー監視・ネットワーク監視を無料提供中です。HTTP,FTP,MAILサーバーを24時間監視し異常時には担当者に携帯メールします！

www.cman.jp

↓
「グローバルIPアドレス または ドメイン」の箇所にまずは1つ目の
　ほにゃらら-1.ns.cloudflare.com
を入力して、

• 無料でご利用いただけますが「ご注意・制約事項」を確認下さい

をチェックONして「管理情報照会実行」をクリック

↓
「入力の逆引き または 正引き」の箇所にあるのが「ほにゃらら-1.ns.cloudflare.com」のIPアドレスです。

このIPアドレスをメモしておきます。

同様に「ほにゃらら-2.ns.cloudflare.com」のIPアドレスも調べて、それぞれの値をメモしておきます。

サーバーのサポートに問い合わせをする

• ほにゃらら-1.ns.cloudflare.com
• ほにゃらら-2.ns.cloudflare.com

のIPアドレスを調べたら、サーバーのサポートに問い合わせをするわけですが、単に丸投げしても対応してくれないと思います。

以下は私が問い合わせをした時のメッセージを改造したやつです。
これをご自身の状況にあわせて修正して問い合わせをすればたぶん対応してくれるかと思います。

お世話になります、●名前●です。

●サーバーサービス名(例、カラフルボックスとか)●内の以下のWordPressサイト
https://ほにゃらら.com/
https://ほにゃらら.com/
https://ほにゃらら.com/
は自分で開設・設定したCloudflareを使っています。

たぶん●週間くらい前から、cPanelのModSecurityおよびCloudflareが原因で、サイトを表示するとランダムに
　・Please wait while your request is being verified
と表示され、正常に表示できません。

「必ずこのサイトがダメ」とか「100％必ず」というわけではなさそうです。

例えば、昨日は問題なかった
https://ほにゃらら.com/
が本日は正常に表示できません。
※表示不具合をご確認していただくたため、後述の「Cloudflareのエッジキャッシュをクリアする」は本日は実行していません。

https://ほにゃらら.com/
は昨日は正常に表示できていませんでしたが本日は正常に表示されています。

上記サイトはCloudflareを経由してはいますが、
https://ほにゃらら.com/
https://ほにゃらら.com/
に関してはCloudflareのエッジキャッシュは無効にしてあります。


おそらく、WordPressサイト、かつ、ModSecurity、かつ、Cloudflareの場合に、ランダムで「Please wait while your request is being verified」の表示になるみたいです。

ググった限りでは解決策は
　・全サイト、ModSecurityを有効 → 無効 → 有効にする
　・Cloudflareのエッジキャッシュをクリアする(※これだと一時的に正常表示できるだけみたいです。)
　・CloudflareのキャッシュルールのEdgeTTLを、
ステータスコード：シングルコード
ステータスコード：302
期間：ストアなし
にする。
　・サーバー会社に問い合わせして、(可能な場合は)ModSecurityのファイアーウォールからCloudflareのIPアドレスを除外してもらう

【参考サイト】
https://stilltalkintv.com/post-2140/

https://wordpress.org/support/topic/please-wait-while-your-request-is-being-verified/

https://community.cloudflare.com/t/cloudflare-caching-issue/341549/6

https://community.x10hosting.com/threads/cloudflare-issue.210690/

上記解決策のうち、
　・サーバー会社に問い合わせして、(可能な場合は)ModSecurityのファイアーウォールからCloudflareのIPアドレスを除外してもらう
以外の全ては昨日までに全て実行済みです。

それでも解決出来ない場合は、
　・ModSecurityを無効にする
　・Cloudflareにて「一時停止」あるいは「開発者モード」にする
のどちらかを設定すれば解決できるはずですが、どちらも最後の手段です。

たぶん私なら、
　・ModSecurityを無効にする
にします。

　・サーバー会社に問い合わせして、(可能な場合は)ModSecurityのファイアーウォールからCloudflareのIPアドレスを除外してもらう
に関して、●サーバーサービス名(例、カラフルボックスとか)●側でご対応していただくことは可能でしょうか？
お忙しいところ恐縮ですが、ご検討・ご対応よろしくお願いします。

サーバー会社が対応してくれるかどうかは完全にサーバー会社次第ですので、「対応してくれたらラッキー」くらいの感覚です。
私の場合はカラフルボックスは対応してくれましたが、残念ながら私の場合は【解決策その4】では解決できずに再発しました。

【解決策その5】Cloudflareのページキャッシュにて、「キャッシュの対象」にしてあるルールに「302の場合はキャッシュしない(302のTTLをストアなしにする)」という設定を追加する

Cloudflareのページキャッシュにある「キャッシュの対象」にしてあるルールに以下の条件を追加します。

■注意■
色々試した結果、この解決策は不要です、と思います。
私はこのルールはいったん追加しましたが再発したので追加した内容は削除して元に戻しました。

Cloudflareの設定 → Caching → Cache Rulesにて、「キャッシュの対象」にしてあるルールのその下に、「ステータスコード TTL」を以下のように追加します。

 

ルール名：既存のルール名 + 【302対策】とか
ステータスコード TTL
スコープ：シングルコード
ステータスコード：302
期間：ストアなし

 

【解決策その6】■これで解決 ■CloudflareのWAFのカスタムルールにて、自分のIPアドレスと /cdn-cgi/ を除外する

Please wait while your request is being verified… の件はかなり時間をかけて自分でも調査しました。
Please wait while your request is being verified… のページでは延々と302リダイレクトがかかりっぱなしの状態みたいでしたので、個人的には302関係が原因なのかと思いました。

世界中のサイトを調べて色々試したものの再発し、最後はAIに相談しながらさらに調査・検証を進めました。

「Please wait while your request is being verified」が出る原因の候補

以下の2つはAIによる回答です。
※複数のAIとかなり長時間・数日かけてやり取りした内容を超端折って書いています。

自分のIPアドレスを除外するのって意味あるの？

• 自分のIPアドレスを除外するって意味あるの？

そう思いますよね？

新規記事を追加したり既存の記事を修正したりすると、(私の場合)すぐにキャッシュをクリアしてそのページの表示確認をします。
誤字があったりしたらすぐに修正して、再度キャッシュをクリアして、すぐにまたそのページの表示確認をします。

つまり、自分のIPアドレスは短時間に繰り返しそのページを訪れます。

自分自身の短時間のアクセスが原因でCloudflareのWAFのチェックに引っかかり Please wait while your request is being verified… と表示され、それがCloudflareのエッジキャッシュとして保存されると、一般ユーザーがそのページを訪問しても当然 Please wait while your request is being verified… のままです。
これを回避するために、CloudflareのWAF設定にて自分のIPアドレスを除外する・・・という理屈です。

また、CloudflareのWAFは様々な脅威からサイトを守ってくれますが、WAFのカスタムルールおよびページキャッシュの設定次第ではおそらく誤爆もあります。

WAF・Webアプリケーションファイアウォール

CloudflareのWebアプリケーションファイアウォールサービスは、業界をリードする保護を提供します。当社のクラウドベースのWAFサービスがアプリケーションを安全に保つ仕組みをご覧ください。

www.cloudflare.com

・
・
・
と偉そうに書いたものの、実はハッキリとは理解していません＞＜

私の予想ではCloudflareのWAFにて /cdn-cgi/ を除外するのが正しい解決策な気がしますが、複数のAIに相談して「自分のIPアドレスを除外する」というアドバイスが複数ありましたので、念の為除外設定することにしました。

ということで、CloudflareのWAFのカスタムルールにて、1番上から以下の2つのルールを追加します。

WAFのカスタムルールで自分のIPアドレスと /cdn-cgi/ を除外する

Cloudflareの設定 → セキュリティ → WAFのカスタムルールにて、

• 自分のIPアドレス(IPv4)
• 自分のIPアドレス(IPv6)
• /cdn-cgi/

の3つを除外します。

• 自分のIPアドレス(IPv4)
• 自分のIPアドレス(IPv6)

の値は、

IPアドレスの確認(IPv4アドレス・IPv6アドレス)

このページでは今現在接続しているIPアドレスを確認することが出来ます。IPv4・IPv6それぞれのIPアドレスを確認することが出来ます。

minsoku.net

で確認できます。

(ip.src eq ●自分のIPアドレス(IPv4)●) or (ip.src eq ●自分のIPアドレス(IPv6)●)

(http.request.uri contains "/cdn-cgi/" and not cf.client.bot)

たぶん2つ目のルールが解決策だと思いますが、念の為1つ目も残したまま・有効のままにしてあります。

【解決策その7】【たぶん不要】Cloudflareのキャッシュルールにて、Cloudflareアカウント内の全サイトの /(つまりトップページ )および /cdn-cgi/ を除外(キャッシュをバイパス)する

この記事の冒頭で書きましたが、【解決策その6】と同時に【解決策その7】も設定したものの、ちょっと違う気がするので【解決策その7】の設定は残したまま無効にしてありますが、今のところ Please wait while your request is being verified… は再発していません。

【たぶん不要】トップページと /cdn-cgi/ をページキャッシュから除外する

Cloudflareの設定 → Caching → Cache Rulesにて、以下の2つを上から1番目・2番目に追加します。

※現時点では、追加したルール2つは残したまま2つとも無効にしてあります。

ルール名はお好みに変更してOKです。

(http.host eq "●ホスト名その1●" and http.request.uri.path eq "/") or (http.host eq "●ホスト名その2●" and http.request.uri.path eq "/")

(http.request.uri contains "/cdn-cgi/")

再度書きますが、【解決策その7】はたぶん不要です。

「Please wait while your request is being verified…」と表示される件の解決策は以上となります。

参考

以下は複数のAIとのやり取りの残骸ですが、将来役に立つかもしれないのでメモとして書いておきます。

以下は、参考にしたサイトです。

Cloudflare経由でmixhostのWordpressログイン不可！解決方法を紹介 - レンタルサーバー 賢者の選択

2022年9月27日未明あたりから、Cloudflareを有効にしたWordpressサイトが表示しにくくなり、ダッシュボードにログインできなくなりました。

stilltalkintv.com

Please wait while your request is being verified…

Please wait while your request is being verified… Resolved pjc123 (@pjc123) 10 months, 2 weeks ago On the website listed...

wordpress.org

Just a moment...

community.cloudflare.com

Using Cloudflare “Cache Everything” with Imunify360

Cloudflare Cache Everything plugin caused and endless CAPTCHA loop giving visitors now change to pass CAPTCHA.

blog.imunify360.com

以下、全て追記です。

【番外編】Windowsのタスクスケジューラ・サーバーのCRONで定期的にCloudflareのキャッシュをパージする【Cloudflare API利用】

解決策その1234567を試したけどダメで、手動で定期的にCloudflareのキャッシュをパージするしか解決策がない場合は、以下の手順でWindowsのタスクスケジューラあるいはサーバーのCRONで定期的にCloudflareのキャッシュをパージすることが可能です。

「Cloudflare API」経由でCloudflareのキャッシュパージを実行します。

【共通】Cloudflareのキャッシュパージ専用のAPIトークンを作成・取得する

Cloudflareの管理画面の「APIトークンを取得」

Just a moment...

dash.cloudflare.com

の「トークンを作成する」をクリック

画像が続いて見づらいので少し小さく表示しています。
画像をクリックすれば本来のサイズで表示されます。※お使いの端末の画面横幅に準じます。

　↓

「カスタムトークンを作成する」の「始める」をクリック

　↓

として、「概要に進む」をクリック

　↓

の下にある「トークンを作成する」をクリック

以上でキャッシュパージ専用のAPIトークンが作成され、

と表示されてるはずです。

ここまでの作業でCloudflareにてキャッシュパージ用のAPIトークンは作成されましたが、これが正しく実行できるのか、WindowsのタスクスケジューラあるいはCRONに登録する前にWindowsのターミナルで実行確認してみます。

Windowsのターミナル(あるいはPowerShell)で実行確認してみる

先に書いておきますと、Cloudflare API経由でキャッシュパージするには

• 「キャッシュパージ専用のAPIトークン」の値
• ゾーンIDの値

が必要です。

Windowsのターミナル(あるいはPowerShell)で下記コマンド

curl.exe -X POST "https://api.cloudflare.com/client/v4/zones/●ゾーンID●/purge_cache" -H "Authorization: Bearer ●APIトークン●" -H "Content-Type: application/json" --data '{"purge_everything":true}'

を実行すると以下のようになります。

上記のようになれば

• Cloudflareのキャッシュパージ専用のAPIトークンの作成・設定

および

• Windowsターミナル(あるいはPowerShell)でのCloudflareのキャッシュパージ

の全てが正しく作成・設定・実行できています。

●Windowsのタスクスケジューラに登録して実行する場合

下記内容で「purge_cloudflare_cache.ps1」等のファイル名で保存し(文字コード：UTF-8、改行コード：LF)、タスクスケジューラに登録します。

# purge_cloudflare_cache.ps1
# ログファイルの設定
$LogFile = "C:\Logs\purge_cloudflare_cache.log"
$MaxLogSize = 5MB  # ログファイルの最大サイズ

# ログディレクトリが存在しない場合は作成
$LogDir = Split-Path $LogFile -Parent
if (-not (Test-Path $LogDir)) {
    New-Item -ItemType Directory -Path $LogDir -Force
}

# ログファイルのサイズチェックとクリア
if (Test-Path $LogFile) {
    $fileSize = (Get-Item $LogFile).Length
    if ($fileSize -ge $MaxLogSize) {
        Clear-Content -Path $LogFile
        "$(Get-Date): Log file cleared due to size limit ($MaxLogSize)" | Out-File -FilePath $LogFile -Append
    }
}

# キャッシュパージの実行
try {
    $response = curl.exe -X POST "https://api.cloudflare.com/client/v4/zones/●ゾーンID●/purge_cache" `
                        -H "Authorization: Bearer ●APIトークン●" `
                        -H "Content-Type: application/json" `
                        --data '{"purge_everything":true}' -ErrorAction Stop
    "$(Get-Date): Cache purge successful: $response" | Out-File -FilePath $LogFile -Append
} catch {
    "$(Get-Date): Cache purge failed: $_" | Out-File -FilePath $LogFile -Append
}

実行間隔は、まずは週一で様子見してみてください。

●サーバーのCRONで実行する場合

#!/bin/bash
# purge_cloudflare_cache.sh

# ログファイルの設定
LOGFILE="/var/log/purge_cloudflare_cache.log"
MAX_LOG_SIZE=5242880  # 5MB in bytes

# ログファイルのサイズチェックとクリア
if [ -f "$LOGFILE" ]; then
    FILESIZE=$(stat -c%s "$LOGFILE")
    if [ "$FILESIZE" -ge "$MAX_LOG_SIZE" ]; then
        > "$LOGFILE"
        echo "$(date): Log file cleared due to size limit (5MB)" >> "$LOGFILE"
    fi
fi

# キャッシュパージの実行
RESPONSE=$(curl -s -X POST "https://api.cloudflare.com/client/v4/zones/●ゾーンID●/purge_cache" \
                -H "Authorization: Bearer ●APIトークン●" \
                -H "Content-Type: application/json" \
                --data '{"purge_everything":true}')
if echo "$RESPONSE" | grep -q '"success":true'; then
    echo "$(date): Cache purge successful: $RESPONSE" >> "$LOGFILE"
else
    echo "$(date): Cache purge failed: $RESPONSE" >> "$LOGFILE"
fi

上記コードは

#!/bin/bash
# purge_cloudflare_cache.sh

# ログファイルの設定
LOGFILE="/var/log/purge_cloudflare_cache.log"
MAX_LOG_SIZE=5242880  # 5MB in bytes

# ログファイルのサイズチェックとクリア
if [ -f "$LOGFILE" ]; then
    FILESIZE=$(stat -c%s "$LOGFILE")
    if [ "$FILESIZE" -ge "$MAX_LOG_SIZE" ]; then
        > "$LOGFILE"
        echo "$(date): Log file cleared due to size limit (5MB)" >> "$LOGFILE"
    fi
fi

# キャッシュパージの実行
RESPONSE=$(curl -s -X POST "https://api.cloudflare.com/client/v4/zones/●ゾーンID●/purge_cache" \
                -H "Authorization: Bearer ●APIトークン●" \
                -H "Content-Type: application/json" \
                --data '{"purge_everything":true}')
if echo "$RESPONSE" | grep -q '"success":true'; then
    echo "$(date): Cache purge successful: $RESPONSE" >> "$LOGFILE"
else
    echo "$(date): Cache purge failed: $RESPONSE" >> "$LOGFILE"
fi

でもたぶん問題ないです、と思います。

# .CF_API_TOKEN ファイル
CF_API_TOKEN="●APIトークン●"

source /path/to/.CF_API_TOKEN

-H "Authorization: Bearer ●APIトークン●"
を
-H "Authorization: Bearer $CF_API_TOKEN"

CRONのコマンドは例えば

# 毎週日曜日の7時に実行
0 7 * * 0 /ほにゃらら/public_html/purge_cloudflare_cache.sh

です。

1週間経過してpurge_cloudflare_cache.logが作成されていればCRON自体は実行されています。

purge_cloudflare_cache.logの中を見てエラーがなければ、APIトークン作成・設定およびCRONでのキャッシュパージの全てが正しく実行できています。

WindowsのタスクスケジューラあるいはサーバーのCRONで定期的にCloudflareのキャッシュをパージする件は以上です。

WindowsのタスクスケジューラあるいはサーバーのCRONで定期的にCloudflareのキャッシュをパージするの件は、「Please wait while your request is being verified…」の解決策としては【解決策その1234567】および後述の【解決策その8】のどれものダメな場合の最終手段です。

ただし、Cloudflareの無料版の場合は、定期的にエッジキャッシュを削除することでデメリットよりメリットが上回るような気がします。

Cloudflareのエッジキャッシュを定期的に削除するメリット・デメリット

Cloudflareの有料プランをお使いの場合はエッジキャッシュを定期的に削除する必要はありません。
私のようにCloudflareの無料プランでエッジキャッシュを使っている場合は、定期的にエッジキャッシュを削除することでメリット・デメリットが発生します。

ちょっと難しい内容ですが、ご興味あればお読みください。

■メリット■
エッジキャッシュから押し出されてページ表示が遅くなる確率が下がります。

 

Cloudflareのエッジキャッシュを使っている場合、当然ですが無料プランのサイトより有料プランのサイトのほうが優遇されます。

■注意■
単にCloudflareを使うだけでは各ページはCloudflareにキャッシュされず、単に画像ファイルやcssファイルがキャッシュされるだけです。
ちゃんと設定すれば、無料プランでもCloudflareに各ファイルおよび静的htmlをキャッシュさせることが可能です。

Cloudflareの各種設定を代行します。

Cloudflare設定代行でサイトを強化しませんか？表示の高速化・安定性向上、セキュリティ強化など、様々な面でのメリットが期待できます。経験豊富な専門家がサポートし、検索エンジン上位へのランキング向上やトラフィック増加を実現します。

www.kaimonojyoz.jp

WordPressにログイン状態のページをCloudflare側がキャッシュする不具合？も回避して設定します。

 

ご興味あればご検討ください。

 

エッジキャッシュの仕組みを簡単に説明しますと、世界中に超たくさんあるCloudflareのサーバーに各サイトの各ページの静的htmlがキャッシュが随時保存されて、ページ訪問者の所在地に物理的に近い場所のCloudflareのエッジサーバーのキャッシュでもってページが表示されることで、サーバーキャッシュで表示するより早くなる仕組みです。

 

エッジサーバーは容量に限りがあるので、エッジサーバーのエッジキャッシュの容量がいっぱいになると古いキャッシュは押し出されて破棄されます。
当然、Cloudflareの有料プランあるいはAPO(Automatic Platform Optimization for WordPress)などの課金しているサイトが優遇されます。

 

つまり、エッジサーバーのエッジキャッシュの容量がいっぱいになるとCloudflareの無料プランのサイトのエッジキャッシュは優先的にエッジキャッシュから消えます。

 

(静的htmlがキャッシュされるようにちゃんと設定してある場合)その後無料プランのサイトのページを表示すれば再度エッジキャッシュが作成されます。

 

無料プランの場合に、自分で手動でキャッシュパージして2回目の表示が早くなるのはこのためです。

 

 

無料プランの場合に、後述の

• スクリプトおよびCRONを使って先回りでキャッシュを作成できる
• WordPressのキャッシュ系プラグインで同様のことが実行可能である

に該当する場合のみ、エッジキャッシュが古くなって押し出されるのを待つ前に自分からCRONでキャッシュパージして、先回りでエッジキャッシュを生成することで、ページ表示が遅くなるのをある程度回避することが可能となります。

■デメリット■
最初の訪問者のみ、(相対的に)ページ表示が遅くなります。

PageSpeed Insightsが携帯電話のスコアだけ不安定な理由(最終・当サイトの高速化)

PageSpeed Insightsの『パフォーマンスの問題を診断する』で携帯電話のスコアだけ乱高下する原因を調査しました。

www.kaimonojyoz.jp

の ■これらのキャッシュの関係■ と ■これらのキャッシュの関係■ の箇所に書きましたが、

• サーバーキャッシュ
• ブラウザキャッシュ
• WordPressのキャッシュ系プラグインのキャッシュ
• Cloudflareのキャッシュ(エッジキャッシュ)

キャッシュに色々種類がありますが、大まかに言うと

■リクエストの流れ
ページを訪問したユーザー → (サービスワーカー) → Cloudflare → WordPressのキャッシュ系プラグイン → サーバーキャッシュ → オリジンサーバー

という流れになります。

 

定期的にエッジキャッシュを削除すると定期的に上記流れでいう「Cloudflare」のキャッシュを再作成することになります。
従って最初の1人目だけ(相対的に)ページ表示が遅くなります。

 

スクリプトおよびCRONを使って先回りでキャッシュを作成しておけば上記デメリットはほぼ100％回避できますが、本記事の主旨から外れるため詳細は割愛します。
あるいはW3 Total CacheやLiteSpeed Cach等などのWordPressのキャッシュ系プラグインによってはそれに近い機能があります。

以上のメリット・デメリットを考慮した場合、Cloudflareの無料版を使っている場合は

• スクリプトおよびCRONを使って先回りでキャッシュを作成できる
• WordPressのキャッシュ系プラグインで同様のことが実行可能である

に該当する場合のみ、定期的にエッジキャッシュを削除することでデメリットよりメリットのほうが大きい気がします。

Cloudflareのエッジキャッシュを定期的に削除するのがベターな場合は、あくまで一般ユーザーを先回りしてキャッシュを作成できる場合のみです。
そうでない場合はCloudflareとWordPressにお任せするのが良いかと思います。

なお

• メリット：エッジキャッシュから押し出されてページ表示が遅くなる確率が下がります。
• デメリット：最初の訪問者のみ、(相対的に)ページ表示が遅くなります。

表示速度に関して、上記メリット・デメリットよりも圧倒的に手っ取り早いのは「超高速サーバー ＆ そこそこの料金プラン以上」にすることです。

【解決策その8(※現時点では未検証)】Cache Rules内のルールにて、エッジTTL(オプション)を設定しない

番外編の箇所の記事を追記する時に見つけた参考サイト

Using Cloudflare “Cache Everything” with Imunify360

Cloudflare Cache Everything plugin caused and endless CAPTCHA loop giving visitors now change to pass CAPTCHA.

blog.imunify360.com

要約すると、

つまり、Cache Rules内のルールの中に

があり(ここまではCloudflare利用者のほぼ100％がこのルールがあるはずです)、オプションとして

とか設定してあると、「Please wait while your request is being verified…」が発生する・・・というのがImunify360公式の見解です。

画像クリックで拡大表示できます。
↓

私の場合、手持ちのCloudflareアカウントA・アカウントBのサイトに関して、一定条件以外のサイト・ページ(要はGoogleにインデックスさせたいサイト・ページのみ)でエッジTTLが設定してあります。

【解決策その8】Cache Rules内のルールにて、エッジTTLを設定しない
これが「Please wait while your request is being verified…」の1番の正解というか正しい解決策になりそうな気がします。

手持ちのサイトで今は再発してないのでまだ試してないです。
再発したら試してみます。
・
・
・
でもエッジTTLを設定しないとPageSpeed Insightsで文句言われるんだよなぁ＞＜