⁦429 Too Many Requests⁩ چیست؟ خطای Rate Limit و رفع آن

در یک پلتفرم بازی پیشنهادهای مبادله را نگاه می‌کنید، در یک گفت‌وگوی هوش مصنوعی پشت سر هم سؤال می‌نویسید یا همان صفحه را بارها باز می‌کنید تا ببینید نوبت خالی برای ویزا پیدا می‌شود یا نه. صفحه ناگهان عوض می‌شود و فقط یک سطر روی آن می‌ماند: 429 Too Many Requests. گاهی پیام به فارسی است («تعداد تلاش‌ها بیش از حد مجاز است، بعداً دوباره امتحان کنید»)، گاهی درون یک برنامه به شکل Request failed with status code 429 دیده می‌شود و گاهی نوشته است «rate limit exceeded». همه یک چیز می‌گویند: سرویس مقابل درخواست‌هایی را که از سمت شما می‌آید شمرده و شمارش از حد گذشته است.

در این نوشته توضیح می‌دهیم کد 429 و مفهوم rate limit (محدودیت نرخ) چیست، حد بر چه اساسی شمرده می‌شود، چرا برای کسی که «هیچ کاری نکرده» هم ظاهر می‌شود و چقدر باید صبر کرد. نیمه نخست برای کاربری است که خطا را روی صفحه می‌بیند و نیمه دوم برای توسعه‌دهنده‌ای که از یک API استفاده می‌کند و تیم‌هایی که داده گردآوری می‌کنند.

⁦429 Too Many Requests⁩ یعنی چه؟#

هر بار که مرورگر شما یا یک برنامه به سروری وصل می‌شود، سرور در ابتدای پاسخ یک کد وضعیت سه‌رقمی می‌گذارد. 200 یعنی «انجام شد» و 404 یعنی «چنین صفحه‌ای وجود ندارد». 429 یعنی «درخواست شما را فهمیدم اما اکنون آن را پردازش نمی‌کنم، چون در زمانی کوتاه درخواست‌های بسیار زیادی فرستاده‌اید». این کد در بخش 4 از ⁦RFC 6585⁩ تعریف شده است. همان بخش دو چیز را به سرور واگذار می‌کند: اینکه کاربر چگونه شناخته شود و درخواست‌ها چگونه شمرده شوند. یعنی قاعده پشت 429 در هر سرویس متفاوت است و تنها پیام مشترک است.

همین خطا بسته به رابط کاربری سرویس شکل‌های گوناگونی می‌گیرد:

سطر آخر نوشته جداگانه‌ای دارد: معنای هر سطر آن صفحه، کد Ray ID و کارهایی که صاحب سایت می‌تواند بکند را در ⁦Error 1015⁩ چیست؟ رفع خطای You Are Being Rate Limited توضیح داده‌ایم.

rate limit چیست و چرا گذاشته می‌شود؟#

rate limit سقف تعداد درخواست‌هایی است که یک سرویس در بازه‌ای مشخص از یک کاربر می‌پذیرد. قاعده‌ای است مانند «60 درخواست در دقیقه»، «5 تلاش ورود در ساعت» یا «1000 جست‌وجو در روز». عبارت «rate limit exceeded» می‌گوید از این سقف گذشته‌اید و «rate limited» می‌گوید به همین دلیل محدود شده‌اید. در فارسی به آن محدودیت نرخ یا محدودیت درخواست می‌گویند.

سرویس‌ها این حد را به چهار دلیل می‌گذارند:

• حفظ ظرفیت. تعداد درخواست‌هایی که یک سرور می‌تواند پردازش کند محدود است. یک کاربر یا یک برنامه معیوب نباید همه ظرفیت را مصرف کند.
• امنیت حساب. حد در صفحه‌های ورود عمداً پایین نگه داشته می‌شود. کسی که می‌خواهد گذرواژه را حدس بزند به هزاران تلاش نیاز دارد؛ قاعده «پس از پنج تلاش نادرست صبر کنید» این حمله را تا حد بی‌معنا شدن کند می‌کند.
• تقسیم عادلانه. سهمیه طرح‌های رایگان و پولی متفاوت است و حد سهم هر کس را تعیین می‌کند.
• هزینه. هر درخواست بهایی دارد: زمان پردازنده، پهنای باند و گاهی کارمزد یک سرویس ثالث.

