كيف يعمل نظام نقاط reCAPTCHA v3: دليل تقني متعمق لعام 2026

يواجه مهندسو الأتمتة وفرق ضمان الجودة حاجزًا غير مرئي عند محاولة اختبار تدفقات المستخدمين على المواقع المحمية بـ reCAPTCHA v3. على عكس الإصدارات السابقة التي تعرض تحديًا مرئيًا، يعمل v3 بصمت في الخلفية — يُرجع درجة مخاطر مستمرة من 0.0 إلى 1.0 لكل إجراء، وتقرر المواقع ما إذا كانت ستسمح بالطلب أو تتحداه أو ترفضه بناءً على هذه الدرجة. فهم كيف يعمل نظام نقاط reCAPTCHA v3 أمر بالغ الأهمية لأي شخص يبني أتمتة شرعية، من اختبارات QA إلى مراقبة الأسعار وأبحاث الأمان.

في هذا الدليل التقني المتعمق، سنفكك المحرك الخفي للتقييم خطوة بخطوة: من نموذج التسجيل ونطاقات الدرجات، إلى الإشارات التي يدمجها Google، إلى سبب فشل بروكسيات مراكز البيانات بشكل منهجي، وأخيرًا كيفية بناء أتمتة شرعية تتجاوز الفحص باستخدام بروكسيات سكنية حقيقية من مواقع ProxyHat.

كيف يعمل نظام نقاط reCAPTCHA v3: المحرك الخفي للتقييم

reCAPTCHA v3 هو جيل مختلف تمامًا عن سابقيه. لا يعرض صورًا لإشارات المرور أو أرصفة الشوارع. بدلاً من ذلك، يستدعي grecaptcha.execute() في الخلفية، ويُرجع رمزًا مميزًا (token) يُرسل إلى خادمك للتحقق عبر siteverify. يستجيب Google بدرجة مخاطر من 0.0 (خطر مرتفع) إلى 1.0 (خطر منخفض)، مع تقسيم النطاق إلى 11 درجة محددة: 0.0، 0.1، 0.2، 0.3، 0.4، 0.5، 0.6، 0.7، 0.8، 0.9، و1.0.

تستخدم معظم المواقع عتبات مماثلة لما يلي:

• درجة أقل من 0.3 → رفض أو حظر الطلب (block)
• درجة من 0.3 إلى 0.6 → عرض تحدٍ إضافي مثل reCAPTCHA v2 أو التحقق بخطوتين (challenge)
• درجة أعلى من 0.6 → السماح بالطلب (allow)

هذه العتبات ليست موحدة — يحدد كل موقع عتباته الخاصة. بعض المواقع المالية تعيين عتبة السماح عند 0.8 أو أعلى، بينما قد تقبل مواقع أقل حساسية درجة 0.5. وفقًا لـ توثيق Google الرسمي لـ reCAPTCHA v3، يجب على المطورين اتخاذ إجراءات بناءً على الدرجة بدلاً من الاعتماد على قيمة ثابتة.

النقطة الحرجة: الدرجة تُرجع لكل إجراء (action)، وليس لكل جلسة. الإجراء هو سلسلة تحددها عند استدعاء grecaptcha.execute() — مثل login أو signup أو checkout. يجب أن يتطابق هذا الإجراء مع ما يتوقعه الخادم، وإلا يُرفض الرمز المميز. هذا التصميم يمنع إعادة استخدام الرمز المميز عبر إجراءات مختلفة.

الإشارات التي يدمجها Google في تقييم المخاطر

لا يعتمد reCAPTCHA v3 على إشارة واحدة. بدلاً من ذلك، يدمج Google مئات الإشارات في نموذج تعلم آلي يُنتج الدرجة النهائية. هذه الإشارات تنقسم إلى عدة فئات رئيسية:

التتبع السلوكي وتفاعل الصفحة

يقيس reCAPTCHA v3 توقيتات تفاعل المستخدم مع الصفحة: حركة الماوس، التمرير (scroll)، النقرات، وضغطات المفاتيح. النمط المثالي يشمل حركة ماوس منحنية بأوقات استجابة تتراوح بين 100ms و300ms بين الأحداث. الأتمتة التي تملأ حقولًا في أقل من 50ms أو تتحرك في خطوط مستقيمة مثالية تُرصد فورًا.

