رفع خطای 429 و محدودیت نرخ در SearXNG

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

یک نمونه SearXNG که به‌صورت self-hosted اجرا شده، به دو دلیل نامرتبط خطای 429 برمی‌گرداند و محدودیت نرخی (rate limit) که باید اصلاح کنید، معمولاً آن چیزی نیست که تصور می‌کنید. دلیل اول محلی است: محدودکننده (limiter) خودِ SearXNG تشخیص داده که درخواست از طرف یک ربات بوده و با وضعیت 429 پاسخ داده است Too Many Requests. دلیل دوم مربوط به upstream است: یک موتور جستجو آدرس IP سرور شما را مسدود کرده است که این موضوع برای کاربران شما به‌صورت یک صفحه نتایج با موارد ناقص نمایش داده می‌شود، نه به شکل خطای 429.

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

این راهنما نصب کانتینری که در یک نمونه SearXNG خودمیزبان روی VPS شخصی توضیح داده شده را فرض می‌گیرد. تمام نام تنظیمات در ادامه، از مستندات و سورس‌کد فعلی upstream گرفته شده و در اوت 2026 بررسی شده‌اند.

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

مشکل را در حالی بازتولید کنید که پنجره لاگ باز است.

cd ./searxng/
docker compose logs -f searxng-core

پیام‌های محدودکننده (limiter) از لاگر با نام searx.limiter ارسال می‌شوند و یک آدرس IP را ذکر می‌کنند. برخورد با لیست سیاه (blocklist) به صورت BLOCK 203.0.113.10: matched BLOCKLIST و برخورد با لیست سفید (allowlist) به صورت PASS 203.0.113.10: matched PASSLIST ثبت می‌شود. اگر محدودکننده نتواند به ذخیره‌گاه شمارنده خود دسترسی پیدا کند، لاگ عبارت The limiter requires Valkey, please consult the documentation را نشان می‌دهد که به این معنی است که هیچ چیزی شمارش نمی‌شود.

هر بررسی ربات به صورت جداگانه در سطح debug ثبت می‌شود، بنابراین به‌طور پیش‌فرض آن را نخواهید دید. برای یک تست، سطح debug را در settings.yml فعال کنید:

general:
  debug: true

سپس لاگ خطوطی به شکل NOT OK (http_accept_language) را در کنار شبکه کلاینت اضافه می‌کند که نام بررسی ناموفق را ذکر می‌کند. پس از آن دوباره آن را غیرفعال کنید، زیرا مستندات بالادستی توصیه می‌کنند که یک نمونه (instance) مستقرشده را با سطح debug فعال اجرا نکنید.

خطاهای موتور (engine) هیچ شباهتی به این ندارند. آن‌ها به جای IP، نام یک موتور را ذکر می‌کنند و رایج‌ترین آن‌ها خطای timeout است:

HTTP requests timeout (search duration : 3.1 s, timeout: 3.0 s)

صفحه‌ای نیز برای این مورد وجود دارد. با باقی ماندن enable_metrics روی مقدار پیش‌فرض true، نمونه شما خطاهای موتور را در /stats/errors ثبت می‌کند و /preferences فهرست می‌کند که کدام موتورها در حال حاضر پاسخ می‌دهند. اگر /stats/errors پر است و لاگ هیچ خط searx.limiter را در خود ندارد، مشکل شما از محدودکننده نیست.

پیش از هرگونه عیب‌یابی، نسخه را ثابت (Pin) کنید

پیکربندی کانتینر بالادستی (upstream) شامل دو فایل است.

mkdir -p ./searxng/core-config/
cd ./searxng/

curl -fsSL \
    -O https://raw.githubusercontent.com/searxng/searxng/master/container/docker-compose.yml \
    -O https://raw.githubusercontent.com/searxng/searxng/master/container/.env.example

cp -i .env.example .env

فایل compose نسخه docker.io/searxng/searxng:${SEARXNG_VERSION:-latest} را دریافت می‌کند. تنظیم‌نشدن یک متغیر به معنای latest است و latest باعث می‌شود که نمونه (instance) در docker compose pull بعدی تغییر کند؛ بنابراین تنظیمی که هفتهٔ گذشته کار می‌کرد، ممکن است با کدی که آن را می‌خواند، ناسازگار شود. تگ‌های SearXNG شامل تاریخ و commit هستند. تگ نمونه در .env.example بالادستی تا اوت 2026 برابر با 2026.3.25-541c6c3cb است، پس یک تگ واقعی را در .env تنظیم کنید:

