SearXNG 429 errors మరియు rate limits ఎలా సరిచేయాలి

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

Self-hosted SearXNG instance రెండు పరస్పర సంబంధం లేని కారణాల వల్ల 429 errors ను తిరిగి ఇస్తుంది. మీరు సరిచేయాల్సిన rate limit సాధారణంగా మీరు అనుకునేది కాదు. మొదటి కారణం local: ఒక 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 పేరు August 2026 లో పరిశీలించిన ప్రస్తుత upstream documentation మరియు source నుంచి తీసుకోబడింది.

సెట్టింగ్ మార్చే ముందు 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 అని కనిపిస్తుంది. అంటే ఏదీ count కావడం లేదు.

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

general:
  debug: true

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

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

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

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

ఏదైనా డీబగ్ చేయడానికి ముందు 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 చేస్తుంది. Variable unset గా ఉంటే 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 ను set చేయండి:

SEARXNG_VERSION=2026.3.25-541c6c3cb

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

లిమిటర్‌కు Valkey అవసరం; లేకపోతే అది పనిచేయదు

లిమిటర్ ప్రతి client పంపే అభ్యర్థనలను లెక్కిస్తుంది. ఆ లెక్కలను worker processes మధ్య పంచుకోవాలి. ఈ store Valkey, ఇది Redis యొక్క నిర్వహించబడుతున్న fork. పాత SearXNG మార్గదర్శకాల్లో ఈ setting ను redis: అని పేర్కొంటారు. ప్రస్తుత releases valkey: ను చదువుతాయి. అందువల్ల పాత post నుండి కాకుండా ప్రస్తుత documentation నుండి key name ను copy చేయండి. కొన్ని pages ఇంకా పాత సమాచారాన్ని ఉపయోగిస్తూ SearXNG బదులుగా Searx ను వివరిస్తాయి. అవి వేర్వేరు codebaseలు, వాటి limiters కూడా వేర్వేరు. కాబట్టి config block ను copy చేయడానికి ముందు ఆ page ఈ రెండు projects లో దేనికి రాసిందో నిర్ధారించండి.

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 ఇప్పటికే docker.io/valkey/valkey:9-alpine image పై searxng-valkey service ను నడుపుతుంది. అందువల్ల ఆ host name compose network లో resolve అవుతుంది. అదే value ను 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 లేకుండా service అందించడం కొనసాగిస్తుంది. public_instance: true తో process బదులుగా sys.exit(1) ను call చేస్తుంది. Broken bot protection ఉన్న open instance ప్రతి engine నుండి ఒక రోజులోనే CAPTCHAs (computers మరియు humans ను వేరు చేయడానికి ఉపయోగించే completely automated public turing test) ను సేకరిస్తుంది. public_instance: true ను set చేసిన వెంటనే container పదేపదే 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"
  }
]

సాధారణ క్లయింట్‌కు 20 సెకన్ల burst window లో 15 అభ్యర్థనలు, 10 నిమిషాల window లో 150 అభ్యర్థనలు అనుమతించబడతాయి. ఒక అభ్యర్థన suspicious గా గుర్తించబడిన తర్వాత, అదే క్లయింట్‌కు ప్రతి burst window లో 2 అభ్యర్థనలు మాత్రమే అనుమతించబడతాయి. చివరి వరుస అత్యంత కఠినమైనది: 30 రోజుల window లో 3 suspicious అభ్యర్థనలు గుర్తించబడిన తర్వాత, ఆ 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 ను edit చేయాలి. /etc/searxng/limiter.toml నియంత్రించేది clients ను group చేయడానికి ఉపయోగించే address prefixes, trusted proxies జాబితా, optional link token check, అలాగే pass మరియు block lists.

Header checks ఆధారంగా ఒక అభ్యర్థన suspicious గా గుర్తించబడుతుంది. ప్రతి 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 గా set చేయబడింది.
• http_user_agent: User-Agent లేదు లేదా known bot pattern కు సరిపోతుంది.
• http_sec_fetch: Sec-Fetch-Mode లేదా Sec-Fetch-Dest header browser పంపే విలువతో సరిపోలదు.

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

Reverse proxy వెనుక limiter అందరికీ ఒకేసారి అడ్డుకుంటుంది

ఇది పనిచేస్తున్న instance ను పాడుచేసే అత్యంత సాధారణ కారణం. SearXNG మొదటి నమ్మదగని IP ను X-Forwarded-For లోని client address గా తీసుకుంటుంది. అది అందుబాటులో లేకపోతే 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 connect అయ్యే address ను మాత్రమే జాబితాలో ఉంచండి. Docker లో అది సాధారణంగా 172.16.0.0/12 లోని bridge network అవుతుంది. ఆ line default గా commented out గా ఉంటుంది.

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

మీ ఏజెంట్‌కు గంటకు నాలుగు API అభ్యర్థనలు

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

search:
  formats:
    - html
    - json

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

