SearXNG 429 Errors మరియు Rate Limits ఎలా సరిచేయాలి

SearXNG 429 errors ను ఎందుకు ఇస్తుంది

Self-hosted SearXNG instance రెండు సంబంధం లేని కారణాల వల్ల 429 errors ను ఇస్తుంది. మీరు సరిచేయాల్సిన rate limit సాధారణంగా మీరు ఊహించేది కాదు. మొదటి కారణం స్థానికమైనది: ఒక request bot నుంచి వచ్చిందని SearXNG యొక్క స్వంత limiter నిర్ణయించి, Too Many Requests కు status 429 తో సమాధానం ఇచ్చింది. రెండవది upstream కారణం: ఒక search engine మీ server IP address ను తిరస్కరించింది. దీని ప్రభావం మీ users కు 429గా కాకుండా, కొన్ని అంశాలు లేని results page గా కనిపిస్తుంది.

ఈ రెండు సందర్భాలకు ఒకే పరిష్కారం ఉండదు. Limiter మీ నియంత్రణలో ఉంటుంది కాబట్టి దాన్ని మార్చవచ్చు. Upstream blocking Google వైపున జరుగుతుంది కాబట్టి మీ settings.yml లో చేసే ఏ మార్పూ దాన్ని తొలగించదు. మీకు ఏ సందర్భం ఎదురైందో సుమారు ఒక నిమిషంలో log చెబుతుంది. కాబట్టి ముందుగా దానినే పరిశీలించండి.

ఈ guide మీ స్వంత VPSలో self-hosted SearXNG instanceలో వివరించిన container install ను ఆధారంగా తీసుకుంటుంది. దిగువన ఉన్న ప్రతి setting name ప్రస్తుత upstream documentation మరియు source నుంచి తీసుకోబడింది. వీటిని August 2026లో తనిఖీ చేశాము.

మార్పు చేసే ముందు log పరిశీలించండి

log window తెరిచి సమస్యను మళ్లీ ఉత్పత్తి చేయండి.

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

Limiter సందేశాలు searx.limiter పేరుతో ఉన్న logger నుంచి వస్తాయి. వాటిలో IP address ఉంటుంది. Blocklist hit ఇలా కనిపిస్తుంది: BLOCK 203.0.113.10: matched BLOCKLIST. Allowlist hit ఇలా కనిపిస్తుంది: PASS 203.0.113.10: matched PASSLIST. Limiter తన counter store ను చేరుకోలేకపోతే log లో The limiter requires Valkey, please consult the documentation కనిపిస్తుంది. అంటే ఎలాంటి లెక్కింపూ జరగడం లేదు.

ప్రతి bot check debug level వద్ద log అవుతుంది. అందువల్ల అవి default గా కనిపించవు. settings.yml లో ఒక పరీక్ష కోసం debug ను ప్రారంభించండి:

general:
  debug: true

తర్వాత log లో client network పక్కన NOT OK (http_accept_language) ఆకారంలోని lines జతచేయబడతాయి. విఫలమైన check పేరు కూడా అందులో ఉంటుంది. ఆ తరువాత debug ను మళ్లీ ఆపండి. అమలులో ఉన్న instance ను debug on తో నడపవద్దని upstream సూచిస్తుంది.

Engine failures దీనికి పూర్తిగా భిన్నంగా కనిపిస్తాయి. వాటిలో IP బదులుగా engine పేరు ఉంటుంది. సాధారణంగా కనిపించేది timeout:

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

దీనికి ప్రత్యేక page కూడా ఉంది. default విలువ true గా ఉన్న enable_metrics తో, మీ instance engine errors ను /stats/errors వద్ద record చేస్తుంది. ప్రస్తుతం ఏ engines సమాధానం ఇస్తున్నాయో /preferences చూపిస్తుంది. /stats/errors నిండిగా ఉండి, log లో searx.limiter lines ఏవీ లేకపోతే, సమస్య limiter లో లేదు.

మీరు ఏదైనా debug చేయడానికి ముందు version ను స్థిరపరచండి