حد بر چه اساسی شمرده می‌شود؟#

نخستین پرسش پس از دریافت 429 این است: شمارنده به نام چه کسی نگه‌داری می‌شود؟ صفحه MDN درباره کد 429 روش‌های ممکن را برمی‌شمارد: برای کل سرور، برای یک منبع، به‌ازای هر نشانی IP، هر کاربر یا هر برنامه. اینکه کدام روش به کار رفته تعیین می‌کند چه چیزی سودمند است و چه چیزی نیست.

بیشتر سرویس‌ها چند تا از این شمارنده‌ها را هم‌زمان نگه می‌دارند. GitHub نمونه خوبی است چون قاعده‌اش را آشکارا نوشته است: طبق مستندات محدودیت نرخ در REST API درخواست‌های بدون احراز هویت به 60 درخواست در ساعت محدودند و این شمارنده نه به کاربر که به نشانی IP فرستنده درخواست وابسته است. حد کاربر احرازشده 5000 درخواست در ساعت است و به حساب وابسته است.

rate limit چگونه کار می‌کند؟#

جزئیات از سرویسی به سرویس دیگر فرق می‌کند، اما روند یکی است:

1. سرویس قاعده‌ای می‌نویسد. قاعده سه بخش دارد: چه کسی شمرده شود (IP، حساب، کلید)، بازه زمانی و آستانه.
2. هر درخواست ورودی در یک شمارنده ثبت می‌شود. سرور پیش از پردازش درخواست نگاه می‌کند به کدام شمارنده تعلق دارد و آن را یک واحد بالا می‌برد.
3. با گذشتن از آستانه، درخواست بدون پردازش رد می‌شود. سرور به جای آماده کردن صفحه یک پاسخ کوتاه 429 می‌فرستد.
4. سرور می‌تواند بگوید چقدر باید صبر کنید. این کار را با سرآیند پاسخ Retry-After انجام می‌دهد. این سرآیند اجباری نیست و هر سایتی آن را نمی‌فرستد.
5. با گذشت زمان شمارنده خالی می‌شود. پنجره بسته می‌شود یا توکن تازه‌ای در سطل می‌افتد و دسترسی خودبه‌خود باز می‌شود.
6. جریمه کسی که پافشاری کند ممکن است بزرگ‌تر شود. برخی سرویس‌ها کلاینتی را که با وجود 429 با همان آهنگ ادامه می‌دهد برای مدتی طولانی‌تر و با کدی سخت‌گیرانه‌تر مسدود می‌کنند. مستندات GitHub این را آشکارا نوشته است: ادامه دادن به فرستادن درخواست در زمانی که محدود شده‌اید می‌تواند به مسدود شدن یکپارچه‌سازی شما بینجامد.

نکته‌ای درباره گام دوم: باز کردن یک صفحه یک درخواست نیست. مرورگر تصویرها، اسکریپت‌ها و پرس‌وجوهای پس‌زمینه را جداگانه می‌خواهد و با یک کلیک ممکن است ده‌ها درخواست به سرور برود.

هیچ کاری نکرده‌ام؛ چرا 429 برای من آمد؟#

در پیشنهادهای جست‌وجو، کنار این خطا بیشتر نام Steam، Roblox، ChatGPT، Outlook و سایت‌های نوبت ویزا دیده می‌شود. وجه مشترکشان این است: کاربر در این جاها بی‌آنکه بداند درخواست‌های زیادی تولید می‌کند.

• صفحه‌های بازار و مبادله در پلتفرم‌های بازی. فهرست قیمت، موجودی و صفحه پیشنهادها با هر بار باز شدن پرس‌وجوهای فراوانی در پس‌زمینه می‌فرستند. یک افزونه مرورگر که قیمت‌ها را دنبال می‌کند می‌تواند حد را در چند دقیقه پر کند. ابزارهای ثالثی که به حسابتان وصل کرده‌اید هم از طرف شما درخواست می‌فرستند.
• گفت‌وگوهای هوش مصنوعی. هر پیام عملیاتی پرهزینه است و به همین دلیل حد هم بر شمار کل پیام‌ها و هم بر فاصله آن‌ها گذاشته می‌شود. استفاده چند نفر از یک حساب یا بازتولید پیاپی پاسخ کوتاه‌ترین راه رسیدن به حد است.
• حساب‌های ایمیل. تلاش‌های ورود با گذرواژه نادرست، تلفنی فراموش‌شده که هنوز با گذرواژه قدیمی می‌کوشد وصل شود یا یک برنامه ایمیل شمارنده را به جای شما پر می‌کند.
• سایت‌های نوبت‌دهی و بلیت. اینجا تولیدکننده درخواست خود کاربر است: صفحه‌ای که هر چند ثانیه تازه می‌شود تا شاید جای خالی پیدا شود.

