رفع خطای CAPTCHA موتورهای جستجو در SearXNG

معنای خطای CAPTCHA در SearXNG

خطاهای CAPTCHA در SearXNG از سوی موتورهای جستجویی ناشی می‌شوند که instance شما از آن‌ها پرس‌وجو می‌کند. سرور شما از یک موتور جستجو درخواست نتایج کرده است، اما آن موتور به‌جای نتایج، یک صفحه چالش (challenge page) بازگردانده است. از آنجا که در پاسخ دریافتی چیزی برای تجزیه (parse) وجود نداشته، SearXNG یک خطا برای آن موتور ثبت کرده است. instance شما کاملاً سالم است. ماشینی که تحت کنترل شما نیست، تشخیص داده است که درخواست شما شبیه به رفتار یک انسان نبوده است.

همین یک واقعیت، تعیین‌کننده تمام راهکارهای زیر است. این تصمیم روی سخت‌افزار خودِ موتور جستجو گرفته شده است، بنابراین هیچ تغییری در settings.yml شما نمی‌تواند آن را نقض کند. آنچه شما می‌توانید تغییر دهید، آدرسی است که درخواست از آن خارج می‌شود، انتخاب موتورهایی که از آن‌ها پرس‌وجو می‌کنید و نحوه رفتار instance شما پس از شروع امتناع یک موتور از پاسخ‌دهی است.

دو خطای مشابه و نحوه تشخیص آن‌ها از یکدیگر

خطای اول زمانی رخ می‌دهد که نمونه (instance) شخصی شما در پاسخ به مرورگرتان کد HTTP 429 (درخواست‌های بیش از حد) را برمی‌گرداند. این مربوط به limiter در SearXNG است؛ لایه تشخیص ربات که پیش از endpoint جستجو قرار دارد. این بخش روی سرور شما اجرا می‌شود و پیکربندی آن بر عهده شماست. limiter که کد 429 را به کاربران شما برمی‌گرداند یک مشکل مجزا با تنظیمات جداگانه است و هیچ‌کدام از توصیه‌های زیر برای آن کاربرد ندارد.

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

• اگر صفحه بارگذاری نمی‌شود یا endpoint جستجو کد 429 برمی‌گرداند: limiter خود را بررسی کنید.
• اگر صفحه بارگذاری می‌شود اما نتایج ناقص هستند یا یک موتور جستجو با خطا علامت‌گذاری شده است: مشکل بالادستی است؛ ادامه مطلب را بخوانید.

هر دو خطا ممکن است هم‌زمان در یک نمونه رخ دهند و بر یکدیگر تأثیر بگذارند؛ زیرا limiter که بیش از حد آزاد تنظیم شده باشد، اجازه می‌دهد ترافیکی عبور کند که نرخ کوئری‌های خروجی شما را افزایش می‌دهد. این دو مورد را به‌صورت جداگانه عیب‌یابی کنید.

چرا موتورهای SearXNG روی VPS خطای CAPTCHA برمی‌گردانند اما روی لپ‌تاپ من خیر؟

دلیل این موضوع، آدرسی است که درخواست از آن ارسال می‌شود. اتصال خانگی شما دارای آدرسی از محدوده یک ISP (ارائه‌دهنده خدمات اینترنتی) مصرف‌کننده است که در طول زمان با بسیاری از کاربران عادی به اشتراک گذاشته می‌شود. VPS شما دارای آدرسی از محدوده دیتاسنتر است و این محدوده‌ها عمومی هستند: هر کسی می‌تواند بررسی کند که کدام آدرس‌ها متعلق به یک ارائه‌دهنده میزبانی است. موتوری که می‌خواهد از ورود اسکریپرها (scrapers) جلوگیری کند، در وهله اول درخواست‌های ارسالی از محدوده‌های میزبانی را مشکوک تلقی می‌کند، زیرا ترافیک بسیار کمی در این محدوده‌ها مربوط به انسان‌هایی است که از مرورگر استفاده می‌کنند.