దీనికి సరైన పరిష్కారం ఈ 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 కు ఇతర అన్ని methods కంటే ప్రాధాన్యం ఉంటుంది. అందువల్ల allowlist లో ఉన్న client header checks ను కూడా దాటవేస్తుంది. bare curl call కూడా పనిచేస్తుంది. Range ను సాధ్యమైనంత చిన్నదిగా ఉంచండి. Routable పరిధి కంటే VPN subnet లేదా container network కు ప్రాధాన్యం ఇవ్వండి. మరో సరైన పరిష్కారం agent ను public path నుండి పూర్తిగా దూరంగా ఉంచడం. దాన్ని internal network లోని container address కు point చేయండి. అక్కడ proxy మరియు దాని limiter ఆ traffic ను చూడవు. దీన్ని ఎలా అమలు చేయాలో AI agent కు SearXNG search skill ఇవ్వడం లో వివరించబడింది.

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

ఇంజిన్లు మిమ్మల్ని నిరోధించినప్పుడు

[
  {
    "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 పేరుతో గుర్తించిన exception ను లేవనెత్తి, కొంతకాలం ఆ ఇంజిన్‌కు అభ్యర్థనలు పంపడం ఆపుతుంది. Too-many-requests సమాధానం దాన్ని 3600 సెకన్లపాటు suspend చేస్తుంది. సాధారణ CAPTCHA లేదా access-denied సమాధానం దాన్ని 1 day పాటు suspend చేస్తుంది. Cloudflare ద్వారా అందించిన CAPTCHA దాన్ని 15 days పాటు suspend చేస్తుంది. ఇది జాబితాలోని అత్యంత దీర్ఘమైన default వ్యవధి, ఎందుకంటే block edge వద్ద ఉందని ఆ సమాధానం సూచిస్తుంది; మళ్లీ ప్రయత్నించడం వల్ల ప్రయోజనం ఉండదు. మీరు ఎదుర్కొన్న మూడు CAPTCHA వరుసల్లో ఏది అనేది తరువాత ప్రయత్నించాల్సిన పరిష్కారాన్ని నిర్ణయిస్తుంది. మీ instance నమోదు చేసిన exception ఏదో తెలిసిన తర్వాత, CAPTCHA errors కు ప్రత్యేకమైన పరిష్కారాల సమితి ఉంటుంది.

సాధారణ failures కోసం వేరు settings ఉపయోగిస్తారు. Timeout లేదా parse error వల్ల search.ban_time_on_fail ఆధారంగా నిర్ణయించే స్వల్ప వ్యవధికి engine suspend అవుతుంది. దీని default 5 seconds, మరియు search.max_ban_time_on_fail దాన్ని 120 seconds కు పరిమితం చేస్తుంది. అందువల్ల నెమ్మదిగా ఉన్న engine రెండు నిమిషాల్లో స్వయంగా మళ్లీ పనిచేస్తుంది. కానీ blocked 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 ను నిజంగా block చేస్తున్న engine అయితే, దాన్ని తొలగించండి. ప్రతి search తన slowest engine కోసం వేచి ఉంటుంది. అందువల్ల శాశ్వతంగా suspended గా ఉన్న engine ను ఉంచడం latency ను పెంచుతుంది, కానీ ఎలాంటి ఫలితాలు ఇవ్వదు.

use_default_settings:
  engines:
    remove:
      - google

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

డేటాసెంటర్ IPని botగా పరిగణిస్తారు

మీ VPS చిరునామా hosting rangeకు చెందినది. పెద్ద search engines ఈ rangeలను automationగా స్కోర్ చేస్తాయి. కొన్ని engines అటువంటి చిరునామా నుంచి వచ్చే ప్రతి requestకు CAPTCHA చూపిస్తాయి. Headers ఎంత సరైనవైనా, requests ఎంత నెమ్మదిగా పంపించినా ఇది మారదు. settings.ymlలోని ఏ setting కూడా ఈ నిర్ణయాన్ని మార్చదు. Query టైప్ చేస్తున్న వ్యక్తికి బదులుగా మీ serverను engines చూడటం self-hosting ద్వారా మీరు అంగీకరించిన privacy trade-offలో ప్రధాన భాగం. ఇది ఎంతవరకు privacyని కప్పిపుచ్చుతుందో భావించే ముందు SearXNG వాస్తవంగా ఎంత దాచుతుంది అనే సమాచారాన్ని చదవడం ఉపయోగకరం.

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

మొదట మీకే తెలిసేలా instance ను monitor చేయండి

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

FAQ

Reverse proxy వెనుక SearXNG ను ఉంచిన తర్వాత ప్రతి సందర్శకుడికి 429 ఎందుకు తిరిగి వస్తోంది?

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

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

ప్రతి IP addressకు గంటకు 4 requests. HTML కాకుండా వేరే formatను అడిగే ప్రతి request ప్రత్యేక one-hour windowలో లెక్కించబడుతుంది. ఆ limit 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 తో పాటు limiterను enable చేయండి. ఆ జత ఉద్దేశపూర్వకంగా రూపొందించబడింది. public_instance: true సెట్ చేసి, పనిచేసే Valkey లేకపోతే process status 1తో exit అవుతుంది. అప్పుడు అది రక్షణ లేకుండా నడవదు.