هل SearXNG آمن؟ من يرى استعلاماتك فعلاً؟

هل SearXNG آمن؟ الإجابة المختصرة

يكون SearXNG آمناً من جهة وغير آمن من جهة أخرى. لذلك لا يمكن الإجابة عن سؤال «هل SearXNG آمن؟» قبل تحديد الشخص أو الجهة التي تريد إخفاء نشاطك عنها. SearXNG هو محرّك بحث تجميعي. يأخذ استعلامك ويرسله إلى Google وBing وDuckDuckGo وأي محرّكات أخرى فعّلتها، ثم يدمج النتائج الواردة في صفحة نتائج واحدة. ترى محرّكات البحث الـinstance. ويراك الـinstance.

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

لا يخفي أي جزء من هذا نشاط البحث عن شبكتك أنت. فما يزال مزوّد خدمة الإنترنت لديك (ISP) يرى اتصالاً بالـinstance. وما يزال محلّل DNS لديك (نظام أسماء النطاقات) يرى اسم المضيف. ضع هذا الحد في اعتبارك أثناء قراءة بقية المقال.

ما الذي يغيّره SearXNG في طلب البحث

عندما تبحث في Google مباشرةً، يحصل Google على عنوان IP الخاص بك، وملفات تعريف الارتباط، ورأس User-Agent، والصفحة التي أتيت منها، وتُربط هذه البيانات كلها بملف تعريف يستمر بعد انتهاء الجلسة. يعمل SearXNG كوسيط بينك وبين محرك البحث. وتوضح وثائقه وظيفتين أساسيتين له: «إزالة البيانات الخاصة من الطلبات المرسلة إلى خدمات البحث» و«إنشاء ملف تعريف متصفح عشوائي لكل طلب». لا تُمرَّر ملفات تعريف الارتباط الخاصة بك إلى أي محرك بحث. وتُخزَّن تفضيلاتك في متصفحك أنت، لا في حساب على الخادم.

يُرسَل رأسا استجابة مفعّلان افتراضياً، ويؤدي كل منهما وظيفة فعلية:

default_http_headers:
  X-Robots-Tag: noindex, nofollow
  Referrer-Policy: no-referrer

Referrer-Policy: no-referrer يعني أنه عند النقر على نتيجة، لا يعرف الموقع الوجهة أي صفحة بحث أرسلتك إليه، لأن المتصفح لا يرسل الرأس Referer. ويمنع X-Robots-Tag: noindex, nofollow ظهور مثيلك وصفحات النتائج فيه ضمن فهارس محركات البحث.

ما لا يغيّره SearXNG هو طلب البحث نفسه. يصل الطلب إلى المثيل كاملاً وقابلاً للقراءة، لأن TLS (أمان طبقة النقل) ينتهي عنده. وكل نقطة أدناه ناتجة عن هذه الحقيقة.

في الخادم العام، يرى المشغّل كل استعلام

توضح وثائق المشروع ذلك صراحة: «يجب على مستخدمي النسخة العامة الوثوق بمسؤول تلك النسخة»، ولا يمكنهم معرفة «ما إذا كانت طلباتهم تُسجَّل وتُجمَّع وتُرسل إلى طرف ثالث أو تُباع له». إن ادعاء عدم الاحتفاظ بالسجلات في صفحة تعريفية يظل ادعاءً. لا توجد طريقة لاختباره من الخارج، ولذلك لا يبقى أمامك إلا الثقة أو لا شيء. كما أن بعض النسخ العامة لا تزال تشغّل Searx الأصلي بدلاً من هذه النسخة المتفرعة، وهذا مهم لأن لم يتلقَّ Searx أي commit برمجي منذ 2023، والاعتماد على برنامج بحث غير مُصان يعني شيئاً إضافياً ستثق به من دون تحقق.

كما أن التسجيل هو المسار الأسهل، لأن الإعداد الافتراضي الذي يأتي مع البرنامج يضع استعلامك في URL:

server:
  method: "GET"

باستخدام GET، ينتقل الاستعلام باعتباره ?q=... في سطر الطلب. يكتب أي Reverse Proxy عادي سطر الطلب هذا في access log، ولذلك تُسجَّل الاستعلامات من دون أن يقرر أحد تسجيلها:

203.0.113.5 - - [20/Aug/2026:09:14:02 +0000] "GET /search?q=redundancy+pay+notice+period&category_general=1&language=en HTTP/1.1" 200 15321 "-" "Mozilla/5.0 (X11; Linux x86_64)"

في الخادم الخاص بك، تحقّق بنفسك:

sudo tail -n 5 /var/log/nginx/access.log

