SSD Nodes Learn Hosting plans →
راهنماها Matt Connorتوسط Matt Connor · به‌روزرسانی شده 2026-08-26

آیا SearXNG امن است؟ بررسی حریم خصوصی و امنیت

موتور جستجوی SearXNG چگونه IP شما را مخفی می‌کند؟ در این مقاله بررسی می‌کنیم که چه کسی به پرس‌وجوهای شما دسترسی دارد و چرا استفاده از سرور شخصی برای امنیت ضروری است.

آیا SearXNG امن است؟ پاسخ کوتاه

SearXNG از یک جهت امن و از جهت دیگر ناامن است؛ بنابراین پرسش «آیا SearXNG امن است» تنها زمانی پاسخ دارد که مشخص کنید از چه کسی پنهان می‌شوید. SearXNG یک موتور جستجوی متا (metasearch engine) است: پرس‌وجوی شما را دریافت کرده، آن را به Google، Bing، DuckDuckGo و هر موتور دیگری که فعال کرده‌اید می‌فرستد و سپس نتایج بازگشتی را در یک صفحه ادغام می‌کند. موتورهای جستجو، instance را می‌بینند و instance، شما را می‌بیند.

در یک instance عمومی که توسط یک غریبه اداره می‌شود، آن شخص تمام پرس‌وجوهای شما را به صورت متن ساده (plain text) دریافت می‌کند و هیچ‌چیز در صفحه درباره (about) آن سایت نمی‌تواند ثابت کند که با آن داده‌ها چه می‌کند. روی سرور شخصی خودتان، موتورهای بالادستی (upstream engines) به جای آدرس خانه شما، آدرس سرور شما را می‌بینند. این جابه‌جایی، تمام داستان حریم خصوصی است و ارزش آن دقیقاً به اندازه سروری است که روی آن اجرا می‌شود.

هیچ بخشی از این فرآیند، جستجوهای شما را از شبکه خودتان پنهان نمی‌کند. ارائه‌دهنده خدمات اینترنت (ISP) شما همچنان اتصال به آن instance را می‌بیند. DNS resolver شما نیز همچنان نام میزبان (hostname) را می‌بیند. هنگام مطالعه ادامه مطلب، این مرز را در نظر داشته باشید.

تغییراتی که SearXNG در درخواست جستجو ایجاد می‌کند

اگر مستقیماً در Google جستجو کنید، Google آدرس IP، کوکی‌ها، هدر User-Agent و صفحه‌ای که از آن آمده‌اید را دریافت می‌کند؛ تمام این موارد به پروفایلی متصل می‌شوند که فراتر از یک نشست (session) باقی می‌ماند. SearXNG در این میان قرار می‌گیرد. مستندات آن دو عملکرد اصلی خود را این‌گونه توصیف می‌کند: «حذف داده‌های خصوصی از درخواست‌هایی که به سرویس‌های جستجو ارسال می‌شوند» و «ایجاد یک پروفایل مرورگر تصادفی برای هر درخواست». کوکی‌های شما هرگز به موتور جستجو ارسال نمی‌شوند. تنظیمات برگزیده شما به‌جای ذخیره در یک حساب کاربری روی سرور، در مرورگر خودتان ذخیره می‌شود.

دو هدر پاسخ به‌صورت پیش‌فرض ارسال می‌شوند که هر دو وظیفه مهمی دارند:

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

Referrer-Policy: no-referrer به این معناست که وقتی روی یک نتیجه کلیک می‌کنید، سایت مقصد هرگز متوجه نمی‌شود که از کدام صفحه جستجو به آنجا هدایت شده‌اید، زیرا مرورگر هدر Referer را حذف می‌کند. X-Robots-Tag: noindex, nofollow باعث می‌شود نمونه (instance) شما و صفحات نتایج آن از نمایه‌سازی (index) توسط موتورهای جستجو دور بمانند.

