---
title: "وب اسکرپینگ بدون مسدود شدن: راهنمای عملی"
description: "اسکرپرها بیشتر به دلیل محدودیت نرخ، هدرهای ناقص و یک IP واحد مسدود می‌شوند. شیوه جمع‌آوری داده در چارچوب قواعد و بدون فشار بر سایت را توضیح می‌دهیم."
url: https://proxynet.io/fa/blog/web-scraping-without-getting-blocked
date: 2026-09-13
author: "Acar Diveroli"
category: "وب اسکرپینگ"
lang: fa
---

# وب اسکرپینگ بدون مسدود شدن: راهنمای عملی

اسکریپت پایش قیمت روز اول خوب کار می‌کند، روز دوم صفحه‌های نیمه‌خالی برمی‌گرداند و روز سوم برای همه درخواست‌ها `403` می‌گیرد. تقریباً هر کسی که اسکرپر می‌نویسد این را تجربه می‌کند و نخستین واکنش معمولاً جست‌وجوی «IP بیشتر» یا «پنهان شدن بهتر» است. بیشتر مسدودسازی‌ها علتی عادی‌تر دارند: ده‌ها درخواست در ثانیه، هدرهایی که هیچ‌گاه با مرورگر واقعی جور نیستند، انباشته شدن همه بار روی یک آدرس IP و قواعدی که سایت آشکارا اعلام کرده اما کسی نخوانده است.

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

> **نکته: پاسخ کوتاه**
>
> اسکرپرها بیشتر به سه دلیل مسدود می‌شوند: فرستادن درخواست با سرعتی که به سایت فشار بیاورد، به کار بردن هدرهایی ناسازگار با کلاینت واقعی و فرستادن همه ترافیک از یک آدرس IP. راه‌حل این است که سرعت درخواست را محدود کنید و به پاسخ‌های `429` و `Retry-After` احترام بگذارید، هویت کلاینتی سازگار که شما را معرفی کند به کار ببرید، در صورت نیاز بار را میان IPهای مختلف پخش کنید و از robots.txt و شرایط سایت پیروی کنید. اگر API رسمی وجود دارد، نخست همان را به کار ببرید.

## چرا سایت‌ها اسکرپرها را مسدود می‌کنند؟

پشت محدود کردن ترافیک خودکار توسط یک سایت، معمولاً به‌جای فرض بدخواهی، هزینه‌های مشخصی قرار دارد:

- **بار سرور.** یک اسکریپت که صدها درخواست در ثانیه می‌فرستد می‌تواند منابعی را که یک فروشگاه اینترنتی کوچک برای بازدیدکنندگان واقعی کنار گذاشته مصرف کند. در صفحه‌های جست‌وجو و فیلتر که به پایگاه داده فشار می‌آورند، اثر چند برابر می‌شود.
- **باند و هزینه زیرساخت.** هر درخواست در صورت‌حساب سرور و CDN سایت دیده می‌شود.
- **محافظت از محتوا و داده تجاری.** وقتی قیمت، موجودی و داده آگهی‌ها به‌صورت انبوه توسط رقیبان گرفته شود، صاحب سایت ممکن است بخواهد آن را محدود کند.
- **امنیت.** ورود با حمله brute force، آزمون کارت و احتکار موجودی هم با ترافیک خودکار انجام می‌شود. سامانه‌های محافظتی در نگاه نخست نمی‌توانند این ترافیک را از اسکرپر مشروع جدا کنند.

بیشتر این تصمیم‌ها نه در کد خود سایت، بلکه در لایه مدیریت ربات جلوی آن گرفته می‌شوند. CDNها و سرویس‌های امنیتی هر درخواست را با نشانه‌هایی مانند سرعت، شهرت IP، سازگاری هدرها و رفتار امتیازدهی می‌کنند. برای نمونه‌ای از اینکه این لایه ترافیک ربات را چگونه دسته‌بندی می‌کند، [Cloudflare Precursor](/fa/blog/cloudflare-precursor) را ببینید.

## نشانه‌های مسدود شدن چیست؟

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

