كيفية إعداد مهلة وإعادة المحاولة للوكيل: حماية من فقدان البيانات أثناء عملية التصفح

عندما تعمل مع البروكسي لزحف الأسواق، أو أتمتة وسائل التواصل الاجتماعي، أو جمع البيانات، فإن المشكلة الأكثر شيوعًا هي الطلبات المعلقة وفقدان البيانات. قد لا يستجيب خادم البروكسي في الوقت المناسب، أو قد ينقطع الاتصال، أو قد يتجمد السكربت الخاص بك لعدة دقائق. ونتيجة لذلك، تفقد الوقت والبيانات والمال.

في هذا الدليل، سأوضح لك كيفية إعداد timeout (مهلات) و retry logic (منطق المحاولات المتكررة) للعمل مع البروكسي بشكل صحيح. ستتعلم القيم المناسبة للمهلات المستخدمة لمهام مختلفة، وكيفية إعادة الاتصال تلقائيًا عند حدوث أخطاء، وكيفية عدم فقدان أي طلب. يناسب هذا المقال كل من يكتب الكود بلغة بايثون وأيضًا من يستخدم أدوات الزحف الجاهزة.

لماذا يعد timeout أمرًا حيويًا عند العمل مع البروكسي

تخيل الوضع: لقد قمت بتشغيل زاحف الأسعار من Wildberries لـ 10,000 منتج. يعمل السكربت عبر البروكسي لتجنب الحظر. كل شيء يسير على ما يرام، ولكن في الطلب رقم 523، يتوقف خادم البروكسي عن الاستجابة - ربما يكون مثقلاً أو غير متاح مؤقتًا. بدون إعداد timeout، سيبقى السكربت في انتظار الرد إلى أجل غير مسمى (أو حتى ينتهي timeout النظامي الذي يتراوح بين 2-5 دقائق). في النهاية، يتوقف الزحف، وتفقد الوقت، وعندما تلاحظ المشكلة، قد تمر عدة ساعات.

Timeout (المهلة) هو الحد الأقصى لوقت الانتظار للحصول على رد من الخادم. إذا لم يستجب الخادم في هذا الوقت، يتم قطع الطلب، ويمكنك إما إعادة المحاولة عبر بروكسي آخر، أو تسجيل الخطأ في السجل. هذا مهم بشكل خاص عند العمل مع البروكسي، لأن:

• يمكن أن تكون خوادم البروكسي غير مستقرة - خاصة العامة أو الرخيصة. حتى البروكسي السكنية عالية الجودة أحيانًا تفقد الاتصال بسبب انقطاع الإنترنت عن المستخدم الحقيقي.
• يمكن أن يقوم الموقع المستهدف بحظر IP - إذا تم حظر البروكسي، فلن يستجيب على الإطلاق أو سيستجيب لفترة طويلة جدًا (مقدمًا CAPTCHA أو إعادة توجيه).
• تأخيرات الشبكة غير متوقعة - خاصة عند استخدام البروكسي من دول أخرى. قد يمر الطلب عبر عدة عقد وسيطة.
• تتطلب العمليات الكبيرة الاستقرار - إذا كنت تقوم بزحف 100,000 صفحة أو تدير 50 حسابًا على Instagram، حتى 1% من الطلبات المعلقة = 1000 عملية مفقودة.

بدون إعداد المهلات بشكل صحيح، سيقضي السكربت الخاص بك الوقت في انتظار البروكسيات غير المتاحة بدلاً من التبديل إلى البروكسيات العاملة. هذا يؤثر بشكل مباشر على سرعة العمل واستقرار النتائج.

أنواع المهلات: connect و read و total timeout

هناك ثلاثة أنواع رئيسية من المهلات التي يجب فهمها وضبطها بشكل منفصل. يقوم العديد من المطورين المبتدئين ومستخدمي الزواحف بضبط مهلة عامة واحدة فقط، مما يؤدي إلى مشاكل.

1. Connect timeout (مهلة الاتصال)