آنچه SearXNG تغییر نمی‌دهد، خودِ عبارت جستجو است. این عبارت به‌صورت کامل و خوانا به نمونه می‌رسد، زیرا TLS (امنیت لایه انتقال) در همان‌جا خاتمه می‌یابد. تمام نکات زیر از همین یک واقعیت ناشی می‌شوند.

در یک نمونه عمومی، اپراتور تمام پرس‌وجوها را می‌بیند

مستندات خود پروژه این موضوع را صریح بیان می‌کند: کاربران یک instance عمومی «باید به administrator آن instance اعتماد کنند» و نمی‌توانند بدانند «آیا درخواست‌هایشان log، تجمیع و برای شخص ثالث ارسال یا به او فروخته می‌شود یا نه». ادعای no-logs در landing page صرفاً یک ادعاست. از بیرون راهی برای آزمودن آن وجود ندارد؛ بنابراین یا باید اعتماد کنید یا از سرویس استفاده نکنید. برخی instanceهای عمومی همچنان Searx اصلی را اجرا می‌کنند، نه این fork را؛ این موضوع اهمیت دارد، زیرا Searx از 2023 تاکنون هیچ code commitای نداشته است و نرم‌افزار جست‌وجوی بدون نگه‌داری، مورد دیگری است که ناچار می‌شوید بدون امکان بررسی به آن اعتماد کنید.

ثبت لاگ همچنین مسیری است که کمترین تلاش را می‌طلبد، زیرا تنظیمات پیش‌فرض ارائه‌شده، پرس‌وجوی شما را در 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

جست‌وجوهای شما در آنجا قرار دارند، زیرا فرمت لاگ combined در nginx، مقدار $request را می‌نویسد که همان خط کامل درخواست شامل query string است. SearXNG هیچ نقشی در این مورد ندارد. تغییر نمونه به method: "POST"، پرس‌وجو را به بدنه درخواست منتقل می‌کند، بنابراین دیگر در access log و تاریخچه مرورگر ظاهر نمی‌شود. مستندات صادقانه بیان می‌کنند که POST معایبی دارد که «سهولت استفاده برای کاربر نهایی را به‌شدت محدود می‌کند»، که عمدتاً مربوط به دکمه بازگشت (back) مرورگر است. این معامله‌ای است که شما آگاهانه انجام می‌دهید.

دو پیامد برای هر نمونه عمومی وجود دارد. اپراتور می‌تواند پرس‌وجوهای شما را بخواند، چه قصد جمع‌آوری آن‌ها را داشته باشد و چه نداشته باشد. یک نسخه پشتیبان یا یک نفوذ امنیتی، به همان لاگ دسترسی پیدا می‌کند.

روی VPS شخصی، موتورهای جستجو سرور شما را می‌بینند نه شما را

یک نمونه (instance) شخصی را روی یک VPS (سرور خصوصی مجازی) اجرا کنید؛ تغییر حاصل بسیار ساده است. گوگل دیگر آدرس IP خانگی شما را همراه با پرس‌وجو (query) دریافت نمی‌کند. گوگل آدرس IP سرور شما را همراه با پرس‌وجو دریافت می‌کند. این شرکت نمی‌تواند آن جستجو را به حساب کاربری واردشده، تلفن همراه یا پروفایل تبلیغاتی متصل به اتصال اینترنت خانگی شما مرتبط کند. مراحل ساخت این نمونه در راهنمای اجرای نمونه SearXNG شخصی روی VPS توضیح داده شده است.

دقیق باشید که چه چیزی تغییر نکرده است. موتورهای جستجو همچنان متن پرس‌وجو، زمان‌بندی، زبان و منطقه‌ای که درخواست کرده‌اید و الگوی تمام جستجوهای شما در طول ماه‌ها را می‌بینند که همگی تحت یک آدرس ثابت گروه‌بندی شده‌اند. اگر شما تنها کاربر هستید، آن آدرس یک جریان داده برای هر شخص است که نامی بر آن نیست. شکستن این گروه‌بندی مستلزم آن است که نمونه SearXNG از طریق یک outbound proxy یا شبکه Tor به موتورهای جستجو متصل شود؛ قابلیتی که SearXNG از آن پشتیبانی می‌کند اما پیاده‌سازی آن یک کار جداگانه است.

