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

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

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

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

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

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

اگر مستقیماً در 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) شما و صفحات نتایج آن از ایندکس‌های جستجو دور بمانند.

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

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

مستندات خود پروژه به‌صراحت بیان می‌کند: کاربران یک نمونه عمومی «باید به مدیر آن نمونه اعتماد کنند» و آن‌ها نمی‌توانند بدانند که «آیا درخواست‌هایشان ثبت، تجمیع و برای شخص ثالث ارسال یا فروخته می‌شود یا خیر». ادعای عدم ثبت لاگ در یک صفحه فرود، صرفاً یک ادعاست. از بیرون هیچ راهی برای آزمایش آن وجود ندارد، بنابراین یا باید اعتماد کرد یا کلاً از آن استفاده نکرد.

ثبت لاگ همچنین مسیر کمترین مقاومت است، زیرا تنظیمات پیش‌فرض ارائه‌شده، پرس‌وجوی شما را در 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 به صورت متن ساده (cleartext) ارسال می‌شود. ISP محتوای پرس‌وجو (query) را نمی‌بیند.
• سرویس‌دهنده DNS شما، جستجوی آن نام میزبان را می‌بیند. هنگام بارگذاری صفحه، آن را در کلاینت با sudo tcpdump -ni any port 53 زیر نظر بگیرید تا درخواست رکورد A برای نمونه شما ظاهر شود.
• ارائه‌دهنده VPS شما سخت‌افزار را مدیریت می‌کند، بنابراین می‌تواند دیسک و حافظه ماشین مجازی را بخواند. رمزنگاری دیسک در داخل یک VM اجاره‌ای این موضوع را برطرف نمی‌کند، زیرا سیستم در حال اجرا، کلید را در اختیار دارد.
• هر کسی که دسترسی root روی نمونه داشته باشد، همه چیز را می‌بیند. این شامل خود شما و هر کسی که بعداً به سیستم نفوذ کند می‌شود.

مورد دیگری هم وجود دارد که افراد فراموش می‌کنند. درخواست‌های خروجی سرور شما از شبکه خودِ سرور قابل مشاهده است، بنابراین ارائه‌دهنده شما می‌تواند ببیند که ماشین شما در تمام طول روز با 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 تنظیم‌نشده یا منطبق با ابزارهای شناخته‌شده‌ای مانند 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 می‌آید که در لیست نیست؛ بنابراین همه بازدیدکنندگان به عنوان یک کلاینت واحد شمارش می‌شوند و اولین کاربر فعال، دسترسی بقیه را مسدود می‌کند. آن زیرشبکه را به 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 رایگان برای اسکرپ کردن (scraping) منتشر کرده‌اید؛ این سریع‌ترین راه برای مسدود شدن آدرس سرور شما توسط موتورهایی است که به آن‌ها وابسته‌اید. آن را خاموش نگه دارید یا پشت لایه احراز هویت قرار دهید.

جایی که داستان حریم خصوصی SearXNG به پایان می‌رسد

SearXNG هویت پرسش‌کننده را از موتورهای جستجو پنهان می‌کند. این ابزار آنچه را که در شبکه خود انجام می‌دهید، از دید شبکه پنهان نمی‌کند. چهار محدودیت از این واقعیت ناشی می‌شود:

• ترافیک شما در همه جا به جز کادر جستجو بدون تغییر باقی می‌ماند. هر فعالیت دیگری که دستگاه انجام می‌دهد، دقیقاً مانند قبل از شبکه شما خارج می‌شود.
• یک کاربر روی یک سرور، یک شناسه پایدار برای هر موتور جستجو است. این شناسه فاقد نام است و کل مزیت آن همین است.
• گرداننده هر نمونه (instance)، پرس‌وجو را به صورت متن ساده (plain text) می‌خواند. تنها نسخه‌ای از این ابزار که می‌توانید آن را تأیید کنید، حالتی است که خودتان گرداننده آن باشید.
• لاگ‌های دسترسی خودتان، رکوردی را که سعی در اجتناب از آن داشتید، بازسازی می‌کنند. آن‌ها را بخوانید و اگر ترجیح می‌دهید خالی بمانند، به method: "POST" سوییچ کنید.

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

FAQ

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

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

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

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

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

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

آیا self-hosting کردن SearXNG کیفیت نتایج جستجوی من را کاهش می‌دهد؟

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