يقوم البائع بتشغيل محلل أسعار المنافسين في الليل، وفي الصباح يتلقى إشعارًا: انتهى الترافيك، وتم استهلاك الحزمة بنسبة 90%. هل هذه حالة مألوفة؟ غالبًا ما يكون اللوم ليس على المحلل نفسه، بل على عدم وجود حدود على مستوى البروكسي والسكريبت. في هذه المقالة، سنناقش كيف يتسرب الترافيك بلا فائدة، وكيفية وضع حماية لضمان أن حزمة البروكسي الساكن أو المتنقل تكفي حتى نهاية الفترة المحسوبة.
لماذا ينتهي الترافيك في الليل
يبدو أن عملية البحث في Wildberries أو Ozon أو Avito هي مهمة بسيطة: أرسل طلبًا - احصل على JSON مع السعر. لكن في الواقع، يتم استهلاك الترافيك ليس فقط على البيانات المفيدة. المصادر الرئيسية للإفراط في الاستهلاك هي:
- تحميل الصور والوسائط. إذا كان المحلل يفتح صفحة المنتج بالكامل عبر المتصفح (وليس يقوم بإجراء طلب مباشر إلى API)، فإنه يقوم تلقائيًا بتحميل الصور ومقاطع الفيديو واللافتات - وهذا عشرات الميجابايت لكل بطاقة.
- طلبات متكررة بسبب CAPTCHA والحظر. يتعرف السوق على الروبوت، ويظهر CAPTCHA أو حظر مؤقت لعنوان IP، ويقوم السكريبت بإجراء طلب متكرر - يتم استهلاك الترافيك بلا فائدة، ولا تصل البيانات.
- عدم وجود تخزين مؤقت للطلبات. بدون منطق "تمت معالجته بالفعل في هذه الساعة - لا تكرار" يمكن أن يقوم السكريبت بالاستعلام عن نفس البطاقات عدة مرات في الليل.
- تدفقات متوازية بدون قيود. يبدو أن تشغيل 50-100 تدفقًا في نفس الوقت يعجل العمل، ولكن في الوقت نفسه يتم استهلاك الترافيك بشكل أسرع بكثير مما هو مخطط له، ويتم حظر جزء من الطلبات ببساطة.
- اختيار خاطئ لنوع البروكسي. عادةً ما يتم تسعير البروكسي الساكن والمتنقل بناءً على حجم الترافيك (جيجابايت)، على عكس بروكسي مراكز البيانات، حيث يتم الدفع غالبًا بناءً على عدد عناوين IP أو وقت الإيجار. إذا كان المحلل مضبوطًا على مجموعة سكنية بدون رقابة - فإن الحد ينفد بسرعة.
تؤدي مجموعة من هذه العوامل إلى أن السكريبت، الذي تم تصميمه للعمل لمدة شهر، يستهلك حزمة الترافيك في جلسة واحدة لعملية البحث عن 10-20 ألف بطاقة منتجات.
كيف يتم حساب الترافيك لأنواع البروكسي المختلفة
قبل وضع الحدود، من المهم فهم ما الذي تدفع مقابله بالضبط. تحسب أنواع البروكسي المختلفة الاستهلاك بطرق مختلفة، وهذا يؤثر بشكل مباشر على استراتيجية التوفير.
| نوع البروكسي | التسعير | خطر الإفراط في الاستهلاك | متى تستخدم |
|---|---|---|---|
| بروكسي سكنية | حسب حجم الترافيك (جيجابايت) | مرتفع بدون حدود | البحث مع تجاوز حماية مكافحة الروبوتات في الأسواق |
| بروكسي متنقلة | حسب حجم الترافيك أو الوقت | مرتفع، الترافيك أغلى | البحث في النسخ المتنقلة من المواقع، تجاوز الحظر الصارم |
| بروكسي مراكز البيانات | حسب عدد IP / وقت الإيجار | منخفض، الترافيك عادةً غير محدود | البحث الجماعي بدون حماية صارمة ضد الروبوتات |
إذا كنت تبحث في Wildberries أو Ozon، حيث تعمل حماية ضد الروبوتات بنشاط، فإن IP السكنية أو المتنقلة ضرورية تقريبًا - يتم حظر عناوين مراكز البيانات بسرعة. ولكن بسبب التسعير بناءً على الترافيك، من المهم جدًا وضع حدود مسبقًا.
كم من الترافيك تحتاجه فعليًا لعملية البحث
لوضع حد مناسب، يجب أن تستند إلى الأرقام الحقيقية، وليس على المشاعر. النفقات التقريبية في الممارسة العملية:
- طلب إلى API بطاقة المنتج (JSON، بدون صور): 5-30 كيلوبايت لكل بطاقة. على 10,000 بطاقة - حوالي 50-300 ميغابايت.
- تحميل صفحة المنتج عبر متصفح بدون رأس مع الصور: 1-3 ميغابايت لكل بطاقة. على نفس 10,000 بطاقة - 10-30 جيجابايت.
- مراقبة الأسعار كل ساعة لـ 1000 SKU: مع الطلبات المبسطة - حوالي 1-5 جيجابايت يوميًا، مع تحميل كامل للصفحات - 50-100 جيجابايت يوميًا.
الفرق بين "البحث الخفيف" و"البحث الثقيل" هو عشرات المرات. لذلك، الخطوة الأولى لتوفير الترافيك هي إيقاف تحميل الصور ومقاطع الفيديو والسكريبتات الخارجية حيثما كان ذلك ممكنًا، والعمل مباشرة مع API السوق أو النسخة المتنقلة من الموقع، التي تزن أقل من النسخة المكتبية.
الحدود في متصفحات مكافحة الكشف ومديري البروكسي
بالنسبة لأولئك الذين يبحثون عبر متصفح مكافحة الكشف (مثل Dolphin Anty، AdsPower، Multilogin، GoLogin، Octo Browser) أو مدير بروكسي خاص بهم، فإن أسهل طريقة لتحديد الاستهلاك هي إعداد الحدود على مستوى الملف الشخصي وحساب مزود البروكسي.
- قم بتسجيل الدخول إلى حساب مزود البروكسي وابحث عن قسم إدارة الترافيك أو الحدود للمستخدمين الفرعيين/المنافذ.
- قم بإنشاء حساب فرعي أو منفذ منفصل للبحث - لا تستخدم نفس مجموعة البروكسي المستخدمة لحسابات الزراعة في Instagram أو TikTok. تقسيم المهام يظهر على الفور إلى أين يذهب الترافيك.
- قم بتعيين حد يومي أو ساعي للترافيك على هذا الحساب الفرعي - على سبيل المثال، 5 جيجابايت يوميًا بدلاً من استهلاك كل حزمة الشهر في جلسة واحدة.
- في متصفح مكافحة الكشف، قم بإيقاف تحميل الصور تلقائيًا للملفات الشخصية التي تستخدم فقط لجمع البيانات، وليس لمشاهدة الصفحات بصريًا.
- قم بإعداد جدول زمني لتشغيل الملفات الشخصية بحيث تتم عملية البحث في فترات قصيرة مع فترات توقف - هذا يقلل من خطر الحظر ويمنح الوقت لتتبع استهلاك الترافيك بين التشغيلات.
هذه الطريقة مهمة بشكل خاص للوكالات والمستقلين الذين يقومون بعمليات بحث في عدة أسواق في نفس الوقت: بدون تقسيم الحسابات الفرعية، من الصعب فهم أي مشروع "أكل" الترافيك.
تحديد الترافيك على مستوى السكريبت وAPI
إذا كان المحلل مكتوبًا بشكل مستقل باستخدام Python أو Node.js، يمكن تضمين الحدود مباشرة في الكود - وهذا يوفر تحكمًا أكثر دقة من إعدادات واجهة مزود البروكسي.
مثال على عداد بسيط للترافيك باستخدام requests:
import requests
MAX_BYTES_PER_DAY = 5 * 1024 * 1024 * 1024 # حد 5 جيجابايت يوميًا
used_bytes = 0
proxies = {
"http": "http://user:pass@proxy_host:port",
"https": "http://user:pass@proxy_host:port",
}
def safe_get(url):
global used_bytes
if used_bytes >= MAX_BYTES_PER_DAY:
raise RuntimeError("تم استنفاد الحد اليومي للترافيك، تم إيقاف البحث")
response = requests.get(url, proxies=proxies, timeout=10)
used_bytes += len(response.content)
return response
# مثال على الاستدعاء
resp = safe_get("https://card.wb.ru/cards/detail?nm=123456")
print("تم استخدام الترافيك:", round(used_bytes / 1024 / 1024, 2), "ميغابايت")
المنطق بسيط: يقوم السكريبت بحساب حجم كل استجابة بالبايت ويتوقف بمجرد الوصول إلى الحد المحدد. هذا يحمي من الحالة التي يؤدي فيها خطأ في الحلقة أو تكرار الطلبات اللانهائية إلى "أكل" حزمة الترافيك الشهرية في بضع ساعات.
من المفيد أيضًا إضافة:
- تأخير أسي عند الأخطاء (إعادة المحاولة مع الانتظار) - بدلاً من إعادة الطلب على الفور عند ظهور CAPTCHA أو الحظر، ينتظر السكريبت فترة متزايدة (5 ثوانٍ، 15 ثانية، 60 ثانية)، مما يقلل من عدد الطلبات غير المجدية.
- تحديد عدد التدفقات المتوازية - على سبيل المثال، لا تزيد عن 10-20 اتصالًا متزامنًا عبر مجموعة البروكسي، لتجنب إثارة الحظر وعدم استهلاك الترافيك بلا فائدة.
- إيقاف تحميل الموارد في المتصفح بدون رأس - إذا كانت عملية البحث تتم عبر Selenium أو Puppeteer، يمكن في إعدادات المتصفح حظر تحميل الصور والخطوط وCSS، مع ترك فقط استجابات HTML/JSON.
مراقبة الاستهلاك في الوقت الحقيقي
يعمل الحد بدون مراقبة بشكل أقل فعالية، لأنك تعرف عن المشكلة فقط بعد توقف السكريبت. للتحكم في الاستهلاك أثناء العمل:
- قم بتفعيل الإشعارات في حساب مزود البروكسي عند الوصول إلى 50%، 80% و100% من حزمة الترافيك الشهرية - تدعم معظم الخدمات مثل هذه التنبيهات عبر البريد الإلكتروني أو في Telegram.
- احتفظ بسجل بسيط في السكريبت نفسه: قم بتسجيل حجم الترافيك في الساعات، لرؤية ذروات الاستهلاك والعثور بسرعة على مصدر المشكلة.
- قم بتقسيم الترافيك حسب المهام عبر حسابات فرعية أو علامات منفصلة - بشكل منفصل لعملية البحث في Wildberries، بشكل منفصل لـ Ozon، بشكل منفصل لـ Avito. هذا يسهل التحليل، لمعرفة أي مشروع يستهلك أكبر قدر من الترافيك.
- قارن الاستهلاك مع حجم البيانات المتوقع: إذا استهلكت 20 جيجابايت ل10,000 بطاقة بدلاً من 300 ميغابايت المحسوبة، فهذا يعني أن هناك موارد إضافية يتم تحميلها أو طلبات متكررة.
قائمة مراجعة للتحكم في ميزانية الترافيك
- تم إيقاف تحميل الصور ومقاطع الفيديو تلقائيًا في الملفات الشخصية للبحث
- يتم استخدام طلب مباشر إلى API السوق حيثما كان ذلك ممكنًا، بدلاً من تحميل الصفحة بالكامل
- تم تعيين حد يومي أو ساعي للترافيك على الحساب الفرعي للبروكسي
- تم تقسيم البحث إلى مجموعات بروكسي منفصلة حسب المشاريع (Wildberries، Ozon، Avito)
- تم تنفيذ عداد للترافيك في السكريبت مع إيقاف عند الوصول إلى الحد
- تم إعداد تأخير وbackoff عند ظهور CAPTCHA أو الحظر بدلاً من إعادة المحاولة الفورية
- تم تحديد عدد التدفقات المتوازية لعملية البحث
- تم تفعيل الإشعارات حول استهلاك الترافيك من مزود البروكسي
- يتم الاحتفاظ بسجل لاستهلاك الترافيك حسب الساعات لتحليل الشذوذ
الأخطاء الشائعة للمبتدئين
في الممارسة العملية، يتم تفسير معظم حزم الترافيك "المحترقة" من خلال عدة أخطاء نموذجية:
- تشغيل البحث "في الليل بدون إشراف" بدون حدود. يعمل السكريبت 8-10 ساعات دون توقف، وإذا حدثت حلقة من الطلبات المتكررة في أي مكان، يتم استهلاك الترافيك بشكل مستمر حتى الصباح.
- مجموعة بروكسي واحدة لجميع المهام. زراعة حسابات في Instagram، اختبار إعلانات في Facebook Ads وعمليات البحث في Ozon تستخدم نفس الترافيك - من المستحيل فهم ما الذي يستهلكه بالضبط.
- تجاهل CAPTCHA. بدلاً من تقليل تكرار الطلبات عند ظهور أولى علامات CAPTCHA، يستمر السكريبت في ضرب الموقع بنفس الكثافة، مما يستهلك الترافيك على استجابات غير مفيدة برمز خطأ.
- اختيار البروكسي السكنية حيث يكفي استخدام بروكسي مراكز البيانات. إذا لم يقم السوق بحظر عناوين IP لمراكز البيانات بشكل صارم، فإن الدفع الزائد عن الترافيك من مجموعة سكنية غير مبرر - للأهداف الأقل حماية، يمكن استخدام بروكسي مراكز البيانات مع نموذج تسعير مختلف.
- عدم وجود اختبار تجريبي. قبل بدء عملية البحث الكاملة على آلاف البطاقات، من الأفضل تشغيل السكريبت على 50-100 بطاقة وقياس الاستهلاك الفعلي للترافيك، لتعميمه على الحجم الكامل.
الخاتمة
يتم "حرق" الترافيك لعملية البحث ليس بسبب حجم البيانات، ولكن بسبب عدم وجود رقابة: الصور الزائدة، الطلبات المتكررة عند الحظر، التدفقات المتوازية بدون قيود ومجموعة بروكسي واحدة لجميع المهام. الحل هو تقسيم الترافيك حسب المشاريع، وضع حدود يومية على مستوى حساب البروكسي، تضمين عداد الاستهلاك في السكريبت نفسه وإعداد المراقبة مع الإشعارات قبل أن تنتهي الحزمة بالفعل.
إذا كنت تبحث في الأسواق مع حماية نشطة ضد الروبوتات مثل Wildberries أو Ozon، نوصي باستخدام بروكسي سكنية لتجاوز الحظر و IP المتنقلة لأكثر السيناريوهات حساسية ضد حماية مكافحة الروبوتات - ولكن في كلا الحالتين، تأكد من وضع حدود للترافيك مسبقًا، حتى لا تضيع الحزمة الشهرية في جلسة واحدة في الليل.