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

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

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

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

لا يخفي أي جزء من هذا نشاط البحث عن شبكتك أنت. سيظل مزود خدمة الإنترنت (ISP) يرى اتصالاً بالمثيل. وسيظل محلل 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 (أمان طبقة النقل) ينتهي عنده. وتنتج كل نقطة أدناه عن هذه الحقيقة وحدها.

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

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

كما أن التسجيل هو المسار الأقل جهداً، لأن الإعداد الافتراضي الذي يأتي مع البرنامج يضع استعلامك في 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)"

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

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

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

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

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

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

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

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

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

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

هناك طرف آخر ينساه الناس. تظهر الطلبات الصادرة من خادمك على شبكة الخادم نفسه، لذلك يستطيع مزود الخدمة رؤية أن جهازك يتصل بـ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 من مثيل يعمل بشكل طبيعي في المتصفح. يجب إصلاح ذلك قبل توجيه مهارة البحث لدى وكيل إلى مثيلك الخاص. توجد المجموعة الكاملة من الأسباب والإعدادات في دليل حدود المعدل وأخطاء 429 في SearXNG.

هناك مشكلة مهمة في محدِّد المعدل تستحق التوضيح. خلف reverse proxy، يرى SearXNG عنوان الـ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، لذلك إذا كان عنوان مركز البيانات مقيّداً من المحركات، فسيجيب عدد أقل منها وستكون الصفحة أقل ثراءً. كما يختفي الترتيب المخصّص، ما يزيل إعادة الترتيب المدفوعة بالإعلانات ويزيل أيضاً النية المحلية؛ لذلك تعرض عمليات البحث الحساسة للموقع نتائج أضعف إلى أن تعيّن منطقتك في التفضيلات.