هذه هي المدة المخصصة لإنشاء اتصال مع خادم البروكسي. إذا لم يتم إنشاء الاتصال في هذا الوقت - يتم قطع الطلب. تتولى مهلة الاتصال مسؤولية المصافحة الأولية (TCP handshake) بين عميلك والبروكسي.

عندما يحدث: خادم البروكسي غير متاح، مثقل، أو تم حظر IP بواسطة جدار الحماية.

القيم الموصى بها:

• للبروكسي السريعة من مراكز البيانات: 3-5 ثوانٍ
• للبروكسي السكنية: 5-10 ثوانٍ
• للبروكسي المحمولة: 10-15 ثوانٍ (الإنترنت المحمول أبطأ)

2. Read timeout (مهلة القراءة)

هذه هي مدة الانتظار للحصول على رد من الخادم المستهدف بعد أن تم إنشاء الاتصال مع البروكسي. إذا لم يبدأ الخادم في إرسال البيانات خلال هذا الوقت - يتم قطع الطلب. تحمي مهلة القراءة من الحالات التي يقبل فيها الخادم الطلب، ولكنه "يتجمد" ولا يقدم ردًا.

عندما يحدث: يقوم الموقع المستهدف بمعالجة الطلب ببطء، مثقل، أو يتعمد إبطاء الطلبات المشبوهة.

القيم الموصى بها:

• لزحف الصفحات البسيطة (HTML): 10-15 ثوانٍ
• لزحف الصفحات ذات التقديم باستخدام JavaScript: 30-60 ثوانٍ
• لطلبات API: 5-10 ثوانٍ
• لتنزيل الملفات الكبيرة: 120+ ثوانٍ

3. Total timeout (المهلة الإجمالية)

هذه هي الحد الأقصى للوقت المخصص لتنفيذ الطلب بالكامل من البداية إلى النهاية، بما في ذلك الاتصال، إرسال الطلب، استلام وقراءة الرد. تعتبر المهلة الإجمالية "مفتاح الطوارئ" الذي يضمن عدم تنفيذ أي طلب لفترة أطول من الوقت المحدد.

عند الاستخدام: عندما يكون من المهم أن يتوافق كل طلب مع إطار زمني صارم (على سبيل المثال، عند الزحف في الوقت الحقيقي للتحكيم).

الصيغة: المهلة الإجمالية = مهلة الاتصال + مهلة القراءة + احتياطي 20-30%

القيم المثلى للمهلات لمهام مختلفة

تعتمد القيم الصحيحة للمهلات على مهمتك، نوع البروكسي، والموقع المستهدف. ستؤدي المهلات القصيرة جدًا إلى عدد كبير من الأخطاء الكاذبة (البروكسي يعمل، لكنك تتجاهله). بينما ستؤدي المهلات الطويلة جدًا إلى فقدان الوقت في انتظار البروكسيات الميتة.

Retry logic: كيفية إعداد المحاولات المتكررة بشكل صحيح

يحل timeout مشكلة الطلبات المعلقة، ولكنه لا يحل مشكلة فقدان البيانات. إذا لم يستجب البروكسي - ستحصل ببساطة على خطأ وستفقد هذا الطلب. لذلك، فإن retry logic (منطق المحاولات المتكررة) أمر حيوي.

Retry logic هي إعادة الطلب تلقائيًا عند حدوث خطأ. المبادئ الأساسية لإعدادها بشكل صحيح:

1. حدد الأخطاء التي تتطلب إعادة المحاولة

ليس كل الأخطاء تحتاج إلى إعادة المحاولة. على سبيل المثال:

• يجب إعادة المحاولة: Timeout، Connection refused، Proxy error، 502/503/504 (أخطاء مؤقتة في الخادم)، Rate limiting (429)
• لا يجب إعادة المحاولة: 404 (الصفحة غير موجودة)، 403 (الوصول ممنوع إلى الأبد)، 401 (تفويض غير صحيح)، أخطاء التحقق من البيانات

2. قم بضبط عدد المحاولات

يعتمد العدد الأمثل للمحاولات على أهمية البيانات:

• للمهام غير الحرجة (الزحف من أجل التحليل): 2-3 محاولات
• للمهام الهامة (مراقبة أسعار المنافسين): 3-5 محاولات
• للمهام الحرجة (العمل مع حسابات الإعلانات): 5-10 محاولات

3. استخدم exponential backoff (التأخير الأسي)

لا تعيد الطلب على الفور - قد يؤدي ذلك إلى تفاقم المشكلة (على سبيل المثال، إذا كان الخادم مثقلاً). استخدم تأخيرًا متزايدًا بين المحاولات:

• المحاولة الأولى: على الفور
• المحاولة الثانية: بعد 1-2 ثانية
• المحاولة الثالثة: بعد 4-5 ثوانٍ
• المحاولة الرابعة: بعد 10-15 ثانية

الصيغة: التأخير = التأخير الأساسي * (2 ^ رقم المحاولة). على سبيل المثال: 1 ثانية، 2 ثانية، 4 ثوانٍ، 8 ثوانٍ، 16 ثانية.

4. تدوير البروكسي عند المحاولات المتكررة

القاعدة الأكثر أهمية: عند إعادة المحاولة، استخدم بروكسي آخر من مجموعة البروكسي الخاصة بك. إذا لم يتمكن بروكسي واحد من تنفيذ الطلب، فإن احتمال نجاحه عند إعادة المحاولة - منخفض. بينما من المرجح أن يتعامل بروكسي آخر مع الطلب بنجاح.

هذا مهم بشكل خاص عند العمل مع البروكسي السكنية، حيث لديك مجموعة من مئات أو آلاف عناوين IP. عند كل إعادة محاولة، اختر عنوان IP عشوائي جديد من المجموعة.

أمثلة على إعداد timeout و retry بلغة بايثون

دعنا نستعرض أمثلة عملية لتنفيذ timeout و retry logic باستخدام مكتبات شائعة في بايثون.

المثال 1: الإعداد الأساسي باستخدام requests

مكتبة requests هي الأكثر شعبية لطلبات HTTP في بايثون. إليك كيفية إعداد timeout وإعادة المحاولة البسيطة:

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

# إعداد retry logic
retry_strategy = Retry(
    total=5,  # الحد الأقصى 5 محاولات
    backoff_factor=1,  # التأخير: 1، 2، 4، 8، 16 ثانية
    status_forcelist=[429, 500, 502, 503, 504],  # رموز الأخطاء لإعادة المحاولة
    allowed_methods=["HEAD", "GET", "POST", "PUT", "DELETE"]
)

adapter = HTTPAdapter(max_retries=retry_strategy)
session = requests.Session()
session.mount("http://", adapter)
session.mount("https://", adapter)

# إعداد البروكسي
proxies = {
    'http': 'http://username:password@proxy.example.com:8080',
    'https': 'http://username:password@proxy.example.com:8080'
}

# تنفيذ الطلب مع timeout
try:
    response = session.get(
        'https://www.wildberries.ru/catalog/electronics',
        proxies=proxies,
        timeout=(5, 15)  # مهلة الاتصال 5 ثوانٍ، مهلة القراءة 15 ثانية
    )
    print(f"نجاح! الحالة: {response.status_code}")
    print(f"حجم الرد: {len(response.content)} بايت")
except requests.exceptions.Timeout:
    print("خطأ: تجاوزت المهلة")
except requests.exceptions.ProxyError:
    print("خطأ: مشكلة في البروكسي")
except requests.exceptions.RequestException as e:
    print(f"خطأ في الطلب: {e}")

في هذا المثال، قمنا بإعداد إعادة المحاولة تلقائيًا على مستوى الجلسة. عند حدوث أخطاء 429، 500، 502، 503، 504، ستقوم المكتبة تلقائيًا بإعادة الطلب حتى 5 مرات مع تأخير أسي.

المثال 2: تدوير البروكسي عند إعادة المحاولة

مثال أكثر تقدمًا مع تدوير البروكسي من المجموعة عند كل محاولة:

import requests
import random
import time

