رفع خطای 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 قرار دارند. پیش از جای‌گذاری هر چیزی، این نام‌های کلیدی را با مستندات تنظیمات نسخهٔ در حال اجرای خود تطبیق دهید، زیرا این تنظیمات در نسخه‌های مختلف جابه‌جا شده‌اند. طبق مستندات مورخ 2 September 2026، مقادیر پیش‌فرض به شرح زیر است:

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

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

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

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

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

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

در تاریخ 2 سپتامبر 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: 2.0
  extra_proxy_timeout: 10.0
  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) را حل کند، socks5h:// را به socks5:// ترجیح دهید، زیرا h به این معنی است که نام به جای جستجو در سرور شما، به پروکسی ارسال می‌شود. همزمان بودجه زمانی (timeout) را افزایش دهید. مقدار پیش‌فرض request_timeout برابر با 2.0 ثانیه است؛ یک پروکسی به هر درخواست یک رفت‌وبرگشت اضافه می‌کند و موتورهایی که قبلاً در زمان مناسب پاسخ می‌دادند، اکنون با خطای timeout مواجه می‌شوند. extra_proxy_timeout دقیقاً برای همین منظور وجود دارد و هنگام استفاده از پروکسی، ثانیه‌های بیشتری به زمان مجاز اضافه می‌کند.

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

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

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

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

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

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

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

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

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

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

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

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

FAQ

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

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

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

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

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

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

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

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