چند عامل دیگر نیز به آدرس اضافه می‌شوند. نمونه (instance) شما برای هر جستجوی کاربر، یک درخواست به ازای هر موتور ارسال می‌کند؛ بنابراین حتی تعداد کمی از کاربران، نرخ درخواستی را از یک آدرس واحد تولید می‌کنند که هیچ فردی به تنهایی قادر به تولید آن نیست. SearXNG طبق طراحی، هیچ نشست (session) با موتور نگه نمی‌دارد و هیچ کوکی با عمر طولانی حمل نمی‌کند، بنابراین هر درخواست بدون هیچ پیشینه‌ای می‌رسد. همچنین، آدرس ممکن است دارای سابقه‌ای باشد که شما ایجاد نکرده‌اید، زیرا ارائه‌دهندگان آدرس‌ها را بازیافت می‌کنند و مستأجر قبلی ممکن است ماه‌ها از آن برای اسکریپ کردن استفاده کرده باشد.

خودِ امتناع از پاسخ همیشه یک شکست آشکار نیست. یک موتور می‌تواند با کد 403، با 429، یا با HTTP 200 و یک صفحه چالش (challenge page) در بدنه پاسخ دهد. مورد آخر باعث سردرگمی کاربران می‌شود، زیرا بررسی کد وضعیت نشان می‌دهد که موتور سالم است، در حالی که SearXNG هیچ نتیجه‌ای در پاسخ پیدا نمی‌کند. به همین دلیل است که باید به جای استفاده از curl برای موتور و نگاه کردن به خط وضعیت، گزارش خطای نمونه خود را مطالعه کنید.

پیش از هر تغییری، گزارش‌های نمونه خود را بخوانید

هر راهکار در ادامه، با نام موتور جستجویی که دچار خطا شده و دلیلی که نمونه شما برای آن ثبت کرده است، آغاز می‌شود. SearXNG هر دو مورد را نمایش می‌دهد. صفحه /stats فهرستی از موتورها به همراه تعداد خطاها و میزان پایداری آن‌ها را نشان می‌دهد و /stats/errors جزئیات خطا را به‌صورت JSON برمی‌گرداند که برای نگهداری و مقایسه در هفته‌های آینده مناسب‌تر است. این صفحات را در مرورگری که معمولاً برای دسترسی به نمونه خود استفاده می‌کنید، باز کنید.

لاگ کانتینر، رویدادها را دقیقاً در لحظه وقوع ثبت می‌کند. نام سرویس در اینجا همان نامی است که در فایل compose منتشرشده در مستندات کانتینر آمده است؛ بنابراین اگر نام سرویس شما متفاوت است، از نام خودتان استفاده کنید.

docker compose logs -f core

در حالی که لاگ در حال دنبال‌شدن (follow) است، یک جستجوی ناموفق انجام دهید. با اجرای جستجو، باید ورودی مربوط به موتورِ دارای خطا ظاهر شود. نام موتور و متن دقیق دلیلی که نمونه شما چاپ کرده است را یادداشت کنید. نام موتور را از پست‌های وبلاگی (از جمله همین پست) کپی نکنید. مجموعه‌ی موتورهایی که آدرس‌های دیتاسنتر را به چالش می‌کشند، ماه به ماه تغییر می‌کند و موتوری که برای شما خطا می‌دهد، ممکن است برای نویسنده پستی که می‌خوانید، به‌خوبی کار کند.

اگر صفحه نتایج هیچ خطایی نشان نمی‌دهد اما نتایج بسیار محدود هستند، display_error_messages را برای آن موتور بررسی کنید. مقدار پیش‌فرض آن true است و نمونه‌ای که آن را غیرفعال کرده باشد، در واقع همان پیامی که به آن نیاز دارید را مخفی می‌کند.

نحوه تلاش مجدد و تعلیق موتورهای ناموفق در SearXNG

SearXNG به موتورهایی که پاسخ نمی‌دهند، به‌طور مداوم درخواست ارسال نمی‌کند. موتور ناموفق به حالت تعلیق در می‌آید و در طول این مدت، کاملاً نادیده گرفته می‌شود؛ به همین دلیل است که یک موتور خراب به یک موتور غایب و بی‌صدا تبدیل می‌شود.