آنچه ISP، سرویس‌دهنده DNS و میزبان شما همچنان می‌بینند

چهار ناظر تحت تأثیر هیچ‌کدام از این موارد قرار نمی‌گیرند.

  • ISP شما یک اتصال TLS به آدرس IP نمونه (instance) شما را می‌بیند و نام میزبان را در فیلد SNI (نشانگر نام سرور) مشاهده می‌کند که در طول handshake به‌صورت متن ساده ارسال می‌شود. ISP محتوای پرس‌وجو را نمی‌بیند.
  • سرویس‌دهنده DNS شما، جستجوی آن نام میزبان را می‌بیند. هنگام بارگذاری صفحه، آن را در کلاینت با sudo tcpdump -ni any port 53 زیر نظر بگیرید؛ در این صورت درخواست رکورد A برای نمونه شما ظاهر می‌شود.
  • ارائه‌دهنده VPS شما سخت‌افزار را مدیریت می‌کند، بنابراین می‌تواند دیسک و حافظه ماشین مجازی را بخواند. رمزنگاری دیسک در داخل یک VM اجاره‌ای این مشکل را برطرف نمی‌کند، زیرا سیستم در حال اجرا کلید را در اختیار دارد.
  • هر کسی که دسترسی root به نمونه داشته باشد، همه چیز را می‌بیند. این شامل شما و هر کسی می‌شود که بعداً به سیستم نفوذ کند.

دسترسی به نمونه به‌عنوان یک سرویس Tor onion دو مورد اول را مسدود می‌کند، زیرا هیچ نام میزبان عمومی برای حل کردن (resolve) و هیچ فیلد SNI برای خواندن وجود ندارد. راهنمای افزودن یک سرویس v3 onion به VPS این تنظیمات را به همراه نشت‌هایی که ممکن است آن آدرس را به IP عمومی سرور شما مرتبط کند، پوشش می‌دهد.

مورد دیگری هم وجود دارد که افراد فراموش می‌کنند. درخواست‌های خروجی سرور شما از شبکه خودِ سرور قابل مشاهده است، بنابراین ارائه‌دهنده شما می‌تواند ببیند که ماشین شما در تمام طول روز با Google و Bing در ارتباط است. این یک الگوی ترافیکی است تا یک پرس‌وجو، و همچنان اطلاعاتی را فاش می‌کند.

اینجاست که بحث VPN مطرح می‌شود. یک VPN (شبکه خصوصی مجازی) دیدگاه ISP شما را به دیدگاه شرکت VPN منتقل می‌کند. این کار هیچ تغییری در اپراتور نمونه و موتورهای جستجو ایجاد نمی‌کند، زیرا موتورها با سرور شما صحبت می‌کنند، نه با شما. این دو مورد به‌درستی در تحلیل مقایسه‌ای VPS در برابر VPN با هم مقایسه شده‌اند.

چرا SearXNG شما را مسدود می‌کند و معنای واقعی خطای 429 چیست

دو رویداد متفاوت وجود دارند که هر دو به عنوان «مسدود شدن توسط SearXNG» توصیف می‌شوند و راه‌حل‌های متفاوتی دارند.

مورد اول، محدودکننده (limiter) خودِ شماست که با کد HTTP 429 پاسخ می‌دهد. این قابلیت، محافظت در برابر ربات‌ها در SearXNG است و به‌صورت پیش‌فرض غیرفعال است:

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