upstream container setup రెండు files తో ఉంటుంది.

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 file docker.io/searxng/searxng:${SEARXNG_VERSION:-latest} ను pull చేస్తుంది. unset variable అంటే latest. latest అంటే తదుపరి docker compose pull నాటికి instance మీ నియంత్రణ లేకుండా మారుతుంది. అందువల్ల గత వారం పనిచేసిన setting, దాన్ని చదివే code కు ఇక సరిపోకపోవచ్చు. SearXNG tags లో date మరియు commit ఉంటాయి. August 2026 నాటికి upstream .env.example లోని example tag 2026.3.25-541c6c3cb. కాబట్టి .env లో నిజమైన version ను సెట్ చేయండి:

SEARXNG_VERSION=2026.3.25-541c6c3cb

ప్రచురించిన tags ను పరిశీలించి, మీరు వాస్తవంగా పరీక్షించిన release ను pin చేయండి. తరువాత స్థిరమైన target పై debug చేయండి. అదే .env file లో మీ secret key కూడా ఉంటుంది. కాబట్టి ఆ directory ని ఎక్కడైనా commit చేయడానికి ముందు Docker Compose లో env files మరియు secrets ఎలా పనిచేస్తాయో చదవండి.

Limiter కు Valkey అవసరం; లేకపోతే అది పనిచేయదు

Limiter ప్రతి client నుంచి వచ్చే requests ను లెక్కిస్తుంది. ఆ లెక్కలను worker processes మధ్య పంచుకోవాలి. ఈ store Valkey. ఇది Redis యొక్క నిర్వహించబడుతున్న fork. పాత SearXNG guides ఈ setting ను redis: అని పేర్కొంటాయి. ప్రస్తుత releases valkey: ను చదువుతాయి. అందువల్ల పాత post నుంచి కాకుండా ప్రస్తుత documentation నుంచి key name ను copy చేయండి.

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

Upstream compose file ఇప్పటికే searxng-valkey service ను docker.io/valkey/valkey:9-alpine image పై నడుపుతుంది. అందువల్ల ఆ host name compose network లో resolve అవుతుంది. అదే విలువను SEARXNG_VALKEY_URL environment variable తో set చేయవచ్చు. SearXNG మరియు Valkey ఒకే host ను share చేస్తే Unix socket URL (unix:///path/to/socket.sock?db=0) కూడా పనిచేస్తుంది.

Store అందుబాటులో లేకపోతే ఏమి జరుగుతుందో మరొక key పై ఆధారపడి ఉంటుంది. public_instance: false తో limiter Valkey error ను log చేసి ఆగిపోతుంది. అందువల్ల instance rate limiting లేకుండానే requests ను అందించడం కొనసాగిస్తుంది. public_instance: true తో process బదులుగా sys.exit(1) ను call చేస్తుంది. Broken bot protection ఉన్న open instance ఒక రోజులో ప్రతి engine నుంచి CAPTCHAs (completely automated public turing test to tell computers and humans apart) ను సేకరిస్తుంది. public_instance: true ను set చేసిన వెంటనే container loop లో restart అవుతుంటే, కారణం ఇదే. ప్రతి exit కు ముందు కనిపించే చివరి line 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"
  }
]

సాధారణ client 20 సెకన్ల burst window లో 15 requests, 10 నిమిషాల window లో 150 requests పంపగలదు. ఒక request అనుమానాస్పదంగా గుర్తించబడిన తర్వాత, అదే client ప్రతి burst window లో 2 requests కు పరిమితం అవుతుంది. చివరి వరుసలో పరిమితి అత్యంత కఠినంగా ఉంటుంది: 30 రోజుల window లో 3 అనుమానాస్పద requests గుర్తించబడిన తర్వాత, ఆ address ను search చేయడానికి బదులుగా start page కు redirect చేస్తుంది. Log లో BLOCK: too many request from ... in SUSPICIOUS_IP_WINDOW (redirect to /) అని కనిపిస్తుంది.

ఈ సంఖ్యలు searx/botdetection/ip_limit.py లో constants గా ఉన్నాయి. ఇవి settings కావు. limiter.toml వీటిని మార్చే అవకాశం ఇవ్వదు. కాబట్టి వీటిని మార్చాలంటే source ను సవరించాలి. /etc/searxng/limiter.toml నియంత్రించేది clients ను సమూహాలుగా విభజించడానికి ఉపయోగించే address prefixes, trusted proxies జాబితా, optional link token check, అలాగే pass మరియు block lists.

