← العودة إلى المدونة
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

لماذا يكشف المحلل عن بصمة TLS حتى مع عنوان IP سكني نظيف: كيفية التحقق والإصلاح

لا ينقذ عنوان IP السكني من الحظر إذا كان بصمة TLS للبارسر تختلف عن بصمة المتصفح العادي. نناقش كيفية التحقق من ذلك وضبطه بشكل صحيح.

📅١٧ ربيع الآخر ١٤٤٨ هـ

لقد حصلت على IP سكني مكلف، وضبطت التدوير، وأدخلت وكيل مستخدم واقعي — ومع ذلك، لا يزال البرنامج يذهب إلى CAPTCHA أو يحصل على استجابة فارغة. المشكلة تكمن تقريبًا دائمًا في IP، ولكن في بصمة TLS: المكتبة التي ترسل طلب HTTPS "تبدو" ليست مثل المتصفح الحقيقي. أنظمة مكافحة الروبوتات في Wildberries وOzon وCloudflare وAkamai ترى ذلك قبل أن تتحقق من عنوان IP الخاص بك.

ما هي بصمة TLS ولماذا هي أهم من IP

عندما يقوم العميل بإنشاء اتصال HTTPS، فإنه يرسل إلى الخادم حزمة ClientHello — جزء من عملية المصافحة TLS. تحتوي على قائمة بالإصدارات المدعومة من TLS، مجموعة التشفير (cipher suites)، ترتيب الامتدادات (extensions)، المنحنيات البيانية وخوارزميات الضغط. هذه المجموعة من المعلمات فريدة لكل ارتباط "مكتبة + نظام تشغيل + إصدار كومة TLS".

يقوم Chrome وFirefox وSafari بتشكيل ClientHello بطريقتهم الخاصة، وهذه المجموعة لا تتغير تقريبًا من طلب إلى آخر — على عكس IP أو وكيل المستخدم، اللذان يمكن تزويرهما بسهولة. أما المكتبات HTTP القياسية — requests، urllib3، HttpClient القياسي في Java، كومة TLS المدمجة في Node.js — فإنها تشكل ClientHello مختلف تمامًا، لأنها تستخدم OpenSSL أو مكتبة أخرى بشكل مختلف عن المتصفح.

لهذا السبب يمكنك توصيل IP سكني "نظيف" تمامًا، وإدخال وكيل مستخدم جديد من Chrome الحقيقي — ومع ذلك، لا يزال يتم حظرك. يرى الخادم IP المستخدم من المنزل، ويرى عنوان "Chrome 124"، ولكن عملية المصافحة TLS تقول: "هذا برنامج Python". عدم التطابق هو إشارة مباشرة لمكافحة الروبوتات.

كيف تكشف أنظمة مكافحة الروبوتات عن البرنامج من خلال JA3/JA4

لتحويل معلمات ClientHello إلى معرف مضغوط، يتم استخدام خوارزمية JA3 (وإصدارها الأحدث JA4). تأخذ إصدار TLS، قائمة التشفير، الامتدادات والمنحنيات، وتجمعها في سلسلة ثم تقوم بتجزئتها عبر MD5. ينتج عن ذلك تجزئة قصيرة من النوع 769,47-53-5-10...,0-23-65281...,29-23-24,0، التي تحدد "بصمة" العميل بشكل فريد.

يحتفظ مزودو مكافحة الروبوتات (Cloudflare وAkamai وPerimeterX وDataDome — ونظائرهم الذين يستخدمهم Wildberries وOzon) بقواعد بيانات معروفة من تجزئات JA3/JA4 لمكتبات HTTP الشعبية: requests وaiohttp وScrapy وNode fetch وJava HttpClient وGo net/http. إذا تطابقت التجزئة مع توقيع معروف لـ "البرنامج"، وليس مع توقيع Chrome/Firefox/Safari — يتم وضع علامة على الطلب كاشتباه قبل تحليل السلوك.

بعد ذلك، تنظر النظام إلى تطابق بصمة TLS مع وكيل المستخدم المعلن. إذا كانت الرؤوس تقول "Chrome 124 على Windows"، وكانت بصمة TLS تتوافق مع OpenSSL 1.1.1 من المكتبة القياسية لـ Python — فهذا يسمى TLS/HTTP mismatch، وهو أحد أكثر إشارات الكشف موثوقية. هكذا يتم الكشف عن البرامج حتى مع IP سكني مثالي ورؤوس صحيحة.

كيفية التحقق من بصمة TLS الخاصة بك: الأدوات

