SearXNG 429 பிழைகளை சரிசெய்வது எப்படி?

SearXNG ஏன் 429 பிழைகளை அளிக்கிறது

சுயமாக இயங்கும் (self-hosted) SearXNG instance இரண்டு தொடர்பில்லாத காரணங்களுக்காக 429 பிழைகளை அளிக்கிறது. நீங்கள் சரிசெய்ய வேண்டிய rate limit, பொதுவாக நீங்கள் நினைப்பது அல்ல. முதல் காரணம் உள்ளூர் சார்ந்தது: SearXNG-ன் சொந்த limiter, ஒரு கோரிக்கை bot-இடமிருந்து வந்ததாகக் கருதி Too Many Requests நிலைக் குறியீட்டுடன் 429 எனப் பதிலளிக்கிறது. இரண்டாவது காரணம் upstream சார்ந்தது: ஒரு தேடுபொறி உங்கள் server-ன் IP முகவரியைத் தடுத்துள்ளது. இது உங்கள் பயனர்களுக்கு 429 பிழையாகத் தெரியாமல், தேடல் முடிவுகளில் சில தகவல்கள் விடுபட்ட பக்கமாகத் தெரியும்.

இந்த இரண்டு நிகழ்வுகளுக்கும் ஒரே தீர்வு கிடையாது. limiter உங்களுடையது, எனவே அதை நீங்கள் மாற்றலாம். Upstream தடுப்பு Google தரப்பில் நடக்கிறது, எனவே உங்கள் settings.yml-ல் எதை மாற்றினாலும் அதை நீக்க முடியாது. log கோப்பைப் பார்த்தால் ஒரு நிமிடத்தில் எது நடக்கிறது என்று தெரிந்துவிடும், எனவே அங்கிருந்து தொடங்கவும்.

இந்த வழிகாட்டி உங்கள் சொந்த VPS-ல் சுயமாக இயங்கும் SearXNG instance-ல் விவரிக்கப்பட்டுள்ள container நிறுவலை அடிப்படையாகக் கொண்டது. கீழே உள்ள ஒவ்வொரு அமைப்பின் பெயரும் ஆகஸ்ட் 2026-ல் சரிபார்க்கப்பட்ட தற்போதைய upstream ஆவணங்கள் மற்றும் மூலக் குறியீட்டிலிருந்து பெறப்பட்டது.

அமைப்பை மாற்றுவதற்கு முன் log-ஐ வாசிக்கவும்

ஒரு log window-ஐத் திறந்து வைத்துக்கொண்டு சிக்கலை மீண்டும் நிகழ்த்திக் காட்டவும்.

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

Limiter செய்திகள் searx.limiter என்ற பெயருடைய logger-லிருந்து வருகின்றன, அவை ஒரு IP முகவரியைக் குறிப்பிடுகின்றன. ஒரு 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 சரிபார்ப்பும் debug நிலையில் பதிவு செய்யப்படுகிறது, எனவே இயல்பாக உங்களால் அதைப் பார்க்க முடியாது. ஒரு சோதனைக்காக settings.yml-ல் debug-ஐ இயக்கவும்:

general:
  debug: true

அதன்பிறகு, client network-க்கு அருகில் NOT OK (http_accept_language) போன்ற வடிவத்தில் வரிகள் log-ல் சேர்க்கப்படும், அவை தோல்வியடைந்த சரிபார்ப்பின் பெயரைக் குறிப்பிடும். சோதனையை முடித்த பிறகு debug-ஐ மீண்டும் அணைத்துவிடவும், ஏனெனில் deployed instance-ஐ debug நிலையில் இயக்க வேண்டாம் என்று upstream அறிவுறுத்துகிறது.

Engine தோல்விகள் இதிலிருந்து முற்றிலும் மாறுபட்டவை. அவை IP-க்கு பதிலாக ஒரு engine-ன் பெயரைக் குறிப்பிடுகின்றன, அவற்றில் மிகவும் பொதுவானது timeout ஆகும்:

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

