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

إذا كنت تدير بنية استخراج بيانات تعتمد على بروكسي سكني، فمن المرجح أنك واجهت هذا السيناريو: ينجح تسجيل الدخول في الطلب الأول، لكن الطلب الثاني يُعيدك إلى صفحة المصادقة. السبب؟ البوابة الدوارة غيّرت عنوان IP الصادر بين الطلبين، فاعتبر الموقع المستهدف أنك مستخدم مختلف. هنا يكمن جوهر النقاش حول الجلسات الثابتة مقابل الدوارة للبروكسي — وهو قرار معماري يؤثر مباشرة على نسبة النجاح والتكلفة والتعقيد التشغيلي.

الجلسات الثابتة مقابل الدوارة للبروكسي: ما الفرق الجوهري؟

الفرق بسيط في المبدأ لكنه عميق في الأثر:

• البوابة الدوارة (Rotating): تُعيّن عنوان IP صادرًا جديدًا لكل طلب HTTP. هذا يعني أن 1,000 طلب يمكن أن يمر عبر 1,000 عنوان IP مختلف. مناسب للاستخراج عالي الحجم من البيانات العامة دون الحاجة إلى حالة جلسة.
• الجلسة الثابتة (Sticky): تُثبّت عنوان IP سكنيًا واحدًا لمدة TTL محددة — عادةً من دقيقة واحدة إلى 30 دقيقة — بحيث تمر جميع الطلبات ضمن تلك النافذة من نفس IP. ضروري لأي تدفق يعتمد على حالة مرتبطة بـ IP.

الجدول التالي يلخص المقاييس الحرجة:

المقياس	البوابة الدوارة	الجلسة الثابتة
تغيير IP	لكل طلب	مثبت لمدة TTL (1–30 دقيقة)
حالة الجلسة على الموقع	تُكسر فورًا	محفوظة طوال TTL
مناسب لـ	استخراج صفحات عامة، فحص الأسعار	تسجيل الدخول، عربات التسوق، تعدد الصفحات
خطر الحظر لكل IP	منخفض جدًا (توزيع الحمل)	متوسط (تركيز على IP واحد)
التعقيد التشغيلي	منخفض	متوسط (إدارة TTL وإعادة التدوير)

السياق التقني: لماذا تنكسر حالة الجلسة دون الثبات؟

العديد من المواقع تربط حالة الجلسة على الخادم بعنوان IP الخاص بالعميل. هذا ليس مجرد قرار أمني عشوائي — بل هو دفاع ضد اختطاف الجلسة و CSRF. على سبيل المثال، تنص توصيات Mozilla Developer Network حول منع CSRF على ربط رموز الجلسة بمعرّفات إضافية بما فيها عنوان IP كطبقة دفاع. عندما يتغير IP بين الطلبين، يعتبر الخادم أن الرمز قد سُرق ويُبطل الجلسة.

هذه الحالة المرتبطة بـ IP تظهر في أربعة سيناريوهات شائعة:

1. تسجيل الدخول والمصادقة: بعد POST إلى /login، يتوقع الخادم أن طلبات المتابعة تأتي من نفس IP الذي استلم ملف تعريف الارتباط.
2. رموز CSRF: تُولّد لكل جلسة وتُتحقق أحيانًا ضد IP المصدر. تغيير IP يُبطل الرمز.
3. عربات التسوق: محتوى العربة مرتبط بجلسة خادم، والتي بدورها مرتبطة بـ IP. تغيير IP = عربة فارغة.
4. ترقيم صفحات النتائج: بعض المواقع تُولّد رموز ترقيم صفحات مرتبطة بـ IP لمنع استخراج البيانات. تغيير IP بين الصفحة 1 و2 يُعيدك للبداية.

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

التحكم في الجلسة عبر اسم المستخدم

صممت ProxyHat آلية بسيطة لكنها قوية: كل التحكم في الجلسة يُمرّر عبر اسم المستخدم في عنوان URL البروكسي. لا حاجة لرؤوس HTTP إضافية أو إعدادات بوابة معقدة.

البوابة الدوارة (السلوك الافتراضي)

بدون أي رموز في اسم المستخدم، تعيّن البوابة IP جديدًا لكل طلب:

http://USERNAME:PASSWORD@gate.proxyhat.com:8080

كل طلب بهذا التكوين يخرج من IP مختلف.

الجلسة الثابتة مع استهداف جغرافي

أضف رمز -session-abc123 لتثبيت IP، و -country-US لتثبيت الدولة:

http://USERNAME-session-abc123-country-US:PASSWORD@gate.proxyhat.com:8080

هذا التكوين يثبّت عنوان IP سكنيًا في الولايات المتحدة لمدة تصل إلى 30 دقيقة، طالما استخدمت نفس قيمة abc123. تغيير قيمة الجلسة يُنشئ جلسة جديدة بـ IP جديد.

يمكنك أيضًا الاستهداف على مستوى المدينة:

http://USERNAME-session-abc123-country-DE-city-berlin:PASSWORD@gate.proxyhat.com:8080

