استخبارات IPكيف تتحقق من زواحف ووكلاء الذكاء الاصطناعي عبر IP: DNS العكسي ونطاقات CIDR وWeb Bot Auth
كيفية التحقق من زاحف ذكاء اصطناعي عبر IP: DNS عكسي مؤكَّد أمامياً، ونطاقات CIDR المنشورة، وWeb Bot Auth (RFC 9421) لـ GPTBot وGooglebot ووكلاء الذكاء الاصطناعي.
ترى GPTBot أو ClaudeBot أو PerplexityBot في سجلاتك وعليك أن تتخذ قراراً: السماح أو تحديد المعدل أو الحظر. لكن قبل ذلك كله عليك الإجابة عن سؤال أبسط: هل هو فعلاً ذلك البوت؟ لأن ترويسة User-Agent ادعاء لا إثبات. يستطيع أي شخص تنفيذ curl -A "GPTBot/1.3" https://your-site.com وستسجل سجلاتك بإخلاص "GPTBot".
وهذا ليس نظرياً. فقد وجد فريق Satori في HUMAN Security أن 5.7% من كل الحركة التي تدّعي أنها زاحف ذكاء اصطناعي معروف كانت منتحلة، وبلغت 7.7% في بعض الأيام (نحو مليوني طلب يومياً)، مع انتحال وكيل ChatGPT-User في نحو طلب واحد من كل ستة. يغطي هذا الدليل الطرق الثلاث الحقيقية للتحقق من زاحف على طبقتي IP والتشفير (DNS عكسي مؤكَّد أمامياً، وقوائم سماح CIDR التي ينشرها المشغّل، وWeb Bot Auth)، إضافة إلى أوجه القصور التي تعثر فيها أغلب الأدلة الأخرى.
لماذا لا يثبت User-Agent بقيمة "GPTBot" شيئاً
User-Agent بيانات وصفية يبلغ عنها العميل بنفسه. لا مصادقة فيه، ولا توقيع، ولا شيء يستطيع الخادم الأصلي فحصه. والتحقق من زاحف يعني ربط الطلب ببنية تحتية أو مفتاح يتحكم فيه المشغّل فعلاً. وهناك ثلاثة أنظمة بالضبط تفعل ذلك:
- DNS عكسي مؤكَّد أمامياً (FCrDNS): أثبت أن العنوان يُحل من نطاق المشغّل وإليه.
- قوائم سماح CIDR المنشورة: طابق العنوان مع النطاقات التي ينشرها المشغّل.
- Web Bot Auth (RFC 9421): تحقق من توقيع تشفيري على الطلب نفسه.
كل ما يلي يدور حول تنفيذ هذه الطرق بشكل صحيح، ومعرفة ما تستطيع كل منها إثباته وما لا تستطيع.
رهانات 2026: البوتات هي غالبية الويب
لم يعد التحقق من الزواحف تخصصاً ضيقاً في SEO منذ أصبحت الحركة الآلية معظم الإنترنت. فقد وجد تقرير Imperva للبوتات الضارة 2026 أن الحركة الآلية شكّلت 53% من حركة الويب التي رصدها في 2025، وأن البوتات الضارة وحدها شكّلت 40%. وحين تكون معظم الطلبات آلية وتواصل زواحف الذكاء الاصطناعي نموها في الحجم، يصبح "هل هذا البوت حقيقي؟" سؤالاً عند نقاط تسجيل الدخول والتسجيل والدفع، لا في robots.txt فحسب. وعند الدفع صار سؤال احتيال أيضاً: راجع كيف توقف احتيال وكلاء التسوق بالذكاء الاصطناعي دون حظر مبيعات الوكلاء الحقيقية. وللاطلاع على أي إشارة IP تجيب عن أي سؤال بوت، من نطاقات الزواحف إلى علامات الماسحات، راجع محورنا عن اكتشاف البوتات عبر IP.
الطريقة 1: DNS عكسي مؤكَّد أمامياً، منفَّذ بشكل صحيح
FCrDNS هي الطريقة المعتمدة التي توثّقها Google للتحقق من Googlebot. أربع خطوات:
# 1. Reverse-DNS the source IP → hostname
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com
# 2. Confirm the suffix matches the operator
# Googlebot: googlebot.com, google.com, or googleusercontent.com
# Bingbot: *.search.msn.com
# 3. Forward-DNS that hostname → IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1
# 4. Confirm it matches the original IP. Match = verified.
لماذا الخطوة الأمامية جوهرية: يتحكم المهاجم في سجل PTR العكسي لعنوانه، فيستطيع توجيه 1.2.3.4 إلى crawl-fake.googlebot.com. أما ما لا يستطيعه فهو تزوير DNS الأمامي الموثوق لـ googlebot.com ليجعل ذلك الاسم يُحل إلى 1.2.3.4. والفحص الذي يطابق سلسلة سجل PTR مع "googlebot.com" فحسب (وهو ما يقترحه عدد مدهش من الدروس) قابل للانتحال بنفسه. التأكيد الأمامي هو لب الأمر. ولـ Google تحديداً، بأنواع زواحفها الثلاثة وملفات نطاقاتها المنفصلة، راجع دليلنا عن التحقق من Googlebot عبر IP وكشف Googlebot المزيف.
سقف الدقة الذي ينبغي التنبيه إليه: سجلات PTR اختيارية وكثيراً ما تغيب، خصوصاً لدى مزودي الذكاء الاصطناعي الأحدث. وحين لا يوجد PTR يعيد FCrDNS "غير قابل للتحقق"، وهذا ليس نجاحاً ولا فشلاً. وهنا تأتي الطريقة 2.
الطريقة 2: قوائم سماح CIDR المنشورة، لكل بوت
يتخطى معظم مزودي الذكاء الاصطناعي سجلات PTR وينشرون بدلاً منها نطاقات IP لزواحفهم بصيغة JSON. وهذا هو الفحص الأكثر عملية من الناحية التشغيلية. اسحب موجز المصدر الأولي لكل مشغّل:
- OpenAI: ملفات لكل بوت:
openai.com/gptbot.jsonوopenai.com/searchbot.jsonوopenai.com/chatgpt-user.json(وثائق زواحف OpenAI). - Google: خمسة ملفات CIDR تحت
developers.google.com/static/crawling/ipranges/. - Anthropic: تنشر ملفاً واحداً لبوتاتها،
claude.com/crawling/bots.json، مرتبطاً من صفحة المساعدة الخاصة بالزواحف. وقائمة العناوين في وثائق منصتها مخصصة لـ API لا للزواحف. - Perplexity:
perplexitybot.jsonوperplexity-user.json. - Apple iCloud Private Relay: ملف CSV للمخارج في
mask-api.icloud.com/egress-ip-ranges.csv(وثائق Apple). ملاحظة: هؤلاء بشر على مرحّل خصوصية لا بوتات. أدرجهم في قائمة السماح ولا تحظرهم.
نحمّل 19 ملف نطاقات للزواحف من 10 مشغّلين؛ وفي قائمة IP للزواحف الموثّقة كل منها، مع تاريخه وكيفية بناء قائمة السماح.
ثلاث قواعد تفصل التطبيق الصحيح عن المعطوب:
- طابق كل بوت مع ملفات مشغّله، ومع ملفه الخاص فقط حيث ينشر المشغّل ملفاً لكل بوت. يوجد
GPTBotفيgptbot.jsonلا في "نطاق ما لدى OpenAI"، ومطابقة ملف OpenAI الخطأ تخلط بين زاحف تدريب وجالب يطلقه المستخدم. تنشر Anthropic ملفاً مشتركاً واحداً لبوتاتها الثلاثة، وملفا DuckDuckGo متطابقان، لذا فالمشغّل هناك هو أدق مطابقة متاحة. تبيّن مقارنتنا بين GPTBot وOAI-SearchBot وChatGPT-User ما يفعله كل بوت من OpenAI، وما يكلّفه حظره، واستعلاماً حقيقياً من كل ملف. - طابق البادئة المنشورة بدقة، ولا تطابق ASN الاستضافة أبداً. إدراج "كل AWS" أو "كل Google Cloud" في قائمة السماح لأن بوتاً ما يعمل هناك سيمرّر كل مهاجم على السحابة نفسها.
- حدّث وفق جدول. تتغير هذه النطاقات؛ عاملها كموجز لا كثابت.
عدم تماثل المزودين: أي طريقة موجودة أصلاً
تخلط معظم الأدلة المزودين معاً. لكنهم يختلفون، في أي طريقة تحقق متاحة وفي رموز الزواحف التي يطلقها كل منهم، وهي تحمل دلالات سياسة مختلفة:
| المشغّل | FCrDNS | CIDR المنشورة | Web Bot Auth | رموز بارزة (سياسات مختلفة) |
|---|---|---|---|---|
| ✅ (المعتمد) | ✅ | ⚠️ تجريبي | Googlebot مقابل الجالبات التي يطلقها المستخدم | |
| OpenAI | ✕ (غالباً لا PTR) | ✅ لكل بوت | ناشئ | GPTBot (تدريب) · ChatGPT-User (جلب المستخدم) · OAI-SearchBot |
| Anthropic | ✕ | ✅ | ناشئ | ClaudeBot · Claude-User · Claude-SearchBot |
| Perplexity | ✕ | ✅ (متنازع عليها) | لا يوجد | PerplexityBot · Perplexity-User |
الفارق الدقيق الذي يكسر خطوط المعالجة الساذجة: الجالبات التي يوجّهها المستخدم تتصرف كزوار حقيقيين وقد تنطلق بشكل مشروع من خارج نطاقات البوتات المنشورة. حين يطلب مستخدم من مساعد فتح رابط معين، قد يأتي ذلك الجلب من بنية سحابية عامة بـ User-Agent لمتصفح عادي. لذلك قد يحظر "ليس في نطاق GPTBot" إجراء وكيل لمستخدم حقيقي. ويجب أن تختلف سياسة تحديد المعدل والحظر بحسب الرمز لا بحسب المزود.
التحقق من زواحف SEO والتحليلات: AhrefsBot وأقرانه
تتحقق طريقتا طبقة IP نفسهما من زواحف SEO والتحليلات التي يريد الناس تحديدها في سجلاتهم أكثر من غيرها: AhrefsBot، وأقرانه مثل SemrushBot وDataForSeoBot. هي ليست زواحف ذكاء اصطناعي، لكن التحقق مطابق:
- AhrefsBot قابل للتحقق عبر DNS عكسي مؤكَّد أمامياً (تُحل عناوينه إلى أسماء مضيفين تحت نطاقات Ahrefs الخاصة)، وتنشر Ahrefs نطاقات IP لزاحفها لإدراجها في قوائم السماح. نفّذ فحص FCrDNS نفسه من الطريقة 1، أو طابق مع القائمة المنشورة من الطريقة 2.
- الفخ هو نفسه الذي يوقع زواحف الذكاء الاصطناعي: لا تدرج في قائمة السماح بحسب ASN. وصول "AhrefsBot" من نطاق استضافة عشوائي لم تتحقق منه هو نمط الانتحال تماماً، إذ يستطيع أي طرف إرسال
User-Agent: AhrefsBot/7.0. تأكد من العنوان لا من السلسلة.
إذا كنت تبحث عن "عناوين IP لـ AhrefsBot" لبناء قاعدة جدار ناري، فالنسخة الدائمة هي فحص DNS عكسي مؤكَّد أمامياً مع النطاق المنشور من المشغّل، يُحدَّث وفق جدول، لا قائمة IP مكتوبة يدوياً تتعفن أول مرة يضيف فيها الزاحف سعة.
الطريقة 3: Web Bot Auth والتحقق التشفيري
الحل البنيوي للانتحال هو التوقف عن الوثوق بموقع الشبكة والتحقق من توقيع بدلاً من ذلك. في Web Bot Auth يوقّع الوكيل كل طلب بمفتاح Ed25519 باستخدام توقيعات رسائل HTTP وفق RFC 9421 (معيار مقترح، فبراير 2024). ويحمل الطلب:
Signature: قيمة التوقيعSignature-Input: المكونات المغطاة، وcreated/expires، وkeyid، وtag="web-bot-auth"Signature-Agent: اختياري، يسمّي الوكيل الموقِّع
تُكتشف المفاتيح بوصفها JWKS في /.well-known/http-message-signatures-directory (المبنية على آلية URI المعروفة في RFC 8615). والتحقق: اجلب الدليل، وطابق بصمة keyid، وتحقق من التوقيع ونافذة created/expires. وميزته على طرق IP حاسمة: فهو يصمد على العناوين المشتركة والمتدوِّرة وعناوين CGNAT، لأن الهوية تسافر مع الطلب لا مع المسار.
فحص للواقع: تجريبي وليس معياراً
كن صريحاً مع نفسك في بنيتك هنا. تُحدَّد Web Bot Auth في مسودات إنترنت لدى IETF (draft-meunier-web-bot-auth-architecture، 2 مارس 2026، بمؤلفين من Cloudflare وGoogle) تحمل النص الثابت "لم تقرّها IETF وليس لها وضع رسمي" وتنتهي صلاحيتها في 3 سبتمبر 2026. ودعم Google نفسها تجريبي صراحةً. فهي "لا توقّع كل طلب بعد" وتطلب من المشغّلين مواصلة استخدام التحقق عبر IP وDNS العكسي وUser-Agent. وعلى طبقة البنية التحتية فهي أكثر تقدماً: دمجت Cloudflare توقيعات الرسائل في برنامج البوتات الموثّقة لديها (يوليو 2025) وأضافت AWS WAF دعمها (نوفمبر 2025). الخلاصة: فضّل التوقيعات حيث توجد، لكن لا تعتمد عليها بعد.
خط القرار متعدد الطبقات (انسخه)
اجمع الطرق الثلاث في ترتيب أولوية، ثم أثرِ وصنّف. وبعد أن يُوثَّق البوت، قرر ماذا تفعل بكل زاحف ذكاء اصطناعي موثّق بالسياسة ثلاثية المستويات في ذلك الدليل:
1. Parse the claimed bot token from the User-Agent; treat it as a HINT only.
2. If a Web Bot Auth signature is present → verify against the JWKS.
PASS → verified-good (strongest; IP-independent). Done.
3. Else match source IP against the vendor's published CIDR file,
pinned to that specific token.
IN RANGE → verified-good.
4. Else run FCrDNS where a PTR record exists.
FORWARD-CONFIRMED → verified-good.
5. Enrich the IP (this is where an IP-intelligence API slots in):
ASN / owner, hosting/datacenter flag, VPN/proxy/Tor flags,
and an IP risk score.
6. Classify:
verified-good → allow
declared-but-unverified → rate-limit or challenge (NOT hard block)
undeclared automation → challenge / block by behavior + provenance
الخطوة 5 هي حيث يتموضع GeoIPHub: فحين لا يكون عنوان IP لبوت يعرّف نفسه ضمن نطاق منشور وليس له PTR، فإن مالك ASN وعلامة مركز البيانات/الاستضافة وعلامات VPN والبروكسي وTor ودرجة المخاطر هي ما يتيح لك تقييم الحالات غير الحاسمة عند تسجيل الدخول والتسجيل والدفع بدلاً من التخمين. وإذا حددت المعدل لفئة المعلَن عنها غير الموثّقة، فاعتمد بادئة المصدر لا العنوان في مصادر IPv6؛ ويشرح دليلنا عن تقييد معدل IPv6 وحظره بحسب بادئة /64 السبب.
ASN Google نفسه، Googlebot موثّق وآخر غير موثّق
عنوانان في شبكة Google نفسها يحصلان على حكمين متعاكسين للزاحف، لأن الفحص يستخدم البادئة المنشورة لا ASN. استعلمنا عن عنواني Google بتاريخ 2026-10-05 (تتغير النتائج مع تحرك النطاقات): 192.178.4.0، وهو أول عنوان في أول بادئة IPv4 في ملف نطاقات Googlebot الذي تنشره Google، و8.8.8.8، وهو Google Public DNS.
[
{
"ip": "192.178.4.0",
"asn": { "asn": 15169, "org": "GOOGLE - Google LLC", "asn_type": "hosting", "user_type": "search_engine_spider" },
"detection": { "is_hosting": true, "is_vpn": false, "is_proxy": false },
"threat": {
"is_crawler": true,
"crawler": {
"verified": true,
"name": "Googlebot",
"operator": "Google",
"category": "search_engine",
"verification_method": "ip_range_list"
}
},
"scoring": {
"fraud_score": 0,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip", "no_ptr_datacenter", "verified_crawler"]
}
},
{
"ip": "8.8.8.8",
"asn": { "asn": 15169, "org": "GOOGLE - Google LLC", "asn_type": "hosting", "user_type": "hosting" },
"detection": { "is_hosting": true, "is_vpn": false, "is_proxy": false },
"threat": {
"is_crawler": false,
"crawler": { "verified": false, "name": "none", "verification_method": "none" }
},
"scoring": {
"fraud_score": 15,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip", "no_ptr_datacenter"]
}
}
]
كلاهما في AS15169 وكلاهما استضافة، لذا ستعامل قائمة سماح مبنية على ASN العنوانين بالطريقة نفسها. والأول فقط داخل ملف Googlebot، ويبيّن threat.crawler.verification_method: "ip_range_list" أن الحكم جاء من الطريقة 2. تخفض إشارة verified_crawler قيمة fraud_score إلى 0، بينما يحتفظ 8.8.8.8 بدرجة مركز البيانات العادية 15. وتنطلق الطريقة no_ptr_datacenter في كليهما لأن سجلنا لا يحتوي PTR لهما، مع أن dig -x 192.178.4.0 الحي يعيد crawl-192-178-4-0.googlebot.com. وهذا مثال صغير وحقيقي على سبب كون فحص النطاقات هو ما ينبغي أتمتته: فهو لا يعتمد على نجاح استعلام PTR.
أوجه القصور والإيجابيات الكاذبة
هذا ما تخطئ فيه المقالات المتصدرة في الترتيب:
- خارج النطاق ≠ مزيف. أظهرت حالة Perplexity (Cloudflare، أغسطس 2025) زاحفاً يستخدم UA عاماً لمتصفح Chrome، وعناوين IP خارج نطاقه المنشور، وأرقام ASN متدوِّرة بمعدل 3-6 ملايين طلب يومياً. الوجود داخل النطاق إيجابي حقيقي؛ أما خارجه فـ غير حاسم، لا دليل على التزييف.
- الانحياز الجغرافي لـ CGNAT. وجد بحث Cloudflare في أواخر 2025 (عبر The Register) أن عناوين CGNAT خضعت لتحديد المعدل بنحو 3 أضعاف رغم إشارات بوت أقل. مئات المستخدمين يتشاركون عنوان IPv4 واحداً، متركزين في أفريقيا وآسيا. فحظر IP الساذج مشكلة إنصاف.
- iCloud Private Relay. عناوين مخرج مشتركة ومتدوِّرة تحمل بشراً حقيقيين؛ أدرجها في قائمة السماح عبر ملف CSV من Apple.
- البروكسيات السكنية. تُبطل إدراج ASN في قوائم السماح كلياً (وجد تقرير Imperva لعام 2025 أن 21% من هجمات البوتات استخدمتها)، وهذا بالضبط سبب كون اكتشاف الحركة المجهولة دون حظر العملاء الحقيقيين مشكلة سلوكية لا استعلام قائمة.
القاعدة: احتفظ بالحظر الصارم لـ السلوك مع المصدر، لا للغياب عن قائمة وحده.
البوتات الموثّقة هي GIVT والمنتحلة هي SIVT
في تصنيف مجلس تقييم الوسائط (Media Rating Council)، الزواحف المعلنة وعناوين IP المعروفة لمراكز البيانات هي حركة غير صالحة عامة (GIVT) يمكن تصفيتها بالقوائم، بينما البوتات "المتنكرة في هيئة مستخدمين مشروعين" حركة غير صالحة متطورة (SIVT) تحتاج إلى تحليل ومراجعة. والتحقق من زاحف عبر IP هو ما ينقل الطلب من الفئة الثانية إلى الأولى. القوائم الكاملة للفئات، وفئات Google التسع، وأيّها يستطيع استعلام IP رؤيته، في GIVT مقابل SIVT: فئات الحركة غير الصالحة لدى Google.
تحقق من زواحف ووكلاء الذكاء الاصطناعي مع GeoIPHub
يوفر GeoIPHub إثراء الخطوة 5 الذي تتركه شركات geo-IP العريقة خارج محتواها التعليمي: ASN ونوع الاتصال، واكتشاف مراكز البيانات/الاستضافة، وعلامات VPN / البروكسي / Tor، وعلامات الزواحف الموثّقة من 19 موجزاً رسمياً للنطاقات (بما فيها GPTBot وClaudeBot وPerplexityBot وAhrefsBot)، ودرجة مخاطر احتيال لعنوان IP. نحن لا نكتشف البروكسيات السكنية؛ فهذه تحتاج إشارات سلوكية. وهذا يتيح لك التأكد من أن بوتاً يعرّف نفسه ينطلق فعلاً من بنية المزود التحتية، وتقييم الحالات غير الحاسمة بدلاً من حظرها بفظاظة. اقرنه بطرق التحقق أعلاه والأدلة ذات الصلة عن اكتشاف الاستيلاء على الحسابات وحشو بيانات الاعتماد ومدى دقة تحديد الموقع الجغرافي لعنوان IP فعلاً.
الأسئلة الشائعة
كيف أتحقق من أن الطلب صادر فعلاً من GPTBot وليس منتحلاً؟
لا تثق بترويسة User-Agent؛ فتزويرها بالغ السهولة. طابق عنوان IP المصدر مع ملف النطاقات الخاص بكل بوت الذي تنشره OpenAI (openai.com/gptbot.json)، وقصر الفحص على GPTBot تحديداً بدلاً من نطاق عام لدى OpenAI. وإذا وُجد توقيع Web Bot Auth صالح فتحقق منه أولاً مقابل دليل مفاتيح OpenAI، لأنه مستقل عن IP. وعامل العنوان غير الموجود في النطاق المنشور على أنه غير حاسم لا على أنه مزيف مثبت، لأن حركة الوكلاء التي يوجّهها المستخدمون قد تنطلق من بنية تحتية أخرى. تعرض مقارنتنا بين GPTBot وOAI-SearchBot وChatGPT-User استعلاماً حقيقياً من كل ملف نطاقات لدى OpenAI.
ما هو DNS العكسي المؤكَّد أمامياً (FCrDNS)؟
FCrDNS فحص من أربع خطوات: استعلام DNS عكسي لعنوان IP المصدر للحصول على اسم مضيف، والتأكد من أن اسم المضيف ينتهي بنطاق المشغّل، ثم استعلام DNS أمامي لذلك الاسم، ثم التأكد من أنه يُحل إلى عنوان IP الأصلي. والخطوة الأمامية هي ما يُبطل الانتحال: يستطيع المهاجم ضبط سجل PTR مزيف على عنوانه، لكنه لا يستطيع تزوير DNS الأمامي الموثوق لدى المشغّل. والفحص الذي يكتفي بفحص سلسلة PTR قابل للانتحال.
لماذا لا أحظر زواحف الذكاء الاصطناعي ببساطة بسلسلة User-Agent؟
لأن User-Agent ادعاء يستطيع أي طرف إرساله. فقد وجدت HUMAN Security أن 5.7% من كل الحركة الموسومة كزاحف ذكاء اصطناعي معروف كانت مزيفة، وبلغت ذروتها قرابة طلب واحد من كل ستة طلبات لوكيل ChatGPT-User. الحظر بالترويسة وحدها يمرّر البوتات المنتحلة ولا يفعل شيئاً لإيقاف مشغّل يكفّ ببساطة عن إعلان هويته.
ما هو Web Bot Auth، وهل هو معيار مكتمل؟
Web Bot Auth أسلوب ناشئ يوقّع فيه البوت كل طلب HTTP تشفيرياً بمفتاح Ed25519 باستخدام توقيعات رسائل HTTP وفق RFC 9421، ويتحقق المصدر منه مقابل مفاتيح منشورة في /.well-known/http-message-signatures-directory. إن RFC 9421 نفسه معيار مقترح (Proposed Standard) منذ فبراير 2024، لكن Web Bot Auth ما زال مسودة إنترنت لدى IETF بلا وضع رسمي حتى منتصف 2026. عامله على أنه تجريبي: تحقق من التوقيعات حيث توجد، لكن أبقِ التحقق عبر IP وDNS العكسي الأساس.
أين ينشر مزودو الذكاء الاصطناعي نطاقات IP لزواحفهم؟
تنشر OpenAI ملفات JSON لكل بوت في openai.com/gptbot.json وsearchbot.json وchatgpt-user.json؛ وتنشر Google ملفات CIDR بصيغة JSON تحت developers.google.com/static/crawling/ipranges/؛ وتنشر Anthropic ملفاً واحداً لبوتاتها في claude.com/crawling/bots.json؛ وتنشر Perplexity الملفين perplexitybot.json وperplexity-user.json. اربط كل فحص بملف البوت المحدد، وطابق البادئات المنشورة بدقة بدلاً من ASN الاستضافة، وحدّث الملفات وفق جدول. وللاطلاع على ملفات OpenAI الثلاثة وأعداد بادئاتها الحالية، راجع نطاقات IP لـ GPTBot وOAI-SearchBot وChatGPT-User.
إذا لم يكن عنوان IP ضمن النطاق الذي ينشره المزود، فهل يعني ذلك أن الطلب مزيف؟
لا. العنوان داخل النطاق، أو اجتياز FCrDNS، أو التوقيع الصالح هو إيجابي حقيقي بثقة عالية، أما العنوان خارج النطاق فغير حاسم. فقد يكون حركة وكيل مشروعة يوجّهها مستخدم من بنية تحتية أخرى، أو عنواناً مشتركاً عبر CGNAT، أو مخرج iCloud Private Relay، أو مزوداً لا ينشر سجلات PTR، أو ملف نطاقات قديماً لديك. احتفظ بالحظر الصارم للإشارات السلوكية وإشارات المصدر، لا لمجرد الغياب عن قائمة.
ألن يؤثر حظر نطاقات IP للزواحف في مستخدمين حقيقيين على عناوين مشتركة؟
بلى، ولهذا لا ينبغي أن يؤدي الغياب عن قائمة IP إلى حظر صارم. فقد وجد بحث Cloudflare في أواخر 2025 أن عناوين CGNAT خضعت لتحديد المعدل بنحو ثلاثة أضعاف عناوين غير CGNAT رغم ظهور مؤشرات بوت أقل، لأن مئات إلى آلاف المستخدمين يتشاركون عنوان IPv4 واحداً، ويتركز CGNAT في أجزاء من أفريقيا وآسيا، مما يخلق انحيازاً جغرافياً. وبالمثل تحمل عناوين مخرج iCloud Private Relay بشراً حقيقيين وينبغي إدراجها في قائمة السماح باستخدام ملف CSV الذي تنشره Apple.
الفريق الذي يقف وراء واجهة GeoIPHub API
بقلم فريق GeoIPHub، وهم من يبنون واجهة GeoIPHub API لاستخبارات IP وماسحها. تُعَدّ المسودات بمساعدة الذكاء الاصطناعي ويحررها الفريق، وأمثلة API استعلامات حقيقية على واجهة API الحية ما لم تُوصف بأنها توضيحية.
أمن الشبكات
منع الاحتيال