أبرز المستجدات
أصبح Proxy Finder يتعلم لكل مضيف (host) على حدة. لم يعد يقتصر على اختيار proxy سريع بشكل عام، بل يختار proxy نجح بالفعل مع الموقع الذي تطلبه. حصل Browser على إصلاح للاستقرار يعالج فئة من أخطاء التشغيل البارد (cold-start). وأصبح بإمكان شاشتي Metrics و Activity في Dashboard تصفية البيانات حسب المنتج.
ما الجديد
يقوم Proxy Finder باختيار proxies تعمل بالفعل مع هدفك
هذا هو التغيير الأكبر هذا الأسبوع، وقد تطلب عدة تكرارات للوصول إلى شكله النهائي.
سابقاً: كان Proxy Finder يختار من مجموعة عامة بناءً على الكفاءة العامة. كان يتم اختيار الـ proxies لـ requestين موجهين إلى نفس الموقع المستهدف من نفس المجموعة الواسعة، على الرغم من أن معظم الـ proxies في تلك المجموعة لن تعمل على هذا الموقع بالتحديد.
الآن: لكل مضيف مستهدف تستعلم عنه، يتتبع Proxy Finder الـ proxies التي نجحت بالفعل في تقديم الـ response. تختار الـ requests الجديدة عينة من الـ proxies التي أثبتت كفاءتها، وتلجأ إلى فحص عينة صغيرة من الـ proxies غير المعروفة لمواصلة التعلم، وتتجنب تلك التي فشلت بالفعل هناك. المجموعة التي أثبتت كفاءتها تكون مخصصة لكل مضيف وتظل محفوظة حتى بعد إعادة التشغيل.
إذا كنت تقوم بعمل scraping لمواقع محمية لا يعمل معها سوى جزء صغير من الـ proxies، فستشعر بهذا التغيير بالتأكيد. اختيار أقل للـ proxies غير الصالحة، ومحاولات إعادة أقل، وهدر أقل للميزانية.
لقد أطلقنا هذه الميزة خلف flag، وأجرينا ستة تكرارات لإصلاح المشكلات الطفيفة (أحدها، وهو تقييد منطق التعلم ليظل مستقراً تحت معدل الزيارات المنخفض، تطلب جولتين إضافيتين)، وقمنا بتفعيلها كخيار افتراضي في بيئة الإنتاج (production) هذا الأسبوع.
أصبح Browser موثوقاً بعد فترات الخمول
إصلاحان، ونتيجة واحدة.
أولاً، كان هناك خلل في الحالة القديمة (stale-state) في Browser عند التشغيل البارد. بعد فترة خمول كافية، كانت طبقة العرض الأساسية تحتفظ بقفل (lock) يمنع عملية التشغيل التالية من النجاح. كان من الممكن أن يفشل الـ request الأول بعد فترة هدوء أو يتوقف عن الاستجابة. نقوم الآن بمسح القفل قبل التشغيل.
ثانياً، كان مسار الـ API العام الذي يوجه إلى Browser يشير إلى الوجهة الخاطئة في بعض البيئات. كان يتم توجيه حركة المرور بشكل خاطئ ودون إشعار. تم تصحيح إعدادات التوجيه (routing config) الآن.
إذا كنت قد واجهت سلوكاً غير مستقر في الـ request الأول على Browser عند انخفاض حجم الاستخدام، فهذا هو السبب.
تصفية Metrics و Activity حسب المنتج
تحتوي صفحتا Metrics و Activity في Dashboard الآن على فلتر لتحديد المنتج. انقر فوق Single أو Browser أو Proxy Finder لتقتصر المخططات البيانية على حركة مرور هذا المنتج فقط. هذا مفيد عندما تريد فقط رؤية زمن الاستجابة (latency) أو الأخطاء من جزء معين من استخدامك بدلاً من العرض المجمع.
تحديث بسيط للموقع
صفحة /jobs أصبحت نشطة الآن. نحن نوظف Founding Engineer و Engineer. توضح كلتا الصفحتين نطاق العمل، وكيف يبدو الشهر الأول، وكيفية التقديم.
لقد قمنا أيضاً بتحسين العرض على الهواتف المحمولة لمعاينة Dashboard على الصفحة الرئيسية، وتحديث صور المشاركة الاجتماعية لكل صفحة عبر تسعة مسارات عامة، وتحديث ملف robots.txt ليتناسب مع عصر الذكاء الاصطناعي في عام 2026 (السماح بأدوات الاسترجاع ومعاينة المشاركة الاجتماعية، وحظر زواحف التدريب)، وتحديث شروط الخدمة (Terms of Service) بفقرة استخدام مقبول أكثر ووضوحاً، وإضافة ملاحظة الاختصاص القضائي لمدينة صوفيا مع استثناء المستهلكين في الاتحاد الأوروبي.
خلف الكواليس
تغيير في المسميات غير موجه للعملاء تم في وقت سابق: أصبحت عبارة "anti-bot bypass" هي "anti-bot resilience" في جميع أنحاء الموقع. نفس المنتج، ونفس السلوك، لكن الصياغة القديمة كانت تتسبب في تفعيل فلاتر سياسات المنصات الإعلانية.
لن ننشر أرقاماً من منطق الاختيار الجديد بعد. نريد أسبوعين كاملين من حركة مرور بيئة الإنتاج (production) الفعلية قبل أن نطلق أي ادعاءات حول معدلات النجاح. سننشر الأرقام الحقيقية فور توفرها.
لقد قضينا الشهر الماضي في إعادة بناء الطبقة التي تحدد الـ proxy الذي يجب استخدامه لكل هدف. والجزء الصعب ليس الخوارزمية، بل قياس ما إذا كانت تساعد بالفعل في ظل أعباء العمل الحقيقية. هذا هو ما يبدو عليه شهر مايو.