اگر هیچ‌کدام با وضع شما جور نیست، نشانی IP مشترک می‌ماند. اگر شمارنده به IP وابسته باشد، همه کسانی که از یک نشانی به اینترنت می‌روند (همه رایانه‌های یک دفتر، مشترکان داده همراه پشت یک نشانی عمومی) یک نفر به شمار می‌آیند: شمارنده را دیگری پر می‌کند و 429 را شما می‌بینید. این سازوکار و راه تشخیص آن در اتصال خودتان را در CGNAT چیست، چگونه تشخیص دهیم و چطور از آن خارج شویم؟ توضیح داده‌ایم. در سرویس‌های رایگان VPN و پروکسی، گروهی بسیار بزرگ‌تر از همان نشانی خروجی استفاده می‌کنند؛ جزئیات در پروکسی رایگان و سایت‌های وب پروکسی امن هستند؟ آمده است.

خطای 429 چقدر طول می‌کشد؟ چرا تازه کردن صفحه سودی ندارد؟#

پاسخ یگانه‌ای وجود ندارد، چون مدت را نه استاندارد که خود سرویس تعیین می‌کند. پنجره ثانیه‌ای در چند ثانیه، سهمیه ساعتی ظرف یک ساعت و سهمیه روزانه روز بعد باز می‌شود. در پاسخ نمونه MDN نوشته شده Retry-After: 3600 یعنی یک ساعت.

تازه کردن صفحه سودی ندارد، چون F5 از دید سرور یک درخواست تازه است: یا بی‌درنگ رد می‌شود یا به شمارنده افزوده می‌شود و می‌تواند زمان انتظار را طولانی‌تر کند. در سرویسی که از پنجره لغزان استفاده می‌کند (پایین‌تر توضیح می‌دهیم) شمارنده کاربری که پیوسته تلاش می‌کند هرگز خالی نمی‌شود.

به جای حدس زدن مدت، می‌توانید آن را بخوانید: با F12 ابزارهای توسعه‌دهنده را باز کنید، در زبانه Network صفحه را یک بار تازه کنید و روی سطر 429 کلیک کنید. اگر در میان سرآیندهای پاسخ Retry-After باشد، عدد کنار آن زمان انتظار به ثانیه است.

اگر بازدیدکننده هستید چه باید بکنید؟#

1. دست نگه دارید. زبانه را ببندید، از برنامه بیرون بیایید و چند دقیقه هیچ چیزی را امتحان نکنید.
2. هر چه به جای شما درخواست می‌فرستد را ببندید. زبانه‌های باز دیگر از همان سایت، افزونه‌های تازه‌سازی خودکار و ردیابی قیمت، برنامه دسکتاپی که در پس‌زمینه کار می‌کند و ابزارهای ثالث متصل به حسابتان.
3. اگر خطا در صفحه ورود است، امتحان کردن گذرواژه را کنار بگذارید. هر تلاش نادرست می‌تواند زمان انتظار را بیشتر کند. اگر مطمئن نیستید، پس از صبر کردن از مسیر «گذرواژه را فراموش کرده‌ام» بروید. اگر دستگاهی هنوز گذرواژه قدیمی را امتحان می‌کند آن را به‌روز کنید.
4. یک بار امتحان کنید. اگر باز شد، مشکل تمام شده است. اگر نشد، زمان انتظار را بیشتر کنید: ده دقیقه، نیم ساعت، چند ساعت.
5. سهم اتصال را بسنجید. اگر VPN یا پروکسی رایگان روشن است آن را خاموش کنید و سپس با داده همراه تلفنتان امتحان کنید. اگر آنجا باز می‌شود و در شبکه دفتر یا خانه باز نمی‌شود، شمارنده به نشانی مشترک شما تعلق دارد. اگر در هر دو اتصال همان خطا را می‌گیرید، شمارنده به حسابتان وابسته است و راهی جز صبر نیست.
6. اگر خطا در استفاده عادی هر روز تکرار می‌شود، به پشتیبانی سرویس بنویسید. بگویید در حال چه کاری بودید و چه پیامی دیدید.