دو لایه این فرآیند را کنترل می‌کنند و هر دو در search: در فایل settings.yml قرار دارند. پیش از کپی کردن هر چیزی، این نام‌ها و مقادیر کلیدی را با searx/settings.yml برای نسخه‌ای که در حال اجرا دارید تطبیق دهید، زیرا این تنظیمات در نسخه‌های مختلف جابه‌جا شده‌اند و مثال موجود در صفحه مستندات تنظیمات، همچنان زمان‌های تعلیق طولانی‌تری را نسبت به فایلی که SearXNG واقعاً بارگذاری می‌کند، نشان می‌دهد. در نسخه ارائه‌شده در searx/settings.yml به تاریخ 17 اکتبر 2026، مقادیر پیش‌فرض به شرح زیر است:

search:
  ban_time_on_fail: 5
  max_ban_time_on_fail: 120
  suspended_times:
    SearxEngineAccessDenied: 180
    SearxEngineCaptcha: 3600
    SearxEngineTooManyRequests: 180
    cf_SearxEngineCaptcha: 1296000
    cf_SearxEngineAccessDenied: 86400
    recaptcha_SearxEngineCaptcha: 604800

لایه اول خطاهای معمولی مانند timeout را مدیریت می‌کند. زمان مسدودسازی از ban_time_on_fail ثانیه شروع شده و با هر شکست متوالی تا سقف max_ban_time_on_fail افزایش می‌یابد. به‌طور پیش‌فرض این سقف دو دقیقه است، بنابراین یک موتور ناپایدار پس از رفع مشکل، ظرف چند دقیقه به‌طور خودکار بازیابی می‌شود.

لایه دوم خطاهایی را مدیریت می‌کند که موضوع این راهنما هستند. هنگامی که SearXNG پاسخ را به جای یک خطای عمومی، به عنوان یک چالش (challenge) یا امتناع (refusal) تشخیص دهد، ورودی منطبق از suspended_times را اعمال می‌کند و بیشتر این اعداد بسیار بزرگ‌تر هستند. 180 ثانیه معادل سه دقیقه برای یک امتناع ساده یا خطای 429 است. 3600 ثانیه معادل یک ساعت برای یک CAPTCHA عمومی است. 86400 ثانیه یک روز کامل است. 604800 ثانیه یک هفته است. 1296000 ثانیه پانزده روز است. کلیدهایی که با پیشوند cf_ شروع می‌شوند، زمانی اعمال می‌شوند که چالش به عنوان Cloudflare تشخیص داده شود و کلیدهای با پیشوند recaptcha_ زمانی که چالش به عنوان reCAPTCHA شناسایی شود.

این موضوع علامتی را توضیح می‌دهد که بیشترین زمان را هدر می‌دهد. شما علت را پیدا می‌کنید، آن را رفع می‌کنید، اما موتور همچنان تا یک ساعت یا حتی روزها پس از یک چالش Cloudflare، هیچ پاسخی برنمی‌گرداند. موتور همچنان در حالت تعلیق است. وضعیت تعلیق در فرآیند در حال اجرا نگهداری می‌شود، بنابراین restart کردن container آن را پاک می‌کند و در جستجوی بعدی، تلاش مجدد برای استفاده از موتور انجام می‌شود. یک restart ساده در اینجا کارساز است و ارزش دارد که پیش از بازسازی بی‌دلیل imageها، بدانید چه زمانی یک restart کافی است و چه زمانی باید container را دوباره ایجاد کنید. اگر موتور بلافاصله پس از restart دوباره شکست خورد، یعنی اصلاح شما کارساز نبوده است.

یک تنظیم برای هر موتور نیازمند هشدار است. retry_on_http_error زمانی که موتور با کدهای وضعیتی که شما لیست کرده‌اید پاسخ دهد، درخواست را دوباره ارسال می‌کند. در برابر موتوری که شما را مسدود کرده است، تلاش‌های مجدد ترافیک بیشتری را به سیستمی می‌فرستد که قبلاً تصمیم گرفته سرور شما یک ربات است. مگر اینکه در حال دور زدن موتوری باشید که واقعاً به‌صورت متناوب دچار مشکل می‌شود، این تنظیم را تغییر ندهید.

مستندات upstream تونل SSH و مواردی که این روش حل نمی‌کند

