Cloudflareを使っているWordPressで「Error 1010」や「The owner of this website has banned your access based on your browser's signature」と表示されたら、クライアントのブラウザー署名を理由にアクセスが拒否されています。
同じサイトでも、通常のブラウザーは開けるのに、特定ブラウザー、古いアプリ、監視ツール、クローラー、外部連携だけが失敗することがあります。WordPressのパスワードや投稿権限を変更する前に、Cloudflareがどの要求情報を問題として扱ったかを確認します。
最初にエラー画面、Ray ID、発生時刻とタイムゾーン、完全なURL、ブラウザー・アプリ名、発生時のUser-Agent、利用回線を保存してください。Browser Integrity CheckやWAFを先に全面停止すると、誤検知の原因が分からないまま防御だけが弱くなります。
先に結論：Error 1010は8段階で確認する
- 1010の画面、Ray ID、時刻、URLを保存する
- 特定ブラウザーだけか、複数クライアントにも起きるかを確認する
- 発生時のUser-Agent、拡張機能、アプリ、回線を記録する
- 一度だけ最新の通常ブラウザーで比較する
- Security EventsでAction・Service・User Agentを照合する
- Browser Integrity Check、User Agent Blocking、Custom Rulesを確認する
- 正規通信なら対象を限定して安全に修正する
- 主要ページ、管理画面、API、防御の再動作を確認する
特定IPが拒否されている場合は、Cloudflare Error 1006系のIP遮断確認手順を使います。一定時間内の要求数で止まる場合は、Cloudflare Error 1015のレート制限確認手順へ進んでください。
Error 1010とは？
Cloudflare公式のError 1010は、サイト所有者がクライアントのブラウザー署名を理由にアクセスを拒否した状態です。公式の解決案では、サイト所有者がBrowser Integrity Checkの設定を確認できると案内されています。
ここでいうブラウザー署名を、画面に表示されたブラウザー名だけに限定しないことが重要です。要求に含まれるUser-Agentや一般的なHTTPヘッダー、欠落・非標準な要求の特徴など、Cloudflare側で評価される通信情報を調べます。
Browser Integrity Checkが確認するもの
Cloudflare公式のBrowser Integrity Checkによると、BICはスパマーに悪用されることが多い一般的なHTTPヘッダーを調べ、User-Agentがない、または非標準なUser-Agentを使う訪問者やクライアントをChallengeします。公式仕様ではBICは既定で有効です。
ただし、1010が出たからといって「その利用者が攻撃者」と断定はできません。古い組み込みブラウザー、独自アプリ、監視・取得ツール、プライバシー機能、セキュリティ製品、プロキシなどが、一般的なブラウザーとは異なる要求を送る場合があります。
逆に、User-Agentだけを一般的なブラウザーへ偽装して通す方法も安全な解決ではありません。正規クライアントなら、用途、送信元、対象パス、認証方式、更新責任を確認できる状態にします。
1010・User-Agentルール・1006系・1015・1020・403の違い
| 表示・機能 | 主な判定軸 | 最初の確認先 |
|---|---|---|
| 1010 | ブラウザー署名・要求ヘッダーの特徴 | BIC、User Agent、Security Events |
| User Agent Blocking | 設定した特定のUser-Agent値 | User agent rules、Custom Rules |
| 1006・1007・1008・1106 | 訪問元IP | IP、IP Access Rules |
| 1015 | 要求回数 | Rate Limiting Rules |
| 1020 | WAFなどのルール条件 | Ray ID、Service、Rule |
| HTTP 403 | Cloudflareまたはオリジンの一般的な拒否 | 応答元、WAF、Webサーバー、権限 |
1010の文言がなく一般的なAccess Deniedなら、Cloudflare Error 1020のRay ID確認手順も確認します。Cloudflare固有番号がない403なら、WordPressの403 Forbiddenを直す確認順で応答元を分けてください。
最初に影響範囲を切り分ける
一つのブラウザーだけか
同じ端末、同じ回線、同じURLで、問題のブラウザーと最新の一般的なブラウザーを一度だけ比較します。片方だけ1010になるなら、ブラウザー、拡張機能、User-Agent、要求ヘッダーの差が有力です。比較のたびにRay IDと時刻を記録します。
特定アプリ・自動処理だけか
監視、RSS取得、API連携、モバイルアプリ、Webhookの確認処理などだけが失敗する場合は、そのクライアントが実際に送るUser-Agentとヘッダーを確認します。製品名の推測ではなく、失敗した要求の記録を使います。
拡張機能やセキュリティ製品の影響か
プライバシー拡張、企業プロキシ、セキュリティソフトが要求ヘッダーを変更する場合があります。すべて無効化するのではなく、管理された検証環境で一要素ずつ比較し、業務端末の保護を恒久的に弱めないでください。
利用者・担当者から受け取る情報
- エラー画面全体とError 1010の文言
- Ray ID、発生時刻、タイムゾーン
- 失敗した完全なURL、HTTPメソッド、直前の操作
- ブラウザー、OS、アプリ、ツールの名称とバージョン
- 発生時のUser-Agent
- 拡張機能、VPN、企業プロキシ、セキュリティ製品の有無
- Wi-Fi、携帯、会社などの回線種別
- 別ブラウザー・別端末・別回線での結果
- 初回発生と直近再現の時刻
HARや詳細ログを受け取る場合は、Cookie、Authorization、フォーム内容、個人情報などが含まれ得ます。必要最小限の範囲で取得し、安全な保管先、共有相手、削除時期を決めてください。
Security EventsでBrowser Integrity Checkを確認する
Cloudflare公式のSecurity Eventsは、Browser Integrity Checkを含むセキュリティ製品が処理・記録したイベントを調査できます。IP、User Agent、Path、Country、Host、Action、Serviceなどで絞り込めます。
1. 新しいRay IDと時刻を使う
古いスクリーンショットだけでなく、再現した直後のRay IDと時刻を使います。利用者のローカル時刻とCloudflare側の表示をそろえ、数分の幅を持たせて検索します。
2. ServiceとActionを特定する
Browser Integrity Checkが記録されているか、別のUser Agent Blocking、Custom Rule、Managed Ruleなどが処理していないかを確認します。1010の見た目だけで原因機能を決め付けず、該当イベントのServiceとActionを読みます。
3. 成功要求と失敗要求を比較する
同じIP・URLで一般ブラウザーは成功し、特定クライアントだけ失敗する場合は、User Agent、Host、Path、メソッド、ヘッダーの有無を比較します。一度に複数条件を変えると差が追えないため、一要素ずつ確認します。
Browser Integrity Checkの設定を確認する
Cloudflareダッシュボードで対象アカウントとゾーンを選び、Security SettingsのBrowser Integrity Checkが有効か確認します。変更前に現在値、対象ゾーン、確認日時、関連する障害記録を保存してください。
公式にはBICをゾーン全体で無効化する方法もありますが、誤検知が一つ見つかっただけで全体をOFFにする必要はありません。Custom RuleのSkip actionでBICを選択的にSkipするか、Configuration Ruleで特定ホスト・パスに対して有効・無効を切り替える方法があります。
User Agent BlockingとCustom Rulesも確認する
Cloudflare公式のUser Agent Blockingは、設定した特定のUser-Agent値をBlockまたはChallengeします。既存のUser agent ruleが問題のクライアントと一致していないか確認してください。
現在の公式資料では、特定User-Agentの制御にはUser agent rulesよりCustom Rulesが推奨されています。Custom RulesならHost、Path、メソッドなどと組み合わせて対象を狭められます。ただしUser-Agentは送信側が変更できるため、強い本人確認の代わりにはしません。
安全な修正方法
通常の利用者はクライアント側を先に整える
古いブラウザーやアプリなら、提供元の正式な更新版へ上げます。User-Agentを隠す拡張機能やプロキシが関係する場合は、管理された検証で原因を確認し、必要ならその製品の正式な設定を見直します。出所不明の拡張機能を追加してUser-Agentを偽装しないでください。
正規の自動クライアントは識別と認証を整える
監視、Webhook、API、クローラーなどは、提供元が定めるUser-Agent、送信元IP、署名、認証方式、更新通知を確認します。単に一般ブラウザーへ偽装させず、運営者が正規通信と検証できる条件を用意します。
BICを外すなら対象を最小限にする
正規クライアントにBICが適さないと確認できた場合は、専用Host、必要なPath、HTTPメソッド、送信元、認証済み条件などを組み合わせ、その通信だけBICをSkipまたは無効化します。対象外の公開ページ、ログイン、XML-RPC、REST APIには必要な検査を残します。
やってはいけない対処
- 証拠を保存せずBICやWAFを全面停止する
- User-Agentを一般ブラウザーへ偽装して原因確認を終える
- 報告されたIPを無条件でAllowにする
- 拡張機能やセキュリティ製品を恒久的に全部無効化する
- 複数のCloudflare設定を同時に変更する
- 自動クライアントを認証なしで広く通す
- 別ブラウザーで開けたことだけで解決扱いにする
- 無関係なWordPressユーザー、テーマ、プラグインを削除する
修正後に確認すること
- 問題の正規ブラウザー・アプリから1010が消えた
- 最新の主要ブラウザーでも公開ページを表示できる
- トップ、投稿、固定ページ、カテゴリー、検索、404が正常
- 管理画面のログイン、保存、プレビューが正常
/wp-json/と必要なREST APIが正常- フォーム、決済、Webhook、監視、RSSが正常
- 画像、CSS、JavaScript、サイトマップを取得できる
- 対象外の経路ではBICと他の防御が動作している
- Security Eventsで同じ誤検知が再発していない
- 1010が1006系、1015、1020、403へ変わっていない
REST APIや外部連携が1010解消後も失敗する場合は、WordPressのJSONレスポンスエラー確認手順で、認証、URL、REST API、サーバー応答を分けてください。
直らないときの確認順
修正後も1010が続く場合は、正しいゾーンを変更したか、BIC以外のUser Agent BlockingやCustom Ruleが残っていないか、Skip ruleの順序と対象範囲が合っているか、アカウントとゾーンの設定が重なっていないかを確認します。
再テストではブラウザーに残った古い画面ではなく、新しいRay IDと時刻を使います。Cloudflare Supportへ相談する場合は、エラー画面、Ray ID、UTCとローカル時刻、URL、発生時IP、User-Agent、Action・Service・Rule、変更前後の設定、再現結果をサイト所有者から提出します。
よくある質問
ブラウザーを変えれば解決ですか？
比較診断には役立ちますが、元の正規クライアントが必要なら原因は残っています。成功・失敗要求のRay ID、User-Agent、Serviceを比較し、更新または限定的な設定修正へ進んでください。
Cookieを消せば直りますか？
ブラウザー署名や要求ヘッダーが原因なら、Cookie削除だけで直るとは限りません。何度も削除する前に、新しいRay IDとSecurity Eventsで処理した機能を確認します。
Browser Integrity CheckをOFFにしてもよいですか？
公式には全体OFFの設定もありますが、誤検知が一件あるだけなら、まず対象Host・Path・認証条件を限定したSkipまたはConfiguration Ruleを検討します。全体OFFが必要な場合も、影響、期限、再有効化条件を記録してください。
まとめ
Error 1010は、サイト所有者側のCloudflare設定がクライアントのブラウザー署名を理由にアクセスを拒否した状態です。WordPress本体を触る前に、Ray ID、時刻、URL、User-Agent、Action、Serviceを結び付けます。
Browser Integrity Check、User Agent Blocking、Custom Rulesのどれが処理したかを確認し、正規通信だけを最小範囲で回復してください。原因を特定できない一般的な拒否なら、Cloudflare Error 1020の確認手順へ進みます。