- **`403 Forbidden`:** درخواست فهمیده شده اما رد شده است. ممکن است به شهرت IP، هدرهای ناقص یا محدودیت جغرافیایی مربوط باشد.
- **`429 Too Many Requests`:** از محدودیت نرخ گذشته‌اید. اغلب هدر `Retry-After` می‌گوید چقدر صبر کنید.
- **`503 Service Unavailable`:** ممکن است سرور واقعاً شلوغ باشد یا سامانه محافظت ربات این پاسخ را موقتاً برگرداند.
- **`200` همراه صفحه بررسی:** کد وضعیت موفق به نظر می‌رسد، اما محتوای صفحه به‌جای فهرست محصول، صفحه بررسی است.
- **`200` همراه محتوای خالی یا ناقص:** انتخابگرهای شما چیزی نمی‌یابند. ممکن است از مسدودسازی یا از صفحه‌ای باشد که محتوا را با جاوااسکریپت بارگذاری می‌کند.
- **هدایت به صفحه ورود:** نشست شما بسته شده است، اغلب به دلیل تغییر IP در میانه نشست.
- **کندتر شدن پاسخ‌ها:** برخی سامانه‌ها به‌جای رد درخواست، پاسخ را عمداً به تأخیر می‌اندازند.

هر کد وضعیت HTTP و اینکه کدام‌ها را باید دوباره تلاش کنید در [کدهای وضعیت HTTP در وب اسکرپینگ](/fa/blog/http-status-codes-web-scraping) آمده است. برای تشخیص اینکه محتوای خالی مسدودسازی است یا صفحه پویا، [صفحه‌های ایستا و پویا](/fa/blog/static-vs-dynamic-pages) را ببینید. اگر سایت پشت Cloudflare است، در [اسکرپر Cloudflare](/fa/blog/cloudflare-scraper) می‌بینید که صفحه بررسی، قاعده فایروال و محدودیت نرخ را چگونه از روی هدرها و بدنه پاسخ از هم جدا کنید.

| نشانه | علت محتمل | راه‌حل مشروع |
|---|---|---|
| `429` فراوان در زمان کوتاه | سرعت درخواست از محدودیت سایت بیشتر است | همروندی را کم کنید، به اندازه `Retry-After` صبر کنید |
| `403` از همان درخواست نخست | هدر ناقص، IP دیتاسنتر یا محدودیت منطقه‌ای | هدرهای سازگار؛ نوع IP و موقعیت متناسب با مخاطبان سایت |
| `403` که پس از مدتی آغاز می‌شود | ترافیک فشرده از یک IP علامت خورده است | کندتر شوید، بار را در زمان و در صورت نیاز میان IPها پخش کنید |
| صفحه بررسی | رفتار یا شهرت IP مشکوک شناخته شده | متوقف شوید، سرعت و دامنه را بازبینی کنید؛ API یا اجازه بجویید |
| `200` اما محتوای خالی | صفحه با جاوااسکریپت بارگذاری می‌شود یا محتوا پنهان شده | درخواست API پس‌زمینه را بیابید؛ در صورت نیاز مرورگر headless |
| نشست ناگهان بسته می‌شود | IP در میانه نشست عوض شده | برای نشست IP ثابت به کار ببرید |
| پاسخ‌ها با گذر زمان کند می‌شوند | بار سرور یا تأخیر عمدی | سرعت درخواست را کم کنید، از ساعت‌های اوج دوری کنید |
| محتوا با مرورگر واقعی متفاوت است | محتوای ویژه ربات یا تفاوت موقعیت | موقعیت را بررسی کنید؛ هویت کلاینتی که شما را معرفی کند |

## سرعت درخواست: چگونه به محدودیت‌ها احترام بگذاریم؟

