プロキシを増やす前に確認する403・429・503の切り分け手順

定期取得が止まっても、IP制限とは限りません。プロキシを追加する前に、対象URLと/robots.txtを別々に確認し、ステータス、ヘッダ、本文、試行間隔を記録します。原因を特定できない段階では、リクエストを増やさないことが基本です。

429：待機時間と制限単位を確認する

429は一定時間内の送信過多を示します。ただしRetry-Afterは任意なので、付いていない429も規格に沿った応答です。値があれば待機時間として扱い、なければレスポンス本文や取得先の公式仕様を確認します。また、429レスポンスはキャッシュへ保存してはいけません（RFC 6585）。

RFCは、利用者の識別方法やリクエストの集計範囲を限定していません。認証情報やCookieで識別される場合もあるため、429だけではIP単位の制限と断定できません。サーバーには429を返す義務もなく、高負荷時に接続を切る場合もあります（RFC 6585）。

403：連続再試行を止める

403を受けたら、IP制限や一時障害と決めつけず、認証状態、取得先の仕様、利用規約、公式API、問い合わせ窓口を確認します。Googleは自社クローラについて、速度制御に401や403を使うべきではなく、429を除く4xxはクロール頻度に影響しないと説明しています。ただし、これはGoogleクローラの挙動であり、自作処理の共通仕様ではありません（Google公式ドキュメント）。

503：対象URLとrobots.txtを分ける

対象ページの503と、/robots.txtの503は意味を分けて記録します。robots.txtが500～599やネットワークエラーで取得不能なら、クローラは全面不許可として扱う必要があります。一方、対象ページだけが503でも、この規定が直ちに適用されるわけではありません（RFC 9309）。

Googleのクローラは5xxや429を受けると一時的に減速し、2xxへ回復した後にクロール速度を段階的に戻します。一般の取得処理への命令ではありませんが、即時に元の頻度へ戻さない判断の参考になります（Google公式ドキュメント）。

記録してから対応を選ぶ

試行ごとに、日時とタイムゾーン、対象URL、robots.txtのURL、各ステータス、Retry-After、Content-Type、本文の短い要約、User-Agent、認証・Cookieの有無、利用経路、試行回数と間隔を保存します。431なら、リクエストヘッダ全体またはCookieなど単一ヘッダの肥大化を確認します。511なら、取得先ではなく経路上の認証用プロキシが返した可能性があります（RFC 6585）。

プロキシ追加のデメリットと向かない条件

プロキシ追加には購入・運用費用がかかり、経路を一つ増やすため、遅延や障害の切り分け対象も増えます。さらに、経路事業者を介する構成では通信情報の取り扱いを確認する必要があります。RFCも、511を使う経路上のポータルでは、意図した相手とポータルの応答を区別しにくく、Cookieの挿入・観測などのセキュリティ上の問題が起こり得ると指摘しています（RFC 6585）。

次の場合、プロキシ追加は原因解決になりません。

429の識別単位がIPだと確認できていない
403の原因や取得許可を確認できていない
robots.txtが取得不能で、全面不許可として扱う必要がある
431でCookieや自作ヘッダを見直すべき状態にある
511が示す経路上の認証問題を調査している

プロキシを増やしても、利用規約や契約上の取得可否は変わりません。robots.txtもアクセス認可の仕組みではないため、許可ルールへの一致と取得可否は別に判断します（RFC 9309）。原因や許可を確認できない場合は、公式APIへの切り替え、運営者への確認、または取得停止を選びます。