تشمل بيانات التفاعل أيضًا: مدة البقاء على الصفحة، عدد العناصر التي تم التفاعل معها، توقيت تحميل الصفحة مقابل وقت الإرسال، وتسلسل الأحداث. المستخدم الحقيقي يقرأ الصفحة، يمرر المؤشر، يتحرك بين الحقول — بينما السكربت ينتقل مباشرة من التحميل إلى الإرسال في أقل من ثانية واحدة.

ملف تعريف المتصفح والبصمات

يجمع Google بصمات المتصفح عبر JavaScript APIs. تشمل هذه الإشارات:

• Canvas fingerprinting: رسم نص على عنصر <canvas> وتحويله إلى بصمة فريدة تعتمد على بطاقة الرسومات ونظام التشغيل والمتصفح
• WebGL rendering: معلومات عن بطاقة الرسومات من خلال WEBGL_debug_renderer_info
• AudioContext fingerprint: بصمة تعتمد على معالجة الصوت في المتصفح
• قائمة الخطوط المثبتة: عدد وأنواع الخطوط المتاحة
• User-Agent وAccept-Language headers: يجب أن تتطابق مع بعضها البعض منطقيًا

بالإضافة إلى ذلك، يستخدم Google بصمة JA3/JA4 TLS — وهي بصمة تعتمد على ترتيب خوارزميات التشفير في اتصال TLS. متصفح Chrome حقيقي يُرسل cipher suites بترتيب محدد يختلف عن ما ترسله مكتبات HTTP مثل requests أو axios. على سبيل المثال، يبدأ Chrome بـ TLS_AES_128_GCM_SHA256 (0x1301) كأول خيار في TLS 1.3، بينما تستخدم مكتبات Python ترتيبًا مختلفًا. هذا يعني أن حتى مع User-Agent صحيح، يمكن كشف الأتمتة من خلال بصمة TLS وحدها.

رسم ملفات تعريف الارتباط من Google (Cookie Graph)

هذه واحدة من أقوى الإشارات وأقلها فهمًا. إذا كان المتصفح يحمل ملفات تعريف ارتباط من Google مثل SID، HSID، SSID، وNID — وهي ملفات تعريف الارتباط المرتبطة بحساب Google أو نشاط التصفح السابق — فإنها تشير إلى أن المستخدم لديه تاريخ تصفح حقيقي. المتصفح المنشأ حديثًا بدون أي ملفات تعريف ارتباط من Google يبدأ بدرجة أقل تلقائيًا، غالبًا في حدود 0.4 إلى 0.5.

سمعة عنوان IP

هنا تأتي النقطة الأكثر أهمية لمستخدمي البروكسي. يصنف Google عناوين IP إلى فئات سمعة: موثوقة (سكنية من مزودي خدمة معروفين)، مشكوك فيها (مراكز بيانات)، وضارة (معروفة بالهجمات السابقة). هذا التصنيف يأتي من سنوات من البيانات عبر منتجات Google المختلفة — Search، Gmail، YouTube، وAdSense. عنوان IP واحد يمكن أن يُساهم بما يصل إلى 0.4 درجة في النموذج النهائي.

لماذا تدمر بروكسيات مراكز البيانات درجة reCAPTCHA v3

هذه هي النقطة التي يفشل فيها معظم مهندسي الأتمتة. حتى لو بنيت أتمتة مثالية — متصفح حقيقي، تفاعل بشري واقعي، بصمات متصفح صحيحة، وملفات تعريف ارتباط من Google — فإن استخدام عنوان IP من مركز بيانات سيؤدي إلى انهيار درجة reCAPTCHA v3 إلى أقل من 0.3 في معظم الحالات.

السبب بسيط: Google يعرف نطاقات IP الخاصة بمراكز البيانات. مزودو الخدمات السحابية مثل AWS وGoogle Cloud وAzure وDigitalOcean يملكون نطاقات ASN محددة. عندما يرى Google طلبًا من عنوان IP في نطاق AS14618 (Amazon) أو AS15169 (Google Cloud)، يُعامل الطلب تلقائيًا كمشكوك فيه — بغض النظر عن سلوك المتصفح.

هذا هو السبب الأساسي الذي يجعل البروكسيانات السكنية ضرورية. عنوان IP سكني يأتي من مزود خدمة إنترنت منزلي (ISP) مثل Comcast أو AT&T أو Deutsche Telekom، ويحمل سمعة طبيعية تراكمت من استخدام إنساني حقيقي. البروكسي السكني لا يخدع Google — بل يُمثل مصدرًا شرعيًا للطلبات من مستخدمين حقيقيين.