# مجموعة البروكسي (استبدل بالبروكسي الحقيقي الخاص بك)
PROXY_POOL = [
    'http://user:pass@proxy1.example.com:8080',
    'http://user:pass@proxy2.example.com:8080',
    'http://user:pass@proxy3.example.com:8080',
    'http://user:pass@proxy4.example.com:8080',
]

def make_request_with_retry(url, max_retries=5, base_delay=1):
    """
    ينفذ الطلب مع إعادة المحاولة وتدوير البروكسي
    """
    for attempt in range(max_retries):
        # اختيار بروكسي عشوائي من المجموعة
        proxy = random.choice(PROXY_POOL)
        proxies = {'http': proxy, 'https': proxy}
        
        try:
            response = requests.get(
                url,
                proxies=proxies,
                timeout=(5, 15),
                headers={'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)'}
            )
            
            # التحقق من رمز الحالة
            if response.status_code == 200:
                return response
            elif response.status_code in [429, 500, 502, 503, 504]:
                # خطأ مؤقت - إعادة المحاولة
                print(f"المحاولة {attempt + 1}: الرمز {response.status_code}, إعادة المحاولة...")
            else:
                # خطأ دائم - التوقف
                print(f"خطأ {response.status_code}, التوقف عن المحاولات")
                return None
                
        except (requests.exceptions.Timeout, 
                requests.exceptions.ProxyError,
                requests.exceptions.ConnectionError) as e:
            print(f"المحاولة {attempt + 1}: الخطأ {type(e).__name__}, إعادة المحاولة...")
        
        # إذا لم تكن هذه هي المحاولة الأخيرة - انتظر بتأخير أسي
        if attempt < max_retries - 1:
            delay = base_delay * (2 ** attempt)
            print(f"انتظار {delay} ثوانٍ قبل المحاولة التالية...")
            time.sleep(delay)
    
    print("تم استنفاد جميع المحاولات")
    return None

# الاستخدام
result = make_request_with_retry('https://www.ozon.ru/category/smartfony-15502/')
if result:
    print(f"نجاح! تم الحصول على {len(result.content)} بايت من البيانات")
else:
    print("فشل في تنفيذ الطلب")

يقوم هذا الكود باختيار بروكسي جديد عشوائي من المجموعة في كل محاولة، مما يزيد بشكل كبير من احتمال نجاح الطلب.

المثال 3: استخدام مكتبة tenacity

للحصول على إدارة أكثر مرونة لـ retry logic، يمكنك استخدام مكتبة متخصصة مثل tenacity:

from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
import requests

@retry(
    stop=stop_after_attempt(5),  # الحد الأقصى 5 محاولات
    wait=wait_exponential(multiplier=1, min=1, max=30),  # تأخير أسي من 1-30 ثانية
    retry=retry_if_exception_type((requests.exceptions.Timeout, 
                                   requests.exceptions.ProxyError,
                                   requests.exceptions.ConnectionError))
)
def fetch_with_proxy(url, proxy):
    """
    وظيفة مع إعادة المحاولة تلقائيًا عبر الديكور
    """
    proxies = {'http': proxy, 'https': proxy}
    response = requests.get(url, proxies=proxies, timeout=(5, 15))
    response.raise_for_status()  # ستثير استثناء عند حدوث خطأ HTTP
    return response

# الاستخدام
try:
    result = fetch_with_proxy(
        'https://www.avito.ru/rossiya/telefony',
        'http://user:pass@proxy.example.com:8080'
    )
    print(f"نجاح! الحالة: {result.status_code}")
except Exception as e:
    print(f"فشل في تنفيذ الطلب بعد جميع المحاولات: {e}")

توفر مكتبة tenacity إمكانيات مرنة جدًا لضبط retry عبر الديكورات. التثبيت: pip install tenacity

حلول جاهزة للزحف بدون كود

إذا لم تكن مبرمجًا أو كنت ترغب في توفير الوقت في التطوير، فهناك أدوات زحف جاهزة تدعم بشكل مدمج timeout و retry logic. لا تحتاج إلى كتابة كود - يكفي إعداد المعلمات في واجهة المستخدم الرسومية.