قبل إصلاح المشكلة، تحتاج إلى رؤية ما يراه الخادم. هناك العديد من الخدمات العامة التي تعرض تجزئة JA3/JA4 الخاصة بك ومجموعة كاملة من معلمات ClientHello:

  • tls.peet.ws — يعرض JA3 وJA4، قائمة التشفير والامتدادات بتنسيق JSON، مما يجعله مناسبًا للتحقق التلقائي بواسطة البرنامج.
  • ja3er.com — قاعدة بيانات معروفة من تجزئات JA3 مرتبطة بمكتبات ومتصفحات معينة.
  • browserleaks.com/tls — مقارنة بصرية لبصمتك مع البصمات النموذجية للمتصفحات.
  • Wireshark محليًا — إذا كنت ترغب في رؤية حزمة ClientHello الخام عند إرسال الطلب من برنامجك.

الاختبار العملي بسيط: افتح tls.peet.ws في Chrome العادي وسجل تجزئة JA4. ثم أرسل طلب GET إلى نفس العنوان من برنامجك (عبر requests أو curl_cffi أو أي مكتبة أخرى) من خلال نفس البروكسي وقارن التجزئات. إذا كانت مختلفة — فإن الخادم يرى الفرق بين "المتصفح" و"البرنامج" في كل طلب، بغض النظر عن مدى نظافة IP.

التحقق باستخدام Python: requests، httpx، curl_cffi

دعونا نفهم عمليًا لماذا تعطي المكتبات القياسية في Python بصمة البرنامج. طلب عادي عبر requests: 

import requests

resp = requests.get("https://tls.peet.ws/api/all", proxies={
    "https": "http://user:pass@proxy_host:port"
})
print(resp.json()["tls"]["ja4"])
# ستكون النتيجة مختلفة عن JA4 في Chrome الحقيقي،
# لأن requests تستخدم وحدة ssl القياسية في Python

المشكلة هي أن requests وhttpx تستخدم OpenSSL النظامي عبر وحدة ssl، وترتيب ومجموعة الامتدادات TLS لديها ثابتة ولا تتطابق مع Chrome/Firefox. الحل هو مكتبة curl_cffi، التي تستخدم curl المعدل مع ملفات تعريف TLS الحقيقية للمتصفحات: 

from curl_cffi import requests as cffi_requests

resp = cffi_requests.get(
    "https://tls.peet.ws/api/all",
    impersonate="chrome124",
    proxies={"https": "http://user:pass@proxy_host:port"}
)
print(resp.json()["tls"]["ja4"])
# ستكون التجزئة مطابقة لـ Chrome 124 الحقيقي على سطح المكتب

المعامل impersonate يجعل curl_cffi يعيد إنتاج ليس فقط ClientHello، ولكن أيضًا ترتيب رؤوس HTTP/2 (frame order)، الذي يدخل أيضًا في البصمة. تستخدم مكتبات مشابهة tls-client لـ Go وundetected-chromedriver لأولئك الذين يقومون بالتجريف عبر متصفح حقيقي، وليس عبر عميل HTTP.

إذا كان التجريف يتم عبر متصفح بدون واجهة (Playwright، Puppeteer، Selenium)، فإن بصمة TLS تتشكل بواسطة محرك Chromium/Firefox وتتطابق افتراضيًا مع المتصفح الحقيقي. لكن هنا تظهر مشكلة أخرى — توقيعات الأتمتة على مستوى JS (علامات webdriver، بصمة canvas)، لذلك تحتاج سيناريوهات بدون واجهة إلى تصحيحات إضافية مثل playwright-stealth.

TLS + HTTP/2 + الرؤوس: لماذا الربط مهم

بصمة TLS هي مجرد طبقة واحدة من الكشف. تقوم أنظمة مكافحة الروبوتات بمقارنة عدة مستويات في نفس الوقت:

  • TLS ClientHello (JA3/JA4) — مجموعة التشفير والامتدادات.
  • بصمة HTTP/2 — ترتيب الرؤوس الوهمية (:method، :path، :authority)، إعدادات إطار SETTINGS، حجم النافذة.
  • رؤوس HTTP — ترتيب ومجموعة الرؤوس العادية (Accept-Language، Sec-Ch-Ua، Sec-Fetch-*).
  • User-Agent — يجب أن يتطابق مع إصدار ملف تعريف TLS: إذا كان UA يقول "Chrome 124"، بينما تتوافق TLS مع Chrome 110، فهذا أيضًا مشبوه.

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

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

دور البروكسي: لماذا لا ينقذ IP النظيف

