Google Colab و Jupyter Notebook هما أدوات مريحة لكتابة وتشغيل سكربتات برمجة البيانات بسرعة دون الحاجة إلى تثبيت Python على الجهاز المحلي. ولكن هناك ميزة في دفاتر السحاب التي غالبًا ما يتم نسيانها: جميع الطلبات تأتي من عناوين IP لمراكز بيانات Google، والتي أصبحت معروفة منذ زمن بعيد لأنظمة مكافحة الروبوتات ويتم حظرها تقريبًا على الفور. في هذه المقالة، سنناقش كيفية توصيل البروكسي بشكل صحيح في Colab و Jupyter، وما هي القيود التي تفرضها البيئة السحابية، وكيفية تنظيم البرمجة بحيث لا تتعطل بعد أول 50 طلبًا.
لماذا يتم حظر Google Colab بشكل متكرر أكثر من جهاز الكمبيوتر العادي
المشكلة الرئيسية في Colab لبرمجة البيانات هي مجموعة عناوين IP المشتركة. في كل مرة تقوم فيها بتشغيل دفتر ملاحظات، تقوم Google بتخصيص آلة افتراضية بعنوان IP من نطاقاتها السحابية (AS15169 وما شابه). تم إدراج هذه النطاقات منذ فترة طويلة في القوائم السوداء لمعظم أنظمة مكافحة الروبوتات: Cloudflare و DataDome و PerimeterX، بالإضافة إلى الحماية المدمجة في Wildberries و Ozon والأسواق التي تتعرف عليها في أجزاء من الثانية. لا تصل الطلبات حتى إلى الموقع - يتم قطعها بواسطة فلتر ASN (رقم النظام المستقل) قبل التحقق من User-Agent أو السلوك.
السبب الثاني هو الاستخدام الجماعي. الآلاف من المطورين يقومون بتشغيل برامج البرمجة والروبوتات وسكربتات ML في نفس الوقت عبر Colab، لذا فإن سمعة هذه العناوين IP لدى العديد من المواقع المستهدفة قد "احترقت" منذ فترة طويلة قبل طلبك. حتى إذا كنت تقوم بعمل طلب GET دقيق مرة كل 10 ثوانٍ، قد يعيد الموقع 403 ببساطة لأن نفس النطاق كان يتعرض لهجوم من قبل شخص ما قبل ساعة ب500 خيط.
السبب الثالث هو أن Jupyter، عند تشغيله محليًا، عادةً لا يواجه هذه المشكلة (إذا كان لديك عنوان IP منزلي أو مكتبي عادي)، ولكن بمجرد أن تبدأ العمل عبر JupyterHub على خادم استضافة أو في حاوية مزود سحابي - تصبح الحالة مشابهة لـ Colab. لذلك، فإن السؤال "هل نحتاج إلى بروكسي أم لا" بالنسبة لدفاتر السحاب يتم حله بشكل قاطع: بدونها، فإن البرمجة لا تعمل تقريبًا بعد أول عدة طلبات.
ما هو نوع البروكسي المناسب لبرمجة البيانات السحابية
يعتمد اختيار نوع البروكسي على ما تقوم ببرمجته ومدى قوة حماية الموقع المستهدف. بالنسبة لـ Colab و Jupyter، من المهم مراعاة نقطة أخرى: جلسة دفتر الملاحظات محدودة زمنياً، لذا فإن الجلسات الثابتة طويلة الأمد للبروكسي ليست دائماً حرجة - غالبًا ما تكون الاستقرار في الاتصال مهمًا في إطار تشغيل واحد.
| نوع البروكسي | متى تستخدم في Colab/Jupyter | الميزات |
|---|---|---|
| بروكسي مراكز البيانات | برمجة المواقع بدون حماية صارمة، واجهات برمجة التطبيقات المفتوحة، الصفحات الثابتة | سرعة عالية، تكلفة منخفضة، لكن يمكن أيضًا حظرها حسب ASN على المواقع العدوانية |
| بروكسي سكنية | برمجة Wildberries و Ozon و Avito و Google و الشبكات الاجتماعية مع حماية ضد الروبوتات | عناوين IP لمستخدمين حقيقيين، نادرًا ما تدخل في القوائم السوداء، تأخير أعلى |
| بروكسي موبايل | برمجة النسخ المحمولة من المواقع، TikTok، Instagram عبر واجهة برمجة التطبيقات | أعلى مستوى من الثقة، لكن أغلى وتدوير أبطأ |
بالنسبة لمعظم مهام برمجة البيانات في الأسواق ومحركات البحث من Colab، فإن التوازن الأمثل سيكون مجموعة من البروكسي السكنية مع تدوير لكل طلب - مما يقلل من احتمال الحظر بناءً على نمط السلوك، حتى لو تم تنفيذ الطلب نفسه من البيئة السحابية لـ Google.
إعداد البروكسي في requests و urllib
إعداد البروكسي الأساسي في Colab لا يختلف عن بيئة Python المحلية. الفرق الوحيد هو أنه في Colab، عادةً ما تحتاج إلى تثبيت المكتبات عبر !pip install، حيث أن الصورة القياسية لا تحتوي دائمًا على كل ما هو ضروري.
!pip install requests
import requests
proxy = {
"http": "http://login:[email protected]:9000",
"https": "http://login:[email protected]:9000"
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}
response = requests.get(
"https://example.com/catalog",
proxies=proxy,
headers=headers,
timeout=15
)
print(response.status_code)
print(response.text[:500])
نقطة مهمة: لا يوجد ملف تكوين دائم في Colab، لذا يتعين عليك إما تضمين اسم المستخدم وكلمة المرور للبروكسي (وهو غير آمن عند نشر دفتر الملاحظات)، أو تخزينها في متغيرات البيئة في Colab عبر google.colab.userdata، أو توصيلها عبر أسرار Colab. هذا أكثر ملاءمة من تخزين كلمة المرور مباشرة في الكود، خاصة إذا كنت تشارك دفتر الملاحظات مع زملائك.
from google.colab import userdata
proxy_login = userdata.get('PROXY_LOGIN')
proxy_pass = userdata.get('PROXY_PASS')
proxy_url = f"http://{proxy_login}:{proxy_pass}@gate.proxycove.com:9000"
proxies = {"http": proxy_url, "https": proxy_url}
بروكسي مع Selenium و Chrome بدون رأس في Colab
إذا كان الموقع يقوم بعرض المحتوى عبر JavaScript (وهي حالة نموذجية لـ Wildberries و Ozon و Avito)، فإن requests البسيطة ليست كافية - تحتاج إلى متصفح بدون رأس. في Colab، عادةً ما يكون Selenium مع Chromium، والذي يجب تثبيته يدويًا، حيث أنه غير موجود في الصورة الأساسية.
!apt-get update
!apt install chromium-chromedriver
!pip install selenium
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
chrome_options = Options()
chrome_options.add_argument('--headless')
chrome_options.add_argument('--no-sandbox')
chrome_options.add_argument('--disable-dev-shm-usage')
chrome_options.add_argument('--proxy-server=http://gate.proxycove.com:9000')
driver = webdriver.Chrome(options=chrome_options)
driver.get("https://example.com/catalog")
print(driver.page_source[:500])
driver.quit()
المشكلة هي أن العلم --proxy-server لا يدعم المصادقة باستخدام اسم المستخدم وكلمة المرور مباشرة. بالنسبة للبروكسي مع المصادقة في Selenium، تحتاج إما إلى استخدام مصادقة IP (القائمة البيضاء بناءً على IP الثابت للدفتر، وهو غير مستقر في Colab، حيث يتغير IP الجهاز مع كل تشغيل جديد)، أو إنشاء ملحق Chrome "في الوقت الحقيقي" مع بيانات اعتماد البروكسي، أو استخدام نفق البروكسي عبر مكتبة مثل selenium-wire، التي تدعم البروكسي المعتمد من الصندوق.
!pip install selenium-wire
from seleniumwire import webdriver
proxy_options = {
'proxy': {
'http': 'http://login:[email protected]:9000',
'https': 'http://login:[email protected]:9000',
}
}
driver = webdriver.Chrome(seleniumwire_options=proxy_options, options=chrome_options)
driver.get("https://example.com/catalog")
Jupyter Notebook: محلي مقابل سحابي
يستخدم Jupyter Notebook، الذي يتم تشغيله على الجهاز المحلي (عبر Anaconda أو مباشرة عبر pip)، عنوان IP المنزلي أو المكتبي الخاص بك - وفي هذه الحالة، تكون البروكسي ضرورية فقط للتخفي أو تجاوز القيود الجغرافية، وليس للحماية من الحظر بسبب ASN لمركز البيانات. الإعداد في هذه الحالة مطابق تمامًا لسكربت Python العادي: نفس requests، نفس Selenium، بدون قيود على تثبيت السائقين والحزم النظامية.
تتغير الحالة إذا كنت تستخدم Jupyter عبر خدمة سحابية: JupyterHub على VPS، دفاتر Kaggle، Deepnote، Binder أو مجموعة سحابية مؤسسية. في هذه الحالات، تعود IP مرة أخرى إلى مركز بيانات المزود، وتكون جميع مشاكل Colab ذات صلة تمامًا. الاختلاف الرئيسي عن Colab هو أن هذه الخدمات غالبًا ما توفر IP أكثر استقرارًا خلال الجلسة (لا يتغير عند إعادة تشغيل النواة)، مما يسهل إعداد القائمة البيضاء بناءً على IP، إذا كان مزود البروكسي الخاص بك يدعم ذلك.
الاستنتاج العملي: إذا كانت البرمجة حاسمة للأعمال (على سبيل المثال، مراقبة أسعار المنافسين يوميًا في الأسواق)، فمن الأفضل عدم الاعتماد على دفاتر السحاب المجانية كبيئة إنتاج، واستخدامها فقط لتطوير واختبار السكربت، ونقل برنامج البرمجة النهائي إلى خادم مع IP ثابت وبروكسي معدة.
قيود دفاتر السحاب التي تعطل البرمجة
بالإضافة إلى مشاكل سمعة IP، فإن Google Colab لديه مجموعة من القيود الفنية التي تؤثر مباشرة على استقرار البرمجة:
- مهلة عدم النشاط. تقوم النسخة المجانية من Colab بإيقاف دفتر الملاحظات بعد ~90 دقيقة من الخمول وتغلق الجلسة قسريًا بعد 12 ساعة من العمل المستمر - يجب تقسيم البرمجة الطويلة لآلاف الصفحات إلى أجزاء أو حفظ النتائج الوسيطة على Google Drive.
- تغيير IP مع كل تشغيل جديد. إذا قمت بفصل وإعادة توصيل بيئة التنفيذ، يتغير عنوان IP للآلة الافتراضية - وهذا يكسر أي إعداد مع القائمة البيضاء بناءً على IP على جانب خدمة البروكسي.
- قيود على الاتصالات الصادرة. تحد Google من عدد الاتصالات الشبكية المتزامنة من آلة افتراضية واحدة، لذا فإن تعدد الخيوط العدواني مع عشرات الطلبات المتوازية قد يتعثر ليس بسبب حظر الموقع، ولكن بسبب حدود Colab نفسها.
- لا يوجد تخزين دائم بدون تركيب القرص. تختفي الكوكيز، وجلسات المتصفح، وذاكرة التخزين المؤقت لاتصالات البروكسي عند كل إعادة تشغيل - للبرمجة مع المصادقة، يجب حفظ الكوكيز بوضوح في ملف على Google Drive.
- تأخيرات الشبكة غير المتوقعة. أحيانًا توفر البنية التحتية السحابية لـ Google قفزات في الكمون، مما يتطلب وضع مهلات الطلبات مع هامش (15-30 ثانية بدلاً من 5-10 القياسية).
تجعل هذه القيود Colab أداة ممتازة لتطوير وتصحيح منطق البرمجة، ولكنها غير مناسبة تمامًا لمهام الإنتاج الطويلة - من الأفضل نقل السكربت الجاهز إلى VPS أو خادم مخصص مع IP خاص.
تدوير البروكسي ومعالجة الأخطاء في الحلقة
لتجنب تعطل البرمجة عند أول حظر، تحتاج الشيفرة إلى منطق المحاولات المتكررة مع استبدال البروكسي. أدناه مثال على حلقة بسيطة مع تدوير ومعالجة الأخطاء، يمكن تشغيلها مباشرة في Colab.
import requests
import time
import random
proxy_pool = [
"http://login:[email protected]:9000",
"http://login:[email protected]:9001",
"http://login:[email protected]:9002",
]
def get_with_retry(url, max_retries=5):
for attempt in range(max_retries):
proxy_url = random.choice(proxy_pool)
proxies = {"http": proxy_url, "https": proxy_url}
try:
response = requests.get(url, proxies=proxies, timeout=20)
if response.status_code == 200:
return response
else:
print(f"محاولة {attempt+1}: الحالة {response.status_code}")
except requests.exceptions.RequestException as e:
print(f"محاولة {attempt+1}: خطأ {e}")
time.sleep(random.uniform(2, 5))
return None
result = get_with_retry("https://example.com/catalog")
if result:
print(result.status_code)
else:
print("تم استنفاد جميع المحاولات")
لبرمجة كتالوجات كبيرة (على سبيل المثال، آلاف بطاقات المنتجات على Wildberries) يتم لف هذه المنطق بشكل إضافي في قائمة مهام مع فترات بين الطلبات وحفظ النتائج الوسيطة في CSV أو قاعدة بيانات مباشرة على Google Drive، حتى لا تفقد التقدم عند انقطاع جلسة Colab.
قائمة التحقق قبل تشغيل برنامج البرمجة في Colab
- تم توصيل البروكسي واختباره عبر طلب اختبار منفصل قبل الحلقة الرئيسية
- يتم تخزين اسم المستخدم وكلمة المرور للبروكسي في أسرار Colab، وليس في الكود المفتوح
- للمواقع التي تستخدم JavaScript، يتم استخدام Selenium مع selenium-wire أو ملحق المصادقة المحدد
- يوجد في الكود منطق retry وتدوير البروكسي عند الأخطاء 403/429
- يتم حفظ النتائج الوسيطة على Google Drive كل N سجل
- تم زيادة مهلات الطلبات مع مراعاة التأخيرات المحتملة في الشبكة السحابية
- تم تحديد توازي الطلبات لتجنب الوصول إلى حدود الاتصالات الصادرة في Colab
- للمهام الإنتاجية، تم التخطيط لنقل السكربت إلى خادم منفصل مع IP ثابت
الخاتمة
Google Colab و Jupyter السحابية مناسبان تمامًا للتطوير السريع واختبار منطق البرمجة، ولكن بسبب IP المشتركة لمراكز البيانات، غالبًا ما تتطلب البروكسي منذ الخطوات الأولى. بالنسبة للمواقع البسيطة بدون حماية عدوانية، تكفي بروكسي مراكز البيانات، ولكن لبرمجة الأسواق ومحركات البحث والشبكات الاجتماعية، تعمل البروكسي السكنية والمحمولة بشكل أكثر موثوقية، حيث نادرًا ما تقع تحت الفلاتر حسب ASN.
إذا كنت تخطط لمراقبة أسعار Wildberries أو Ozon بانتظام مباشرة من Colab، نوصي بالبدء بـ بروكسي سكنية - فهي توفر وصولًا مستقرًا بدون حظر متكرر، وللسكربتات التجريبية الفردية يمكن الاكتفاء ببروكسي مراكز البيانات الأكثر اقتصادية، متصلين بها بنفس الطريقة عبر requests أو Selenium.