Header checks ఆధారంగా ఒక request అనుమానాస్పదంగా గుర్తించబడుతుంది. ప్రతి check కు ఒక పేరు ఉంటుంది. ఆ పేరు debug log లో కనిపిస్తుంది:

• http_accept: Accept header లో text/html లేదు.
• http_accept_encoding: Accept-Encoding header లో gzip లేదా deflate ఏదీ లేదు.
• http_accept_language: Accept-Language header లేదు.
• http_connection: Connection header కు close విలువ సెట్ చేయబడింది.
• http_user_agent: User-Agent లేదు లేదా తెలిసిన bot pattern కు సరిపోతుంది.
• http_sec_fetch: Sec-Fetch-Mode లేదా Sec-Fetch-Dest header browser పంపే విలువకు సరిపోలదు.

Browser ఈ headers అన్నింటినీ పంపుతుంది. సాధారణ curl call వీటిలో దాదాపు ఏదీ పంపదు. అందువల్ల చేతితో రాసిన test request మొదటి ప్రయత్నంలోనే గుర్తించబడుతుంది. అదే search browser tab లో పనిచేస్తుంది. అందుకే “నా browser లో పనిచేస్తోంది, కానీ నా script కు 429 వస్తోంది” అనేది సాధారణ ఫలితం; ఇది ఏదైనా మర్మమైన సమస్య కాదు.

Reverse proxy వెనుక limiter అందరినీ ఒకేసారి block చేస్తుంది

పనిచేస్తున్న instance ను పాడుచేసే అత్యంత సాధారణ కారణం ఇదే. SearXNG client address ను X-Forwarded-For లోని మొదటి untrusted IP నుంచి తీసుకుంటుంది. అది అందుబాటులో లేకపోతే X-Real-IP ను ఉపయోగిస్తుంది. అది కూడా అందుబాటులో లేకపోతే connection ప్రారంభించిన address ను ఉపయోగిస్తుంది. ఆ headers ను నమ్మాలా వద్దా అనేది limiter.toml లోని trusted_proxies నిర్ణయిస్తుంది.

మీ proxy address ఆ జాబితాలో లేకపోతే headers ను విస్మరిస్తుంది. అప్పుడు ప్రతి visitor proxy address తోనే వస్తారు. అందరూ ఒకే counter ను పంచుకుంటారు. మొత్తం అభ్యర్థనలు 10 నిమిషాల్లో 150 దాటిన వెంటనే మొత్తం site ఒకేసారి block అవుతుంది. ఒక user results page ను కొన్ని సార్లు reload చేసినా అందరికీ service ఆగిపోతుంది.

అతి ఎక్కువగా trust చేయడం ఇంకా ప్రమాదకరం. ఒక public range ను జాబితాలో చేరిస్తే, ఏ visitor అయినా స్వంత X-Forwarded-For header పంపవచ్చు. ప్రతి request కు కొత్త identity ఎంచుకోవచ్చు. దీని వల్ల ప్రయత్నించడం తెలిసిన ఎవరికైనా limiter పనిచేయకుండా చేయవచ్చు. మీ స్వంత proxy ఏ address నుంచి connect అవుతుందో ఆ address ను మాత్రమే జాబితాలో చేర్చండి. Docker లో అది సాధారణంగా 172.16.0.0/12 లోని bridge network అవుతుంది. ఆ line సాధారణంగా comment చేసి ఉంటుంది.

[botdetection]
ipv4_prefix = 32
ipv6_prefix = 48

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

Proxy కూడా ఈ headers ను పంపాలి. 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 headers ను మీ కోసం సెట్ చేస్తాయి. కాబట్టి వాటితో trusted_proxies భాగం మాత్రమే చేయాలి. దీనిలోని trade-offs ను self-hosted service కోసం reverse proxy ఎంచుకోవడం లో వివరించారు. రెండు setup లలో ఏదైనా verify చేయడానికి debug ను on చేయండి. Mobile data ఉపయోగిస్తున్న phone నుంచి ఒకసారి search చేయండి. Log line లోని network మీ phone address గానే ఉందని, proxy address కాదని నిర్ధారించండి.

