خطای 429 وردپرس؛ محدودیت درخواست از سایت است یا API؟

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

مثلا ممکن است مشتریان سایت را باز کنند اما افزونه پیامک، 429 بگیرد. در این حالت، تغییر قوانین ورود وردپرس کمکی به سهمیه API شرکت پیامک نمی کند. برعکس، وقتی مرورگر مدیر روی درخواست ذخیره نوشته محدود شده است، باید مسیر همان درخواست از مرورگر تا سرور بررسی شود.

خطای 429 دقیقا چه چیزی را ثابت می کند؟

در استاندارد HTTP برای وضعیت 429، مفهوم اصلی «درخواست بیش از حد در بازه زمانی» است. استاندارد یک عدد ثابت برای همه سایت ها تعیین نمی کند. محدودیت می تواند به حساب، IP، مسیر، کلید API یا سیاست دیگری وابسته باشد. بنابراین از روی کد به تنهایی نمی توان گفت سایت حمله دیده یا ظرفیت هاست تمام شده است.

429 را با 403 و 503 یکی نگیرید. ممکن است همه در یک ابزار به شکل خطا دیده شوند، اما هدف پاسخ و مسیر بررسی متفاوت است. اگر پاسخ واقعی 503 است، راهنمای بررسی خطای 503 وردپرس مسیر مرتبط تری دارد. متن روی صفحه را هم با کد واقعی در Network مرورگر تطبیق دهید؛ عنوان یک صفحه سفارشی همیشه کد تحویل شده نیست.

از یک درخواست نمونه شروع کنید

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

در مرورگر، ابزار توسعه دهنده و بخش Network را باز کنید. بعد از یک بار انجام کار ناموفق، درخواست 429 را پیدا کنید و Response Headers و متن Response را ببینید. شناسه درخواست یا رخداد را اگر وجود دارد نگه دارید. فایل گزارش شبکه می تواند کوکی، توکن و داده فرم داشته باشد؛ آن را بدون پاک سازی اطلاعات محرمانه در دسترس عمومی نگذارید.

چه کسی 429 می گیرد؟	نمونه	بررسی اول
بازدیدکننده سایت	باز کردن صفحه، جستجو یا ارسال فرم	قانون CDN یا WAF و مسیر ورودی
مدیر وردپرس	ذخیره نوشته یا درخواست پس زمینه پیشخوان	درخواست دقیق، تعداد تکرار و قانون مربوط به مدیر
افزونه سمت سرور	پیامک، همگام سازی یا دریافت داده	سهمیه و سیاست API مقصد
ابزار پایش یا ربات مجاز	درخواست های دوره ای از یک مبدا	فاصله پایش و هویت معتبر ابزار

Retry-After را بخوانید، اما از آن وعده نسازید

پاسخ 429 می تواند هدر Retry-After داشته باشد. مقدار آن ممکن است تعداد ثانیه انتظار یا یک تاریخ HTTP باشد؛ جزئیات این قالب در تعریف Retry-After در HTTP آمده است. نبودن این هدر به معنی اجازه تکرار سریع نیست. مدت و محدوده محدودیت را باید از سیاست صادرکننده پاسخ گرفت.

HTTP/1.1 429 Too Many Requests
Retry-After: 120

این نمونه آموزشی می گوید پیش از درخواست بعدی دست کم مهلت اعلام شده را رعایت کنید؛ تضمین نمی کند بعد از آن، هر تعداد درخواست پذیرفته شود. اگر چند worker یا چند سایت از یک حساب مشترک استفاده می کنند، رعایت فاصله در فقط یک بخش شاید مصرف کل را پایین نیاورد. برنامه تلاش دوباره باید بین مصرف کننده های همان سهمیه هماهنگ باشد.

برای درخواست خواندنی، توسعه دهنده می تواند تلاش مجدد محدود با فاصله افزایشی و کمی پراکندگی زمانی طراحی کند. تعداد تلاش و سقف انتظار هم باید مشخص باشد. برای ثبت سفارش یا عملیات مالی، پیش از تکرار باید وضعیت واقعی مقصد و سازوکار جلوگیری از عملیات تکراری روشن شود. یک درخواست ناموفق از دید سایت، همیشه به معنی انجام نشدن کار در مقصد نیست.

429 را CDN صادر کرده یا خود سرور؟

از شناسه رخداد و زمان استفاده کنید تا لاگ CDN، WAF و سرور مبدا کنار هم قرار بگیرند. وجود نام Cloudflare در هدر، به تنهایی ثابت نمی کند قانون همان سرویس پاسخ را ساخته است؛ ترافیک پاسخ مبدا هم می تواند از آن عبور کند. باید رخداد منطبق با همان درخواست یا لاگ منبع پاسخ پیدا شود.

