الاستطلاع الدوري أم رد النداء لاستلام نتائج CaptchaAI

القاعدة العملية بسيطة: إن كان لديك خادم عام يعمل بالفعل، فاعتمد رد النداء ليصلك الرمز المحلول لحظة جهوزه؛ وإن كنت تشغّل سكربتاً محلياً أو دالة serverless بلا عنوان عام، فإن الاستطلاع الدوري أبسط وأسرع في الإعداد. يمنحك CaptchaAI الأسلوبين معاً لاستلام نتائج CAPTCHA، وكلاهما يعمل مع جميع الأنواع المدعومة. الفارق الحقيقي بينهما ليس في دقة الحل، بل في شكل تطبيقك والبنية التي تملكها بالفعل.

يتوقّف القرار عملياً على ثلاثة عوامل لا أكثر:

• هل تملك خادماً عاماً يستطيع CaptchaAI الوصول إليه من الإنترنت؟
• كم عدد مهام CAPTCHA التي تعالجها في الساعة؟
• ما مدى حساسية تطبيقك للكمون بين لحظة الحل ولحظة استلام الرمز؟

مقارنة سريعة بين الأسلوبين

قبل الدخول في الشيفرة، إليك صورة مختصرة تلخّص الفروق العملية التي ستحسم اختيارك:

القاعدة الآمنة عند التردد: ابدأ بالاستطلاع الدوري لأنه يعمل في كل بيئة تقريباً، ويمكنك دائماً الترقية إلى رد النداء لاحقاً من دون المساس بمنطق الحل نفسه.

كيف تختار الأسلوب المناسب لمشروعك

تخيّل فريقاً صغيراً في القاهرة أو الرياض يشغّل أدوات جمع بيانات على أجهزة محلية خلف شبكة الشركة؛ هنا يصبح الاستطلاع الدوري الخيار الطبيعي لأنه لا يحتاج إلى عنوان عام. في المقابل، متجر إلكتروني على خادم SaaS متاح على الإنترنت يستفيد من رد النداء ليضمّ النتيجة مباشرةً إلى قائمة انتظار المعالجة لديه.

اختر الاستطلاع الدوري عندما:

• تشغّل سكربتات محلية أو أدوات CLI
• تبني نموذجاً أولياً أو تجري اختباراً سريعاً
• تعمل داخل شبكة مغلقة بلا نقطة نهاية عامة
• تعالج أقل من 100 مهمة CAPTCHA في الساعة
• تعتمد على دوال serverless مثل Lambda أو Cloud Functions

اختر رد النداء عندما:

• تتجاوز 100 مهمة CAPTCHA في الساعة
• تشغّل تطبيق ويب على خادم متاح لديك بالفعل
• تبني نظاماً غير متزامن أو شبه لحظي
• تريد تقليص عدد استدعاءات API
• تملك مخزن حالة أو قائمة انتظار يستقبل النتيجة

الاستطلاع الدوري: كيف يعمل

استعلم عن نقطة النهاية res.php كل خمس ثوانٍ حتى تصبح النتيجة جاهزة. هذا هو النمط الافتراضي، وهو كل ما تحتاجه في معظم السكربتات:

import requests
import time

API_KEY = "YOUR_API_KEY"

# Submit
resp = requests.get("https://ocr.captchaai.com/in.php", params={
    "key": API_KEY,
    "method": "userrecaptcha",
    "googlekey": "SITE_KEY",
    "pageurl": "https://example.com"
})
task_id = resp.text.split("|")[1]

# Poll
while True:
    time.sleep(5)
    result = requests.get("https://ocr.captchaai.com/res.php", params={
        "key": API_KEY,
        "action": "get",
        "id": task_id
    })
    if result.text == "CAPCHA_NOT_READY":
        continue
    if result.text.startswith("OK|"):
        token = result.text.split("|")[1]
        break

الفكرة مباشرة: أرسل المهمة، خذ معرّفها، ثم كرّر الاستعلام عن res.php حتى تتحول الاستجابة من CAPCHA_NOT_READY إلى رمز جاهز يبدأ بـ OK|. لا بنية تحتية ولا إعداد مسبق.

مزايا الاستطلاع الدوري

• بسيط في التنفيذ ولا يحتاج إلى إعداد مسبق
• لا يستلزم أي بنية تحتية للخادم
• يعمل في أي بيئة تقريباً: السكربتات المحلية، وأدوات CLI، وبيئات serverless
• لا يتطلب فتح نقطة نهاية عامة أو استقبال طلبات خارجية

حدود الاستطلاع الدوري

• يولّد طلبات إضافية أثناء الانتظار من دون قيمة فعلية
• يضيف تأخيراً بسيطاً، إذ لا تعرف بجهوزية النتيجة إلا عند الاستطلاع التالي
• يرفع إجمالي عدد استدعاءات API

رد النداء عبر الـ Webhook

وفّر عنوان pingback عند إرسال المهمة، فيتولّى CaptchaAI إرسال النتيجة إلى عنوانك فور اكتمال الحل — من دون أي استعلام متكرر من طرفك:

# Submit with callback URL
resp = requests.get("https://ocr.captchaai.com/in.php", params={
    "key": API_KEY,
    "method": "userrecaptcha",
    "googlekey": "SITE_KEY",
    "pageurl": "https://example.com",
    "pingback": "https://your-server.com/captcha-callback"
})
task_id = resp.text.split("|")[1]
# No polling needed — result arrives at your callback URL

يرسل CaptchaAI طلب GET إلى عنوان رد النداء الخاص بك:

GET https://your-server.com/captcha-callback?id=TASK_ID&code=TOKEN

خادم رد النداء بلغة Python وإطار Flask