يحل IP السكني مشكلة معينة — يقلل من الشكوك بناءً على الجغرافيا وASN وسمعة العنوان. غالبًا ما تكون IP مراكز البيانات في القوائم السوداء، لأنها تتلقى حركة مرور آلية بشكل جماعي، بينما تنتمي IP السكنية إلى مزودي خدمة حقيقيين ومستخدمين عاديين. بالنسبة للتجريف في Wildberries وOzon أو Avito، فإن هذا أمر حاسم: بدون IP نظيف، يتم حظر الطلب بناءً على هذه الميزة فقط، دون التحقق من TLS.

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

لمراقبة الأسعار في الأسواق حيث تكون السرعة وحجم الطلبات مهمين، غالبًا ما تستخدم بروكسي مراكز البيانات مع تمويه TLS عبر curl_cffi — وهذا أرخص من السكنية وفعال بما فيه الكفاية إذا لم تكن نظام مكافحة الروبوتات في الموقع عدوانيًا جدًا. وللمهام التي يتحقق فيها الموقع بنشاط من الشبكات المحمولة (مثل تجريف الإصدارات المحمولة من التطبيقات عبر API)، يتم استخدام بروكسي محمولة — حيث توفر مستوى إضافيًا من الثقة بفضل سمعة الشبكات المشغلة.

قائمة التحقق من إعداد البرنامج بدون كشف

اجمع التحقق في عملية واحدة قبل تشغيل البرنامج في الإنتاج:

  1. قم بقياس تجزئة JA4 للبرنامج الخاص بك عبر tls.peet.ws وقارنها مع المتصفح الحقيقي من نفس الإصدار.
  2. استخدم مكتبة تدعم انتحال TLS: curl_cffi (Python)، tls-client (Go)، CycleTLS (Node.js).
  3. قم بمزامنة إصدار ملف تعريف TLS (impersonate) مع الإصدار في User-Agent.
  4. تحقق من ترتيب رؤوس HTTP — يجب أن يتطابق مع المتصفح الحقيقي، وليس مع الترتيب الأبجدي.
  5. قم بتوصيل IP سكني أو محمول نظيف يتناسب مع جغرافيا مهمتك.
  6. قم بضبط تدوير IP بشكل منفصل عن ملف تعريف TLS — لا تربط بينهما بشكل صارم.
  7. قم بتحديث ملف تعريف TLS بانتظام عند إصدار إصدارات جديدة من Chrome — تدخل التوقيعات القديمة في قواعد بيانات مكافحة الروبوتات أسرع مما يبدو.
  8. للسيناريوهات التي تتضمن تحقق JS (تحدي Cloudflare)، استخدم متصفح بدون واجهة مع تصحيحات stealth بدلاً من عميل HTTP النظيف.

مقارنة المكتبات والأدوات

الأداة بصمة TLS للمتصفح السرعة متى تستخدم
requests / httpx لا، يعطي البرنامج عالية مواقع بدون كشف TLS، واجهات برمجة التطبيقات الداخلية
curl_cffi نعم، نسخة مطابقة عالية أسواق، مكافحة الروبوتات Cloudflare/Akamai
tls-client (Go) نعم عالية جدًا حمل عالي، تجريف جماعي
Playwright / Puppeteer نعم، محرك حقيقي منخفضة تقديم JS، تحدي Cloudflare، SPA معقدة
Scrapy (قياسي) لا عالية مواقع بدون حماية صارمة ضد الروبوتات

الخاتمة

بصمة TLS هي طبقة من الحماية التي يتجاهلها العديد من البرامج تمامًا، حيث يضيعون الموارد في البحث عن IP ووكيل مستخدم مثاليين، لكنهم ينسون أن هيكل عملية المصافحة TLS نفسها يكشف عن الأتمتة قبل أن ينظر الخادم إلى الرؤوس. الحل هو استخدام المكتبات التي تدعم انتحال TLS (curl_cffi، tls-client)، ومزامنة إصدار الملف الشخصي مع وكيل المستخدم والتحقق من تجزئة JA4 النهائية قبل التشغيل على نطاق واسع.

لا يزال IP عاملًا مهمًا — بدون عنوان نظيف، حتى بصمة TLS المثالية لن تساعد في تجاوز الحظر بناءً على سمعة الشبكة. بالنسبة لتجريف الأسواق ومراقبة الأسعار، من الحكمة دمج إعداد TLS الصحيح مع بروكسي سكنية — هذه المجموعة تغلق كلا طبقتي الكشف وتقلل بشكل ملحوظ من نسبة الحظر في جلسات التجريف الطويلة.