خطای "درخواست‌های بیش از حد" 429: چگونه محدودیت‌ها را با استفاده از پروکسی و چرخش IP دور بزنیم

اگر شما به پارس کردن بازارها، نظارت بر قیمت‌های رقبای خود یا اتوماسیون کار با شبکه‌های اجتماعی مشغول هستید، حتماً با خطای 429 Too Many Requests مواجه شده‌اید. سایت درخواست‌های شما را مسدود می‌کند و آن‌ها را مشکوک می‌داند و تمام اتوماسیون متوقف می‌شود. در این مقاله بررسی می‌کنیم که چرا این مشکل به وجود می‌آید و چگونه می‌توان آن را از طریق تنظیمات صحیح پروکسی، چرخش IP و توزیع بار به درستی حل کرد.

ما راه‌حل‌های خاصی برای وظایف مختلف نشان خواهیم داد: پارس کردن Wildberries و Ozon، نظارت بر رقبا، کار با API شبکه‌های اجتماعی و جمع‌آوری داده‌های انبوه. تمام توصیه‌ها بر اساس تجربه عملی و در پروژه‌های واقعی کار می‌کنند.

خطای 429 Too Many Requests چیست و چرا به وجود می‌آید

خطای 429 Too Many Requests یک کد پاسخ HTTP است که سرور زمانی برمی‌گرداند که شما تعداد مجاز درخواست‌ها را در یک دوره زمانی معین تجاوز می‌کنید. این یک مکانیزم حفاظتی برای سایت‌ها در برابر بارگذاری بیش از حد و جمع‌آوری داده‌های خودکار است.

موقعیت‌های معمولی که خطای 429 به وجود می‌آید:

• پارس کردن بازارها — شما قیمت‌ها را از Wildberries، Ozon یا Avito جمع‌آوری می‌کنید و صدها درخواست در دقیقه ارسال می‌کنید. سایت فعالیت غیرعادی را از یک IP می‌بیند و آن را مسدود می‌کند.
• نظارت بر رقبا — جمع‌آوری خودکار داده‌ها درباره محصولات، قیمت‌ها، موجودی. با بررسی‌های مکرر، محدودیت فعال می‌شود.
• کار با API — بسیاری از API‌ها محدودیت‌های سختی دارند: به عنوان مثال، API اینستاگرام 200 درخواست در ساعت مجاز می‌داند، توییتر — 300 درخواست در 15 دقیقه.
• ثبت‌نام یا اقدامات انبوه — ایجاد حساب‌ها، ارسال پیام‌ها، لایک‌ها. پلتفرم‌ها به سرعت اتوماسیون را شناسایی کرده و IP را مسدود می‌کنند.

مهم است که درک کنید: خطای 429 فقط یک محدودیت فنی نیست. این یک سیگنال است که سایت فعالیت شما را به عنوان مشکوک شناسایی کرده است. اگر به حمله از همان IP ادامه دهید، ممکن است با بن دائمی مواجه شوید.

چگونه سایت‌ها فعالیت مشکوک را شناسایی می‌کنند

برای دور زدن مؤثر مسدودیت‌ها، باید بفهمید که سایت‌ها چگونه شما را شناسایی می‌کنند. سیستم‌های حفاظتی مدرن به تجزیه و تحلیل بسیاری از پارامترها می‌پردازند:

1. آدرس IP و فرکانس درخواست‌ها

واضح‌ترین پارامتر. اگر از یک IP، 100 درخواست در دقیقه ارسال شود، در حالی که یک کاربر عادی 5-10 درخواست می‌فرستد — این یک اتوماسیون واضح است. سایت‌ها محدودیت‌هایی را تعیین می‌کنند:

• Wildberries: تقریباً 60 درخواست در دقیقه از یک IP
• Ozon: حدود 30-40 درخواست در دقیقه
• Avito: محدودیت‌های سخت، به ویژه برای درخواست‌های جستجو
• API اینستاگرام: 200 درخواست در ساعت برای هر برنامه

2. User-Agent و هدرهای مرورگر

اگر شما درخواست‌ها را از طریق اسکریپت بدون User-Agent صحیح ارسال کنید، سایت فوراً متوجه می‌شود که این یک مرورگر واقعی نیست. همچنین هدرها تجزیه و تحلیل می‌شوند: Accept، Accept-Language، Referer. عدم وجود این هدرها یا مقادیر غیرمعمول — یک پرچم قرمز است.