المقارنة التالية توضح الفرق بين أنواع البروكسيانات وتأثيرها على درجة reCAPTCHA v3:

نوع البروكسي	مصدر IP	درجة reCAPTCHA v3 المتوقعة	الاستخدام المناسب
سكني (Residential)	ISP منزلي حقيقي	0.7 - 0.9	اختبارات QA، مراقبة الأسعار، أبحاث SERP
متنقل (Mobile)	شبكة خلوية (4G/5G)	0.8 - 0.9	أتمتة التطبيقات المحمولة، اختبارات الأمان
مركز بيانات (Datacenter)	خادم سحابي	0.1 - 0.3	مهام لا تتطلب تجاوز reCAPTCHA
بدون بروكسي (IP مباشر)	ISP المستخدم	0.6 - 0.9	الاستخدام الشخصي فقط

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

التحقق من الرمز المميز على جانب الخادم

عندما يُرجع grecaptcha.execute() رمزًا مميزًا، يجب إرساله إلى خادمك ثم التحقق منه عبر Google. يتم ذلك بإرسال طلب POST إلى نقطة نهاية siteverify مع المفتاح السري (secret key) والرمز المميز.

استجابة Google تحتوي على عدة حقول مهمة:

• success: true/false — هل الرمز صالح؟
• score: الدرجة من 0.0 إلى 1.0
• action: الإجراء المرتبط بالرمز — يجب أن يتطابق مع ما تتوقعه
• hostname: اسم المضيف الذي تم إنشاء الرمز منه — يجب أن يتطابق مع نطاقك
• error-codes: قائمة بأكواد الأخطاء إن وجدت

الخطأ الأكثر شيوعًا هو عدم التحقق من تطابق action وhostname. إذا تم إنشاء الرمز المميز بإجراء login ولكن خادمك يتوقع signup، يجب رفض الطلب حتى لو كانت الدرجة عالية. وفقًا لـ توثيق siteverify من Google، التحقق من الإجراء واسم المضيف هو مسؤولية المطور وليس Google.

مثال على التحقق الخادمي في Python:

import requests

def verify_recaptcha(token, expected_action, expected_hostname, secret_key):
    resp = requests.post(
        "https://www.google.com/recaptcha/api/siteverify",
        data={
            "secret": secret_key,
            "response": token
        }
    )
    result = resp.json()
    
    if not result["success"]:
        return False, "Token invalid"
    
    if result["action"] != expected_action:
        return False, f"Action mismatch: {result['action']} != {expected_action}"
    
    if result["hostname"] != expected_hostname:
        return False, f"Hostname mismatch: {result['hostname']} != {expected_hostname}"
    
    if result["score"] < 0.3:
        return False, f"Score too low: {result['score']}"
    
    return True, f"Passed with score: {result['score']}"

تنفيذ عملي: تجاوز فحص reCAPTCHA v3 بشكل شرعي

الآن نصل إلى الجزء العملي. الهدف هو بناء أتمتة شرعية — اختبارات QA، أبحاث أمان مرخصة، أو مراقبة أسعار — تتجاوز فحص reCAPTCHA v3 بدرجة أعلى من العتبة. يتطلب هذا ثلاثة مكونات متكاملة: بروكسي سكني حقيقي، متصفح حقيقي (وليس مكتبة HTTP)، وتفاعل بشري واقعي.

سنستخدم بروكسيانات ProxyHat السكنية مع Playwright في Python. البروكسي السكني يضمن أن عنوان IP يحمل سمعة طبيعية، والمتصفح الحقيقي يوفر بصمات TLS وJavaScript صحيحة (بما في ذلك JA3/JA4)، والتفاعل البشري المحاكى يبني سلوكًا واقعيًا.

from playwright.sync_api import sync_playwright
import requests
import time
import random

# ProxyHat residential proxy with US geo-targeting
PROXY_CONFIG = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-country-US",
    "password": "pass"
}

SITE_KEY = "your-recaptcha-site-key"
SECRET_KEY = "your-recaptcha-secret-key"
TARGET_URL = "https://example.com/login"

def human_delay(min_ms=300, max_ms=800):
    time.sleep(random.uniform(min_ms, max_ms) / 1000)