يستقبل هذا الخادم رمز الحل على المسار /captcha-callback ويخزّنه في الذاكرة، بينما يتيح المسار /get-result لبقية تطبيقك الاستعلام عن النتيجة متى شاء:

from flask import Flask, request

app = Flask(__name__)
results = {}

@app.route("/captcha-callback")
def callback():
    task_id = request.args.get("id")
    token = request.args.get("code")
    results[task_id] = token
    return "OK", 200

@app.route("/get-result/<task_id>")
def get_result(task_id):
    token = results.get(task_id)
    if token:
        return {"status": "solved", "token": token}
    return {"status": "pending"}, 202

if __name__ == "__main__":
    app.run(port=8080)

خادم رد النداء بلغة Node.js وإطار Express

المنطق نفسه في Node.js وإطار Express، مع استخدام Map بدل القاموس لتخزين النتائج مؤقتاً ريثما يطلبها تطبيقك:

const express = require("express");
const app = express();

const results = new Map();

app.get("/captcha-callback", (req, res) => {
  const { id, code } = req.query;
  results.set(id, code);
  res.send("OK");
});

app.get("/get-result/:taskId", (req, res) => {
  const token = results.get(req.params.taskId);
  if (token) {
    res.json({ status: "solved", token });
  } else {
    res.status(202).json({ status: "pending" });
  }
});

app.listen(8080);

مزايا رد النداء

• إشعار فوري لحظة اكتمال الحل
• لا طلبات استطلاع مهدرة
• كفاءة أعلى عند الأحجام الكبيرة
• أنسب للبنى غير المتزامنة

حدود رد النداء

• يحتاج إلى خادم أو نقطة نهاية عامة يمكن الوصول إليها
• يتطلب التعامل مع موثوقية الـ Webhook: إعادة المحاولة والمهلات
• بنية تحتية أكثر تعقيداً
• يستلزم ضبط الشبكة والجدار الناري

أخطاء شائعة عند الاختيار

قبل أن تعتمد أحد الأسلوبين، تجنّب هذه الأخطاء المتكررة التي تكلّف وقتاً في التصحيح:

• اعتماد رد النداء على خادم خلف جدار حماية يحجب الطلبات الواردة، فلا تصل النتيجة أبداً.
• الاكتفاء برد النداء وحده دون مسار احتياطي، فتضيع النتيجة إن تعطّل خادمك لحظة وصولها.
• ضبط فاصل استطلاع قصير جداً (أقل من ثانيتين) يرفع عدد الطلبات بلا فائدة تُذكر.
• افتراض أن رد النداء أسرع في الحل نفسه، بينما هو أسرع في استلام النتيجة فقط؛ زمن الحل واحد في الأسلوبين.

نهج هجين: رد النداء مع احتياطي الاستطلاع

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

import requests
import time

API_KEY = "YOUR_API_KEY"
CALLBACK_URL = "https://your-server.com/captcha-callback"

def solve_with_fallback(site_key, page_url):
    # Try callback first
    resp = requests.get("https://ocr.captchaai.com/in.php", params={
        "key": API_KEY,
        "method": "userrecaptcha",
        "googlekey": site_key,
        "pageurl": page_url,
        "pingback": CALLBACK_URL
    })
    task_id = resp.text.split("|")[1]

    # Wait for callback result (check your callback store)
    for _ in range(12):  # 60 seconds
        time.sleep(5)
        result = check_callback_store(task_id)
        if result:
            return result

    # Fallback to polling
    result = requests.get("https://ocr.captchaai.com/res.php", params={
        "key": API_KEY, "action": "get", "id": task_id
    })
    if result.text.startswith("OK|"):
        return result.text.split("|")[1]

    raise TimeoutError()

ينتظر هذا النمط رد النداء لمدة 60 ثانية كحدّ أقصى، فإن لم يصل يستعلم عن res.php مرة أخيرة قبل أن يرفع خطأ المهلة. بذلك تجمع سرعة رد النداء مع أمان الاستطلاع الدوري في مسار واحد.

الأسئلة الشائعة

ما الفاصل الزمني المناسب بين محاولات الاستطلاع الدوري؟

خمس ثوانٍ نقطة انطلاق متوازنة بين سرعة الاستلام وعدد الطلبات. وفي المهام الأطول، يمكنك اعتماد التراجع الأسي لتقليل الطلبات دون التضحية بالاستجابة.

هل يرفع الاستطلاع الدوري تكلفتي في CaptchaAI؟

لا. يعتمد CaptchaAI على تسعير قائم على الـ Threads المتزامنة، مع عدد غير محدود من عمليات الحل لكل Thread شهرياً، ومن دون رسوم لكل عملية حل. لذا لا تُحتسب طلبات الاستطلاع الإضافية تكلفةً منفصلة، وإن ظلّ رد النداء أخف على بنيتك.

هل يعمل رد النداء مع جميع أنواع CAPTCHA المدعومة؟

نعم، آلية pingback مستقلة عن نوع التحدي، فهي تعمل مع كل الأنواع التي يدعمها CaptchaAI — من reCAPTCHA v2/v3 وCloudflare Turnstile وChallenge وGeeTest v3 إلى الصور وBLS. يكفي إضافة معلمة pingback عند إرسال المهمة.

ماذا لو تعذّر وصول رد النداء إلى خادمي؟

قد يعيد CaptchaAI المحاولة، لكن الأضمن أن تبقي مسار الاستطلاع الدوري جاهزاً كشبكة أمان تستعلم بها عن النتيجة عبر res.php، وهو ما يفعله النهج الهجين أعلاه.

أدلة ذات صلة

• تنسيقات الاستجابة في CaptchaAI API
• إعداد مفتاح CaptchaAI API والمصادقة