3. الگوهای رفتاری

یک کاربر واقعی درخواست‌ها را با تناوب ایده‌آل هر 2 ثانیه ارسال نمی‌کند. او اسکرول می‌کند، کلیک می‌کند، و وقفه‌هایی دارد. اگر پارسر شما مانند یک مترونوم کار کند — این مشکوک است.

4. نوع آدرس IP

بسیاری از پلتفرم‌ها لیست‌های سیاه IP‌های دیتاسنترها را نگهداری می‌کنند. اگر از پروکسی‌های ارزان با AWS یا Google Cloud استفاده کنید، احتمال مسدود شدن بیشتر است. IP‌های مقیم از ارائه‌دهندگان واقعی کمتر مشکوک به نظر می‌رسند.

چرخش پروکسی: روش اصلی دور زدن محدودیت‌ها

راه‌حل اصلی مشکل 429 — چرخش آدرس‌های IP است. به جای اینکه تمام درخواست‌ها را از یک IP ارسال کنید، بار را بین چندین آدرس توزیع می‌کنید. هر IP تعداد کمی درخواست ارسال می‌کند و از محدودیت‌ها تجاوز نمی‌کند.

انواع چرخش پروکسی

مثال عملی: پارس کردن Wildberries

فرض کنید شما نیاز دارید قیمت‌های 10,000 محصول را پارس کنید. Wildberries پس از 60 درخواست در دقیقه از یک IP مسدود می‌کند. چگونه حل کنیم:

1. از چرخش بر اساس درخواست استفاده کنید — هر درخواست از یک IP جدید ارسال می‌شود. شما به حدود 167 IP مختلف نیاز دارید (10,000 درخواست / 60 در دقیقه = 167 دقیقه با یک IP، اما با چرخش این کار را در 10-15 دقیقه انجام می‌دهید).
2. تأخیرها را تنظیم کنید — حتی با چرخش نباید 1000 درخواست در ثانیه ارسال کنید. بهینه: 5-10 درخواست در ثانیه با IP‌های مختلف.
3. تصادفی‌سازی را اضافه کنید — تأخیرها باید تصادفی باشند: از 0.5 تا 2 ثانیه بین درخواست‌ها.

برای چنین وظایفی، پروکسی‌های مقیم با چرخش خودکار ایده‌آل هستند — آن‌ها دارای استخرهایی از میلیون‌ها IP هستند و آدرس‌ها را برای هر درخواست بدون دخالت شما تغییر می‌دهند.

تنظیم تأخیرها بین درخواست‌ها

حتی با چرخش پروکسی، نمی‌توانید سایت را با درخواست‌ها با حداکثر سرعت بمباران کنید. سیستم‌های حفاظتی مدرن بار کلی سرور را تجزیه و تحلیل می‌کنند و می‌توانند کل دامنه IP را مسدود کنند اگر فعالیت شبیه به DDoS را ببینند.

قوانین تنظیم تأخیرها

تأخیر نمایی (exponential backoff)

اگر شما هنوز هم با خطای 429 مواجه شدید، به حمله به سایت ادامه ندهید. از استراتژی تأخیر نمایی استفاده کنید:

• اولین تلاش ناموفق → 1 ثانیه صبر کنید
• دومین تلاش ناموفق → 2 ثانیه صبر کنید
• سومین تلاش ناموفق → 4 ثانیه صبر کنید
• چهارمین تلاش ناموفق → 8 ثانیه صبر کنید
• و به همین ترتیب، تا حداکثر (به عنوان مثال، 60 ثانیه)

این استراتژی به سرور زمان می‌دهد تا "خنک" شود و احتمال بن دائمی را کاهش می‌دهد. بسیاری از API‌ها (Google، Twitter) دقیقاً چنین رویکردی را در مستندات خود توصیه می‌کنند.

مثال تنظیم برای وظایف مختلف

User-Agent و هدرها: شبیه‌سازی مرورگر واقعی

چرخش پروکسی و تأخیرها مشکل فرکانس درخواست‌ها را حل می‌کنند، اما این کافی نیست. سایت‌ها تجزیه و تحلیل می‌کنند که شما چگونه درخواست‌ها را ارسال می‌کنید. اگر هدرها مشکوک به نظر برسند — مسدود شدن اجتناب‌ناپذیر است.