در تاریخ 17 October 2026، مستندات مدیریت SearXNG این مشکل را با یک تونل دستی پاسخ می‌دهد. شما یک SOCKS proxy از طریق سرور خود باز می‌کنید، مرورگر دسکتاپ خود را به آن متصل می‌کنید و چالش را به‌صورت دستی پاسخ می‌دهید، در حالی که موتور جستجو آدرس سرور را مشاهده می‌کند.

ssh -q -N -D 8080 user@example.org

دستور -D 8080 یک SOCKS server محلی روی پورت 8080 باز می‌کند که ترافیک را از طریق اتصال SSH هدایت می‌کند. -N هیچ دستور از راه دوری اجرا نمی‌کند و -q آن را در حالت بی‌صدا نگه می‌دارد، بنابراین یک تونل سالم هیچ خروجی چاپ نمی‌کند و به ترمینال باز نمی‌گردد. وضعیت آن را از یک ترمینال دوم بررسی کنید:

curl -x socks://127.0.0.1:8080 http://ipecho.net/plain
curl http://ipecho.net/plain

دستور اول باید آدرس سرور شما و دستور دوم آدرس دسکتاپ شما را چاپ کند. دو پاسخ یکسان به این معنی است که درخواست از طریق تونل عبور نمی‌کند. سپس تنظیمات شبکه مرورگر خود را روی یک SOCKS5 proxy در 127.0.0.1 پورت 8080 قرار دهید، همان بررسی‌کننده آدرس را در مرورگر بارگذاری کنید تا تأیید شود که آدرس سرور را گزارش می‌دهد، و سپس به موتور جستجویی که شما را به چالش کشیده است مراجعه کنید. چالش را در آنجا پاسخ دهید.

حالا بخش واقع‌بینانه ماجرا. چهار مورد این روش را محدود می‌کند. کوکی که موتور جستجو ارائه می‌دهد در مرورگر دسکتاپ شما ذخیره می‌شود و SearXNG به کوکی‌های مرورگر شما دسترسی ندارد، بنابراین تنها چیزی که می‌تواند به instance شما کمک کند، رکوردی است که موتور جستجو برای خودِ آدرس ثبت می‌کند. آن رکورد طبق زمان‌بندی که موتور جستجو انتخاب می‌کند و منتشر نمی‌کند، منقضی می‌شود. هیچ بخشی از این فرآیند خودکار نیست، بنابراین دفعه بعد دوباره باید پشت کیبورد بنشینید. همچنین در یک instance که افراد دیگر از آن استفاده می‌کنند، نرخ پرس‌وجو که باعث ایجاد چالش شده است همچنان برقرار است، بنابراین چالش دوباره بازمی‌گردد.

از این روش برای فعال کردن یک instance در بعدازظهر امروز استفاده کنید. یک instance را بر پایه این روش بنا نکنید.

اصلاح پایدار: حذف یا تغییر وزن موتورهایی که شما را مسدود می‌کنند

ارزان‌ترین و پایدارترین پاسخ، متوقف کردن ارسال کوئری به موتوری است که به سرور شما سرویس نمی‌دهد. فایل settings.yml شما با use_default_settings: true در ایمیج کانتینر شروع می‌شود؛ این یعنی یک ورودی در engines: با یک name منطبق، فقط کلیدهایی را که لیست می‌کنید بازنویسی کرده و بقیه تنظیمات پیش‌فرض را دست‌نخورده باقی می‌گذارد.

use_default_settings: true

engines:
  - name: <engine name from your stats page>
    disabled: true
  - name: <another engine name>
    weight: 0.3

گزینه disabled: true موتور را به‌طور پیش‌فرض خاموش می‌کند اما آن را در صفحه تنظیمات باقی می‌گذارد تا کاربری که به آن نیاز دارد، بتواند برای جستجوهای خود دوباره آن را فعال کند. گزینه inactive: true آن را به‌طور کامل از تنظیمات کاربر حذف می‌کند؛ این همان چیزی است که برای موتوری که هرگز از آدرس شما کار نخواهد کرد، به آن نیاز دارید. گزینه weight کار متفاوتی انجام می‌دهد: این گزینه تعیین می‌کند که نتایج آن موتور هنگام ادغام و رتبه‌بندی توسط SearXNG چقدر اهمیت داشته باشند. بنابراین، وزن کمتر از 1 باعث می‌شود موتورهای حاشیه‌ای حفظ شوند بدون اینکه اجازه یابند صفحه اول نتایج را اشغال کنند.