మీ agent కు గంటకు నాలుగు API అభ్యర్థనలు

JSON output డిఫాల్ట్‌గా నిలిపివేయబడి ఉంటుంది. కాబట్టి దాన్ని agent కు జోడించాలి:

search:
  formats:
    - html
    - json

ఇప్పుడు chart row ను మళ్లీ చూడండి. HTML కాకుండా వేరే format కోరే ప్రతి అభ్యర్థనకు ప్రత్యేక window ఉంటుంది: ఒక్కో address కు, ప్రతి 1 hour వ్యవధిలో 4 అభ్యర్థనలు. ఒక research agent ఆ పరిమితిని ఒకే task లో పూర్తిచేస్తుంది. ఆ తర్వాతి ప్రతి call 429 ను తిరిగి ఇస్తుంది. ఈ పరిమితిని పెంచడం సాధ్యం కాదు, ఎందుకంటే ఆ సంఖ్య source లోనే ఉంది.

దీనికి సరైన పరిష్కారం ఈ client తెలియని client కాదని limiter కు తెలియజేయడం. దీని address ను limiter.toml లోని pass list కు జోడించండి:

[botdetection.ip_lists]
block_ip = []

pass_ip = [
  '10.8.0.0/24',
]

pass_searxng_org = true

pass_ip కు అన్ని ఇతర పద్ధతుల కంటే ప్రాధాన్యత ఉంటుంది. అందువల్ల allowlist లో ఉన్న client header checks ను కూడా దాటుతుంది, అలాగే ఖాళీ curl call పనిచేస్తుంది. సాధ్యమైనంత చిన్న range ను ఉంచండి. Routable పరిధి కంటే VPN subnet లేదా container network కు ప్రాధాన్యత ఇవ్వండి. మరో సరైన పరిష్కారం agent ను public path నుంచి పూర్తిగా దూరంగా ఉంచడం. Proxy మరియు దాని limiter network traffic ను చూడని internal network లోని container address కు దాన్ని పంపండి. దీన్ని ఎలా అమలు చేయాలో AI agent కు SearXNG search skill ఇవ్వడం లో వివరించబడింది.

ఇతరులు నిర్వహించే public instance కు agent ను పంపడం నివారించాలి. దాని వల్ల volunteer యొక్క IP address upstream engines చేత block చేయబడే అవకాశం అత్యధికంగా ఉంటుంది. JSON format డిఫాల్ట్‌గా నిలిపివేయబడటానికి ఇదే కారణం.

మీకు బదులుగా search engines మిమ్మల్ని నిరోధించినప్పుడు

