HTTP 429 Too Many Requests：待ってから正しく再試行する
HTTP 429 Too Many Requests
HTTP 429 Too Many Requests：Retry-After とバックオフ | We.Inc
429 ステータスの意味、Retry-After の読み方、そして指数バックオフとジッターを使った再試行のコードを解説します。計算ツールで自分の再試行スケジュールを計画しましょう。
429 のレスポンスは、サーバーがあなたにレート制限をかけていることを意味します。このクライアントが、一定時間内に許可された数を超えるリクエストを送ったということです。しばらく送信を止めましょう。応答に Retry-After ヘッダーがあればその時間だけ待ち、なければ、多くのクライアントが一斉に再試行しないよう、ランダムなジッターを加えた指数バックオフで再試行します。
429 のレスポンスの読み方
- ステータス 429
- 一定時間内のリクエストが多すぎる
- このクライアントを一時停止し、連打しない
- Retry-After: 120
- 120 秒待つ（秒数形式の遅延）
- 少なくともその時間スリープする
- Retry-After: Wed, 21 Oct 2026 07:28:00 GMT
- その時刻まで待つ（HTTP日付形式）
- 現在時刻を引いてからスリープする
- Retry-After なし
- サーバーからのヒントはない
- ジッター付きの指数バックオフで待つ
- キャッシュ
- 429 はキャッシュに保存してはいけない
- 保存した 429 を後で返さない
最初の待ち時間、上限、許可する再試行回数を設定し、ジッターの方式を選んでください。計算ツールが試行ごとの待ち時間の範囲と最悪の場合の合計を一覧にするので、サーバーの制限時間枠がリセットされる前にクライアントが諦めてしまわないかを確認できます。
- 基本の待ち時間をミリ秒で入力します。最初の再試行の前に使う待ち時間です。
- 上限を入力します。1回の待ち時間として許される最長の時間です。
- 許可する再試行回数とジッターの方式を選びます。
- 試行ごとの範囲と合計を確認し、下にある対応するコードをコピーします。
- サーバーが Retry-After を送ってきたら、常に自分のスケジュールよりそちらを優先しましょう。制限時間枠がいつリセットされるかを知っているのはサーバーで、あなたではありません。
- 再試行するのは、繰り返しても安全なリクエストだけにしましょう。冪等キーなしで支払いの POST を再試行すると、二重に請求されることがあります。
- 待ち時間だけでなく再試行の回数にも上限を設け、使い切ったらわかりやすいエラーを表示しましょう。
- サーバーを管理しているなら、リクエストを黙って捨てたり遅くしたりせず、Retry-After 付きで 429 を返しましょう。行儀のよいクライアントが適応できます。
よくある質問
429 はクライアントエラーですか、サーバーエラーですか？
4xx 系なので、クライアントの振る舞い、つまりリクエストが多すぎることを表します。サーバー側は何も壊れていません。対策は、リクエストを減らすか分散させることです。
Retry-After には何が入っていますか？
120 のような待つべき秒数か、再試行してよいHTTP日付のどちらかです。クライアントは両方の形式に対応すべきです。
指数バックオフにジッターを加えるのはなぜですか？
ジッターがないと、同時に失敗したすべてのクライアントが再び同時に再試行し、アクセスの急増が再現されてしまいます。各時間枠の中でランダムに待つことで、再試行が分散されます。
nginx のレート制限が 429 ではなく 503 を返すのはなぜですか？
limit_req モジュールは、変更しない限り 503 で拒否します。limit_req の行の隣に limit_req_status 429; を追加すれば、クライアントにはより正確なコードが返ります。
CDN は 429 のレスポンスをキャッシュできますか？
してはいけません。RFC 6585 は、429 ステータスコードのレスポンスをキャッシュに保存してはならないとしているので、制限が解除されれば各クライアントは新しい応答を受け取れます。
429 を送るのは誰で、なぜか
- API、ログインフォーム、検索エンドポイントは、ユーザーごと、キーごと、IPアドレスごとにリクエストを数え、超過分を拒否します。数え方は仕様上サーバーに任されているので、ある API は1分単位、別の API は1日単位で制限することもあります。
- レスポンスの本文では制限について説明すべきで、どれくらい待つべきかを伝える Retry-After を加えることもできます。
計算ツールにある3つのバックオフ方式
- 単純な指数バックオフは、上限まで毎回待ち時間を2倍にします：min(cap, base * 2^attempt)。フルジッターは、ゼロからその値までの間でランダムに待ち時間を選びます。イコールジッターは半分を固定し、残りの半分をランダムにするので、最低限の待ちが保証されます。
- フルジッターは負荷を最もよく分散させるので、妥当なデフォルトです。イコールジッターは、決して即座に再試行してはならないクライアントに向いています。
429 を尊重するクライアントのコード
Retry-After とフルジッターを使う fetch
Retry-After の両方の形式を読み、なければフルジッターにフォールバックし、決まった回数の再試行の後に停止します。
自分のサーバーから 429 を送る
nginx：IPごとに制限して 429 で応答する
limit_req はデフォルトで 503 で拒否します。limit_req_status でそれを 429 に切り替えます。
レスポンスの例
制限を説明する短い本文と、秒数で指定した Retry-After です。
再試行スケジュールの計算ツール
基本の待ち時間（ms）
1回の待ち時間の上限（ms）
再試行回数
ジッターの方式
フルジッター
イコールジッター
ジッターなし
各再試行の前の待ち時間
再試行
最短の待ち時間
最長の待ち時間
諦めるまでの最悪の場合の合計：{v}
ゼロより大きい整数を使い、上限は基本の待ち時間以上にしてください。
無料で始める · クレジットカード不要
関連: ガイド｜Webマーケティングと集客を学ぶ
製品
ご利用いただける方
機能
リソース
会社情報
サイトマップを見る