پس از ویرایش، کانتینر را Restart کنید، چند جستجو انجام دهید و سپس دوباره /stats را بررسی کنید. یک صفحه آمار تمیز با 6 موتور فعال، بسیار مفیدتر از صفحه‌ای پر از خطا با 20 موتور است.

راهکار پایدار: ارسال درخواست‌های خروجی از طریق پروکسی

SearXNG می‌تواند درخواست‌های خروجی موتورهای جستجو را از طریق یک پروکسی ارسال کند؛ این کار باعث تغییر آدرسی می‌شود که موتور جستجو مشاهده می‌کند. این تنظیم را به‌صورت سراسری در outgoing: یا برای هر موتور به‌صورت جداگانه، در صورتی که مشکل تنها مربوط به یک موتور خاص باشد، اعمال کنید.

outgoing:
  request_timeout: 3.0
  extra_proxy_timeout: 10
  proxies:
    all://:
      - socks5h://user:password@proxy:1080

engines:
  - name: <engine name>
    proxies:
      http: socks5h://user:password@proxy:1080
      https: socks5h://user:password@proxy:1080

هنگامی که می‌خواهید پروکسی نام میزبان (hostname) را resolve کند، socks5h:// را به socks5:// ترجیح دهید، زیرا h به این معناست که نام به جای جستجو در سرور شما، به پروکسی ارسال می‌شود. همزمان بودجه زمانی (timeout) را افزایش دهید. مقدار پیش‌فرض request_timeout برابر با 3.0 ثانیه است؛ پروکسی یک رفت‌وبرگشت اضافی به هر درخواست اضافه می‌کند و موتورهایی که قبلاً به‌موقع پاسخ می‌دادند، اکنون با خطای timeout مواجه می‌شوند. extra_proxy_timeout دقیقاً برای همین منظور وجود دارد و هنگام استفاده از پروکسی، ثانیه‌هایی به زمان مجاز اضافه می‌کند. آن را به صورت یک عدد صحیح مانند 10 بنویسید. برخلاف request_timeout که اعداد اعشاری را می‌پذیرد، extra_proxy_timeout در طرح‌واره تنظیمات یک عدد صحیح است، بنابراین مقداری مانند 10.0 به عنوان یک settings.yml نامعتبر رد می‌شود، حتی اگر در مثال کامنت‌شده در صفحه مستندات تنظیمات خروجی، به آن شکل نوشته شده باشد.

هزینه‌های استفاده از پروکسی:

• اپراتور پروکسی می‌بیند که نمونه (instance) شما چه موتورهایی را و در چه زمانی پرس‌وجو می‌کند. TLS (امنیت لایه انتقال) عبارات جستجو را از لاگ‌های آن‌ها دور نگه می‌دارد، زیرا پرس‌وجو درون درخواست رمزنگاری‌شده قرار دارد، اما شکل و زمان‌بندی ترافیک شما برای آن‌ها قابل مشاهده است.
• یک آدرس خروجی اشتراکی با هر کس دیگری که هزینه آن را می‌پردازد، مشترک است. اگر آن‌ها عمل scraping انجام دهند، شما اعتبار آن‌ها را به ارث می‌برید؛ گاهی اوقات سریع‌تر از مسدودسازی‌ای که سعی در فرار از آن داشتید.
• استخرهای پروکسی مسکونی ارزان‌قیمت اغلب از دستگاه‌های کاربران عادی ساخته شده‌اند که مالکان آن‌ها آگاهانه با انتقال ترافیک موافقت نکرده‌اند. بدانید چه چیزی خریداری می‌کنید.
• using_tor_proxy: true ترافیک را از طریق Tor مسیریابی می‌کند، اما آدرس‌های گره‌های خروجی به‌طور کامل منتشر می‌شوند و موتوری که محدوده‌های دیتاسنتر را به چالش می‌کشد، معمولاً گره‌های خروجی را نیز حداقل به همان اندازه به چالش می‌کشد.
• جستجو اکنون به سرویسی خارج از سرور شما وابسته است که می‌تواند طبق برنامه خودش از کار بیفتد و نتایج شما را نیز با خود از دسترس خارج کند.