مثال عملي 1: استخراج دوّار بـ Python

هذا السيناريو للاستخراج عالي الحجم من صفحات نتائج بحث عامة دون حالة جلسة. كل طلب يخرج من IP مختلف، مما يوزّع الحمل ويقلل خطر الحظر:

import requests

PROXY = "http://USERNAME:PASSWORD@gate.proxyhat.com:8080"
proxies = {"http": PROXY, "https": PROXY}

keywords = ["laptop", "headphones", "keyboard", "monitor", "webcam"]

for kw in keywords:
    url = f"https://www.example.com/search?q={kw}"
    resp = requests.get(url, proxies=proxies, timeout=30)
    print(f"{kw}: {resp.status_code} — {len(resp.text)} bytes")

لا حاجة لرمز جلسة هنا. كل طلب في الحلقة يخرج من IP مختلف تلقائيًا.

مثال عملي 2: جلسة ثابتة متعددة الخطوات بـ Node.js

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

const axios = require('axios');

const sessionId = 'order-flow-' + Date.now();
const proxyUrl = `http://USERNAME-session-${sessionId}-country-US:PASSWORD@gate.proxyhat.com:8080`;

const client = axios.create({
  proxy: false,
  httpsAgent: new (require('https-proxy-agent').HttpsProxyAgent)(proxyUrl),
  timeout: 30000,
});

async function runFlow() {
  // الخطوة 1: تسجيل الدخول
  const login = await client.post('https://shop.example.com/api/login', {
    email: 'user@example.com',
    password: 'secret',
  });
  console.log('Login:', login.status);

  // الخطوة 2: تصفح منتج
  const product = await client.get('https://shop.example.com/api/products/12345');
  console.log('Product:', product.status);

  // الخطوة 3: إضافة إلى العربة
  const cart = await client.post('https://shop.example.com/api/cart/add', {
    productId: '12345',
    qty: 1,
  });
  console.log('Cart:', cart.status);

  // الخطوة 4: الدفع
  const checkout = await client.post('https://shop.example.com/api/checkout', {
    cartId: cart.data.id,
  });
  console.log('Checkout:', checkout.status);
}

runFlow().catch(console.error);

باستخدام نفس sessionId عبر جميع الطلبات الأربعة، يضمن ProxyHat خروجها جميعًا من نفس IP السكني، طالما الطلبات تتم ضمن نافذة TTL (حتى 30 دقيقة). لو استخدمت البوابة الدوارة هنا، لكسرت حالة الجلسة بعد الطلب الأول وفشل التدفق بأكمله.

الإرشادات التشغيلية: ضبط TTL وإعادة التدوير والتزامن

ضبط TTL للجلسة

القاعدة الأساسية: اجعل TTL أطول بقليل من أطول تدفق متوقع. إذا كان تدفق الدفع يستغرق عادةً 3 دقائق، فاستخدم جلسة بـ TTL مدته 10 دقائق كهامش أمان. إذا كان تدفقك أطول (مثل تصفح كتالوج متعدد الصفحات)، فاستخدم جلسة بـ 30 دقيقة. تجنب المبالغة في الطول — فكل دقيقة إضافية تزيد خطر اعتراض الموقع المستهدف للنشاط الآلي.

إعادة التدوير عند 429 و403

عند تلقي HTTP 429 (تجاوز الحد) أو 403 (ممنوع) على جلسة ثابتة، لا تُعيد المحاولة بنفس الجلسة — فالـ IP قد وُضع على القائمة السوداء مؤقتًا. بدلًا من ذلك، أنشئ جلسة جديدة بقيمة -session- مختلفة للحصول على IP جديد:

import requests
import random
import string

def new_session_id():
    return ''.join(random.choices(string.ascii_lowercase + string.digits, k=12))

def fetch_with_recovery(url, max_retries=3):
    for attempt in range(max_retries):
        sid = new_session_id()
        proxy = f"http://USERNAME-session-{sid}-country-US:PASSWORD@gate.proxyhat.com:8080"
        try:
            resp = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=30)
            if resp.status_code in (429, 403):
                print(f"Attempt {attempt+1}: {resp.status_code} — rotating session")
                continue
            return resp
        except Exception as e:
            print(f"Attempt {attempt+1}: {e}")
    return None

كم جلسة متوازية؟

هذا يعتمد على حجم تجمع IP المتاح ونطاق الحد الأقصى للموقع المستهدف. كقاعدة عامة:

• 100 جلسة متوازية آمنة لمعظم المواقع ذات الحماية المعتدلة.
• 500+ جلسة متوازية تتطلب مراقبة دقيقة لمعدلات 429 و CAPTCHA.
• للاستخراج عالي الحجم (>1,000 طلب/ثانية)، استخدم البوابة الدوارة بدلًا من الجلسات الثابتة لتوزيع الحمل على أكبر عدد ممكن من IP.

راجع صفحة التسعير لفهم حدود التزامن المتاحة في كل خطة.