پاک کردن کوکی‌ها، عوض کردن مرورگر یا خاموش و روشن کردن مودم در این فهرست نیست، چون شمارنده بیشتر به چیزی وابسته است که این کارها تغییرش نمی‌دهد: حساب شما یا نشانی مشترک. هشدار مشابهی که در جست‌وجوهای Google ظاهر می‌شود علت‌های ویژه خودش را دارد و آن را در نوشته‌مان درباره خطای ترافیک غیرعادی Google بررسی کرده‌ایم.

الگوریتم‌های rate limit: پنجره ثابت، پنجره لغزان و token bucket#

از اینجا به بعد نوشته برای توسعه‌دهندگان است. قاعده «10 درخواست در دقیقه» بسته به شیوه نگه‌داری شمارنده به سه شکل متفاوت رفتار می‌کند.

Cloudflare محاسبه تقریبی پنجره لغزان را در نوشته‌ای که محدودکننده نرخ خودش را شرح می‌دهد با یک مثال نشان داده است: حد 50 درخواست در دقیقه است، در دقیقه پیش 42 درخواست آمده و در ثانیه 15 دقیقه جاری 18 درخواست شمرده شده است. برآورد می‌شود 42 × (45/60) + 18 = 49.5 یعنی درست زیر حد. Stripe هم token bucket را در نوشته‌ای درباره محدودکننده‌های نرخ خودش خلاصه می‌کند: هر کاربر یک سطل دارد، هر درخواست یک توکن برمی‌دارد و توکن‌های تازه آرام‌آرام در سطل می‌چکند.

کوتاه‌ترین راه دیدن تفاوت این است که همان ترافیک را به هر سه بدهیم. اسکریپت Python زیر از اتصال شبکه استفاده نمی‌کند و فقط مُهرهای زمانی را از سه شمارنده می‌پرسد.

LIMIT = 10      # requests allowed per window
WINDOW = 60     # window length (seconds)


