# 429 Too Many Requests の意味と対処法

> スクレイパーにとってのHTTP 429 Too Many Requestsの意味、Retry-Afterヘッダーの読み方、Pythonコードによるバックオフとジッターの説明。速度を落とし、回避しないでください。

- URL: https://crawlrelay.com/ja/docs/errors/429-too-many-requests/
- 最終更新: 2026-10-13
- Publisher: CrawlRelay (https://crawlrelay.com)

HTTPステータスコード（4xx、クライアントエラー）：各ツールでの正確なメッセージ、考えられる原因の順序、効果的な修正方法。

**クイックアンサー — プロキシでの429 Too Many Requestsとは何を意味していますか？**

**429 Too Many Requests** はウェブサイトがリクエストレートを制限していることを意味します。一定時間内に受け入れるリクエスト数を超えたためです。対処方法はリクエスト数を減らすことであり、隠すことではありません。CrawlRelayの居住者用プロキシを使う場合は、`Retry-After`ヘッダーを尊重し、ホストごとの同時実行数を制限し、指数関数的かつランダムなジッター付きでバックオフしてください。IPを頻繁に変えてサイトの公開上限を超えることは、ほとんどの利用規約違反になります。

## 429 Too Many Requestsを一目で理解する

| 属性 | 値 |
| --- | --- |
| エラー | 429 Too Many Requests |
| タイプ | HTTPステータスコード（4xx、クライアントエラー） |
| 送信元 | 対象ウェブサイトまたはそのAPIゲートウェイ |
| 定義されている場所 | RFC 6585, section 4 (Retry-After: RFC 9110, section 10.2.3) |
| 再試行しますか？ | はい、Retry-Afterの遅延または指数関数的バックオフの後に対応可能です |
| まず確認すること | Retry-Afterヘッダーとホストごとの1秒あたりのリクエスト数を確認してください |

## 429 Too Many Requestsとは何ですか？

RFC 6585で429が導入されました。サーバーは`Retry-After`ヘッダー（秒数かHTTP日時）を付加し、再アクセス可能な時刻を示します。APIは`X-RateLimit-Remaining`など独自ヘッダーも使うことが多いです。

429はスクレイパーにとってサイトが出す最も礼儀正しい応答であり、コンテンツは利用可能ですが現在のリクエスト速度だと拒否されています。429を無視するサイトは通常403、CAPTCHAまたは恒久的ブロックにエスカレートします。

## a 429はPython、curl、Node.js、ブラウザではどのように表示されますか？

同じ失敗でもツールごとに異なる表示になります。ログ検索用のメッセージは以下の通りです：

- **Python requests / httpx:** `status_code == 429`、多くの場合`Retry-After: 30`付き
- **Scrapy:** デフォルトの`RETRY_HTTP_CODES`で429を`RetryMiddleware`が処理
- **curl:** レスポンスヘッダーで`HTTP/2 429`、続いて`retry-after:`
- **API:** `{"error": "rate_limited"}`のようなJSONボディ

## a 429の原因は何ですか？

最も可能性が高いのは次の通りです：

- **ホストあたりの過剰な同時実行。** 1つのドメインで50並列ワーカーは多くのサイトで攻撃と見なされます。
- **リクエスト間隔なし、または固定遅延で多くのワーカーが同時アクセス。**
- **バックオフなしのリトライ。** 最初の429後のリトライの嵐で負荷が増大。
- **共有制限。** IPではなく、アカウント、APIキー、セッションCookieごとにリクエストをカウントするサイトもあります。
- **重いエンドポイント。** 検索やフィルターURLは静的ページよりも厳しい制限が多いです。

## a 429を段階的に診断するには？

1. 最初の429で`Retry-After`値や制限ヘッダーをログに記録。
2. 合計ではなく、ホストごとの実際のリクエストレートを計測。
3. 制限がIP、Cookie、APIキーのどれに従うか調べ、一度に1つだけ変更。
4. サイトのAPIまたはrobots.txtドキュメントを読み、`Crawl-delay`項目で要求速度を確認。

*curlで失敗したURLをテストする（HTTPポート、詳細表示）*

```bash
# Use the URL that fails; with https://api.ipify.org instead, you test the gateway alone.
# "HTTP/1.1 200 Connection established" first, then the site's own status: the site answered.
curl -v -x http://USERNAME:PASSWORD@gw.crawlrelay.com:7777 https://TARGET_URL

# Same test through the SOCKS5 port, with DNS resolved at the exit
curl -v --socks5-hostname gw.crawlrelay.com:7778 --proxy-user USERNAME:PASSWORD https://TARGET_URL
```

## a 429をどう修正しますか？

- **Retry-Afterを尊重。** サーバー指定の時間は必ず待つこと。
- **グローバルだけでなくホストごとに同時実行を制限。** Scrapyは`CONCURRENT_REQUESTS_PER_DOMAIN`と`AUTOTHROTTLE_ENABLED`が利用可能。
- **指数関数的バックオフ＋ジッター。** 1秒、2秒、4秒...にランダム分を足し最大値も設定。
- **取得量削減。** レスポンスをキャッシュ、`If-Modified-Since`または`If-None-Match`を送信し、更新なしページはスキップ。
- **公式APIを利用。** サイト提供なら制限が通常ドキュメント化されています。

*Python：Retry-After、指数関数的バックオフ、ジッターを使って再試行する*

```python
import random
import time

import requests

PROXY = "http://USERNAME:PASSWORD@gw.crawlrelay.com:7777"
PROXIES = {"http": PROXY, "https": PROXY}
RETRY_STATUSES = {429, 502, 503, 504}


def fetch(url, attempts=5, timeout=(10, 30)):
    for attempt in range(attempts):
        try:
            r = requests.get(url, proxies=PROXIES, timeout=timeout)
        except (requests.exceptions.ConnectionError, requests.exceptions.Timeout):
            r = None  # dropped exit, reset or timeout: a new connection gets a new exit
        if r is not None and r.status_code not in RETRY_STATUSES:
            return r
        retry_after = r.headers.get("Retry-After", "") if r is not None else ""
        if retry_after.isdigit():
            wait = int(retry_after)
        else:
            wait = min(60, 2 ** attempt) + random.uniform(0, 1)
        time.sleep(wait)
    raise RuntimeError("giving up on %s after %d attempts" % (url, attempts))
```

## a 429の後に再試行すべきですか？

はい、429は後でリトライするためにあります。サーバーが`Retry-After`遅延を指定すれば待ち、なければジッター付き指数関数的バックオフを行います。ホストごとの連続429数をカウントし、増えればそのホストの同時実行数を減らしてください。以下のPython関数は基本的な処理を示します。

## 429 Too Many RequestsはCrawlRelayにどう関係しますか？

CrawlRelay経由で届く429は対象のサイト固有のヘッダーと本文を含み、制限はサイトによるものです。ホストごとのペース管理は利用者の役割です。セッション単位でリクエストをカウントするサイトにはスティッキーセッションを使い、速度が測れるようにし、[同時実行ガイド](https://crawlrelay.com/ja/docs/concurrency/)を参照してください。

ゲートウェイ：`gw.crawlrelay.com`、ポート7777（HTTP、HTTPSはCONNECT経由）、ポート7778（SOCKS5）。ユーザー名形式：`USERNAME-country-{cc}-state-{state}-city-{city}-zip-{zip}-asn-{asn}-session-{id}-ttl-{minutes}`。関連情報：[403 Forbidden](https://crawlrelay.com/ja/docs/errors/403-forbidden/) · [503 Service Unavailable](https://crawlrelay.com/ja/docs/errors/503-service-unavailable/) · [同時実行ガイド](https://crawlrelay.com/ja/docs/concurrency/)。

## 429 Too Many Requests：開発者がよく尋ねる質問

### IPをローテーションして429を回避すべきか？

いいえ。429はサイトからの「速度を落とせ」という依頼です。IPごとの制限を下回るためにリクエストを多くのIPに分散するのは回避行為であり、ほとんどの利用規約で禁止されています。IPローテーションは負荷分散や場所の理由には有効ですが、公開された制限を超えるためではありません。リクエスト速度を下げ、可能なページはキャッシュを使ってください。

### 429の後はどのくらい待つべきか？

`Retry-After`ヘッダーで示された秒数だけ、または指定日時まで待ってください。ヘッダーがなければ1～2秒から始め、以降の429があるごとに遅延を倍増し、ランダム分と約1分の上限を設定してください。429が起きたレートではなく、より低い速度で再開してください。

### 数リクエスト/分程度なのに429が出る理由は？

制限はIPではなくアカウントやCookie、APIキーごとである場合や、エンドポイントが重い（検索ページなど）ケースがあります。サイトがボットと分類したクライアントには低い制限を設定している場合もあります。レスポンスヘッダーやAPIドキュメントを調べ、必要ならサイトに追加アクセスを依頼してください。

## 他のプロキシエラーのリファレンス

- [401 Unauthorized vs 407](https://crawlrelay.com/ja/docs/errors/401-unauthorized/)
- [403 Forbidden](https://crawlrelay.com/ja/docs/errors/403-forbidden/)
- [407 Proxy Authentication Required](https://crawlrelay.com/ja/docs/errors/407-proxy-authentication-required/)
- [429 Too Many Requests](https://crawlrelay.com/ja/docs/errors/429-too-many-requests/)
- [502 Bad Gateway](https://crawlrelay.com/ja/docs/errors/502-bad-gateway/)
- [503 Service Unavailable](https://crawlrelay.com/ja/docs/errors/503-service-unavailable/)
- [504 Gateway Timeout](https://crawlrelay.com/ja/docs/errors/504-gateway-timeout/)
- [Cannot connect to proxy (ProxyError)](https://crawlrelay.com/ja/docs/errors/cannot-connect-to-proxy/)
- [Connection reset by peer (ECONNRESET)](https://crawlrelay.com/ja/docs/errors/connection-reset/)
- [ERR_PROXY_CONNECTION_FAILED](https://crawlrelay.com/ja/docs/errors/err-proxy-connection-failed/)
- [ERR_TUNNEL_CONNECTION_FAILED](https://crawlrelay.com/ja/docs/errors/err-tunnel-connection-failed/)
- [Read timed out (ReadTimeout)](https://crawlrelay.com/ja/docs/errors/read-timeout/)
- [SOCKS5 proxy errors](https://crawlrelay.com/ja/docs/errors/socks5-proxy-errors/)
- [SSL: CERTIFICATE_VERIFY_FAILED](https://crawlrelay.com/ja/docs/errors/ssl-certificate-verify-failed/)
- [SSL: WRONG_VERSION_NUMBER](https://crawlrelay.com/ja/docs/errors/ssl-wrong-version-number/)

**失敗ケースを網羅したドキュメント付きレジデンシャルプロキシ** $0.50/GB発のCrawlRelayレジデンシャルプロキシ、期限切れがないトラフィック。 [料金を見る](https://crawlrelay.com/ja/pricing/) · [クイックスタート](https://crawlrelay.com/ja/docs/)

---

CrawlRelay: CrawlRelayは開発者第一のレジデンシャルプロキシおよび4G/5Gモバイルプロキシの回転型サービスです：有効期限なしの使った分だけ支払うトラフィックを$0.50/GBから暗号通貨で購入、IDアップロード不要。KYC不要 — IDもセルフィーも書類も不要。暗号通貨で支払い可能。