متى تتفوق البوابة الدوارة على الجلسة الثابتة؟

البوابة الدوارة هي الخيار الأفضل في الحالات التالية:

• استخراج نتائج SERP: كل صفحة نتائج مستقلة ولا تحتاج حالة. راجع صفحة تتبع SERP لتفاصيل أكثر.
• مراقبة أسعار التجارة الإلكترونية: صفحات المنتجات العامة لا تتطلب تسجيل دخول عادةً.
• جمع بيانات تدريب الذكاء الاصطناعي: استخراج صفحات HTML عامة بكميات ضخمة.
• فحص توفر المنتجات: طلبات نقاطية متكررة عبر آلاف المنتجات.

في هذه السيناريوهات، توزيع الطلبات على أكبر عدد من IP يقلل خطر الحظر لكل IP ويحافظ على معدل نجاح يفوق 95% في معظم الحالات. راجع صفحة استخدامات استخراج الويب لمزيد من التفاصيل.

اعتبارات قانونية وأخلاقية

الاستخراج الآلي للبيانات يخضع لقيود قانونية متزايدة. في الولايات المتحدة، يُستخدم قانون Computer Fraud and Abuse Act (CFAA) في قضايا استخراج البيانات، رغم أن سابقة hiQ Labs v. LinkedIn (2022) قيدت نطاقه. في الاتحاد الأوروبي، يخضع جمع البيانات الشخصية لـ GDPR، والذي يتطلب أساسًا قانونيًا لمعالجة أي بيانات شخصية. اتبع دائمًا robots.txt و شروط الخدمة للموقع المستهدف، وتجنب استخراج البيانات الشخصية دون أساس قانوني. راجع توثيق ProxyHat للحصول على إرشادات الامتثال التفصيلية.

الأخطاء الشائعة والحالات الحدية

الخطأ 1: استخدام جلسة ثابتة لكل شيء

بعض الفرق تستخدم جلسة ثابتة لكل طلباتها خوفًا من كسر الحالة. هذا خطأ — فهو يركز الحمل على IP واحد ويزيد خطر الحظر. استخدم الثبات فقط عندما تحتاجه فعلًا.

الخطأ 2: نسيان TTL

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

الخطأ 3: إعادة استخدام نفس معرّف الجلسة عبر عمليات مختلفة

إذا استخدمت نفس session-abc123 لمهام متعددة تعمل بالتوازي، فستشارك جميعها نفس IP — مما يركز الحمل ويزيد خطر الحظر. استخدم معرّف جلسة فريد لكل تدفق مستقل.

الخطأ 4: عدم مراقبة نسبة 403/429

نسبة 403/429 أعلى من 5% تشير إلى أن استراتيجية الجلسة تحتاج تعديل — إما زيادة عدد الجلسات المتوازية أو التبديل إلى البوابة الدوارة.

متى تختار الجلسة الثابتة مقابل الدوارة: إطار قرار

المعيار	اختر الدوارة	اختر الثابتة
هل يحتاج التدفق لتسجيل دخول؟	لا	نعم
هل توجد حالة عربة تسوق؟	لا	نعم
هل ترقيم الصفحات مرتبط بـ IP؟	لا	نعم
حجم الطلبات	>10,000/ساعة	<10,000/ساعة
عدد المواقع المستهدفة	قليلة، حمولة عالية لكل موقع	متعددة، حمولة منخفضة لكل موقع

للاستهداف الجغرافي المتقدم، راجع صفحة المواقع لمعرفة الدول والمدن المدعومة.

النقاط الرئيسية

• البوابة الدوارة تُعيّن IP جديد لكل طلب — مثالية للاستخراج عالي الحجم دون حالة.
• الجلسة الثابتة تُثبّت IP لمدة 1–30 دقيقة — ضرورية لتدفقات تسجيل الدخول والعربات وترقيم الصفحات المرتبط بـ IP.
• التحكم في الجلسة يكون عبر اسم المستخدم: -session-abc123 للثبات، -country-US للاستهداف الجغرافي.
• عند تلقي 429 أو 403، أنشئ جلسة جديدة بمعرّف مختلف بدلًا من إعادة المحاولة بنفس IP.
• اجعل TTL الجلسة أطول بقليل من أطول تدفق متوقع، واستخدم معرّف جلسة فريد لكل تدفق مستقل.
• راجع دائمًا شروط الخدمة و robots.txt، وتوافق مع CFAA و GDPR عند الاستخراج من مواقع في الولايات المتحدة والاتحاد الأوروبي.

الاختيار بين الجلسات الثابتة والدوارة ليس ثنائيًا — بل هو قرار معماري يعتمد على طبيعة كل تدفق. أفضل الفرق تستخدم كلا النمطين معًا: البوابة الدوارة للاستخراج العام عالي الحجم، والجلسات الثابتة للتدفقات متعددة الخطوات التي تتطلب حالة. ابدأ بتجربة ProxyHat اليوم من صفحة التسعير، وجرّب كلا النمطين لتحديد ما يناسب حالتك.