تظهر عمليات البحث هناك لأن تنسيق سجل nginx، combined، يكتب $request، أي سطر الطلب الكامل الذي يتضمن query string. ولا يملك SearXNG أي تحكم في ذلك. يؤدي تبديل الخادم إلى method: "POST" إلى نقل الاستعلام إلى نص الطلب، ولذلك يتوقف عن الظهور في access log وفي سجل المتصفح. وتوضح الوثائق بصدق أن POST له عيوب «تقيّد بشدة سهولة الاستخدام للمستخدم النهائي»، ولا سيما ما يتعلق بزر الرجوع في المتصفح. هذا تنازل تجريه عن قصد.

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

على VPS الخاص بك، ترى محركات البحث خادمك بدلاً منك

شغّل مثيلك الخاص على VPS (خادم خاص افتراضي)، ويكون التغيير واضحاً وبسيطاً. لم تعد Google تتلقى عنوان IP المنزلي مع استعلامك. بل تتلقى عنوان IP الخاص بخادمك مع الاستعلام. ولا يمكنها ربط ذلك البحث بحسابك الذي سجّلت الدخول إليه، أو بهاتفك، أو بملف الإعلانات المرتبط باتصال أسرتك. يشرح الدليل الخاص بتشغيل مثيل SearXNG الخاص بك على VPS خطوات الإعداد.

كن واضحاً بشأن ما لم يتغير. فما زالت محركات البحث ترى نص الاستعلام، ووقت إرساله، واللغة والمنطقة اللتين طلبت البحث ضمنهما، ونمط كل ما تبحث عنه على مدى أشهر، وتجمع ذلك كله تحت عنوان ثابت واحد. إذا كنت المستخدم الوحيد، يصبح ذلك العنوان سجلاً مستمراً خاصاً بشخص واحد، من دون اسم مرتبط به. ويتطلب كسر هذا التجميع أن يصل المثيل إلى محركات البحث عبر outbound proxy أو عبر Tor، ويدعم SearXNG ذلك، لكنه يتطلب عملاً منفصلاً.

ما يزال مزود خدمة الإنترنت ومحلل الأسماء والمضيف يرون

لا يتأثر أربعة مراقبين بأي من ذلك.

• يرى مزود خدمة الإنترنت لديك اتصال TLS بعنوان IP الخاص بمثيلك، ويرى اسم المضيف في حقل SNI (مؤشر اسم الخادم)، الذي يُرسل بنص واضح أثناء المصافحة. لكنه لا يرى الاستعلام.
• يرى محلل DNS لديك عملية البحث عن اسم المضيف هذا. راقب ذلك على العميل باستخدام sudo tcpdump -ni any port 53 أثناء تحميل الصفحة، وسيظهر طلب سجل A الخاص بمثيلك.
• يشغّل مزود VPS العتاد، لذلك يمكنه قراءة قرص الآلة الافتراضية وذاكرتها. لا يؤدي تشفير القرص داخل آلة افتراضية مستأجرة إلى منع ذلك، لأن النظام قيد التشغيل يحتفظ بالمفتاح.
• يرى أي شخص يملك صلاحيات root على المثيل كل شيء. ويشملك ذلك، كما يشمل أي شخص يتمكن من الدخول لاحقاً.

يؤدي الوصول إلى المثيل باعتباره خدمة onion عبر Tor إلى إغلاق النقطتين الأوليين، لأنه لا يوجد اسم مضيف عام لتحليله ولا حقل SNI لقراءته. ويغطي الدليل الإجرائي لإضافة خدمة onion من الإصدار v3 إلى VPS الإعداد، بالإضافة إلى التسريبات التي قد تربط ذلك العنوان بخلاف ذلك بعنوان IP العام لخادمك.

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

هنا يظهر سؤال VPN. تنقل VPN (الشبكة الخاصة الافتراضية) ما يراه مزود خدمة الإنترنت لديك إلى ما تراه شركة VPN. لكنها لا تغيّر شيئاً في ما يراه مشغّل المثيل، ولا في ما تراه محركات البحث، لأن المحركات تتحدث إلى خادمك وليس إليك. وتُقارَن الخدمتان على نحو صحيح في مقارنة VPS بشبكة VPN.

لماذا يحظرك SearXNG، وما الذي يعنيه الخطأ 429 فعلاً

يوجد حدثان مختلفان يوصف كل منهما بعبارة «حظرني SearXNG»، ولكل منهما إصلاح مختلف.

الأول هو أن أداة تحديد المعدل لديك ترد عليك برمز HTTP 429. هذه هي حماية SearXNG من الروبوتات، وهي معطّلة افتراضياً:

server:
  limiter: true
valkey:
  url: valkey://localhost:6379/0