[
  {
    "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 సమాధానం ఆ engine ను 3600 సెకన్లపాటు నిలిపివేస్తుంది. సాధారణ CAPTCHA లేదా access-denied సమాధానం దాన్ని 1 day పాటు నిలిపివేస్తుంది. Cloudflare ద్వారా అందిన CAPTCHA దాన్ని 15 days పాటు నిలిపివేస్తుంది. జాబితాలో ఇదే అత్యంత దీర్ఘమైన default వ్యవధి, ఎందుకంటే ఆ సమాధానం నిరోధం edge వద్ద ఉందని సూచిస్తుంది. మళ్లీ ప్రయత్నించడం ఉపయోగపడదు.

సాధారణ వైఫల్యాలకు వేరు settings ఉపయోగిస్తారు. Timeout లేదా parse error కారణంగా engine ను search.ban_time_on_fail నుంచి లెక్కించిన స్వల్ప కాలంపాటు నిలిపివేస్తుంది. దీని default విలువ 5 seconds, అలాగే search.max_ban_time_on_fail దాన్ని 120 seconds కు పరిమితం చేస్తుంది. అందువల్ల నెమ్మదిగా ఉన్న engine రెండు నిమిషాల్లో స్వయంగా తిరిగి పనిచేస్తుంది, కానీ నిరోధించబడిన engine గంటలపాటు అందుబాటులో ఉండదు. దీనివల్ల కొందరు random గా భావించే లక్షణం కనిపిస్తుంది: మొదట results సరిగ్గా ఉంటాయి, తరువాత ఒక engine కు చెందిన results మిగిలిన మధ్యాహ్నం మొత్తం కనిపించవు.

ఎవరినైనా నిందించే ముందు timeouts ను సరిచేయడం మంచిది. Default request_timeout విలువ 2.0 seconds. Engine కు సమీపంలోని edge server కు చాలా దూరంలో ఉన్న చిన్న VPS కు ఇది తక్కువ సమయమే కావచ్చు.

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

request_timeout ప్రతి engine కు default విలువ, max_request_timeout గరిష్ఠ పరిమితి, ఒక్కో engine కు ప్రత్యేకమైన timeout కూడా ఉండవచ్చు. వీటిని పెంచితే page latency పెరుగుతుంది, కానీ failures తగ్గుతాయి. కాబట్టి నేరుగా 10 కు మార్చకుండా, అర సెకను చొప్పున పెంచుతూ /stats/errors ను పరిశీలించండి.

మీ address ను engine నిజంగా నిరోధిస్తుంటే, దాన్ని తొలగించండి. ప్రతి search అత్యంత నెమ్మదిగా ఉన్న engine కోసం వేచి ఉంటుంది. కాబట్టి శాశ్వతంగా suspended గా ఉన్న engine ను ఉంచడం latency ను పెంచుతుంది, కానీ ఫలితాలు ఇవ్వదు.

use_default_settings:
  engines:
    remove:
      - google

docker compose restart searxng-core తో మార్పులను అమలు చేయండి. తరువాత కొన్ని searches నిర్వహించి /stats/errors ను reload చేయండి. ఐదు నిమిషాల వాస్తవ వినియోగం తర్వాత కూడా page ఖాళీగా ఉంటే, మార్పు పనిచేసిందని అర్థం.

Datacentre IP botగా పరిగణించబడుతుంది

మీ VPS చిరునామా hosting rangeకు చెందినది. పెద్ద search engines ఆ rangeలను automationగా పరిగణిస్తాయి. కొన్ని engines అలాంటి చిరునామా నుంచి వచ్చే ప్రతి requestకు CAPTCHA చూపిస్తాయి. Headers ఎంత సరిగ్గా ఉన్నా, requests ఎంత నెమ్మదిగా పంపినా ఇది మారదు. settings.ymlలోని ఏ setting కూడా ఆ నిర్ణయాన్ని మార్చదు.

మీరు మార్చగలిగేది ఏ enginesను ఉపయోగించాలో, అలాగే మీ instanceను publicగా జాబితా చేయాలా వద్దా అన్నది. ఒక household మాత్రమే ఉపయోగించే private instance సాధారణంగా ఎలాంటి నిరోధాన్నీ కలిగించదు. Hosting IPపై ఉన్న public instance కఠినమైన enginesలో suspensionలను ఎదుర్కొంటుంది. ఇది మీ configలోని fault కాదు. Software యొక్క సాధారణ ప్రవర్తన ఇదే. SearXNG outgoing.proxies లేదా outgoing.using_tor_proxyతో engine requestsను proxy ద్వారా route చేయగలదు. దీంతో network traffic వేరే చిరునామా నుంచి వెళ్తుంది. Exit nodes మరియు చవకైన proxy poolsను hosting ranges కంటే మరింత ప్రతికూలంగా score చేస్తారు. అందువల్ల ఈ మార్పుతో results మరింత దారుణంగా మారవచ్చని భావించండి.

ఇన్‌స్టాన్స్‌ను పర్యవేక్షించండి, సమస్యను ముందుగా గుర్తించండి

ప్రతి engine suspended స్థితిలో ఉన్నప్పటికీ SearXNG తన port పై సమాధానం ఇస్తుంది. అందువల్ల status code ను మాత్రమే పర్యవేక్షించే uptime check green గానే ఉంటుంది, కానీ instance ఎలాంటి ఫలితాన్ని ఇవ్వదు. అందుకు బదులుగా content ను తనిఖీ చేయండి: నిజమైన search అభ్యర్థన పంపి, response body లో మీరు ఆశించే పదం ఉందో లేదో సరిపోల్చండి. Uptime Kuma keyword monitoring అదనపు tooling లేకుండానే ఇదే పని చేస్తుంది. ప్రతి version bump తర్వాత కూడా /stats/errors ను పర్యవేక్షించండి. Engines తమ HTML ను మార్చవచ్చు. అప్పుడు rate limit సంబంధం లేకుండానే parser విఫలమవుతుంది.

FAQ

SearXNG ను reverse proxy వెనుక ఉంచిన తర్వాత ప్రతి visitor కు 429 ఎందుకు వస్తోంది?

Limiter proxyని clientగా లెక్కిస్తోంది. కనెక్ట్ అవుతున్న address ను /etc/searxng/limiter.toml లోని trusted_proxies లో నమోదు చేసినప్పుడు మాత్రమే SearXNG X-Forwarded-For ను చదువుతుంది. అది నమోదు కాకపోతే ప్రతి visitor ఒకే counterను పంచుకుంటారు. అప్పుడు 10 నిమిషాలకు 150 requests పరిమితిని అందరూ కలిసి దాటుతారు. మీ proxy కనెక్ట్ అయ్యే addressను జోడించండి. Dockerలో అది సాధారణంగా bridge range 172.16.0.0/12 గా ఉంటుంది. Proxy X-Real-IP మరియు X-Forwarded-For ను పంపుతోందని నిర్ధారించండి. మీరు నియంత్రించని rangeను ఎప్పుడూ నమోదు చేయవద్దు. Trusted network ఉంటే ఏ visitor అయినా ఆ headerను సెట్ చేసి ప్రతి requestకు కొత్త identity ఎంచుకోగలడు.

SearXNG limiter గంటకు ఎన్ని API requests అనుమతిస్తుంది?

ప్రతి IP addressకు గంటకు నాలుగు requests అనుమతిస్తుంది. HTML కాకుండా వేరే formatను అడిగే ప్రతి request ప్రత్యేక ఒక గంట windowలో లెక్కించబడుతుంది. ఆ పరిమితి limiter.toml లో కాకుండా searx/botdetection/ip_limit.py లో సెట్ చేయబడుతుంది. అందువల్ల దాన్ని config నుంచి పెంచలేరు. ఒక agent లేదా script ఒక taskలోనే ఆ పరిమితిని దాటుతుంది. Client addressను limiter.toml లోని pass_ip కు జోడించండి. లేదా limiter requestను చూడని internal network ద్వారా instanceను చేరుకోండి.

429 error లేకుండా నా search results ఖాళీగా ఎందుకు వస్తున్నాయి?

మీ usersను కాదు, మీ serverను engines తిరస్కరిస్తున్నాయి. మీ స్వంత instanceలో /stats/errors ను తెరవండి. విఫలమైన ప్రతి engine పేరు, కారణం అందులో కనిపిస్తాయి. CAPTCHA లేదా access-denied entry కనిపిస్తే, ఆ engine మీ server IP addressను block చేసిందని అర్థం. Too-many-requests సమాధానం వచ్చిన తర్వాత SearXNG engineను ఒక గంటపాటు suspend చేస్తుంది. CAPTCHA వచ్చిన తర్వాత ఒక రోజు suspend చేస్తుంది. Upstream blockను ఏ local setting కూడా తొలగించదు. అందువల్ల మీ addressను block చేసే enginesను తొలగించి, సమాధానం ఇచ్చే enginesను ఉంచండి.

Private instanceలో limiterను enable చేయాలా?

మీరు తప్ప మరెవరూ instanceను చేరుకోకపోతే limiter: false ను అలాగే ఉంచండి. ఇది Valkey dependencyను జోడిస్తుంది. మీ స్వంత scriptsను కూడా block చేస్తుంది. మీకు అవసరం లేని traffic నుంచి రక్షణ అందిస్తుంది. Instanceకు public address వచ్చిన వెంటనే, public_instance: true తో పాటు దీన్ని enable చేయండి. ఆ జత ఉద్దేశపూర్వకంగా రూపొందించబడింది. public_instance: true సెట్ చేసి పనిచేసే Valkey లేకపోతే, process రక్షణ లేకుండా నడవకుండా status 1తో exit అవుతుంది.