def human_mouse_move(page, x, y):
    steps = random.randint(15, 30)
    page.mouse.move(x, y, steps=steps)
    human_delay(100, 300)

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy=PROXY_CONFIG,
        headless=False,  # Headed mode for better fingerprint
        args=["--disable-blink-features=AutomationControlled"]
    )
    
    context = browser.new_context(
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                   "AppleWebKit/537.36 (KHTML, like Gecko) "
                   "Chrome/120.0.0.0 Safari/537.36",
        viewport={"width": 1920, "height": 1080},
        locale="en-US"
    )
    
    page = context.new_page()
    
    # Step 1: Navigate and wait for page to settle
    page.goto(TARGET_URL, wait_until="networkidle")
    human_delay(1500, 2500)
    
    # Step 2: Simulate human browsing behavior
    human_mouse_move(page, 400, 300)
    human_mouse_move(page, 600, 450)
    human_mouse_move(page, 350, 500)
    page.mouse.wheel(0, 100)
    human_delay(500, 1000)
    
    # Step 3: Fill form with human-like typing delays
    page.fill("#email", "test@example.com", delay=50)
    human_delay(300, 600)
    page.fill("#password", "securepass123", delay=50)
    human_delay(500, 1000)
    
    # Step 4: Execute reCAPTCHA v3
    token = page.evaluate(f"""
        async () => {{
            await new Promise(r => grecaptcha.ready(r));
            return await grecaptcha.execute('{SITE_KEY}', 
                {{action: 'login'}});
        }}
    """)
    
    # Step 5: Verify token server-side
    resp = requests.post(
        "https://www.google.com/recaptcha/api/siteverify",
        data={
            "secret": SECRET_KEY,
            "response": token
        }
    )
    result = resp.json()
    
    print(f"Score: {result['score']}")
    print(f"Action: {result['action']}")
    print(f"Hostname: {result['hostname']}")
    
    # Verify action and hostname match
    if (result["success"] and 
        result["action"] == "login" and 
        result["score"] > 0.3):
        print("PASSED - Proceed with automation")
    else:
        print("FAILED - Score below threshold")
    
    browser.close()

النقاط الرئيسية في هذا المثال:

• البروكسي السكني: استخدام gate.proxyhat.com:8080 مع user-country-US يضمن عنوان IP سكني من الولايات المتحدة
• المتصفح الحقيقي: Playwright مع Chromium يوفر بصمة TLS وJavaScript صحيحة (JA3/JA4)
• الوضع المرئي (headed): headless=False يوفر بصمة متصفح أكثر واقعية لأن المتصفح headless يكشف نفسه عبر navigator.webdriver
• التأخير البشري: تأخيرات عشوائية بين 100ms و2500ms تحاكي التوقيت البشري الطبيعي
• التحقق من الإجراء: التحقق من تطابق action وhostname على الخادم قبل المتابعة

يمكنك أيضًا استخدام SOCKS5 إذا كان سيناريو الاختبار يتطلب ذلك:

# SOCKS5 proxy configuration
PROXY_CONFIG = {
    "server": "socks5://gate.proxyhat.com:1080",
    "username": "user-country-US",
    "password": "pass"
}

للاطلاع على المزيد من التفاصيل حول الإعداد والخيارات المتقدمة، راجع توثيق ProxyHat الرسمي.

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

1. استخدام مكتبات HTTP بدلاً من متصفح حقيقي

إذا استخدمت requests أو axios أو fetch لتحميل الصفحة، فإن بصمة TLS (JA3/JA4) تكشف الأتمتة فورًا. مكتبات Python requests ترسل cipher suites بترتيب مختلف عن Chrome، وهذا يكفي لخفض الدرجة. الحل: استخدم دائمًا متصفحًا حقيقيًا مثل Playwright أو Selenium مع تعطيل إشارات الأتمتة.

2. الوضع بلا رأس (Headless) بدون تعديلات

المتصفح في الوضع headless يكشف نفسه من خلال عدة إشارات: navigator.webdriver يكون true، وNotification.permission يختلف عن المتصفح العادي، وقائمة الإضافات تكون فارغة. استخدم headless=False أو مكتبات مثل playwright-stealth لتعديل هذه الإشارات.

3. التفاعل السريع جدًا