رایج‌ترین و پیشگیری‌پذیرترین علت مسدودسازی سرعت است. انسان در یک فروشگاه اینترنتی هر چند ثانیه یک صفحه باز می‌کند؛ اسکرپری که با `asyncio` نوشته شده در همان مدت می‌تواند صدها درخواست بفرستد. [⁦RFC 6585⁩](https://www.rfc-editor.org/rfc/rfc6585#section-4) کد `429 Too Many Requests` را دقیقاً برای این وضعیت تعریف می‌کند و می‌گوید سرور می‌تواند با هدر `Retry-After` زمان انتظار را اعلام کند.

قاعده‌های پایه کنترل سرعت:

1. **برای هر سایت سقف همروندی بگذارید.** تعداد درخواست‌های باز به یک دامنه را کم نگه دارید. همروندی کل می‌تواند زیاد باشد، اما سهمی که به یک سایت می‌رسد باید کم بماند.
2. **میان درخواست‌ها تأخیر تصادفی بگذارید.** درخواستی دقیقاً هر 2 ثانیه از بازه‌های نامنظم بیشتر به چشم می‌آید و از جهش‌های لحظه‌ای هم جلوگیری نمی‌کند.
3. **با `429` و `503` کند شوید نه تند.** فرستادن فوری دوباره درخواست ناموفق مشکل را بدتر می‌کند. از backoff نمایی استفاده کنید.
4. **به هدر `Retry-After` احترام بگذارید.** مقدار می‌تواند تعداد ثانیه یا تاریخ HTTP باشد؛ [توضیح MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Retry-After) هر دو شکل را نشان می‌دهد.
5. **درخواست غیرضروری نفرستید.** برای دانلود نکردن دوباره صفحه‌های تغییرنیافته، مقدارهای `ETag` و `Last-Modified` را نگه دارید و با `If-None-Match` و `If-Modified-Since` درخواست شرطی بفرستید؛ اگر صفحه تغییر نکرده باشد سرور `304` بدون بدنه برمی‌گرداند.
6. **از نقشه سایت استفاده کنید.** به‌جای خزیدن پیوندبه‌پیوند کل سایت، از آدرس‌های `sitemap.xml` سایت آغاز کنید. پیدا کردن این فایل و برگزیدن تنها آدرس‌های تغییرکرده با `lastmod` را در نوشته [پیدا کردن نقشه سایت](/fa/blog/find-website-sitemap) توضیح داده‌ایم.
7. **از ساعت‌های اوج دوری کنید.** وقتی مخاطبان سایت بیشترین فعالیت را دارند جمع‌آوری انبوه انجام ندهید.

تابع پایتون زیر در پاسخ‌های `429`، `502`، `503` و `504` به هدر `Retry-After` احترام می‌گذارد؛ اگر هدر نباشد backoff نمایی با جزء تصادفی اعمال می‌کند. پاسخ‌هایی مانند `403` و `404` را دوباره تلاش نمی‌کند، چون فرستادن دوباره نتیجه را تغییر نمی‌دهد:

```python
import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

import requests

RETRY_STATUS = {429, 502, 503, 504}

def retry_after_seconds(value):
    """Retry-After can be seconds or an HTTP date."""
    if not value:
        return None
    if value.isdigit():
        return int(value)
    try:
        when = parsedate_to_datetime(value)
    except (TypeError, ValueError):
        return None
    return max(0.0, (when - datetime.now(timezone.utc)).total_seconds())

def polite_get(session, url, max_attempts=5, base=1.0, cap=60.0):
    for attempt in range(max_attempts):
        try:
            response = session.get(url, timeout=20)
        except (requests.ConnectionError, requests.Timeout):
            response = None

        if response is not None and response.status_code not in RETRY_STATUS:
            return response  # responses such as 200, 404 and 403 are not retried

        wait = None
        if response is not None:
            wait = retry_after_seconds(response.headers.get("Retry-After"))
        if wait is None:
            wait = min(cap, base * 2**attempt) * random.uniform(0.5, 1.0)
        time.sleep(min(wait, cap))

    raise RuntimeError(f"{url}: no response after {max_attempts} attempts")
```

به کار بردن این تابع روی فهرستی از صفحه‌ها با تأخیر میان درخواست‌ها کافی است:

```python
session = requests.Session()
session.headers.update({
    "User-Agent": "ExamplePriceBot/1.0 (+https://example.com/about-our-bot)",
    "Accept-Language": "fa-IR,fa;q=0.9",
})

for url in urls:
    response = polite_get(session, url)
    if response.status_code == 403:
        print("Access denied, stop and investigate:", url)
        break
    process(response.text)
    time.sleep(random.uniform(2, 5))
```

شیوه تنظیم همروندی و آنچه واقعاً سرعت را محدود می‌کند در [همروندی و موازی‌سازی](/fa/blog/concurrency-vs-parallelism) آمده است.

## هدرها و هویت کلاینت سازگار

هدرهای یک درخواست HTTP می‌گویند کلاینت کیست و چه می‌پذیرد. هدرهای پیش‌فرض کتابخانه‌ها با هدرهای مرورگر بسیار متفاوت‌اند. Python Requests به‌طور پیش‌فرض `User-Agent` مانند `python-requests/2.x` می‌فرستد و بسیاری از سایت‌ها این مقدار را مستقیم رد می‌کنند.

اینجا دو رویکرد وجود دارد که به هدف‌های متفاوتی خدمت می‌کنند:

**معرفی خود.** خزنده‌های مشروع نام ربات و آدرسی حاوی اطلاعات درباره آن را در `User-Agent` می‌گذارند: `ExamplePriceBot/1.0 (+https://example.com/about-our-bot)`. مدیر سایت وقتی ترافیک را می‌بیند، می‌داند چه کسی آن را می‌فرستد و چگونه با شما تماس بگیرد؛ در صورت مشکل به‌جای مسدود کردن می‌تواند با شما ارتباط بگیرد. همچنین می‌تواند قواعد robots.txt ویژه همان نام بنویسد.

**سازگاری.** هر هویتی به کار ببرید، باید در سراسر درخواست سازگار باشد. نمونه‌های ناسازگاری:

- `User-Agent` که در هر درخواست تصادفی عوض می‌شود اما با همان کوکی‌ها و همان IP.
- `User-Agent` که ادعا می‌کند کروم است، اما هیچ‌کدام از هدرهای `Accept`، `Accept-Language` و `Sec-CH-UA` را که کروم در هر درخواست می‌فرستد ندارد.
- بازدید از سایتی در ترکیه با `Accept-Language: en-US` و IP خروجی در آمریکا در حالی که انتظار قیمت‌های لیر ترکیه را دارید.

اینکه چه نشانه‌هایی جز هدرها مرورگرها را شناسایی می‌کنند در [اثر انگشت مرورگر](/fa/blog/browser-fingerprinting) آمده است. جعل این نشانه‌ها برای دور زدن محافظت ربات پیشنهاد این نوشته نیست؛ هدف این است که کلاینت شما به‌طور سازگار بگوید چیست.

## گوناگونی IP: چرخش کی لازم است؟

ترافیک فشرده از یک آدرس IP ساده‌ترین واحدی است که محدودیت نرخ بر آن اعمال می‌شود. به همین دلیل «مسدود شدم، IP را عوض کنم» واکنشی بسیار رایج است. اما چرخش دو هدف مشروع و یک کاربرد نادرست دارد.

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

**هدف مشروع 2: دیدن محتوا بر اساس موقعیت.** قیمت، موجودی و نتایج جست‌وجو با کشور و شهر بازدیدکننده تغییر می‌کنند. خروج از موقعیت‌های مختلف تنها راه جمع‌آوری نمای واقعی هر بازار است.

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

چرخش را می‌توان با [پروکسی چرخشی](https://proxynet.io/fa/rotating-proxy) راه انداخت که از یک آدرس در هر اتصال IP خروجی متفاوتی می‌دهد. برای کارهایی که به آدرس اتصال‌های خانگی واقعی نیاز دارند، [پروکسی مسکونی](https://proxynet.io/fa/residential-proxy) ترجیح داده می‌شود. ساختار چرخشی در پایتون را در [چرخش پروکسی در پایتون](/fa/blog/how-to-rotate-proxies-in-python) آورده‌ایم.

## IP ثابت در جایی که نشست لازم است

عوض کردن IP در هر درخواست برای همه کارها درست نیست. در این کارها آدرس IP باید مدتی ثابت بماند:

- **صفحه‌های نیازمند ورود.** اگر گزارش‌ها را از پنل حساب خودتان می‌گیرید، تغییر IP در میانه نشست بررسی‌های امنیتی را فعال می‌کند و نشست بسته می‌شود.
- **جریان‌های چندمرحله‌ای.** جریان‌هایی که وضعیت را در سمت سرور نگه می‌دارند، مانند افزودن به سبد، انتخاب فیلتر یا صفحه‌بندی.
- **بازدیدهای وابسته به کوکی.** درخواست‌هایی با کوکی یکسان که از کشورهای متفاوت می‌آیند، تصویر ناسازگاری از بازدیدکننده می‌سازند.

برای این کارها [پروکسی با نشست ثابت](https://proxynet.io/fa/sticky-proxy) همان IP خروجی را برای مدتی مشخص حفظ می‌کند. قاعده کلی: یک نشست برابر یک IP؛ IP با پایان نشست می‌تواند عوض شود.

## robots.txt و شرایط سایت

پیش از جمع‌آوری داده از یک سایت، دو سند باید بررسی شود.

**robots.txt** فایلی است که سایت در آن می‌گوید نمی‌خواهد ربات‌ها کدام مسیرها را بخزند و قالب آن در [⁦RFC 9309⁩](https://www.rfc-editor.org/rfc/rfc9309) استاندارد شده است. نخزیدن مسیرهایی که با `Disallow` بسته شده‌اند یعنی احترام به ترجیحی که سایت صراحتاً اعلام کرده است. شیوه خواندن فایل و بررسی آن با پایتون را در [فایل robots.txt چیست و چگونه آن را بخوانیم؟](/fa/blog/robots-txt) توضیح داده‌ایم.

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

صفحه‌های دارای داده شخصی دقت بیشتری می‌طلبند؛ تعهدهای KVKK در ترکیه و GDPR در اروپا صرف‌نظر از شیوه جمع‌آوری داده اعمال می‌شوند. چارچوب قانونی را در [آیا وب اسکرپینگ قانونی است؟](/fa/blog/is-data-web-scraping-legal) بررسی کرده‌ایم.

برخی سایت‌ها پیوندهای پنهانی هم می‌گذارند که بازدیدکنندگان نمی‌بینند اما ربات‌ها در آن گیر می‌افتند. خزنده‌ای که پیوندهای قابل‌دیدن را دنبال می‌کند و دامنه را محدود نگه می‌دارد، به‌طور طبیعی از این تله‌ها دور می‌ماند؛ سازوکار آن را در [تله‌های هانی‌پات](/fa/blog/honeypot-traps) توضیح داده‌ایم.

## وقتی CAPTCHA ظاهر شد چه کنیم؟

صفحه بررسی جلوی اسکرپر یعنی سایت ترافیک شما را مشکوک می‌بیند. در این نقطه سرویس‌های حل CAPTCHA یا افزونه‌های گریز از شناسایی پیشنهاد نمی‌شوند؛ آن‌ها یعنی تلاش برای دور زدن کنترل آشکار سایت و معمولاً ریشه مشکل را پنهان می‌کنند. به‌جای آن به این ترتیب پیش بروید:

1. **اسکرپر را متوقف کنید.** ادامه فرستادن درخواست به صفحه بررسی شهرت IP و نشست را بیشتر پایین می‌آورد.
2. **سرعت را بسنجید.** ببینید در دقیقه گذشته چند درخواست به همان سایت فرستاده‌اید.
3. **هدرها را با مرورگر واقعی مقایسه کنید.** هدری ناقص یا متناقض هست؟
4. **دامنه را بازبینی کنید.** آیا مسیرهای بسته robots.txt یا صفحه‌هایی که لازم ندارید را می‌خزید؟
5. **جایگزین بجویید.** API رسمی، گزینه خروجی گرفتن داده یا تماس مستقیم با صاحب سایت.
6. **فقط پس از آن** با سرعت کمتر و هویت کلاینت سازگار دوباره تلاش کنید.

## وقتی مسدود شدید: فهرست تشخیص

- می‌دانید مسدودسازی کی آغاز شد و سرعت درخواست در آن لحظه چه بود؟
- کد پاسخ چیست: `403`، `429`، `503` یا `200` همراه صفحه بررسی؟
- هدر `Retry-After` آمد و به آن احترام گذاشتید؟
- همان آدرس با همان IP در مرورگر واقعی باز می‌شود؟
- هدرهای شما سازگارند یا `User-Agent` همان پیش‌فرض کتابخانه است؟
- مسیرهایی که می‌خزید در robots.txt بسته شده‌اند؟
- شرایط سایت درباره دسترسی خودکار چه می‌گوید؟
- در جریانی که نشست لازم دارد IP عوض می‌شود؟
- محتوای خالی از صفحه‌ای می‌آید که با جاوااسکریپت بارگذاری می‌شود؟
- API رسمی‌ای هست که همان داده را بدهد؟

## کاربردها

- **پایش قیمت:** چند بار در روز، آدرس‌های محصول برگرفته از نقشه سایت و فقط صفحه‌های تغییرکرده با درخواست شرطی. ساختار آن در صفحه [راه‌حل پایش قیمت](/fa/price-monitoring) آمده است.
- **پژوهش بازار و جمع‌آوری کاتالوگ:** صفحه‌های عمومی از سایت‌های متفاوت فراوان، همروندی کم برای هر سایت و چرخش برای پخش بار. ساختار کلی در صفحه [راه‌حل استخراج داده](/fa/data-scraping) آمده است.
- **خزش گسترده:** خزنده‌ای که پیوندها را دنبال می‌کند، به robots.txt احترام می‌گذارد و برای هر دامنه صف نگه می‌دارد. بخش مقیاس‌پذیری در صفحه [راه‌حل وب کراولر](/fa/web-crawler) آمده است.
- **ردیابی نتایج جست‌وجو بر اساس موقعیت:** نخست API رسمی و سپس نقاط خروج در سطح شهر. جزئیات در [خودکارسازی ردیابی رتبه در سئو](/fa/blog/serp-rank-tracking) آمده است.
- **انتخابگرهای پایدار:** حتی بدون مسدود شدن، وقتی ساختار صفحه عوض شود داده خالی برمی‌گردد. شیوه نوشتن انتخابگرهای نشکن را در [انتخابگر CSS یا XPath](/fa/blog/css-selector-vs-xpath) توضیح داده‌ایم.

## اشتباهات رایج

- **آغاز صدها درخواست یک‌جا با `Promise.all` یا `asyncio.gather`.** سرعت کل زیاد به نظر می‌رسد، اما بار روی هر سایت پذیرفتنی نیست.
- **تلاش فوری دوباره پس از `429`.** تلاش دوباره بدون backoff محدودیت نرخ را طولانی‌تر می‌کند.
- **به کار بردن `User-Agent` پیش‌فرض کتابخانه.** بسیاری از سایت‌ها این مقدار را مستقیم مسدود می‌کنند.
- **ساختن `User-Agent` تصادفی در هر درخواست.** هویتی متغیر با همان IP و کوکی‌ها نشانه ناسازگاری است.
- **تغییر IP در هر درخواست در کاری که نشست لازم دارد.** نشست بسته می‌شود و به صفحه ورود هدایت می‌شوید.
- **یکی دانستن کد وضعیت موفق با داده موفق.** صفحه بررسی که با `200` برگردد، چون انتخابگرها خالی برمی‌گردند، بی‌صدا داده خراب می‌سازد. وجود یک عنصر مورد انتظار در محتوای پاسخ را بررسی کنید.
- **نخواندن robots.txt.** خزیدن بدون دانستن ترجیح سایت از هر دو جنبه اخلاقی و قانونی آغاز ضعیفی است.

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

| وضعیت شما | پیشنهاد |
|---|---|
| API رسمی وجود دارد | نخست API |
| تعداد کمی صفحه از یک سایت | یک IP، سرعت کم، هدرهای سازگار |
| صفحه‌های عمومی از سایت‌های فراوان | همروندی کم برای هر سایت همراه پروکسی چرخشی |
| محتوا در کشور یا شهری دیگر | پروکسی مسکونی با انتخاب موقعیت |
| حساب واردشده خودتان | IP از نوع sticky یا ثابت، همان آدرس در طول نشست |
| `429` می‌گیرید | به اندازه `Retry-After` صبر کنید، همروندی را کم کنید |
| صفحه بررسی ظاهر شد | متوقف شوید، فهرست تشخیص را اجرا کنید، جایگزین بجویید |
| صفحه خالی برمی‌گردد | نخست بررسی کنید پویا بارگذاری می‌شود یا نه |
| مسیر در robots.txt بسته است | نخزید |

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

### آیا استفاده از پروکسی مسدودسازی را کاملاً از میان برمی‌دارد؟

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

### چند درخواست در ثانیه امن است؟

مقدار امن یگانه‌ای برای همه سایت‌ها وجود ندارد؛ به زیرساخت سایت، سنگینی صفحه و ساعت روز بستگی دارد. اگر robots.txt مقدار `Crawl-delay` تعیین کرده، به آن احترام بگذارید. اگر نه، با سرعت کم آغاز کنید، با زیر نظر گرفتن `429`ها و زمان پاسخ آرام بیفزایید و به محض دیدن کند شدن سرور عقب بکشید.

### User-Agent مقدار مرورگر باشد یا نام ربات؟

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

### آیا مرورگر headless خطر مسدود شدن را کم می‌کند؟

دیدن داده در صفحه‌هایی را که با جاوااسکریپت بارگذاری می‌شوند ممکن می‌کند، اما به‌خودی‌خود خطر مسدود شدن را کم نمی‌کند. برعکس، هر صفحه ده‌ها درخواست اضافه (تصویر، اسکریپت، برگه سبک) می‌سازد و بار بیشتری بر سایت می‌گذارد. یافتن درخواست API که صفحه در پس‌زمینه می‌فرستد معمولاً کاراتر است.

### IP من مسدود شد. چقدر طول می‌کشد؟

از سایتی به سایت دیگر متفاوت است: از محدودیت نرخ چنددقیقه‌ای تا فهرست سیاه چندروزه. اگر هدر `Retry-After` باشد، مدت را می‌گوید. اگر نه، مدتی صبر کنید و برای بررسی یک درخواست با سرعت بسیار کم بفرستید؛ پیش از برداشته شدن مسدودسازی با همان سرعت ادامه ندهید.

### برای کاری کوچک و یک‌باره هم این همه احتیاط لازم است؟

برای کار یک‌باره چند ده صفحه‌ای، گذاشتن چند ثانیه میان درخواست‌ها، به کار بردن `User-Agent` معنادار و بررسی robots.txt معمولاً کافی است. احتیاط‌های دیگر وقتی اهمیت می‌یابند که کار منظم و در مقیاس بزرگ شود.

## خلاصه

بیشتر اسکرپرها نه به دلیل ناتوانی در پنهان شدن، بلکه به دلیل فشار آوردن به سایت و ناسازگار به نظر رسیدن مسدود می‌شوند. سرعت درخواست را برای هر سایت محدود کنید، به پاسخ‌های `429` و `Retry-After` احترام بگذارید، صفحه‌های تغییرنیافته را دوباره دانلود نکنید، هویت کلاینت سازگاری که شما را معرفی کند به کار ببرید و robots.txt و شرایط سایت را بخوانید. چرخش IP برای پخش بار و دیدن محتوای وابسته به موقعیت است و IP از نوع sticky برای کارهایی که نشست لازم دارند؛ هیچ‌کدام ابزاری برای دور زدن مسدودسازی آشکار نیست. انواع پروکسی متناسب با کار جمع‌آوری داده را در [خدمات پروکسی ما](/fa/proxy) می‌یابید.