Octoparse

زاحف بصري شهير لنظامي Windows و Mac. إعداد timeout و retry:

• افتح إعدادات المهمة → خيارات متقدمة
• Page Load Timeout: اضبط على 20-30 ثانية
• Ajax Timeout: 10-15 ثانية للمحتوى الديناميكي
• Retry Times: 3-5 محاولات عند حدوث خطأ
• في إعدادات البروكسي، يمكنك تحميل قائمة وتمكين تدوير تلقائي

ParseHub

زاحف سحابي مع خطة مجانية. الإعداد:

• الإعدادات → متقدمة → تأخير تحميل الصفحة: 5-10 ثوانٍ
• مهلة الطلب: 30 ثانية
• إعادة المحاولة للطلبات الفاشلة: تمكين، 3 محاولات
• يدعم البروكسي عبر إعدادات المشروع

Apify

منصة لأتمتة مهام الويب مع ممثلين جاهزين (سكريبتات) لزحف المواقع الشهيرة. العديد من الممثلين لزحف الأسواق (Wildberries، Ozon) لديهم بالفعل إعداد مثالي مدمج للtimeout و retry. كل ما تحتاجه هو:

• اختر ممثلًا جاهزًا للموقع المطلوب
• حدد البروكسي (يدعم التكامل مع مزودي البروكسي)
• قم بتشغيل المهمة - كل شيء آخر تم إعداده تلقائيًا

متصفحات مضادة للكشف للأتمتة

إذا كنت تعمل مع وسائل التواصل الاجتماعي أو منصات الإعلانات عبر Dolphin Anty أو AdsPower أو Multilogin، يتم إعداد timeout في ملف تعريف المتصفح:

• Dolphin Anty: إعدادات الملف الشخصي → البروكسي → المهلة: 10-15 ثانية
• AdsPower: إعدادات البروكسي → مهلة الاتصال: 10 ثوانٍ، مهلة القراءة: 20 ثانية
• Multilogin: ملف تعريف المتصفح → الشبكة → مهلة البروكسي: 15 ثانية

عند الأتمتة عبر هذه المتصفحات (مثل سكريبتات Selenium)، يتم وراثة مهلة البروكسي من إعدادات الملف الشخصي، ولكن يمكنك أيضًا تعيين مهلات إضافية على مستوى السكربت.

الأخطاء الشائعة عند إعداد المهلات

حتى المطورين ذوي الخبرة والمتخصصين في الزحف يرتكبون أخطاء نموذجية عند العمل مع المهلات و retry. إليك أكثر الأخطاء شيوعًا:

الخطأ 1: عدم وجود مهلة على الإطلاق

العديد من المكتبات لا تحدد timeout بشكل افتراضي أو تحدد قيمة كبيرة جدًا (عدة دقائق). إذا لم تحدد timeout بوضوح - قد يتجمد السكربت الخاص بك لفترة طويلة.

الحل: دائمًا حدد timeout بوضوح في كل طلب. من الأفضل الحصول على خطأ بعد 15 ثانية من الانتظار لمدة 5 دقائق.

الخطأ 2: استخدام نفس البروكسي في جميع المحاولات المتكررة

إذا لم يستجب البروكسي من المرة الأولى، فإن احتمال النجاح عند إعادة المحاولة عبر نفس البروكسي منخفض جدًا. كثير من الناس ينسون تدوير البروكسيات بين المحاولات.

الحل: استخدم بروكسي جديد من المجموعة في كل إعادة محاولة. هذا أمر حيوي لتحقيق معدل نجاح مرتفع.

الخطأ 3: مهلات قصيرة جدًا للبروكسيات البطيئة

يمكن أن تكون البروكسيات المحمولة وبعض البروكسيات السكنية أبطأ من مراكز البيانات. إذا قمت بتعيين timeout 5 ثوانٍ لبروكسي محمول - ستحصل على العديد من الأخطاء الكاذبة على عناوين IP العاملة.