இதற்கென ஒரு தனிப் பக்கமும் உள்ளது. enable_metrics அதன் இயல்புநிலையான true-ல் இருக்கும்போது, உங்கள் instance /stats/errors-ல் engine பிழைகளைப் பதிவு செய்கிறது, மேலும் தற்போது எந்தெந்த engine-கள் பதிலளிக்கின்றன என்பதை /preferences பட்டியலிடுகிறது. /stats/errors நிரம்பியிருந்து, log-ல் searx.limiter வரிகள் எதுவும் இல்லை என்றால், limiter-ல் சிக்கல் இல்லை என்று அர்த்தம்.

எந்தவொரு பிழைத்திருத்தத்தையும் (debug) தொடங்கும் முன் version-ஐ pin செய்யவும்

Upstream container அமைப்பு இரண்டு கோப்புகளைக் கொண்டது.

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}-ஐ இழுக்கிறது (pull). ஒரு variable அமைக்கப்படாமல் இருந்தால் அது latest என்று பொருள்படும், மேலும் latest என்பது அடுத்த docker compose pull-ன் போது உங்கள் instance மாறிவிடும் என்பதைக் குறிக்கிறது. எனவே, கடந்த வாரம் சரியாக வேலை செய்த ஒரு அமைப்பு, அதை வாசிக்கும் code-உடன் பொருந்தாமல் போகலாம். SearXNG tags ஒரு தேதியையும் commit-ஐயும் கொண்டிருக்கும். ஆகஸ்ட் 2026 நிலவரப்படி upstream .env.example-ல் உள்ள உதாரண tag 2026.3.25-541c6c3cb ஆகும், எனவே .env-ல் ஒரு நிலையான tag-ஐ அமைக்கவும்:

SEARXNG_VERSION=2026.3.25-541c6c3cb

வெளியிடப்பட்ட tags-ஐச் சரிபார்த்து, நீங்கள் உண்மையில் சோதித்த release-ஐ pin செய்யவும், அதன் பிறகு நிலையான இலக்கை வைத்து பிழைத்திருத்தம் செய்யவும். அதே .env கோப்பில் உங்கள் secret key உள்ளது, எனவே அந்த directory-ஐ எங்கும் commit செய்வதற்கு முன் Docker Compose-ல் env கோப்புகள் மற்றும் secrets எவ்வாறு செயல்படுகின்றன என்பதைப் படிக்கவும்.

Limiter இயங்க Valkey தேவை

Limiter ஒவ்வொரு client-ன் கோரிக்கைகளையும் கணக்கிடுகிறது. இந்த எண்ணிக்கையை அனைத்து worker process-களும் பகிர்ந்து கொள்ள வேண்டும். இதற்கான சேமிப்பகமாக Valkey செயல்படுகிறது; இது Redis-ன் பராமரிக்கப்படும் fork ஆகும். பழைய SearXNG வழிகாட்டிகள் இந்த அமைப்பை redis: என்று குறிப்பிடுகின்றன. தற்போதைய பதிப்புகள் valkey: என்பதைப் பயன்படுத்துகின்றன, எனவே பழைய பதிவுகளில் உள்ளவற்றைப் பயன்படுத்தாமல், தற்போதைய ஆவணங்களிலிருந்து key பெயரை நகலெடுக்கவும்.

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

