
Cloudflareヘッダー検証の新しい画面に合わせ、準備からドライラン、復旧手順の保存、遮断開始までを5段階で確認します。
こんなときに使います
たとえば:旧マニュアルと画面が違う、どの順番で設定を進めればよいか確認したい。
操作する画面の開き方
WordPress管理画面の「OptiB」から「セキュリティ・認証」→「セキュリティ」→「シークレットヘッダー検証(Cloudflareガード)」の画面を開きます。表示名は導入版により「Cloudflareヘッダー検証」の場合があります。
対象バージョン:v2.8.8以降
実画面で確認
画面を見ながら確認する

- 段1でシークレットが作成済みか確認します。運用中の値を不要に作り直しません。
- 同じ値をCloudflareのルールに設定してから、段2の「確認して開始」に進みます。
- 確認後はドライランで通常の閲覧・ログイン・外部連携を確かめます。
実画面で確認
続きの画面で確認する

- 段3でアクセスの記録を観察します。
- 段4で復旧手順をダウンロードし、サイト外で読める場所に保存します。
- 必要なアクセスと復旧方法を確かめた担当者が、段5で遮断を有効にします。
始める前に
v2.8.7で5段階の画面に変わり、v2.8.8で新規設定時の到達確認が修正されました。本記事はv2.8.8以降を基準にしています。
設定を間違えると管理者もサイトに入れなくなるため、サーバー管理担当者と進めます。Cloudflareとサーバーの設定を戻せる手段、バックアップを先に用意してください。既存の遮断設定は更新だけでは変わりません。
段1:シークレットを作る
- 画面の「シークレットを作る」で合言葉を用意します。既存サイトで運用中の値を、理由なく作り直さないでください。
- Cloudflareのリクエストヘッダー変更ルールで、全リクエストに
X-OptiB-Origin-Verifyと同じシークレットを付けます。 - シークレットを公開記事や画像に写さず、安全に管理します。
段2:確認して開始
Cloudflare側の設定後、「確認して開始」を押し、到達確認の結果を確認します。v2.8.8では、古いmu-pluginがある場合、この操作時に自動更新されます。手作業で入れ直す必要はありません。
確認できなければ、画面に出た原因を調べます。合格しないまま遮断へ進めないでください。
段3:ドライランで様子を見る
ドライランはアクセスを止めずに記録する予行練習です。通常のページ表示、ログイン、使っている外部連携を確認します。
観察が24時間未満の場合は警告が出ます。警告を了承して進めることはできますが、必要な通信を記録で確認してから判断してください。PHPモードではドライラン中と停止中は遮断しないため、この状態で遮断確認が通らないこと自体は異常ではありません。
段4:復旧手順をダウンロード
復旧手順ファイルをダウンロードし、サイトに入れなくなった場合にも参照できる場所へ保存します。内容を確認して画面のチェックを入れます。ファイルの取得と確認が、遮断開始の前提です。
段5:遮断を有効にする
必要なアクセスと復旧手段を確認してから、担当者が遮断を有効にします。PHPモードでは直後に遮断の動作確認が行われ、正しく働かなければドライランに戻って原因が表示されます。
原因を直した後は、段3の「段5で再度有効化を試す」から進め直します。通常ページ、ログイン、連携が使えることも確認します。
詳細設定で運用している場合
レイヤーやモードの直接選択は、画面下部の「詳細設定(サーバの作業ができる人向け)」にあります。.htaccessで運用中のサイトは「詳細設定で運用中」と表示され、既存の遮断は続きます。PHP側だけ停止しても、.htaccess側の制限は解除されません。
ここまでできたら完了
- 5段階の状態と通常アクセスの結果を担当者と確認した
- 復旧手順をサイト外でも参照できる場所に保存した