الحل: ضع في اعتبارك نوع البروكسي. استخدم timeout لا يقل عن 10-15 ثانية للبروكسيات المحمولة.

الخطأ 4: إعادة المحاولات بلا حدود

يقوم بعض الأشخاص بتنفيذ retry في حلقة while True بدون تحديد عدد المحاولات. إذا كانت المشكلة من جانب الموقع المستهدف (على سبيل المثال، إذا كان الموقع معطلًا تمامًا) - سيستمر السكربت في المحاولة بلا حدود.

الحل: دائمًا حدد عدد المحاولات (3-10 محاولات كحد أقصى) وسجل الطلبات الفاشلة للتحليل لاحقًا.

الخطأ 5: تجاهل نوع الخطأ

ليس كل الأخطاء تحتاج إلى إعادة المحاولة. على سبيل المثال، إذا حصلت على 404 (الصفحة غير موجودة) - فإن إعادة المحاولة غير مجدية، فليس هناك صفحة. بينما 503 (الخدمة غير متاحة مؤقتًا) - من المنطقي إعادة المحاولة بعد بضع ثوانٍ.

الحل: قم بتحليل نوع الخطأ وأعد المحاولة فقط في حالات المشاكل المؤقتة (timeout، خطأ الاتصال، 429، 500، 502، 503، 504).

الخطأ 6: عدم وجود تسجيل

بدون سجلات، لن تفهم لماذا تفشل الطلبات: هل المشكلة في البروكسي، في المهلات، أم في الموقع المستهدف؟

الحل: قم بتسجيل كل خطأ مع الإشارة إلى: أي بروكسي تم استخدامه، ما كانت المهلة، عدد المحاولات التي تمت، وما هو الخطأ الذي حدث بالضبط. سيساعدك ذلك في تحسين الإعدادات.

الخاتمة

الإعداد الصحيح لـ timeout و retry logic ليس مجرد تفصيل تقني، بل هو عامل حيوي لاستقرار وفعالية العمل مع البروكسي. بدون المهلات، ستتجمد السكربتات الخاصة بك على البروكسيات الميتة، مما يؤدي إلى فقدان الوقت. بدون retry logic، ستفقد البيانات عند حدوث أخطاء مؤقتة. وبدون تدوير البروكسي عند المحاولات المتكررة - ستحصل على معدل نجاح منخفض حتى مع مجموعة IP عالية الجودة.

النقاط الرئيسية من هذا الدليل:

• دائمًا حدد timeout بوضوح: مهلة الاتصال 5-10 ثوانٍ، مهلة القراءة 10-30 ثانية حسب المهمة
• استخدم retry logic مع حد 3-5 محاولات وتأخير أسي
• قم بتدوير البروكسي عند كل محاولة إعادة - هذه هي المفتاح لمعدل نجاح مرتفع
• أعد المحاولة فقط للأخطاء المؤقتة (timeout، 429، 500، 502، 503، 504)، ولا تستهلك المحاولات على الأخطاء الدائمة (404، 403)
• قم بتسجيل جميع الأخطاء للتحليل وتحسين الإعدادات
• ضع في اعتبارك نوع البروكسي: البروكسيات المحمولة أبطأ من مراكز البيانات، وزد المهلات وفقًا لذلك

إذا كنت تعمل مع زحف الأسواق (Wildberries، Ozon، Avito)، أو أتمتة وسائل التواصل الاجتماعي، أو منصات الإعلانات، فإن استقرار البروكسي يؤثر بشكل مباشر على نتائجك. استخدم بروكسيات عالية الجودة ذات وقت تشغيل مرتفع وقم بإعداد timeout و retry بشكل صحيح - سيوفر لك ذلك ساعات من الوقت وآلاف الطلبات المفقودة.

للمهام التي تتطلب أقصى درجات الاستقرار وأقل عدد من أخطاء timeout، نوصي بتجربة بروكسيات مراكز البيانات - فهي توفر سرعة استجابة عالية واتصال مستقر، وهو أمر مهم بشكل خاص عند الزحف الجماعي والأتمتة.