Upstream compose கோப்பு ஏற்கனவே docker.io/valkey/valkey:9-alpine image-ல் searxng-valkey சேவையை இயக்குகிறது, எனவே compose network-க்குள் அந்த host பெயர் சரியாகத் தீர்க்கப்படும். SEARXNG_VALKEY_URL environment variable மூலமும் அதே மதிப்பை அமைக்கலாம். SearXNG மற்றும் Valkey ஒரே host-ல் இயங்கினால், Unix socket URL (unix:///path/to/socket.sock?db=0) பயன்படுத்தலாம்.

சேமிப்பகம் கிடைக்கவில்லை என்றால் என்ன நடக்கும் என்பது மற்றொரு key-ஐப் பொறுத்தது. public_instance: false அமைப்பில், limiter Valkey பிழையை log செய்துவிட்டு, rate limiting இல்லாமலேயே instance-ஐத் தொடர்ந்து இயக்கும். public_instance: true அமைப்பில், process sys.exit(1)-ஐ அழைக்கும். ஏனெனில், bot பாதுகாப்பு இல்லாத ஒரு instance, ஒரு நாளுக்குள் அனைத்து engine-களிடமிருந்தும் CAPTCHA (கணினிகளையும் மனிதர்களையும் வேறுபடுத்திக் காட்டும் தானியங்கி சோதனை) கோரிக்கைகளைப் பெற்றுவிடும். public_instance: true அமைத்த பிறகு ஒரு container தொடர்ந்து restart ஆகிக்கொண்டிருந்தால், அது இதனால்தான். ஒவ்வொரு முறை வெளியேறுவதற்கு முன்பும் கடைசி வரியில் Valkey பற்றிய குறிப்பு இருக்கும்.

Limiter எதை கணக்கிடுகிறது என்பது குறித்த விளக்கம்

[
  {
    "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 கோரிக்கைகளையும், 10 நிமிட window-க்குள் 150 கோரிக்கைகளையும் அனுப்பலாம். ஒரு கோரிக்கை சந்தேகத்திற்குரியதாகக் கருதப்பட்டால், அதே client-ன் வரம்பு burst window-க்கு 2 ஆகக் குறையும். கடைசி வரி மிகவும் கடுமையானது: 30 நாள் window-க்குள் 3 முறை சந்தேகத்திற்குரியதாகக் குறிக்கப்பட்டால், அந்த முகவரியிலிருந்து வரும் தேடல் கோரிக்கைகள் 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 code-ஐத் திருத்த வேண்டும். /etc/searxng/limiter.toml எதைக் கட்டுப்படுத்துகிறது என்றால்: client-களை வகைப்படுத்தப் பயன்படும் address prefixes, நம்பகமான proxies பட்டியல், விருப்பத்தேர்வாக உள்ள link token சரிபார்ப்பு, மற்றும் pass/block பட்டியல்கள்.

Header சோதனைகள் மூலம் ஒரு கோரிக்கை சந்தேகத்திற்குரியதாகக் குறிக்கப்படுகிறது. ஒவ்வொரு சோதனைக்கும் ஒரு பெயர் உண்டு, அதை 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 இவை அனைத்தையும் அனுப்பும். ஒரு சாதாரண curl அழைப்பு இவற்றில் எதையும் அனுப்புவதில்லை, எனவே கையால் எழுதப்பட்ட test request முதல் முயற்சியிலேயே சந்தேகத்திற்குரியதாகக் குறிக்கப்படும், அதே சமயம் browser tab-ல் அதே தேடல் சரியாக வேலை செய்யும். இதனால்தான் "என் browser-ல் வேலை செய்கிறது, ஆனால் என் script-க்கு 429 பிழை வருகிறது" என்பது ஒரு மர்மமான விஷயம் அல்ல, இது ஒரு இயல்பான விளைவாகும்.

Reverse proxy-க்கு பின்னால் இருக்கும் limiter அனைவரையும் ஒரே நேரத்தில் தடுக்கிறது

இது இயங்கிக்கொண்டிருக்கும் ஒரு instance-ஐ செயலிழக்கச் செய்யும் மிகவும் பொதுவான வழியாகும். SearXNG, X-Forwarded-For-ல் உள்ள முதல் நம்பகத்தன்மையற்ற IP-யிலிருந்து client முகவரியை எடுத்துக்கொள்கிறது, அதற்குப் பிறகு X-Real-IP-ஐயும், இறுதியில் இணைப்பைத் திறந்த முகவரியையும் பயன்படுத்துகிறது. இந்த headers நம்பகமானவையா என்பது limiter.toml-ல் உள்ள trusted_proxies மூலம் தீர்மானிக்கப்படுகிறது.

உங்கள் proxy-யின் முகவரி அந்தப் பட்டியலில் இல்லை என்றால், headers புறக்கணிக்கப்படும் மற்றும் ஒவ்வொரு பார்வையாளரும் proxy-யின் முகவரியுடனேயே வருவார்கள். இதனால் அவர்கள் அனைவரும் ஒரே counter-ஐப் பகிர்ந்துகொள்வார்கள், மேலும் மொத்த எண்ணிக்கை 10 நிமிடங்களில் 150 கோரிக்கைகளைத் தாண்டும்போது, தளம் முழுவதுமாகத் தடுக்கப்படும். ஒரு பயனர் முடிவுகள் பக்கத்தை (results page) சில முறை reload செய்தாலே, அது மற்ற அனைவரையும் பாதிக்கும்.

அதிகமாக நம்புவதும் ஆபத்தானது. ஒரு பொதுவான IP range பட்டியலில் இருந்தால், எந்தவொரு பார்வையாளரும் தங்கள் சொந்த X-Forwarded-For header-ஐ அனுப்பி ஒவ்வொரு கோரிக்கைக்கும் ஒரு புதிய அடையாளத்தை உருவாக்க முடியும்; இது தெரிந்தவர்களுக்கு limiter செயலிழந்துவிடும். உங்கள் proxy இணைக்கும் முகவரியை மட்டும் பட்டியலில் சேர்க்கவும். Docker-ல் இது பொதுவாக 172.16.0.0/12-க்குள் இருக்கும் ஒரு bridge network ஆகும், மேலும் அந்த வரி 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 வேலையை மட்டும் செய்தால் போதும். இதிலுள்ள சாதக பாதகங்கள் self-hosted service-க்கு reverse proxy-யைத் தேர்ந்தெடுத்தல் பகுதியில் விவரிக்கப்பட்டுள்ளன. எந்தவொரு அமைப்பையும் சரிபார்க்க, debug-ஐ ஆன் செய்து, உங்கள் மொபைல் டேட்டாவைப் பயன்படுத்தி ஒருமுறை தேடுங்கள். log வரியில் உள்ள network உங்கள் proxy-யின் முகவரியாக இல்லாமல், உங்கள் மொபைலின் முகவரியாக இருப்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்.

உங்கள் agent ஒரு மணி நேரத்திற்கு நான்கு API கோரிக்கைகளை மட்டுமே பெறுகிறது

JSON வெளியீடு இயல்பாகவே முடக்கப்பட்டுள்ளது, எனவே ஒரு agent-க்கு அதைச் சேர்க்க வேண்டும்:

search:
  formats:
    - html
    - json

இப்போது வரைபடத்தின் வரிசையை மீண்டும் கவனிக்கவும். HTML அல்லாத பிற வடிவங்களைக் கோரும் எந்தவொரு கோரிக்கையும் அதன் சொந்த window-ல் கணக்கிடப்படும்: ஒரு முகவரிக்கு, ஒரு 1 hour-க்கு 4 கோரிக்கைகள். ஒரு research agent இதை ஒரே பணியில் தீர்த்துவிடும், அதன் பிறகு வரும் ஒவ்வொரு அழைப்பும் 429 பிழையைத் தரும். இந்த எண்ணிக்கையை உயர்த்துவது ஒரு தீர்வாகாது, ஏனெனில் இந்த எண் source code-ல் உள்ளது.

இதற்கான சரியான தீர்வு, இந்த client ஒரு அந்நியர் அல்ல என்பதை limiter-க்குத் தெரிவிப்பதாகும். அதன் முகவரியை 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 சோதனைகளைத் தவிர்க்கும், மேலும் ஒரு சாதாரண curl அழைப்பும் வேலை செய்யும். இந்த range-ஐ உங்களால் முடிந்தவரை சிறியதாக வைத்திருங்கள், மேலும் பொதுவான நெட்வொர்க்கில் உள்ள எதையும் விட VPN subnet அல்லது container network-க்கு முன்னுரிமை கொடுங்கள். மற்றொரு சரியான தீர்வு, agent-ஐ பொதுப் பாதையில் (public path) இருந்து முற்றிலும் விலக்கி வைப்பதாகும்: அதை internal network-ல் உள்ள container முகவரிக்குச் சுட்டிக்காட்டவும், அங்கு proxy மற்றும் அதன் limiter அந்த traffic-ஐக் காணாது. இதை எவ்வாறு இணைப்பது என்பது AI agent-க்கு SearXNG search skill-ஐ வழங்குதல் பகுதியில் விளக்கப்பட்டுள்ளது.

மற்றொருவர் இயக்கும் பொதுவான instance-க்கு agent-ஐச் சுட்டிக்காட்டுவதைத் தவிர்க்க வேண்டும். இது ஒரு தன்னார்வலரின் IP முகவரியை upstream engines மூலம் தடுப்பதற்கான மிக விரைவான வழியாகும், இதனால்தான் 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 ஒரு குறிப்பிட்ட exception-ஐ உருவாக்கி, அந்தத் தேடுபொறியிடம் சிறிது காலத்திற்குத் தகவல்களைக் கேட்பதை நிறுத்திவிடும். Too-many-requests பதில் கிடைத்தால், அது 3600 வினாடிகளுக்கு இடைநிறுத்தப்படும். சாதாரண CAPTCHA அல்லது access-denied பதில் கிடைத்தால், அது 1 day காலத்திற்கு இடைநிறுத்தப்படும். Cloudflare மூலம் வழங்கப்படும் CAPTCHA, அந்தத் தேடுபொறியை 15 days காலத்திற்கு இடைநிறுத்தும்; இதுவே பட்டியலில் உள்ள மிக நீண்ட கால இடைநிறுத்தமாகும், ஏனெனில் இத்தகைய பதில் அந்தத் தடுப்பு edge-ல் உள்ளது என்பதையும், மீண்டும் முயற்சிப்பதால் பலனில்லை என்பதையும் குறிக்கிறது.

சாதாரண தோல்விகளுக்கு வெவ்வேறு அமைப்புகள் பயன்படுத்தப்படுகின்றன. ஒரு timeout அல்லது parse error ஏற்பட்டால், search.ban_time_on_fail-லிருந்து பெறப்பட்ட குறுகிய காலத்திற்கு அந்தத் தேடுபொறி இடைநிறுத்தப்படும்; இதன் default மதிப்பு 5 வினாடிகள் மற்றும் search.max_ban_time_on_fail மூலம் இது அதிகபட்சம் 120 வினாடிகளாகக் கட்டுப்படுத்தப்படுகிறது. எனவே, மெதுவான ஒரு தேடுபொறி சில நிமிடங்களில் தானாகவே சரியாகிவிடும், ஆனால் தடுக்கப்பட்ட ஒரு தேடுபொறி பல மணிநேரங்களுக்குச் செயல்படாது. மக்கள் குறிப்பிடும் சீரற்ற (random) சிக்கலுக்கு இதுவே காரணம்: தேடல் முடிவுகள் சரியாக இருக்கும், திடீரென்று ஒரு தேடுபொறியின் முடிவுகள் மட்டும் மாலை முழுவதும் கிடைக்காமல் போகும்.

யாரையும் குறை கூறுவதற்கு முன் timeout சிக்கல்களைச் சரிபார்ப்பது அவசியம். default request_timeout மதிப்பு 2.0 வினாடிகள் ஆகும்; இது தேடுபொறியின் அருகிலுள்ள edge server-லிருந்து தொலைவில் இருக்கும் ஒரு சிறிய VPS-க்கு மிகக் குறைவான நேரமாகும்.

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

request_timeout என்பது ஒவ்வொரு தேடுபொறிக்கும் பொதுவான default ஆகும், max_request_timeout என்பது அதன் உச்சவரம்பு (ceiling), மேலும் ஒரு குறிப்பிட்ட தேடுபொறிக்குத் தனியாக timeout-ஐ அமைக்க முடியும். இவற்றை அதிகரிப்பது பக்கத்தின் latency-ஐக் கூட்டி தோல்விகளைக் குறைக்கும், எனவே 10 வினாடிகளுக்கு நேரடியாகச் செல்லாமல், அரை வினாடி இடைவெளியில் உயர்த்தி, /stats/errors-ஐக் கவனிக்கவும்.

உங்கள் IP முகவரியைத் தொடர்ந்து தடுக்கும் ஒரு தேடுபொறியை நீக்கிவிடுவது நல்லது. ஒவ்வொரு தேடலும் அதன் மிக மெதுவான தேடுபொறிக்காகக் காத்திருக்கும், எனவே நிரந்தரமாக இடைநிறுத்தப்பட்ட ஒரு தேடுபொறியை வைத்திருப்பது latency-ஐ அதிகரிக்குமே தவிர, எந்தப் பயனும் தராது.

use_default_settings:
  engines:
    remove:
      - google

மாற்றங்களைச் செயல்படுத்த docker compose restart searxng-core-ஐப் பயன்படுத்தவும், பின்னர் சில தேடல்களைச் செய்து /stats/errors-ஐ reload செய்யவும். ஐந்து நிமிட உண்மையான பயன்பாட்டிற்குப் பிறகு பக்கம் காலியாக இருந்தால், அந்த மாற்றம் சரியாக வேலை செய்கிறது என்று அர்த்தம்.

Datacentre IP ஒரு bot ஆகக் கருதப்படும்

உங்கள் VPS முகவரி ஒரு hosting range-ஐச் சேர்ந்தது. பெரிய தேடுபொறிகள் இத்தகைய range-களை தானியங்கி (automation) செயல்பாடாகக் கருதுகின்றன. நீங்கள் எவ்வளவு மெதுவாக கோரிக்கைகளை அனுப்பினாலும் அல்லது headers எவ்வளவு சரியாக இருந்தாலும், சில தேடுபொறிகள் இத்தகைய முகவரிகளிலிருந்து வரும் ஒவ்வொரு கோரிக்கைக்கும் CAPTCHA-வை வழங்கும். settings.yml-ல் உள்ள எந்த அமைப்பும் இந்த முடிவை மாற்றாது.

நீங்கள் எதை மாற்ற முடியும் என்றால், எந்த தேடுபொறிகளைப் பயன்படுத்த வேண்டும் என்பதையும், உங்கள் instance பொதுவெளியில் பட்டியலிடப்பட்டுள்ளதா என்பதையும் மட்டுமே. ஒரு வீட்டில் மட்டும் பயன்படுத்தப்படும் private instance எதையும் தூண்டுவதில்லை. Hosting IP-ல் இயங்கும் ஒரு public instance, கடுமையான தேடுபொறிகளால் தடை செய்யப்படும்; இது மென்பொருளின் பிழை அல்ல, மாறாக அதன் இயல்பான நிலையாகும். SearXNG, outgoing.proxies அல்லது outgoing.using_tor_proxy மூலம் தேடுபொறி கோரிக்கைகளை ஒரு proxy வழியாக அனுப்ப முடியும்; இது traffic-ஐ வேறொரு முகவரிக்கு மாற்றும். Exit nodes மற்றும் மலிவான proxy pools ஆகியவை hosting range-களை விட மோசமாகவே மதிப்பிடப்படுகின்றன. எனவே, இந்த மாற்றத்தால் தேடல் முடிவுகள் மோசமடையக்கூடும் என்பதை கவனத்தில் கொள்ளவும்.

Instance-ஐ கண்காணித்து முதலில் கண்டறியவும்

SearXNG-ன் அனைத்து engine-களும் suspended நிலையில் இருந்தாலும், அது தனது port-ல் பதிலளிக்கும். எனவே, status code-ஐ மட்டும் கண்காணிக்கும் uptime check, instance எதையும் வழங்காதபோதும் green நிலையிலேயே இருக்கும். அதற்குப் பதிலாக உள்ளடக்கத்தைச் சரிபார்க்கவும்: ஒரு உண்மையான search-ஐ மேற்கொண்டு, response body-ல் நீங்கள் எதிர்பார்க்கும் ஒரு வார்த்தை உள்ளதா எனப் பார்க்கவும். Uptime Kuma keyword monitoring கூடுதல் கருவிகள் ஏதுமின்றி இதைச் சரியாகச் செய்கிறது. ஒவ்வொரு version bump-க்குப் பிறகும் /stats/errors-ஐக் கவனிக்கவும்; ஏனெனில் engine-கள் தங்கள் HTML-ஐ மாற்றக்கூடும், இதனால் rate limit இல்லாமலேயே parser செயலிழக்க வாய்ப்புள்ளது.

FAQ

எனது reverse proxy-க்கு பின்னால் SearXNG-ஐ அமைத்த பிறகு, ஏன் ஒவ்வொரு பயனருக்கும் 429 பிழை வருகிறது?

ஏனெனில், limiter உங்கள் proxy-ஐயே வாடிக்கையாளராகக் கருதி கணக்கிடுகிறது. இணைக்கும் முகவரி /etc/searxng/limiter.toml-ல் உள்ள trusted_proxies-ல் பட்டியலிடப்பட்டிருந்தால் மட்டுமே SearXNG X-Forwarded-For-ஐ வாசிக்கும். அவ்வாறு பட்டியலிடப்படவில்லை எனில், அனைத்து பயனர்களும் ஒரே கணக்கீட்டைப் பகிர்ந்துகொள்வார்கள்; இதனால் 10 நிமிடங்களுக்கு 150 கோரிக்கைகள் என்ற வரம்பை அவர்கள் அனைவரும் சேர்ந்து விரைவாகக் கடந்துவிடுவார்கள். உங்கள் proxy இணைக்கும் முகவரியைச் சேர்க்கவும்; Docker-ல் இது பொதுவாக 172.16.0.0/12 என்ற bridge வரம்பாக இருக்கும். மேலும், proxy ஆனது X-Real-IP மற்றும் X-Forwarded-For-ஐ அனுப்புவதை உறுதி செய்யவும். உங்கள் கட்டுப்பாட்டில் இல்லாத எந்தவொரு வரம்பையும் பட்டியலிட வேண்டாம்; ஏனெனில், நம்பகமான நெட்வொர்க்கில் எந்தவொரு பயனரும் அந்த header-ஐ அமைத்து, ஒவ்வொரு கோரிக்கைக்கும் புதிய அடையாளத்தைத் தேர்வு செய்ய முடியும்.

SearXNG limiter ஒரு மணி நேரத்திற்கு எத்தனை API கோரிக்கைகளை அனுமதிக்கிறது?

ஒரு IP முகவரிக்கு ஒரு மணி நேரத்திற்கு நான்கு கோரிக்கைகள். HTML அல்லாத பிற வடிவங்களைக் கோரும் எந்தவொரு கோரிக்கையும் தனி ஒரு மணி நேர காலக்கெடுவில் கணக்கிடப்படும். இந்த வரம்பு limiter.toml-ல் அல்லாமல் searx/botdetection/ip_limit.py-ல் அமைக்கப்பட்டுள்ளது, எனவே இதை configuration மூலம் அதிகரிக்க முடியாது. ஒரு agent அல்லது script இதை ஒரே பணியில் கடந்துவிடும். வாடிக்கையாளரின் முகவரியை limiter.toml-ல் உள்ள pass_ip-ல் சேர்க்கவும், அல்லது limiter கோரிக்கையைக் கவனிக்காத ஒரு internal network வழியாக அந்த instance-ஐ அணுகவும்.

429 பிழை இல்லாமல் ஏன் எனது தேடல் முடிவுகள் காலியாக வருகின்றன?

தேடுபொறிகள் (engines) உங்கள் பயனர்களை அல்ல, உங்கள் server-ஐயே நிராகரிக்கின்றன. உங்கள் instance-ல் /stats/errors-ஐத் திறந்து பார்க்கவும்: அது தோல்வியடைந்த ஒவ்வொரு தேடுபொறியையும் அதன் காரணத்தையும் குறிப்பிடும். CAPTCHA அல்லது access-denied என்பது அந்தத் தேடுபொறி உங்கள் server-ன் IP முகவரியைத் தடுத்துள்ளது என்று பொருள். SearXNG அந்தத் தேடுபொறியைத் தற்காலிகமாக நிறுத்திவிடும்; அதிகப்படியான கோரிக்கைகள் வந்தால் ஒரு மணி நேரமும், CAPTCHA வந்தால் ஒரு நாளும் நிறுத்திவைக்கப்படும். எந்தவொரு உள்ளூர் அமைப்பும் (local setting) upstream தடையை நீக்காது, எனவே உங்கள் முகவரியைத் தடுக்கும் தேடுபொறிகளை நீக்கிவிட்டு, பதிலளிக்கும் தேடுபொறிகளை மட்டும் வைத்திருக்கவும்.

ஒரு private instance-ல் limiter-ஐ நான் இயக்க வேண்டுமா?

உங்களைத் தவிர வேறு யாரும் அந்த instance-ஐ அணுகவில்லை என்றால், limiter: false-ஐ அப்படியே விடவும். இது Valkey dependency-ஐச் சேர்க்கிறது மற்றும் உங்கள் சொந்த script-களையும் தடுக்கிறது; மேலும், உங்களுக்குத் தேவையில்லாத traffic-லிருந்து இது பாதுகாக்கிறது. அந்த instance பொது முகவரியைப் (public address) பெற்றவுடன், public_instance: true-உடன் சேர்த்து இதை இயக்கவும். இந்த ஜோடி வேண்டுமென்றே அமைக்கப்பட்டது: public_instance: true இருந்து, Valkey சரியாகச் செயல்படவில்லை எனில், பாதுகாப்பற்ற முறையில் இயங்குவதற்குப் பதிலாக process ஆனது status 1-உடன் வெளியேறிவிடும்.