رفع خطای 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 ثبت می‌شود. اگر محدودکننده نتواند به ذخیره‌گاه شمارنده (counter store) خود دسترسی پیدا کند، لاگ عبارت 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

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

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

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

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

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

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

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

[botdetection]
ipv4_prefix = 32
ipv6_prefix = 48

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

proxy نیز باید هدرها را ارسال کند. 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 را فعال کنید، یک بار با گوشی خود از طریق اینترنت موبایل جستجو انجام دهید و در خط لاگ بررسی کنید که شبکه نمایش‌داده‌شده، آدرس گوشی شما باشد نه آدرس proxy.

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

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

search:
  formats:
    - html
    - json

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

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

[botdetection.ip_lists]
block_ip = []

pass_ip = [
  '10.8.0.0/24',
]

pass_searxng_org = true

pass_ip نسبت به هر روش دیگری اولویت دارد، بنابراین کلاینتی که در لیست مجاز قرار دارد، بررسی‌های هدر را نیز دور می‌زند و یک فراخوانی ساده curl به‌درستی کار می‌کند. محدوده را تا حد امکان کوچک نگه دارید و استفاده از یک زیرشبکه VPN یا شبکه کانتینری را به هر مسیر قابل مسیریابی (routable) ترجیح دهید. راه‌حل تمیز دیگر این است که عامل را به‌طور کامل از مسیر عمومی دور نگه دارید: آن را به آدرس کانتینر در شبکه داخلی هدایت کنید، جایی که پروکسی و محدودکننده آن، ترافیک را مشاهده نمی‌کنند. نحوه پیاده‌سازی این مورد در آموزش مهارت جستجوی 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"
  }
]

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

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

پیش از مقصر دانستن دیگران، ارزش دارد که وقفه‌های زمانی (timeouts) را اصلاح کنید. مقدار پیش‌فرض 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 را بازخوانی کنید. مشاهده یک صفحه خالی پس از پنج دقیقه استفاده واقعی، به این معناست که تغییرات اعمال شده‌اند.

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

آدرس VPS شما متعلق به یک محدوده میزبانی (hosting range) است و موتورهای جستجوی بزرگ، این محدوده‌ها را به عنوان منبع اتوماسیون امتیازدهی می‌کنند. برخی از آن‌ها برای هر درخواستی که از چنین آدرسی ارسال شود، بدون توجه به مودبانه بودن هدرها یا کند بودن سرعت ارسال، CAPTCHA نمایش می‌دهند. هیچ تنظیمی در settings.yml این قضاوت را تغییر نمی‌دهد. این‌که موتورهای جستجو به جای فرد تایپ‌کننده، سرور شما را می‌بینند، تمامِ بهای حریم خصوصی است که با self-hosting پرداخته‌اید؛ مطالعه میزان واقعی پنهان‌سازی در SearXNG پیش از آن‌که تصور کنید این ابزار فراتر از این عمل می‌کند، ضروری است.

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

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

سرویس SearXNG حتی زمانی که تمام موتورهای جستجو معلق هستند، روی پورت خود پاسخ می‌دهد؛ بنابراین بررسی uptime که فقط وضعیت کد پاسخ (status code) را چک می‌کند، همچنان سبز باقی می‌ماند در حالی که نمونه هیچ نتیجه‌ای برنمی‌گرداند. محتوا را بررسی کنید: یک جستجوی واقعی انجام دهید و وجود کلمه‌ای که انتظار دارید در بدنه پاسخ باشد را مطابقت دهید. نظارت بر کلمات کلیدی در Uptime Kuma دقیقاً همین کار را بدون نیاز به ابزار اضافی انجام می‌دهد. پس از هر بار ارتقای نسخه، /stats/errors را نیز زیر نظر بگیرید، زیرا موتورها ساختار HTML خود را تغییر می‌دهند و این موضوع باعث از کار افتادن parser می‌شود، بدون اینکه محدودیت نرخ (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. هیچ تنظیمات محلی نمی‌تواند مسدودسازی از سمت سرویس‌دهنده بالادستی را رفع کند، بنابراین موتورهایی که آدرس شما را مسدود می‌کنند حذف کرده و موتورهایی که پاسخ می‌دهند را نگه دارید.

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

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