هدرهای الزامی برای شبیه‌سازی مرورگر

حداقل مجموعه هدرهایی که باید در هر درخواست وجود داشته باشد:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cache-Control: max-age=0

چرخش User-Agent

از یک User-Agent یکسان برای تمام درخواست‌ها استفاده نکنید. یک لیست از 10-20 نسخه به‌روز مرورگرها ایجاد کنید و آن‌ها را به‌طور تصادفی تغییر دهید:

• Chrome (Windows، macOS، Linux)
• Firefox (نسخه‌های مختلف)
• Safari (macOS، iOS)
• Edge (Windows)

Referer و Origin

بسیاری از سایت‌ها بررسی می‌کنند که درخواست از کجا آمده است. اگر شما صفحه محصول را پارس می‌کنید، در هدر Referer باید لینکی به کاتالوگ یا جستجو باشد. اگر API را پارس می‌کنید — باید Origin صحیح باشد.

مثال برای پارس کردن Wildberries:

Referer: https://www.wildberries.ru/catalog/0/search.aspx?search=ноутбук
Origin: https://www.wildberries.ru

کدام پروکسی‌ها را برای دور زدن 429 انتخاب کنیم

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

مقایسه انواع پروکسی برای دور زدن محدودیت‌ها

توصیه‌ها برای انتخاب

برای پارس کردن بازارها (Wildberries، Ozon، Avito): از پروکسی‌های مقیم با چرخش بر اساس درخواست استفاده کنید. استخر باید بزرگ باشد — حداقل 10,000 IP. این تضمین می‌کند که هر IP تعداد کمی درخواست ارسال می‌کند و تحت محدودیت‌ها قرار نمی‌گیرد.

برای کار با API شبکه‌های اجتماعی: پروکسی‌های موبایل — انتخاب بهینه هستند. اینستاگرام و TikTok به IP‌های اپراتورهای موبایل بیشتر از مقیم‌ها اعتماد می‌کنند. یک IP موبایل می‌تواند بدون مشکل 5-10 حساب را پشتیبانی کند.

برای نظارت بر قیمت‌های رقبا: پروکسی‌های مقیم با چرخش بر اساس تایمر (هر 10-15 دقیقه). این امکان را می‌دهد که یک سری درخواست‌ها را از یک IP انجام دهید و سشن را حفظ کنید، اما در عین حال از محدودیت‌ها تجاوز نکنید.

برای وظایف ساده (پارس کردن اخبار، وبلاگ‌ها): پروکسی‌های دیتاسنترها ممکن است مناسب باشند، اگر سایت حفاظت جدی نداشته باشد. اما آماده باشید که با مسدودیت‌های دوره‌ای مواجه شوید.

موارد واقعی: پارس کردن بازارها و API

مورد 1: نظارت بر قیمت‌ها در Wildberries (10,000 محصول روزانه)

وظیفه: فروشنده بازار به نظارت بر قیمت‌های رقبا در 10,000 موقعیت می‌پردازد. نیاز به جمع‌آوری داده‌ها 2 بار در روز است.

مشکل: با استفاده از یک IP پس از 50-60 درخواست بن می‌شد. پارس کردن 10,000 محصول چندین ساعت طول می‌کشید و با مسدودیت‌های مداوم مواجه بود.

راه‌حل:

1. پروکسی‌های مقیم با استخر 50,000 IP و چرخش بر اساس درخواست را متصل کردم
2. تأخیرهای تصادفی از 0.5 تا 2 ثانیه بین درخواست‌ها را تنظیم کردم
3. چرخش User-Agent (20 گزینه Chrome و Firefox) را اضافه کردم
4. هدرهای Referer و Accept صحیح را تنظیم کردم

نتیجه: پارس کردن 10,000 محصول 15-20 دقیقه طول می‌کشد بدون هیچ مسدودیتی. هر IP حداکثر 1-2 درخواست ارسال می‌کند، که نمی‌توان آن را به عنوان اتوماسیون شناسایی کرد.

مورد 2: اتوماسیون اینستاگرام (50 حساب مشتری)

وظیفه: آژانس SMM به مدیریت 50 حساب مشتری در اینستاگرام می‌پردازد. نیاز به انتشار محتوا، پاسخ به نظرات و جمع‌آوری آمار دارد.