پروکسی مسدودسازی را جابه‌جا می‌کند، نه اینکه آن را حذف کند، و داستان حریم خصوصی نمونه شما اکنون شامل یک شخص ثالث نیز می‌شود. اگر دلیل شما برای self-hosting، کوتاه بودن داستان حریم خصوصی است، پیش از ثبت‌نام در هر سرویسی، آن را در برابر آنچه یک نمونه self-hosted واقعاً پنهان می‌کند و آنچه پنهان نمی‌کند بسنجید.

اصلاح پایدار: اجرای عمدی مجموعه‌ای کوچک‌تر از موتورها

گزینه‌ای که اکثر افراد از آن صرف‌نظر می‌کنند، پذیرش تعداد کمتری از موتورهاست. ارزش SearXNG در ادغام نتایج است و ادغام شش موتور که همیشه پاسخ می‌دهند، بهتر از بیست موتور است که نیمی از آن‌ها برای ساعت‌ها یا روزها معلق (suspended) هستند. وضعیت /stats را برای یک هفته زیر نظر بگیرید و موتورهایی را که سابقه عملکرد پاکی از آدرس شما دارند، حفظ کنید.

موتورهایی که با استفاده از API key به آن‌ها احراز هویت می‌کنید، رفتار متفاوتی دارند؛ زیرا موتور می‌داند شما چه کسی هستید و به‌جای حدس زدن اینکه آیا شما یک انسان هستید یا خیر، سهمیه (quota) اعمال می‌کند. هزینه این کار، داشتن یک حساب کاربری، یک کلید در فایل تنظیمات و معمولاً پرداخت صورت‌حساب است. برای یک یا دو موتور که برای شما اهمیت دارند، این اغلب کم‌دردسرترین مسیر است.

این تصمیم را با در نظر گرفتن سایر ابزارهای خود بگیرید. یک موتور معلق برای هر چیزی که نتایج را از طریق API می‌خواند نامرئی است، زیرا JSON API که Open WebUI و ابزارهای مشابه پرس‌وجو می‌کنند به‌جای بازگرداندن خطایی که ابزار شما متوجه آن شود، صرفاً نتایج کمتری را برمی‌گرداند. اگر فرآیند خودکاری به instance شما وابسته است، به‌جای اینکه منتظر بمانید تا کسی از افت کیفیت پاسخ‌ها شکایت کند، /stats/errors را طبق یک زمان‌بندی مشخص بررسی (poll) کنید.

آیا اصلاً ارزش این همه دردسر را دارد؟

پاسخ این پرسش در تعداد کاربران نهفته است. یک نمونه (instance) برای یک نفر، روزانه تعداد اندکی جستجو از یک آدرس IP ارسال می‌کند؛ نرخی که بسیاری از موتورهای جستجو هرگز آن را به چالش نمی‌کشند. زمانی که یکی از آن‌ها شما را به چالش کشید، راه‌حل ساده است: آن موتور را حذف کنید؛ به‌قدری که حتی متوجه نبودنش نخواهید شد. این تجربه معمولِ اجرای SearXNG روی یک VPS کوچک برای استفاده شخصی است و نیازی به تونل یا پروکسی ندارد.

یک نمونه عمومی یا اشتراکی، ماشینی متفاوت است که همان نرم‌افزار را اجرا می‌کند. نرخ پرس‌وجو (query rate) عامل محرک است و با افزودن هر کاربر افزایش می‌یابد، بنابراین چالش‌ها سریع‌تر از آن‌چه هر پیکربندی بتواند مدیریت کند، ظاهر می‌شوند. از همان ابتدا برای مجموعه‌ای کوچک‌تر از موتورهای جستجو برنامه‌ریزی کنید و به یاد داشته باشید که هر پروکسی که اکنون اضافه می‌کنید، جستجوهای دیگران را نیز با حساب کاربری شما منتقل می‌کند.

