Cloudflare Error 1020 / 1015：アクセス拒否とレート制限

このエラーの意味と見分け方

• リクエストしたWebサイトまたはリソースの代わりに、Cloudflareのエラーページが表示される。
• ページに Error 1020: Access denied または Error 1015: You are being rate limited と明示される。
• 通常、レスポンスにはCloudflare Ray ID、おおよその時刻、影響を受けたホスト名が含まれる。
• Error 1020は、特定のIPアドレス、パス、リクエストパターン、またはセキュリティルールの条件にだけ影響し、他の訪問者は接続できる場合がある。
• Error 1015は、リクエスト頻度が下がると解消することがある一方、短時間にリクエストが集中した際に再発したり、NAT、プロキシ、企業ゲートウェイ経由で1つのパブリックIPを共有するユーザーに影響したりする場合がある。
• オリジンアプリケーションが処理する前に、Cloudflareのエッジでリクエストが停止された可能性がある。すべての同様の障害が同じ原因だと決めつけず、エラーをオリジンログと比較する。

可能性の高い順の主な原因

最も可能性の高い原因

1. Cloudflareのファイアウォール、WAF、またはセキュリティルールがリクエストに一致した（1020）。 ルールは送信元IP、国、URIパス、HTTPメソッド、ヘッダー、ユーザーエージェント、その他のリクエスト属性を評価する場合があります。
2. 設定済みのレート制限のしきい値を超えた（1015）。 ページの繰り返し読み込み、APIポーリング、クローラー、並列ダウンロード、ログイン試行、または1つの共有アドレスの背後にいる多数のユーザーによって、ポリシーが発動することがあります。
3. セキュリティポリシーの範囲が意図より広い。 管理用パスや悪意のあるトラフィック向けに設計したルールが、正当な訪問者、監視サービス、社内ネットワーク、APIクライアントにも一致する場合があります。
4. 共有または特殊な送信元IPのパターンが一致した。 VPN、プロキシ、キャリアNAT、企業ゲートウェイによって、無関係なユーザーが1つのアドレスからアクセスしているように見える場合があります。
5. 最近のCloudflare設定変更によってブロックが発生した。 ファイアウォール、WAF、bot対策、またはレート制限を変更した直後にエラーが始まった場合は、特にこの可能性が高くなります。

これらのエラーだけで、オリジンサーバーが停止している証拠にはなりません。ブロックされたリクエストはオリジンに到達しない可能性がある一方、別のオリジン障害によって異なるレスポンスが返されることもあります。

修正方法

訪問者の場合

1. エラーページ全体を記録する。 1020または1015のどちらが表示されたか、Ray ID、タイムスタンプ、タイムゾーン、ホスト名、失敗したURLまたは操作を確認します。パスワード、トークン、その他の機密性の高いリクエストデータは共有しないでください。
2. 短時間の再試行を止める。 1015の場合は、再試行する前に時間を置いてください。繰り返しの更新、複数のタブ、または自動再試行によって、レート制限が長引いたり繰り返し発動したりすることがあります。
3. 不要なリクエスト元を一時停止する。 ダウンロードマネージャー、負荷の高いブラウザー拡張機能、スクリプト、APIポーリング、クローラー、その他同じサイトに繰り返しリクエストするツールを停止します。適切な場合は、VPNやプロキシを使わず、通常のブラウザーから1回だけ試してください。ただし、許可されていないアクセス制御を回避してはいけません。
4. 問題が限定的かサイト全体に及ぶかを確認する。 特定のパス、アカウント操作、またはネットワークだけがブロックされ、他のページは動作している場合があります。別のネットワークからリクエストに成功しても、すべてのユーザーにとってサイトが正常だとは限りません。
5. サイト運営者に連絡する。 エラー番号、Ray ID、タイムスタンプ、影響を受けたURL、実行していた操作の説明を伝えます。パブリックIPアドレスは、運営者から求められ、共有しても問題ない場合に限って提供してください。

Cloudflare zoneを管理している場合

1. レスポンスの発生レイヤーを確認する。 Cloudflareの表示、エラー番号、Ray ID、タイムスタンプを確認します。イベントをオリジンのアクセスログと比較し、該当するオリジンリクエストがなければ、ブロックはCloudflareのエッジで発生した可能性が高いと判断できます。
2. Error 1020の場合は、セキュリティイベントと一致したルールを確認する。 Ray ID、時刻、送信元IP、リクエストパスを使って、リクエストを拒否したファイアウォールルール、WAF、カスタムルール、アクセス​​ポリシーなどを特定します。すべてのセキュリティ制御を無効にするのではなく、ルール式を確認してください。
3. Error 1015の場合は、レート制限の分析情報と設定を確認する。 一致したホスト名、パス、メソッド、クライアント識別情報、しきい値を特定します。NAT、プロキシ、企業ゲートウェイを通じて、多数の正当なユーザーが1つのアドレスを共有していないか確認してください。
4. ブロックされたリクエストと許可されたリクエストを比較する。 パス、クエリ文字列、メソッド、ヘッダー、送信元ネットワーク、リクエスト頻度を確認します。これにより、誤検知と、実際に過剰または悪意のあるトラフィックを区別できます。
5. 権限のある最小限の変更を行う。 ルール式の範囲を狭め、意図しない条件を修正し、限定的な例外を作成するか、影響を受けたエンドポイントのレート制限ポリシーを調整します。責任を持つセキュリティ担当者の承認がない限り、認証パスや管理用パスのより強固な制御は維持してください。
6. 安全にテストして監視する。 影響を受けたトラフィックを再現する、権限のあるテストリクエストを使用します。正当なアクセスが機能し、同時に、意図した保護が対象として設計されたトラフィックに対して引き続き発動することを確認してください。変更後はCloudflareのイベントとオリジンログを確認します。
7. 一致内容が不明な場合は、証拠を添えてエスカレーションする。 Ray ID、タイムスタンプとタイムゾーン、ルール識別子またはポリシー名、ホスト名、パス、送信元ネットワークの状況、関連するイベントの詳細を保存します。各結果を記録せずに、ルールを何度も変更することは避けてください。

予防と修正確認

• 特に公開ページ、API、共有ネットワークでは、ファイアウォールとWAFの式を可能な限り狭く設定する。
• 広範なグローバルしきい値に頼らず、パス、メソッド、クライアント識別情報、トラフィックパターンを適切に組み合わせてレート制限の範囲を設定する。
• 正当なトラフィックを評価する際は、NAT、VPN、プロキシ、企業の送信元アドレスを共有された識別情報として考慮する。
• ルールの導入または変更後は、通常のユーザー、監視システム、APIクライアントからのトラフィックを含めて、セキュリティイベントを確認する。
• サポートチームには、繰り返し再試行するのではなく、Ray ID、タイムスタンプ、ホスト名、影響を受けたパスを収集する標準手順を用意する。
• Cloudflareエッジでのブロックとオリジンエラーの違いを文書化し、対応者が最初に正しいログを確認できるようにする。
• 限定的に承認した例外を記録して定期的に見直し、保護を弱める恒久的で広範な許可リストは避ける。