ملء نموذج في 50ms غير بشري. المستخدم الحقيقي يستغرق 200ms على الأقل لكل حقل، ويتوقف بين الحقول. أضف تأخيرات عشوائية بين 200ms و1000ms بين الإجراءات، وتأكد من أن حركة الماوس ليست خطية مثالية.

4. عدم بناء ملفات تعريف الارتباط

الانتقال مباشرة إلى صفحة الدخول بدون زيارة الصفحة الرئيسية أولاً يبدو مشبوهًا. قم بزيارة الصفحة الرئيسية، انتظر ثانيتين، ثم انتقل إلى صفحة الدخول. هذا يبني ملفات تعريف ارتباط أساسية ويُنشئ تاريخ تصفح واقعي.

5. تدوير البروكسي بشكل مفرط

تغيير عنوان IP بين كل طلب يثير الشك. استخدم جلسات لاصقة (sticky sessions) مع user-session-abc123 للحفاظ على نفس IP خلال الجلسة. هذا أكثر واقعية — المستخدم الحقيقي لا يغير موقعه الجغرافي بين كل نقرة.

# Sticky session - same IP for entire session
PROXY_CONFIG = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-country-US-session-abc123",
    "password": "pass"
}

6. تجاهل درجة 0.3 الحرجة

درجة reCAPTCHA v3 عند 0.3 هي الحد الفاصل بين الرفض والتحدي. إذا حصلت على درجة 0.3 باستمرار، فأنت على الحافة — أي إشارة سلبية إضافية ستدفعك إلى أقل من 0.3. الهدف يجب أن يكون 0.7 أو أعلى لضمان هامش آمن. راجع سجلاتك بانتظام وتتبع توزيع الدرجات عبر الوقت.

متى يكون هذا الاستخدام مناسبًا

التقنيات الموصوفة هنا مخصصة للاستخدامات الشرعية فقط. إليك متى يكون استخدامها مناسبًا:

• اختبارات QA المؤتمتة: التحقق من أن تدفقات المستخدمين تعمل بشكل صحيح على مواقعك المحمية بـ reCAPTCHA
• أبحاث الأمان المرخصة: اختبار اختراق مع إذن صريح من المالك وفقًا لمعايير مثل دليل OWASP لاختبار أمان الويب
• أتمتة إمكانية الوصول: اختبار توافق المواقع مع قارئات الشاشة وأدوات المساعدة
• مراقبة الأسعار وأبحاث SERP: جمع بيانات عامة من مواقع التجارة الإلكترونية ومحركات البحث — راجع حالة استخدام تتبع SERP

تحذير قانوني: استخدام هذه التقنيات للاحتيال، أو إنشاء حسابات وهمية، أو تجاوز إجراءات الأمان دون إذن قد ينتهك قانون الاحتيال وإساءة استخدام الكمبيوتر (CFAA) في الولايات المتحدة، ولوائح حماية البيانات العامة (GDPR) في الاتحاد الأوروبي. راجع دائمًا شروط الخدمة للموقع المستهدف واحصل على إذن صريح قبل أي اختبار. لمزيد من المعلومات حول المواقع المتاحة عبر شبكتنا، راجع قائمة مواقع ProxyHat.

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

• reCAPTCHA v3 يُرجع درجة مخاطر مستمرة من 0.0 إلى 1.0 مقسمة إلى 11 درجة محددة، مع عتبة رفض عند 0.3
• يدمج Google مئات الإشارات: السلوك، بصمات المتصفح، ملفات تعريف الارتباط، بصمة TLS (JA3/JA4)، وسمعة IP
• عناوين IP من مراكز البيانات تُنهي الدرجة إلى أقل من 0.3 بغض النظر عن سلوك المتصفح
• البروكسي السكني + متصفح حقيقي + تفاعل بشري = درجة 0.7 أو أعلى
• التحقق من تطابق action وhostname على الخادم أمر بالغ الأهمية للأمان
• الاستخدام مقتصر على الاختبارات الشرعية والأتمتة المرخصة فقط — راجع شروط الخدمة دائمًا

فهم كيف يعمل نظام نقاط reCAPTCHA v3 هو الخطوة الأولى نحو بناء أتمتة موثوقة. بالاقتران مع بروكسيانات ProxyHat السكنية ومتصفح حقيقي، يمكن لفرق QA وأبحاث الأمان تجاوز الفحص بشكل شرعي وموثوق. ابدأ بفترة تجريبية اليوم واختبر الفرق بنفسك.