کلاینت‌های خودکار در این میان قرار می‌گیرند و به سمت سناریوهای دشوارتر متمایل هستند. عاملی (agent) که برای پاسخ به یک پرسش، چندین جستجو انجام می‌دهد، ترافیکی انفجاری ایجاد می‌کند که هیچ انسانی قادر به تولید آن نیست؛ بنابراین نمونه‌ای که ابزارهای کدنویسی و پژوهشی را به سمت آن هدایت می‌کنید، زودتر از نمونه‌ای که به‌صورت دستی استفاده می‌شود، با چالش مواجه خواهد شد. اگر کاربرد شما چنین است، مجموعه‌ای از موتورها را بر اساس پایداری انتخاب کنید، نه گستردگی، و اجازه دهید عامل با نتایجی کار کند که واقعاً قابل دریافت هستند.

قانون کلی این است: اگر موتور جستجو دلیل اصلی شما برای میزبانی شخصی (self-hosting) است، برای حفظ آن بجنگید؛ در غیر این صورت، آن را حذف کنید.

FAQ

چرا یک موتور جستجوی SearXNG پس از رفع مشکل همچنان نتیجه‌ای برنمی‌گرداند؟

زیرا آن موتور همچنان در حالت تعلیق است. هنگامی که SearXNG یک چالش یا امتناع از سوی یک موتور را شناسایی می‌کند، پرس‌وجو از آن موتور را برای مدتی که در search.suspended_times تعیین شده متوقف می‌کند؛ مقادیر پیش‌فرض ارائه‌شده در نرم‌افزار، بسته به نوع امتناع، از سه دقیقه تا پانزده روز متغیر هستند. وضعیت تعلیق در پردازش در حال اجرا نگهداری می‌شود، بنابراین راه‌اندازی مجدد container آن را پاک می‌کند و در جستجوی بعدی، موتور دوباره امتحان می‌شود. اگر موتور بلافاصله پس از راه‌اندازی مجدد دوباره شکست بخورد، یعنی اصلاح شما کارساز نبوده است.

آیا خطای CAPTCHA یک موتور با خطای 429 که instance من برمی‌گرداند یکی است؟

این دو در جهت مخالف حرکت می‌کنند. خطای 429 از سمت instance شما به مرورگر، محدودکننده داخلی خودِ SearXNG است که تشخیص داده درخواست شما خودکار به نظر می‌رسد و تنظیم آن بر عهده شماست. خطای CAPTCHA یا مسدودسازی، امتناع یک موتور بالادستی از پاسخ‌دهی به سرور شماست که بر روی سخت‌افزاری که شما کنترلی بر آن ندارید، تصمیم‌گیری شده است. اگر صفحه نتایج بارگذاری می‌شود و فقط برخی از موتورها غایب هستند، شما با مورد دوم مواجه هستید.

آیا استفاده از VPN یا پروکسی روی سرور، خطاهای CAPTCHA موتورها را رفع می‌کند؟

گاهی اوقات، اما هزینه‌هایی دارد. هدایت درخواست‌های خروجی از طریق outgoing.proxies، آدرسی را که موتور می‌بیند تغییر می‌دهد که می‌تواند مسدودسازی مرتبط با محدوده IP دیتاسنتر شما را رفع کند. در این حالت، اپراتور پروکسی می‌بیند که شما چه موتورهایی را در چه زمانی جستجو می‌کنید، یک آدرس خروجی مشترک با اعتبار سایر مشتریان به موتورها می‌رسد و تأخیر اضافه باعث ایجاد timeout می‌شود، مگر اینکه request_timeout و extra_proxy_timeout را افزایش دهید. Tor از طریق using_tor_proxy در دسترس است، اما آدرس‌های خروجی آن منتشر شده‌اند و به‌طور گسترده با چالش مواجه می‌شوند.

آیا می‌توانم SearXNG را طوری تنظیم کنم که CAPTCHA را به‌طور خودکار حل کند؟

هیچ تنظیمی برای این کار وجود ندارد. روشی که پروژه مستند کرده است، دستی است: یک تونل SSH SOCKS، مرورگر شخصی شما و حل دستی چالش توسط خودتان. هر سیستمی که برای پاسخ خودکار به چالش‌ها بسازید، برخلاف سیاست‌های اعلام‌شده موتورها عمل می‌کند و با هر بار تغییر چالش، بی‌سروصدا از کار می‌افتد؛ این یعنی شما به‌جای اجرای یک instance جستجو، درگیر نگهداری یک scraper خواهید شد. حذف موتورهایی که آدرس شما را مسدود می‌کنند، راهکاری است که همیشه کار می‌کند.