class FixedWindow:
    def __init__(self):
        self.window_id, self.count = None, 0

    def allow(self, now):
        window_id = int(now // WINDOW)
        if window_id != self.window_id:          # new window: the counter resets
            self.window_id, self.count = window_id, 0
        if self.count >= LIMIT:
            return False
        self.count += 1
        return True


class SlidingWindow:
    def __init__(self):
        self.window_id, self.count, self.previous = None, 0, 0

    def allow(self, now):
        window_id = int(now // WINDOW)
        if window_id != self.window_id:
            # if the previous window was empty, nothing carries over
            self.previous = self.count if window_id - 1 == self.window_id else 0
            self.window_id, self.count = window_id, 0
        elapsed = now % WINDOW
        # the previous window's count is weighed by the share of it that remains
        estimate = self.previous * (WINDOW - elapsed) / WINDOW + self.count
        if estimate >= LIMIT:
            return False
        self.count += 1
        return True


class TokenBucket:
    def __init__(self):
        self.tokens, self.updated = float(LIMIT), 0.0

    def allow(self, now):
        # tokens are added for the elapsed time, the bucket cannot exceed capacity
        self.tokens = min(LIMIT, self.tokens + (now - self.updated) * LIMIT / WINDOW)
        self.updated = now
        if self.tokens < 1:
            return False
        self.tokens -= 1
        return True


def run(name, timestamps):
    print(name)
    for limiter in (FixedWindow(), SlidingWindow(), TokenBucket()):
        accepted = sum(limiter.allow(t) for t in timestamps)
        print(f"  {type(limiter).__name__:<14} {accepted}/{len(timestamps)} accepted")


# Scenario 1: two bursts on either side of the window boundary (seconds 59 and 61)
run("Burst at the boundary", [59.0] * 10 + [61.0] * 10)
# Scenario 2: one request every 7.5 seconds for two minutes (8 per minute)
run("Steady pace", [i * 7.5 for i in range(16)])

خروجی:

Burst at the boundary
  FixedWindow    20/20 accepted
  SlidingWindow  11/20 accepted
  TokenBucket    10/20 accepted
Steady pace
  FixedWindow    16/16 accepted
  SlidingWindow  16/16 accepted
  TokenBucket    16/16 accepted

در سناریوی نخست پنجره ثابت با وجود قاعده «10 در دقیقه» در دو ثانیه 20 درخواست را عبور داد، چون شمارنده در ثانیه 60 صفر شد. پنجره لغزان بار دقیقه پیش را به یاد داشت و از جهش دوم تنها یک درخواست را پذیرفت (چون محاسبه تقریبی است دقیقاً روی 10 نایستاد). token bucket توکن‌هایش را در جهش نخست خرج کرد و همه جهش دوم را رد کرد. سناریوی دوم درس اصلی را برای کلاینت دارد: ترافیکی که زیر حد و منظم برود در هیچ الگوریتمی 429 نمی‌بیند. آنچه به حد می‌خورد میانگین نیست، انباشت است.

نمونه‌ای که همین منطق token bucket را در سمت کلاینت و برای ترمز کردن درخواست‌های خودتان به کار می‌برد در دسترسی امن LLM به وب: محدودیت نرخ و مجوزها آمده است.

اگر از API استفاده می‌کنید: حد چگونه از سرآیندها خوانده می‌شود؟#

APIهایی که خوب مستند شده‌اند حد را از غافلگیری درمی‌آورند: در هر پاسخ با سرآیندها می‌گویند چقدر از سهمیه‌تان مانده است. نقطه اتصال سهمیه در GitHub برای آزمودن این موضوع مناسب است، چون فراخوانی این نقطه اتصال از سهمیه اصلی شما کم نمی‌کند:

curl -s -o /dev/null -D - https://api.github.com/rate_limit | grep -i -E "^HTTP|^x-ratelimit"

در یک فراخوانی بدون احراز هویت، پاسخ چیزی شبیه این است:

HTTP/1.1 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 53
X-RateLimit-Used: 7
X-RateLimit-Resource: core
X-RateLimit-Reset: 1789799592

Limit کل سهم پنجره را می‌دهد، Remaining مقدار باقی‌مانده را و Reset لحظه صفر شدن شمارنده را (زمان Unix به ثانیه). عدد 60 در اینجا به نشانی IP شما تعلق دارد؛ همکاری که همان دستور را از همان دفتر اجرا کند هم از همان شمارنده خرج می‌کند. برنامه‌ای که این سرآیندها را می‌خواند می‌تواند هنگام نزدیک شدن به حد خودش آهسته‌تر شود.

سه نکته را باید در نظر داشت:

• نام سرآیندها استاندارد نیست. X-RateLimit-* عادتی رایج است، اما Reset در یک API زمان Unix و در دیگری ثانیه‌های باقی‌مانده است. IETF برای سامان دادن به این پراکندگی روی پیش‌نویسی کار می‌کند که سرآیندهای RateLimit و RateLimit-Policy را تعریف می‌کند؛ هنگام نوشتن این متن هنوز RFC نشده بود.
• حد همیشه با 429 نمی‌آید. GitHub در همان مستند نوشته است که هنگام گذشتن از حد ممکن است 403 یا 429 برگرداند. فقط به کد نگاه نکنید؛ سرآیندها و پیام درون بدنه پاسخ را هم ببینید.
• محدودیت نرخ و سهمیه دو چیز جدا هستند. محدودیت نرخ دقیقه‌ای با صبر باز می‌شود؛ سهمیه ماهانه یا اعتبار تمام‌شده در بخش طرح و پرداخت حل می‌شود. هر دو می‌توانند با یک کد بیایند و تفاوت را پیام درون بدنه می‌گوید.

قاعده پس از دریافت 429 کوتاه است. اگر Retry-After هست از آن پیروی کنید؛ اگر نیست عقب‌نشینی نمایی به کار ببرید (1، 2، 4، 8 ثانیه و به هر کدام سهمی تصادفی بیفزایید)، برای شمار تلاش‌ها سقف بگذارید و انتظار را بر همه درخواست‌هایتان به آن سرویس اعمال کنید. دو شکل Retry-After و نمونه Python آزموده‌ای که این تصمیم‌ها را اجرا می‌کند در کدهای وضعیت HTTP در وب اسکرپینگ: 403، 407، 429، 503 آمده است و همان کد را اینجا تکرار نمی‌کنیم. اثر همروندی بر نرخ 429 را در همروندی و موازی‌سازی در وب اسکرپینگ بخوانید.

آیا با عوض کردن IP می‌توان از rate limit گذشت؟#

در بیشتر موارد نه. اگر شمارنده به حساب، نشست یا کلید API وابسته باشد، نشانی IP اصلاً در محاسبه نیست: درخواستی که از نشانی تازه می‌آید در شمارنده همان حساب ثبت می‌شود.

حتی وقتی شمارنده به IP وابسته است، عوض کردن IP مشکل را حل نمی‌کند و فقط جایش را عوض می‌کند. دغدغه حد هویت شما نیست، باری است که بر سرویس می‌گذارید. پخش کردن همان آهنگ میان نشانی‌های دیگر سرور را به همان اندازه خسته می‌کند؛ سرویسی که این را ببیند قاعده را بر پایه رفتار می‌نویسد و مسدودسازی از 429 به شکلی ماندگارتر درمی‌آید. نوشتن نشانی ساختگی در سرآیند X-Forwarded-For یا عوض کردن User-Agent در هر درخواست هم از همین دسته است: سروری که درست پیکربندی شده به نشانی‌ای که کلاینت می‌نویسد اعتماد نمی‌کند و سرآیندهای ناهمخوان نشانه آشکار ترافیک خودکارند. اینکه سایت‌ها این نشانه‌ها را چگونه می‌خوانند در نوشته‌مان درباره سازوکار تشخیص ربات آمده است.

چرخش IP جایگاه مشروعی دارد، اما آن جایگاه «پس از دریافت 429» نیست. در یک کار گردآوری داده مجاز و پرحجم، نخست آهنگ کل به سطحی پایین آورده می‌شود که سایت تاب بیاورد و با robots.txt و شرایط استفاده سازگار باشد؛ سپس این ترافیک میان نشانی‌ها پخش می‌شود. راه‌های عملی پایبندی به آهنگ در وب اسکرپینگ بدون مسدود شدن: راهنمای عملی آمده است. شیوه کار چرخش را در نوشته‌مان درباره چرخش IP و بخش محصول را در صفحه پروکسی چرخشی ببینید.

چه کسانی به اقتضای کار با محدودیت نرخ سروکار دارند؟#

• تیم‌هایی که قیمت و موجودی را پایش می‌کنند. کاری که هر روز هزاران صفحه محصول می‌خواند اگر آهنگ را با سایت تنظیم نکند نرخ 429 آن به‌سرعت بالا می‌رود: راهکار پایش قیمت.
• کسانی که داده کاتالوگ و بازار گردآوری می‌کنند. برای هر سایت بودجه آهنگ جداگانه‌ای نگه‌داری می‌شود: راهکار استخراج داده.
• کسانی که به APIهایی با لیست سفید IP وصل می‌شوند. سهمیه به همان نشانی یا کلید نوشته می‌شود: نوشته‌مان درباره IP ثابت برای دسترسی به API.
• کسانی که اتوماسیون می‌سازند. گردش‌کاری که در یک دقیقه صدها فراخوانی آغاز کند در نخستین اجرا به حد می‌خورد؛ تنظیم‌های انتظار در وب اسکرپینگ با ⁦n8n⁩: تنظیم HTTP Request و پروکسی آمده است.
• تیم‌های عملیاتی که از شبکه‌ای پرجمعیت کار می‌کنند. اگر ده‌ها کارمند از یک نشانی دفتر به یک پنل وصل شوند، شمارنده مبتنی بر IP مجموع تیم را می‌بیند. هدف در اینجا گذشتن از حد نیست، بلکه وابسته کردن شمارنده تنها به استفاده خودتان است: پروکسی ISP نشانی ثابتی می‌دهد که نزد یک ارائه‌دهنده خدمات اینترنت ثبت شده و با کس دیگری مشترک نیست.

خطاهای رایج#

• ادامه دادن به تازه کردن صفحه روی صفحه 429. هر تازه‌سازی در شمارنده ثبت می‌شود.
• ادامه دادن به امتحان گذرواژه در حد ورود. زمان انتظار بیشتر می‌شود و در برخی سرویس‌ها حساب موقتاً قفل می‌شود.
• فرض کردن اینکه حد به IP وابسته است. اگر شمارنده به حساب یا کلید وابسته باشد، عوض کردن شبکه وقت تلف کردن است.
• تلاش دوباره بدون انتظار در سمت توسعه‌دهنده. پاسخِ تلاش بی‌درنگ پس از 429 یک 429 دیگر است.
• استفاده از یک کلید API در چند برنامه و جست‌وجوی حد در تک‌تک برنامه‌ها. شمارنده از آنِ کلید است و بدون دیدن مجموع نمی‌توان تشخیص داد.

راهنمای انتخاب#

پرسش‌های متداول#

آیا ⁦429 Too Many Requests⁩ مسدودسازی دائمی است؟#

نه. 429 از شمارنده‌ای وابسته به زمان می‌آید و با خالی شدن شمارنده دسترسی خودبه‌خود باز می‌شود. با حساب شما کاری انجام نمی‌شود.

آیا «too many requests» به معنای ویروس یا خرابی اینترنت است؟#

نه. پیام از سرور سرویسی می‌آید که به آن وصل شده‌اید و تنها به شمار درخواست‌ها مربوط است. اگر سایت‌های دیگر عادی باز می‌شوند، اینترنت شما مشکلی ندارد.

آیا خاموش و روشن کردن مودم خطای 429 را رفع می‌کند؟#

راه مطمئنی نیست. با اتصال دوباره مودم، نشانی IP در برخی اشتراک‌ها عوض می‌شود و در برخی نه؛ اگر شمارنده به حساب وابسته باشد هم تفاوتی ندارد. اینکه نشانی IP در چه شرایطی عوض می‌شود را در نوشته‌مان درباره تغییر نشانی IP توضیح داده‌ایم.

آیا rate limit و مسدود شدن IP یکی هستند؟#

نه. rate limit شمارنده‌ای وابسته به زمان است: برای همه اعمال می‌شود و با صبر باز می‌شود. مسدود شدن IP تصمیمی بلندمدت درباره یک نشانی مشخص است و بیشتر با 403 خودش را نشان می‌دهد. نشانی‌ای که پیوسته به حد فشار بیاورد ممکن است با گذشت زمان به گروه دوم برود.

اگر سرآیند Retry-After نباشد چقدر باید صبر کنم؟#

اگر کاربر هستید با چند دقیقه آغاز کنید و پس از هر تلاش ناموفق مدت را بیشتر کنید. اگر برنامه می‌نویسید عقب‌نشینی نمایی به کار ببرید و برای شمار تلاش‌ها سقف بگذارید.

آیا استفاده از پروکسی خطای 429 را رفع می‌کند؟#

اگر حد را آهنگ یا رفتار خودتان پر می‌کند، نه: همان آهنگ شمارنده نشانی تازه را هم پر می‌کند و شمارنده وابسته به حساب اصلاً نشانی را نمی‌بیند. حالتی که پروکسی تفاوت ایجاد می‌کند آن است که شمارنده را نه شما که دیگرانی پر می‌کنند که نشانی را با آن‌ها مشترک هستید. در آن صورت یک نشانی ثابت که تنها از آنِ شماست شمارنده را به استفاده خودتان محدود می‌کند.

خلاصه#

429 Too Many Requests پاسخی موقتی است که می‌گوید به محدودیت نرخ (rate limit) یک سرویس خورده‌اید. حد می‌تواند بر اساس نشانی IP، حساب، نشست، کلید API یا یک نقطه اتصال شمرده شود و همین تعیین می‌کند چه چیزی سودمند است. راه‌حل برای کاربر دست نگه داشتن، بستن چیزهایی که در پس‌زمینه درخواست می‌فرستند و صبر کردن است. راه‌حل برای توسعه‌دهنده خواندن سرآیندهای سهمیه، پیروی از Retry-After و پایین آوردن آهنگ است. با چرخاندن IP نمی‌توان از حد گذشت؛ چرخش تنها برای پخش کردن باری است که از آغاز برنامه‌ریزی شده و به سایت احترام می‌گذارد. انواع نشانی مناسب کارتان را در خدمات پروکسی ما می‌یابید.