در سایت دارای Cloudflare، راهنمای رسمی خطای 429 بررسی Rate Limiting Analytics را برای محدود شدن کاربران سایت مطرح می کند. سهمیه API مدیریت Cloudflare را با محدودیت بازدیدکننده سایت اشتباه نگیرید. عدد مجاز یک API مدیریتی، تنظیم پیشنهادی برای ورود یا جستجوی وردپرس شما نیست.

اگر درخواست پیش از رسیدن به مبدا متوقف شده باشد، ممکن است در access log سایت دیده نشود. اگر به مبدا رسیده و آنجا 429 تولید شده، قانون وب سرور، افزونه یا سامانه امنیتی میزبان باید بررسی شود. از پشتیبانی بخواهید منبع مشخص را اعلام کند؛ عبارت کلی «CDN را بردارید» بدون این شواهد، مسیر تشخیص را کوتاه نمی کند.

چرا چند نفر در یک دفتر با هم محدود می شوند؟

ممکن است همه از یک IP خروجی مشترک استفاده کنند و قانون بر اساس IP شمارش کند. یک کاربر پرمصرف یا یک ابزار پس زمینه می تواند روی دیگران اثر بگذارد. این فقط یک احتمال است؛ شمارنده و ویژگی های قانون را بررسی کنید. تغییر شبکه برای مقایسه محدود مفید است، اما دور زدن مداوم محدودیت با IPهای تازه راه حل مدیریتی نیست.

برای پیشخوان، نوع درخواست را مهم تر از نام مدیر بدانید

اگر فقط ذخیره در ویرایشگر یا یک عملیات مدیریتی مشکل دارد، مسیر و روش همان درخواست را یادداشت کنید. یک قانون عمومی که تمام درخواست های REST یا admin-ajax را مشابه ورود ناموفق حساب کرده، ممکن است کار سالم را هم بگیرد. تعداد تب های باز، ابزار همگام سازی و افزونه ای که درخواست تکراری می سازد نیز ارزش بررسی دارند.

در توصیه های طراحی Rate Limiting در Cloudflare، تطبیق قانون با نوع ترافیک و ویژگی های درخواست اهمیت دارد. آستانه مناسب ورود با عملیات جستجوی عمومی یا ویرایش محتوا لزوما برابر نیست. تغییر را محدود، ثبت شده و قابل برگشت انجام دهید؛ معاف کردن تمام پیشخوان یا همه IPهای یک شبکه از همه کنترل ها، اصلاح دقیقی نیست.

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

وقتی افزونه از یک API بیرونی 429 می گیرد

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

در HTTP API وردپرس، دریافت یک پاسخ HTTP با دریافت WP_Error فرق دارد. توسعه دهنده باید کد را هم بخواند؛ تابع دریافت کد پاسخ وردپرس برای همین کار وجود دارد. صرف اینکه اتصال خطای شبکه نداده، به معنی موفقیت 2xx یا پذیرفته شدن عملیات تجاری نیست.

محدودیت مقصد را از مستندات همان سرویس بگیرید. اگر سهمیه واقعا برای نیاز عادی کافی نیست، درباره پلن یا شیوه اتصال تصمیم بگیرید. کوتاه کردن فاصله cron یا افزایش تعداد worker، سهمیه شرکت دیگر را بیشتر نمی کند و ممکن است صف تلاش مجدد را بزرگ تر کند.

آیا خرید هاست قوی تر 429 را برطرف می کند؟

فقط اگر تشخیص نشان دهد سیاست یا ظرفیت محیط فعلی باید تغییر کند، بررسی زیرساخت معنی دارد. برای سهمیه حساب API یا قانون نادرست WAF، منابع بیشتر درمان مستقیم نیست. پیش از خرید، منبع پاسخ و الگوی مصرف را روشن کنید.

یک اصلاح را با همان سناریو بسنجید

پس از رعایت مهلت و اصلاح علت، یک عملیات عادی را تکرار کنید و نتیجه واقعی را ببینید. برای فرم، رسیدن داده؛ برای ویرایش، ذخیره نسخه تازه؛ و برای API، تایید نتیجه در مقصد مهم است. چند پاسخ 200 از صفحه اصلی، سلامت مسیر درگیر را ثابت نمی کند.

در گزارش پایان، مسیر خطادار، قانون یا سهمیه، تغییر انجام شده و نتیجه را ثبت کنید. اگر بررسی چند لایه لازم است، محدوده مدیریت و پشتیبانی سایت را مشخص کنید. خطای 429 زمانی درست مدیریت شده که مصرف عادی موفق باشد، تلاش های مجدد مهار شده باشند و حفاظت لازم سایت هم کار کند.