مشکل: API اینستاگرام محدودیت 200 درخواست در ساعت برای هر برنامه دارد. با کار بر روی 50 حساب، محدودیت‌ها در 10 دقیقه تمام می‌شدند.

راه‌حل:

1. 10 برنامه مختلف API اینستاگرام (5 حساب برای هر برنامه) ایجاد کردیم
2. هر برنامه از یک پروکسی موبایل جداگانه استفاده می‌کند
3. تأخیر 18 ثانیه بین درخواست‌ها را تنظیم کردیم (200 درخواست/ساعت = 1 درخواست هر 18 ثانیه)
4. تأخیر نمایی را در صورت دریافت 429 اضافه کردیم

نتیجه: همه 50 حساب به طور پایدار کار می‌کنند. خطاهای 429 به ندرت رخ می‌دهند (1-2 بار در هفته) و به طور خودکار از طریق تلاش‌های مجدد پردازش می‌شوند.

مورد 3: پارس کردن Avito (آگهی‌ها در سراسر روسیه)

وظیفه: aggregator املاک آگهی‌ها را از Avito در تمام شهرهای روسیه برای پایگاه داده خود جمع‌آوری می‌کند.

مشکل: Avito یکی از سخت‌ترین حفاظت‌ها را در میان سایت‌های روسی دارد. مسدودیت‌ها پس از 10-15 درخواست حتی از IP‌های مختلف دیتاسنترها آغاز می‌شد.

راه‌حل:

1. انتقال به پروکسی‌های مقیم با وابستگی جغرافیایی (IP از همان شهر که پارس می‌شود)
2. افزایش تأخیرها به 3-5 ثانیه بین درخواست‌ها
3. استفاده از مرورگر headless (Puppeteer) به جای درخواست‌های ساده HTTP
4. شبیه‌سازی اقدامات کاربر: اسکرول، کلیک، حرکات ماوس

نتیجه: پارس موفق 50,000+ آگهی در روز. مسدودیت‌ها 95% کاهش یافته است. 5% باقی‌مانده از طریق تلاش‌های مجدد با IP جدید پردازش می‌شوند.

مورد 4: نظارت بر API رقبا (e-commerce)

وظیفه: فروشگاه اینترنتی موجودی کالاها و قیمت‌ها را از 20 رقیب از طریق API آن‌ها پیگیری می‌کند.

مشکل: بیشتر API‌های رقبا دارای محدودیت‌های عمومی (100-500 درخواست در ساعت) هستند. در صورت تجاوز، 429 برمی‌گردد.

راه‌حل:

1. ایجاد صف درخواست‌ها با اولویت‌ها (مهم‌ترین کالاها بیشتر بررسی می‌شوند)
2. نظارت بر محدودیت‌ها از طریق هدرهای پاسخ (X-RateLimit-Remaining)
3. وقفه خودکار در صورت رسیدن به 80% محدودیت
4. استفاده از چندین کلید API برای هر رقیب (جایی که ممکن است)

نتیجه: سیستم به طور خودکار درخواست‌ها را به گونه‌ای توزیع می‌کند که هرگز محدودیت‌ها را تجاوز نکند. داده‌ها با حداکثر فرکانس ممکن بدون مسدودیت به‌روزرسانی می‌شوند.

نتیجه‌گیری

خطای 429 Too Many Requests یک مکانیزم حفاظتی برای سایت‌ها است که می‌توان آن را با رویکرد صحیح دور زد. اصول اصلی حل مشکل:

• چرخش آدرس‌های IP — بار را بین چندین پروکسی توزیع کنید تا هر آدرس حداقل درخواست‌ها را ارسال کند
• تأخیرهای صحیح — شبیه‌سازی یک کاربر واقعی با وقفه‌های تصادفی از 1 تا 5 ثانیه
• هدرهای صحیح — از User-Agent‌های به‌روز و مجموعه کامل هدرهای مرورگر استفاده کنید
• انتخاب نوع پروکسی — برای سایت‌های پیچیده (بازارها، شبکه‌های اجتماعی) از پروکسی‌های مقیم یا موبایل استفاده کنید
• پردازش خطاها — از تأخیر نمایی در صورت دریافت 429 استفاده کنید، به سایت دوباره حمله نکنید

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

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