از اوت 2026، این محدودکننده به یک دیتابیس Valkey نیاز دارد و قوانین خود را از /etc/searxng/limiter.toml می‌خواند. اگر افراد ناشناس واقعاً از سرور شما استفاده می‌کنند، server.public_instance: true را نیز تنظیم کنید، زیرا مقدار پیش‌فرض آن false است و رفتارهای در نظر گرفته شده برای استفاده عمومی را کنترل می‌کند.

این محدودکننده چندین بررسی (probe) انجام می‌دهد. http_user_agent یک User-Agent تنظیم‌نشده یا User-Agentهایی که با ابزارهای شناخته‌شده‌ای مانند curl و wget مطابقت دارند را به عنوان ربات شناسایی می‌کند. http_accept درخواستی که هدر Accept آن شامل text/html نباشد را ربات تلقی می‌کند. link_token کلاینتی را که هرگز URL مربوط به /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 به‌جای آدرس بازدیدکننده، آدرس پروکسی را می‌بیند، مگر اینکه آن پروکسی مورد اعتماد باشد:

[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 = []

لیست پیش‌فرض، پروکسی روی همان میزبان (host) را پوشش می‌دهد. پروکسی در یک شبکه Docker مجزا، از آدرسی مانند 172.18.0.5 می‌آید که در لیست نیست؛ بنابراین همه بازدیدکنندگان به عنوان یک کلاینت واحد شمرده می‌شوند و اولین کاربر پرمشغله، دسترسی بقیه را مسدود می‌کند. آن زیرشبکه (subnet) را به trusted_proxies اضافه کنید.

نوع دوم مسدودسازی در سمت بالادست (upstream) رخ می‌دهد. یک موتور جستجو تشخیص می‌دهد که آدرس دیتاسنتری که جستجوهای زیادی انجام می‌دهد یک scraper است و پاسخ‌دهی به سرور شما را متوقف می‌کند. برای این مورد، شما خطای 429 دریافت نمی‌کنید. در عوض، صفحه‌ای از نتایج را می‌بینید که نتایج آن موتور خاص در آن غایب است و یک خطا برای آن ثبت شده است؛ SearXNG پس از تکرار خطاها، آن موتور را برای مدتی معلق می‌کند. علت این امر آدرسی است که VPS شما روی آن قرار دارد، بنابراین راه‌حل‌ها به جای تغییر در محدودکننده، شامل انتخاب موتورهای دیگر و صبر کردن است.

آیا اشتراک‌گذاری یک instance با افراد غریبه مفید است یا مضر؟

هر دو، اما در جهت‌های مخالف؛ به همین دلیل است که پاسخ به این پرسش مبهم به نظر می‌رسد. ناشناسی یک اثر جمعی است. در یک instance عمومی و شلوغ، پرس‌وجوی شما از همان آدرسی ارسال می‌شود که پرس‌وجوهای هزاران نفر دیگر ارسال شده است، بنابراین هیچ موتور جست‌وجویی نمی‌تواند پرس‌وجوی شما را از میان آن انبوه جدا کند. در یک instance تک‌کاربره، هر پرس‌وجویی که از آن آدرس ارسال می‌شود متعلق به شماست و موتورها یک جریان دادهٔ تمیز و تک‌نفره دریافت می‌کنند که هیچ نامی به آن متصل نیست.

از دیدگاه اپراتور، وضعیت برعکس است. یک جمعیت بزرگ به این معناست که یک غریبه به پرس‌وجوهای متنی (plain text) کل آن جمعیت، از جمله شما، دسترسی دارد. در سرور شخصی خودتان، شما کنترل پرس‌وجوهای خود را در دست دارید و هیچ‌کس دیگری به آن‌ها دسترسی ندارد.

بنابراین، بر اساس تهدیدی که واقعاً با آن مواجه هستید، انتخاب کنید. آیا نگران پروفایل‌سازی تبلیغاتی و ردیابی بین‌سایتی (cross-site tracking) هستید؟ جمعیت به‌خوبی از عهدهٔ این مورد برمی‌آید و ریسک اپراتور ناچیز است. آیا نگران این هستید که یک شخص یا شرکت خاص، یک جست‌وجوی مشخص شما را بخواند؟ جمعیت در اینجا هیچ کمکی نمی‌کند، زیرا اپراتور متن خام را می‌بیند. یک راه میانهٔ مناسب، داشتن یک instance برای گروه کوچکی از افرادی است که می‌شناسید. در این حالت، شما یک جمعیت کوچک دارید و اپراتوری که می‌توانید هویتش را تأیید کنید، چرا که آن اپراتور خود شما هستید.

آیا نتایج SearXNG از Google بهتر هستند؟

خیر. SearXNG هیچ ایندکس مستقلی ندارد، بنابراین تمام نتایج موجود در صفحه از موتورهای جستجوی بالادستی (upstream) دریافت می‌شوند و سقف کیفیت نتایج، همان سقف کیفیت موتورهایی است که فعال کرده‌اید. اگر Google و Bing را غیرفعال کنید، کیفیت نتایج بلافاصله افت می‌کند، زیرا بخش عمده‌ای از پوشش وب عمومی توسط همین موتورها تأمین می‌شود.

آنچه تغییر می‌کند، پردازشی است که روی داده‌های شما اعمال می‌شود. هیچ‌چیز از جستجوهای شما یک پروفایل تبلیغاتی نمی‌سازد و هیچ‌چیز نتایج را بر اساس آنچه هفتهٔ گذشته کلیک کرده‌اید، بازچینی نمی‌کند. این موضوع دو جنبه دارد، زیرا شخصی‌سازی گاهی شامل قصد و نیت محلی (local intent) نیز می‌شود. جستجویی مانند "pharmacy open now" در SearXNG ضعیف‌تر عمل می‌کند، زیرا موتور جستجو هیچ سیگنال مکانی از شما ندارد و تنها موقعیت دیتاسنتری که سرور در آن قرار دارد را می‌شناسد. هنگامی که نتایج محلی اهمیت دارند، منطقه (region) را در تنظیمات (preferences) مشخص کنید.

دو تنظیم تعیین می‌کنند که هنگام مشاهده نتایج، نمونهٔ (instance) شما چقدر نشت اطلاعات دارد. image_proxy به‌صورت پیش‌فرض false است، بنابراین تصاویر بندانگشتی (thumbnails) مستقیماً از سایت‌های میزبان بارگذاری می‌شوند و آن سایت‌ها آدرس مرورگر شما را مشاهده می‌کنند. تنظیم image_proxy: true آن‌ها را از طریق نمونهٔ شما هدایت می‌کند که البته هزینهٔ پهنای باند و حافظه را به همراه دارد. همچنین formats به‌صورت پیش‌فرض فقط html است، بنابراین درخواست‌های JSON (مخفف JavaScript object notation) با خطای 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، پرس‌وجو را به صورت متن ساده (plain text) می‌خواند. تنها نسخه‌ای از این وضعیت که می‌توانید آن را تأیید کنید، زمانی است که خودتان گرداننده باشید.
  • لاگ‌های دسترسی خودتان، رکوردی را که سعی در اجتناب از آن داشتید، بازسازی می‌کنند. آن‌ها را بخوانید و اگر ترجیح می‌دهید خالی بمانند، به method: "POST" سوییچ کنید.

SearXNG ناظر را جابه‌جا می‌کند، اما نظارت را حذف نمی‌کند. تصمیم بگیرید که کدام ناظر برایتان اهمیت دارد، instance متناسب با آن را انتخاب کنید و یک رابط جستجو را به عنوان نرم‌افزار ناشناسی (anonymity software) در نظر نگیرید.

FAQ

آیا استفاده از SearXNG روی یک نمونه عمومی امن است؟

این سرویس در برابر موتورهای جستجو امن است، اما در برابر اپراتور سرور خیر. پرس‌وجوی شما به‌صورت متن ساده (plain text) به آن سرور می‌رسد و مستندات پروژه تصریح می‌کند که کاربران «باید به مدیر آن نمونه اعتماد کنند» و نمی‌توانند بدانند «آیا درخواست‌هایشان ثبت، تجمیع و برای شخص ثالث ارسال یا فروخته می‌شود یا خیر». با تنظیمات پیش‌فرض method: "GET"، پرس‌وجو به‌عنوان بخشی از خط درخواست در لاگ دسترسی reverse proxy نیز ثبت می‌شود، فارغ از اینکه اپراتور بخواهد یا نه. برای جستجوهای عادی که نگرانی اصلی پروفایل‌سازی تبلیغاتی است، از یک نمونه عمومی استفاده کنید. هیچ مطلبی را در نمونه‌ای وارد نکنید که حاضر نیستید آن را مستقیماً به مالک آن سرور تحویل دهید.

آیا SearXNG جستجوهای مرا از ارائه‌دهنده اینترنت مخفی می‌کند؟

متن پرس‌وجو مخفی می‌ماند، اما فعالیت شما خیر. ارائه‌دهنده شما یک اتصال TLS به آدرس نمونه شما و نام میزبان (hostname) را در فیلد SNI که به‌صورت متن ساده در handshake ارسال می‌شود، می‌بیند و DNS resolver شما نیز جستجوی آن نام میزبان را مشاهده می‌کند. هیچ‌کدام نمی‌توانند ببینند چه چیزی جستجو کرده‌اید، زیرا اتصال رمزنگاری‌شده است. SearXNG یک VPN نیست و هیچ حفاظتی برای سایر فعالیت‌های دستگاه شما فراهم نمی‌کند.

چرا SearXNG خطای 429 برمی‌گرداند؟

خطای 429 از محدودکننده (limiter) خودِ نمونه ناشی می‌شود که یک مکانیزم محافظت در برابر ربات‌هاست و پیامی از سمت Google نیست. بررسی‌های این سیستم، درخواستی را که هدر Accept آن فاقد text/html باشد و User-Agent آن تنظیم نشده یا با ابزارهایی مانند curl و wget مطابقت داشته باشد، علامت‌گذاری می‌کند. بررسی سوم، یعنی توکن لینک، کلاینتی را شناسایی می‌کند که هرگز URL مربوط به /client<token>.css را که مرورگرها بارگذاری می‌کنند، فراخوانی نکرده است. پشت یک reverse proxy که در trusted_proxies در فایل /etc/searxng/limiter.toml پیکربندی نشده باشد، تمام بازدیدکنندگان به‌عنوان یک کلاینت واحد شمرده می‌شوند؛ بنابراین یک کاربر پرمصرف، دسترسی بقیه را مسدود می‌کند. زمانی که یک موتور جستجوی بالادستی (upstream engine) سرور شما را مسدود کند، نتایج آن موتور به‌سادگی از صفحه حذف می‌شود و شما هیچ خطای 429 دریافت نمی‌کنید.

آیا میزبانی شخصی SearXNG کیفیت نتایج جستجوی مرا کاهش می‌دهد؟

گاهی اوقات، به دو دلیل که دانستن آن‌ها مفید است. نتایج از موتورهای بالادستی می‌آیند، بنابراین آدرس یک دیتاسنتر که توسط موتورها محدود (throttle) شده باشد، به معنای پاسخ‌دهی تعداد کمتری از موتورها و در نتیجه صفحه نتایج خلوت‌تر است. همچنین رتبه‌بندی شخصی‌سازی‌شده حذف می‌شود که باعث از بین رفتن مرتب‌سازی مبتنی بر تبلیغات و همچنین حذف نتایج مرتبط با موقعیت مکانی می‌شود؛ بنابراین جستجوهای حساس به مکان تا زمانی که منطقه (region) خود را در تنظیمات (preferences) مشخص نکنید، نتایج ضعیف‌تری ارائه می‌دهند.