SEARXNG_VERSION=2026.3.25-541c6c3cb

تگ‌های منتشرشده را بررسی کنید و نسخه‌ای را که واقعاً تست کرده‌اید ثابت کنید، سپس عیب‌یابی را روی یک هدف مشخص انجام دهید. همان فایل .env کلید امنیتی شما را نگه می‌دارد، بنابراین پیش از commit کردن آن دایرکتوری در هر جایی، نحوه کار فایل‌های env و secrets در Docker Compose را مطالعه کنید.

محدودکننده به Valkey نیاز دارد، در غیر این صورت اجرا نمی‌شود

محدودکننده (limiter)، تعداد درخواست‌ها را به ازای هر کلاینت می‌شمارد و این شمارش‌ها باید بین پردازش‌های worker به اشتراک گذاشته شوند. این فضای ذخیره‌سازی، Valkey است که نسخه نگهداری‌شده و انشعاب (fork) از Redis محسوب می‌شود. راهنماهای قدیمی‌تر SearXNG این تنظیم را redis: می‌نامند. نسخه‌های فعلی از valkey: استفاده می‌کنند، بنابراین نام کلید را از مستندات فعلی کپی کنید و به پست‌های قدیمی تکیه نکنید.

use_default_settings: true
server:
  secret_key: "change-this-value"
  limiter: true
  public_instance: false
valkey:
  url: valkey://searxng-valkey:6379/0