اعتباراً من August 2026، تحتاج أداة تحديد المعدل إلى قاعدة بيانات Valkey، وتقرأ قواعدها من /etc/searxng/limiter.toml. اضبط server.public_instance: true أيضاً إذا كان أشخاص غير موثوقين يستخدمون الخادم فعلاً، لأن قيمته الافتراضية هي false، وهو يتحكم في السلوك المخصص للاستخدام العام.

تشغّل أداة تحديد المعدل عدة اختبارات. يعتبر http_user_agent الطلب روبوتاً إذا كان User-Agent غير مضبوط، أو إذا كان يطابق أدوات معروفة مثل curl وwget. ويعتبر http_accept الطلب روبوتاً إذا لم يتضمن رأس Accept القيمة text/html. ويضع link_token علامة الاشتباه على العميل عندما لا يجلب مطلقاً عنوان /client<token>.css الذي يحمّله المتصفح الحقيقي. عند نجاح أحد الاختبارات، يعيد SearXNG الرمز 429 ويكتب سطراً من مستوى ERROR في مسجل botdetection.

لذلك يفشل هذا الأمر، وهذا سلوك مقصود:

curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test'

يرسل curl القيمتين User-Agent: curl/8.5.0 وAccept: */*، ولذلك ينجح اختباران في الوقت نفسه. لهذا تحصل البرامج النصية ووكلاء الذكاء الاصطناعي على الخطأ 429 من مثيل يعمل بشكل طبيعي في المتصفح. يجب إصلاح هذه المشكلة قبل توجيه مهارة البحث لدى وكيل إلى مثيلك الخاص. توجد جميع الأسباب والإعدادات في دليل حدود معدل SearXNG وأخطاء 429.

توجد مشكلة شائعة أخرى في أداة تحديد المعدل. عند تشغيل SearXNG خلف Reverse Proxy، فإنه يرى عنوان الـproxy بدلاً من عنوان الزائر، ما لم يكن هذا الـproxy موثوقاً:

[botdetection]
ipv4_prefix = 32
ipv6_prefix = 48
trusted_proxies = ['127.0.0.0/8', '::1']

[botdetection.ip_limit]
link_token = false

[botdetection.ip_lists]
pass_ip = []
block_ip = []

تتضمن القائمة الافتراضية proxy يعمل على المضيف نفسه. أما proxy الموجود في شبكة Docker منفصلة، فيتصل من عنوان مثل 172.18.0.5، وهذا العنوان غير موجود في القائمة. لذلك يُحتسب جميع الزوار كعميل واحد، وقد يتسبب أول مستخدم كثيف في حظر الجميع. أضف تلك الشبكة الفرعية إلى trusted_proxies.

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

هل تساعد مشاركة instance مع أشخاص لا تعرفهم أم تضر؟

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

لكن وضع المشغّل مختلف. فوجود مجموعة كبيرة يعني أن شخصاً غريباً يحتفظ بالاستعلامات النصية الصريحة لهذه المجموعة، بما فيها استعلاماتك. أما في خادمك الخاص، فأنت تحتفظ باستعلاماتك ولا يملك أي شخص استعلامات غيرك.

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

هل نتائج SearXNG أفضل من نتائج Google؟

لا. لا يحتفظ SearXNG بفهرس خاص به، لذلك تأتي كل نتيجة في الصفحة من محرك خارجي، ويظل الحد الأقصى للجودة مرتبطاً بالمحركات التي فعّلتها. إذا عطّلت Google وBing، تنخفض الجودة في اليوم نفسه، لأن معظم تغطية الويب العامة كانت تأتي منهما.

ما يتغير هو المعالجة التي تُطبَّق على استعلامك. لا ينشئ أي مكوّن ملفاً إعلانياً من الاستعلام، ولا يعيد ترتيب النتائج بناءً على ما نقرت عليه في الأسبوع الماضي. يؤثر ذلك في الاتجاهين، لأن التخصيص ينقل أيضاً دلالات البحث المحلي. تعود عملية بحث مثل "pharmacy open now" بنتائج أضعف عبر SearXNG، لأن المحرك لا يملك إشارة عن موقع خادمك تتجاوز مركز البيانات الذي يوجد فيه. اضبط المنطقة في التفضيلات عندما تكون النتائج المحلية مهمة.

يحدد إعدادان مقدار البيانات التي تكشفها نسختك أثناء قراءة تلك النتائج. image_proxy يكون false افتراضياً، لذلك تُحمَّل الصور المصغرة مباشرةً من المواقع التي تستضيفها، وترى تلك المواقع عنوان متصفحك. يؤدي ضبط image_proxy: true إلى تمريرها عبر النسخة بدلاً من ذلك، مقابل زيادة استهلاك النطاق الترددي والذاكرة. كذلك، يأتي formats مضبوطاً على html فقط، لذلك يُرفض طلب JSON (ترميز كائنات JavaScript) بالرمز 403 Forbidden:

curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test&format=json'

إذا فعّلت json على نسخة عامة، فقد نشرت واجهة API مجانية للكشط، وهي أسرع طريقة لحظر عنوان خادمك من المحركات التي تعتمد عليها. اتركه معطلاً، أو أبقه خلف المصادقة.

نهاية حدود الخصوصية في SearXNG

يخفي SearXNG هويتك عن محركات البحث عندما تُجري الاستعلام. لكنه لا يخفي ما تفعله عن شبكتك. وتترتب على ذلك أربعة حدود.

• تظل حركة الشبكة لديك كما هي في كل مكان باستثناء مربع البحث. كل ما تفعله الآلة غير ذلك يغادر شبكتك بالطريقة نفسها تماماً.
• يُعدّ مستخدم واحد على خادم واحد معرّفاً ثابتاً لدى كل محرك. لا يتضمن المعرّف اسماً، وهذه هي الفائدة الوحيدة.
• يستطيع مشغّل أي instance قراءة الاستعلام كنص واضح. أن تكون أنت مشغّل instance هو الإصدار الوحيد من ذلك الذي يمكنك التحقق منه.
• تعيد سجلات الوصول الخاصة بك بناء السجل الذي كنت تحاول تجنّبه. اقرأها، وانتقل إلى method: "POST" إذا كنت تفضّل أن تظل فارغة.

ينقل SearXNG جهة المراقبة. لكنه لا يزيل المراقبة. حدّد جهة المراقبة التي تهمك، واختر instance المطابق لذلك، ولا تتعامل مع واجهة البحث على أنها برنامج لإخفاء الهوية.

FAQ

هل استخدام SearXNG على مثيل عام آمن؟

هو آمن من محركات البحث، لكنه غير آمن من مشغّل المثيل. يصل استعلامك إلى ذلك الخادم بنص واضح، وتذكر وثائق المشروع أنّ المستخدمين «يجب أن يثقوا بمسؤول ذلك المثيل»، ولا يمكنهم معرفة «ما إذا كانت طلباتهم تُسجَّل أو تُجمَّع أو تُرسَل إلى طرف ثالث أو تُباع له». مع الإعداد الافتراضي المضمّن في method: "GET"، يظهر الاستعلام أيضاً في سجل الوصول الخاص بالـreverse proxy باعتباره جزءاً من سطر الطلب، سواء أراد المشغّل ذلك أم لا. استخدم مثيلاً عاماً لعمليات البحث العادية عندما يكون القلق هو التتبّع الإعلاني. لا تكتب في مثيل عاماً أي شيء لا تريد تسليمه إلى مالكه.

هل يخفي SearXNG عمليات البحث عن مزوّد خدمة الإنترنت؟

يُخفى نص الاستعلام، لكن النشاط لا يُخفى. يرى مزوّد الخدمة اتصال TLS بعنوان المثيل، واسم المضيف في حقل SNI ذي النص الواضح ضمن عملية المصافحة، كما يرى محلّل DNS طلب البحث عن ذلك الاسم. لا يرى أيٌّ منهما ما بحثت عنه، لأن الاتصال مشفّر. SearXNG ليس VPN، ولا يوفّر حماية لأي شيء آخر تفعله الآلة.

لماذا يعيد SearXNG الخطأ 429؟

يصدر الخطأ 429 من محدِّد المعدّل الخاص بالمثيل، وهو آلية لحماية الخدمة من الروبوتات، وليس رسالة من Google. ترصد اختبارات الحماية طلباً يفتقر رأسه Accept إلى text/html، وUser-Agent غير المعيّن أو المطابق لأدوات مثل curl وwget. ويرصد اختبار ثالث، وهو رمز الرابط، العميل الذي لا يجلب مطلقاً عنوان /client<token>.css الذي يحمّله المتصفح. إذا كان الـreverse proxy خلف المثيل مفقوداً من trusted_proxies في /etc/searxng/limiter.toml، فسيُحتسب كل زائر باعتباره عميلاً واحداً، ولذلك يمكن لمستخدم واحد نشط أن يحجب بقية المستخدمين. وعندما يحظر محرك upstream خادمك بدلاً من ذلك، تختفي نتائج ذلك المحرك من الصفحة فحسب، ولا تحصل على الخطأ 429 إطلاقاً.

هل يجعل الاستضافة الذاتية لـ SearXNG نتائج البحث أسوأ؟

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