فایل compose بالادستی، از قبل یک سرویس searxng-valkey را روی ایمیج docker.io/valkey/valkey:9-alpine اجرا می‌کند، بنابراین این نام میزبان (host name) در شبکه compose قابل حل است. همین مقدار را می‌توان با متغیر محیطی SEARXNG_VALKEY_URL تنظیم کرد و در صورتی که SearXNG و Valkey روی یک میزبان مشترک باشند، یک URL سوکت یونیکس (unix:///path/to/socket.sock?db=0) نیز کار می‌کند.

اینکه در صورت نبود فضای ذخیره‌سازی چه اتفاقی می‌افتد، به یک کلید دیگر بستگی دارد. با تنظیم public_instance: false، محدودکننده خطای Valkey را لاگ کرده و از کار می‌ایستد، بنابراین نمونه (instance) بدون هیچ‌گونه محدودیت نرخ (rate limiting) به سرویس‌دهی ادامه می‌دهد. با تنظیم public_instance: true، پردازش به جای آن sys.exit(1) را فراخوانی می‌کند؛ زیرا یک نمونه باز که محافظت در برابر ربات آن دچار اختلال شده است، ظرف یک روز از تمام موتورهای جستجو CAPTCHA (آزمون تورینگ عمومی کاملاً خودکار برای تشخیص انسان از کامپیوتر) دریافت می‌کند. کانتینری که بلافاصله پس از تنظیم public_instance: true در یک حلقه بازراه‌اندازی (restart loop) قرار می‌گیرد، دچار همین وضعیت است و آخرین خط پیش از هر خروج، به Valkey اشاره دارد.

محدودکننده دقیقاً چه چیزی را می‌شمارد

[
  {
    "label": "Burst, normal client",
    "max_requests": 15,
    "window": "20 seconds"
  },
  {
    "label": "Burst, flagged client",
    "max_requests": 2,
    "window": "20 seconds"
  },
  {
    "label": "Sustained, normal client",
    "max_requests": 150,
    "window": "10 minutes"
  },
  {
    "label": "Sustained, flagged client",
    "max_requests": 10,
    "window": "10 minutes"
  },
  {
    "label": "Any non-HTML format",
    "max_requests": 4,
    "window": "1 hour"
  },
  {
    "label": "Flagged requests before block",
    "max_requests": 3,
    "window": "30 days"
  }
]

یک کلاینت عادی در یک بازه زمانی 20 ثانیه‌ای مجاز به ارسال 15 درخواست و در یک بازه 10 دقیقه‌ای مجاز به ارسال 150 درخواست است. هنگامی که یک درخواست به عنوان مشکوک علامت‌گذاری شود، سقف مجاز برای همان کلاینت در هر بازه زمانی به 2 کاهش می‌یابد. ردیف آخر سخت‌گیرانه‌ترین حالت است: پس از 3 درخواست علامت‌گذاری‌شده در یک بازه 30 روزه، آن آدرس به‌جای جستجو به صفحه شروع هدایت می‌شود و لاگ عبارت BLOCK: too many request from ... in SUSPICIOUS_IP_WINDOW (redirect to /) را ثبت می‌کند.

این اعداد در searx/botdetection/ip_limit.py ثابت هستند. این مقادیر تنظیمات محسوب نمی‌شوند و limiter.toml نیز گزینه‌ای برای تغییر آن‌ها ارائه نمی‌دهد، بنابراین تغییر آن‌ها مستلزم ویرایش سورس‌کد است. آنچه /etc/searxng/limiter.toml کنترل می‌کند، پیشوندهای آدرسی است که برای گروه‌بندی کلاینت‌ها استفاده می‌شوند، لیست پروکسی‌های مورد اعتماد، بررسی اختیاری توکن لینک، و لیست‌های مجاز (pass) و مسدود (block).

یک درخواست بر اساس بررسی هدرها به عنوان مشکوک علامت‌گذاری می‌شود و هر بررسی نامی دارد که در لاگ دیباگ مشاهده خواهید کرد:

• http_accept: هدر Accept شامل text/html نیست.
• http_accept_encoding: هدر Accept-Encoding نه شامل gzip است و نه deflate.
• http_accept_language: هدر Accept-Language وجود ندارد.
• http_connection: هدر Connection روی close تنظیم شده است.
• http_user_agent: مقدار User-Agent وجود ندارد یا با الگوی ربات‌های شناخته‌شده مطابقت دارد.
• http_sec_fetch: هدر Sec-Fetch-Mode یا Sec-Fetch-Dest با آنچه یک مرورگر ارسال می‌کند، متفاوت است.

یک مرورگر تمام این موارد را ارسال می‌کند. یک فراخوانی ساده با curl تقریباً هیچ‌کدام از آن‌ها را ارسال نمی‌کند، بنابراین یک درخواست تست که به‌صورت دستی نوشته شده باشد در همان تلاش اول علامت‌گذاری می‌شود، در حالی که همان جستجو در تب مرورگر به‌درستی کار می‌کند. به همین دلیل است که «در مرورگر من کار می‌کند، اما اسکریپت من خطای 429 می‌گیرد» یک نتیجه طبیعی است و نه یک اتفاق مرموز.

مسدود شدن همه کاربران توسط محدودکننده در پشت reverse proxy

این رایج‌ترین روش برای از کار انداختن یک نمونه (instance) فعال است. SearXNG آدرس کلاینت را از اولین IP غیرقابل‌اعتماد در X-Forwarded-For می‌گیرد، سپس به X-Real-IP بازمی‌گردد و در نهایت به آدرسی که اتصال را برقرار کرده است رجوع می‌کند. اینکه آیا این هدرها اصلاً قابل‌اعتماد هستند یا خیر، توسط trusted_proxies در limiter.toml تعیین می‌شود.

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

اعتماد بیش از حد نیز وضعیت را بدتر می‌کند. اگر یک محدوده عمومی (public range) در لیست باشد، هر بازدیدکننده‌ای می‌تواند هدر X-Forwarded-For خود را ارسال کند و برای هر درخواست یک هویت جدید انتخاب کند؛ این کار عملاً محدودکننده را برای هر کسی که از این ترفند آگاه باشد، غیرفعال می‌کند. فقط آدرسی را در لیست قرار دهید که پروکسی شما از آن طریق متصل می‌شود. در Docker، این آدرس معمولاً یک شبکه bridge در داخل 172.16.0.0/12 است و آن خط به‌صورت پیش‌فرض کامنت شده است.

[botdetection]
ipv4_prefix = 32
ipv6_prefix = 48

trusted_proxies = [
  '127.0.0.0/8',
  '::1',
  '172.16.0.0/12',
]

پروکسی نیز باید هدرها را ارسال کند. Nginx به‌صورت خودکار هیچ‌کدام از آن‌ها را اضافه نمی‌کند:

location / {
    proxy_pass http://127.0.0.1:8080;

    proxy_set_header Host              $host;
    proxy_set_header Connection        $http_connection;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
}

Caddy و Traefik هدرهای forwarded را به‌صورت خودکار تنظیم می‌کنند، بنابراین با استفاده از آن‌ها فقط به بخش trusted_proxies از کار نیاز دارید. مزایا و معایب این روش‌ها در انتخاب یک reverse proxy برای سرویس‌های self-hosted بررسی شده است. برای تأیید صحت هر یک از تنظیمات، debug را فعال کنید، یک بار از طریق اینترنت موبایل گوشی خود جستجو کنید و بررسی کنید که شبکه ثبت‌شده در لاگ، آدرس گوشی شما باشد نه آدرس پروکسی.

عامل شما در هر ساعت چهار درخواست API دریافت می‌کند

خروجی JSON به‌صورت پیش‌فرض غیرفعال است، بنابراین عامل باید آن را اضافه کند:

search:
  formats:
    - html
    - json

حالا دوباره ردیف جدول را بخوانید. هر درخواستی که فرمتی غیر از HTML بخواهد، در پنجرهٔ اختصاصی خود شمارش می‌شود: 4 درخواست در هر 1 hour، برای هر آدرس. یک عامل تحقیق این سهمیه را در یک تسک مصرف می‌کند و هر فراخوانی پس از آن، خطای 429 برمی‌گرداند. افزایش محدودیت گزینه‌ای در دسترس نیست، زیرا این عدد در سورس‌کد تعریف شده است.

راهکار تمیز این است که به محدودکننده (limiter) بگویید این کلاینت یک غریبه نیست. آدرس آن را به لیست مجاز در limiter.toml اضافه کنید:

[botdetection.ip_lists]
block_ip = []

pass_ip = [
  '10.8.0.0/24',
]

pass_searxng_org = true

pass_ip نسبت به هر روش دیگری اولویت دارد، بنابراین کلاینتی که در لیست مجاز قرار دارد، بررسی‌های هدر را نیز دور می‌زند و یک فراخوانی ساده curl کار می‌کند. محدوده را تا حد امکان کوچک نگه دارید و یک زیرشبکه VPN یا شبکه کانتینری را به هر چیزی که قابل مسیریابی است ترجیح دهید. راهکار تمیز دیگر این است که عامل را به‌طور کامل از مسیر عمومی دور نگه دارید: آن را به آدرس کانتینر در شبکه داخلی هدایت کنید، جایی که پروکسی و محدودکنندهٔ آن هرگز ترافیک را نمی‌بینند. نحوهٔ پیاده‌سازی این مورد در آموزش مهارت جستجوی SearXNG به یک عامل هوش مصنوعی پوشش داده شده است.

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

زمانی که موتورهای جستجو شما را مسدود می‌کنند

[
  {
    "label": "SearxEngineTooManyRequests",
    "suspended_seconds": 3600,
    "roughly": "1 hour"
  },
  {
    "label": "SearxEngineAccessDenied",
    "suspended_seconds": 86400,
    "roughly": "1 day"
  },
  {
    "label": "SearxEngineCaptcha",
    "suspended_seconds": 86400,
    "roughly": "1 day"
  },
  {
    "label": "recaptcha_SearxEngineCaptcha",
    "suspended_seconds": 604800,
    "roughly": "7 days"
  },
  {
    "label": "cf_SearxEngineCaptcha",
    "suspended_seconds": 1296000,
    "roughly": "15 days"
  }
]

هنگامی که یک موتور جستجو با کد 429 یا صفحه CAPTCHA پاسخ می‌دهد، SearXNG یک استثنای نام‌گذاری‌شده ایجاد کرده و برای مدتی از آن موتور پرس‌وجو نمی‌کند. پاسخ «درخواست‌های بیش از حد» (too-many-requests)، آن موتور را به مدت 3600 ثانیه معلق می‌کند. یک CAPTCHA ساده یا پاسخ «دسترسی رد شد» (access-denied)، آن را به مدت 1 day معلق می‌سازد. CAPTCHAای که از طریق Cloudflare ارائه شود، موتور را به مدت 15 days معلق می‌کند که طولانی‌ترین زمان پیش‌فرض در لیست است، زیرا این پاسخ به معنای مسدودسازی در لبه شبکه (edge) است و تلاش مجدد کمکی نخواهد کرد.

خطاهای معمولی از تنظیمات متفاوتی استفاده می‌کنند. یک وقفه زمانی (timeout) یا خطای تجزیه (parse error)، موتور را برای مدت کوتاهی که از search.ban_time_on_fail مشتق شده معلق می‌کند؛ مقدار پیش‌فرض این پارامتر 5 ثانیه است و توسط search.max_ban_time_on_fail تا سقف 120 ثانیه محدود می‌شود. بنابراین، یک موتور کند خودبه‌خود در عرض چند دقیقه بازیابی می‌شود، اما یک موتور مسدودشده برای ساعت‌ها از دسترس خارج می‌ماند. این تفاوت، دلیلی بر علائمی است که کاربران به عنوان «تصادفی» گزارش می‌دهند: نتایج در ابتدا خوب هستند، اما نتایج یک موتور خاص برای باقی روز ناپدید می‌شود.

پیش از آنکه کسی را مقصر بدانید، ارزش دارد که وقفه‌های زمانی را اصلاح کنید. مقدار پیش‌فرض request_timeout برابر با 2.0 ثانیه است که برای یک VPS کوچک که از نزدیک‌ترین سرور لبه (edge server) موتور جستجو فاصله دارد، بسیار کم است.

outgoing:
  request_timeout: 3.0
  max_request_timeout: 10.0
engines:
  - name: bing
    timeout: 5.0

request_timeout مقدار پیش‌فرض برای هر موتور است، max_request_timeout سقف آن محسوب می‌شود و هر موتور می‌تواند timeout اختصاصی خود را داشته باشد. افزایش این مقادیر، تأخیر صفحه را در ازای خطاهای کمتر افزایش می‌دهد؛ بنابراین با گام‌های نیم‌ثانیه‌ای پیش بروید و به‌جای پریدن مستقیم به عدد 10، /stats/errors را زیر نظر بگیرید.

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

use_default_settings:
  engines:
    remove:
      - google

تغییرات را با docker compose restart searxng-core اعمال کنید، سپس چند جستجو انجام داده و /stats/errors را بازخوانی کنید. مشاهده یک صفحه خالی پس از پنج دقیقه استفاده واقعی، به این معناست که تغییرات اعمال شده‌اند.

آدرس IP دیتاسنتر به عنوان ربات شناسایی می‌شود

آدرس VPS شما متعلق به محدوده IPهای میزبانی (hosting) است و موتورهای جستجوی بزرگ، این محدوده‌ها را به عنوان منبع اتوماسیون امتیازدهی می‌کنند. برخی از آن‌ها بدون توجه به مودبانه بودن هدرها یا کند بودن نرخ درخواست‌ها، برای هر درخواست از چنین آدرسی CAPTCHA نمایش می‌دهند. هیچ تنظیمی در settings.yml این قضاوت را تغییر نمی‌دهد.

آنچه می‌توانید تغییر دهید، انتخاب موتورهای جستجویی است که از آن‌ها پرس‌وجو می‌کنید و همچنین عمومی بودن یا نبودن نمونه (instance) شماست. یک نمونه خصوصی که توسط یک خانوار استفاده می‌شود، به‌ندرت باعث فعال شدن محدودیت‌ها می‌شود. یک نمونه عمومی روی IP میزبانی، در سخت‌گیرترین موتورها با تعلیق مواجه خواهد شد و این وضعیت عادی نرم‌افزار است، نه خطایی در پیکربندی شما. SearXNG می‌تواند درخواست‌های موتورها را از طریق یک پروکسی با outgoing.proxies یا outgoing.using_tor_proxy هدایت کند که ترافیک را به آدرس دیگری منتقل می‌کند. گره‌های خروجی (exit nodes) و استخرهای پروکسی ارزان، امتیاز بدتری نسبت به محدوده‌های میزبانی دارند، بنابراین انتظار داشته باشید که این تغییر، کیفیت نتایج را کاهش دهد.

نظارت بر نمونه برای اطلاع سریع از وضعیت

سرویس SearXNG حتی زمانی که تمام موتورهای جستجو معلق هستند، روی پورت خود پاسخ می‌دهد؛ بنابراین بررسی uptime که فقط کد وضعیت HTTP را چک می‌کند، همچنان سبز باقی می‌ماند در حالی که نمونه هیچ نتیجه‌ای برنمی‌گرداند. محتوا را بررسی کنید: یک جستجوی واقعی انجام دهید و وجود یک کلمه مورد انتظار را در بدنه پاسخ (response body) مطابقت دهید. مانیتورینگ کلمات کلیدی در Uptime Kuma این کار را بدون نیاز به ابزار اضافی انجام می‌دهد. پس از هر ارتقای نسخه، /stats/errors را نیز زیر نظر بگیرید، زیرا موتورها ساختار HTML خود را تغییر می‌دهند و این موضوع باعث از کار افتادن پارسر می‌شود، بدون اینکه لزوماً با محدودیت نرخ (rate limit) مواجه شوید.

FAQ

چرا پس از قرار دادن SearXNG پشت یک reverse proxy، برای همه بازدیدکنندگان خطای 429 ارسال می‌شود؟

زیرا محدودکننده (limiter)، پروکسی را به عنوان کلاینت شناسایی می‌کند. SearXNG تنها زمانی X-Forwarded-For را می‌خواند که آدرس متصل‌شونده در trusted_proxies در فایل /etc/searxng/limiter.toml فهرست شده باشد. اگر این آدرس فهرست نشده باشد، همه بازدیدکنندگان از یک شمارنده مشترک استفاده می‌کنند و همگی با هم از حد مجاز 150 درخواست در هر 10 دقیقه عبور می‌کنند. آدرسی که پروکسی شما از آن متصل می‌شود (که در Docker معمولاً محدوده bridge یعنی 172.16.0.0/12 است) را اضافه کنید و مطمئن شوید که پروکسی هدرهای X-Real-IP و X-Forwarded-For را ارسال می‌کند. هرگز محدوده‌ای را که کنترل نمی‌کنید در این لیست قرار ندهید، زیرا یک شبکه مورد اعتماد به هر بازدیدکننده‌ای اجازه می‌دهد آن هدر را تنظیم کرده و برای هر درخواست یک هویت جدید انتخاب کند.

محدودکننده SearXNG در هر ساعت اجازه چند درخواست API را می‌دهد؟

چهار درخواست به ازای هر آدرس IP در هر ساعت. هر درخواستی که فرمتی غیر از HTML درخواست کند، در یک بازه زمانی یک‌ساعته جداگانه محاسبه می‌شود و این محدودیت به جای limiter.toml در searx/botdetection/ip_limit.py تنظیم شده است، بنابراین نمی‌توان آن را از طریق فایل پیکربندی افزایش داد. یک عامل (agent) یا اسکریپت، این درخواست را در یک تسک ارسال می‌کند. آدرس کلاینت را به pass_ip در limiter.toml اضافه کنید، یا از طریق یک شبکه داخلی که محدودکننده هرگز درخواست را در آن نمی‌بیند، به این instance دسترسی پیدا کنید.

چرا نتایج جستجوی من بدون دریافت خطای 429، خالی برمی‌گردند؟

موتورهای جستجو سرور شما را مسدود کرده‌اند، نه کاربران شما را. فایل /stats/errors را در instance خود باز کنید: این فایل نام هر موتوری که با شکست مواجه شده و دلیل آن را ذکر می‌کند. وجود CAPTCHA یا خطای access-denied به این معنی است که آن موتور، آدرس IP سرور شما را مسدود کرده است. SearXNG سپس آن موتور را تعلیق می‌کند؛ برای یک ساعت پس از دریافت پاسخ too-many-requests و برای یک روز پس از دریافت CAPTCHA. هیچ تنظیمات محلی نمی‌تواند مسدودسازی از سمت سرور مقصد (upstream) را رفع کند، بنابراین موتورهایی که آدرس شما را مسدود می‌کنند حذف کرده و فقط موتورهایی که پاسخ می‌دهند را نگه دارید.

آیا باید محدودکننده را روی یک instance خصوصی فعال کنم؟

اگر هیچ ترافیکی جز ترافیک خودتان به instance نمی‌رسد، limiter: false را غیرفعال بگذارید. این کار یک وابستگی به Valkey ایجاد می‌کند، اسکریپت‌های خودتان را مسدود می‌کند و از شما در برابر ترافیکی که ندارید محافظت می‌کند. به محض اینکه instance دارای یک آدرس عمومی شد، آن را به همراه public_instance: true فعال کنید. این جفت تنظیمات هدفمند هستند: با public_instance: true و بدون وجود یک Valkey فعال، پروسه به جای اجرا شدن بدون محافظت، با وضعیت 1 متوقف می‌شود.