SearXNG-ஐ உங்கள் சொந்த VPS-ல் நிறுவுவது எப்படி?

நீங்கள் உருவாக்குவது என்ன

SearXNG-ஐ self-host செய்வதன் மூலம், உங்கள் சொந்த server-ல் இயங்கும் ஒரு தனிப்பட்ட search engine-ஐப் பெறலாம். SearXNG என்பது ஒரு metasearch engine ஆகும்: இது உங்கள் query-ஐப் பெற்று, Google, Bing, DuckDuckGo மற்றும் Wikipedia போன்ற பிற search engine-களிடம் கேட்டு, வரும் முடிவுகளை ஒருங்கிணைத்து ஒரே பக்கமாகக் காட்டுகிறது. இதில் பயனர் profile உருவாக்கப்படுவதில்லை, tracking cookie-களும் அமைக்கப்படுவதில்லை; ஏனெனில் உங்கள் query-ஐச் சேமிக்கும் ஒரே இயந்திரம் உங்கள் server மட்டுமே. Searx என்று அழைக்கப்படும் பழைய வழிகாட்டிகளை நீங்கள் கண்டிருந்தால், அதுதான் இந்த project-ன் முன்னோடி. அந்த project செப்டம்பர் 2023 முதல் பராமரிக்கப்படவில்லை; அதன் repository-லேயே Searx இனி பராமரிக்கப்படாது என்று அறிவிக்கப்பட்டுவிட்டது. மே 2026-ல் ஆவணப்படுத்தல் குறிப்புக்காகச் செய்யப்பட்ட ஒரு commit-ஐத் தவிர, அதில் எந்த மாற்றமும் இல்லை. எனவே நீங்கள் எதைப் பின்பற்றுவதற்கு முன்பும் இரண்டின் நிலையையும் சரிபார்க்கவும்.

இதற்கான stack சிறியது. இரண்டு containers, ஒரு settings file, ஒரு reverse proxy. இது ஒரு சிறிய VPS-ல் எளிதாக இயங்கும். இது எல்லா self-hosted service-களுக்கும் பொருந்தாது: PhotoPrism மற்றும் Immich ஒப்பீட்டில் பார்த்தது போல, சிலவற்றின் RAM பயன்பாடு web app-ஐ விட indexer-ஐப் பொறுத்தே அமையும். உங்கள் instance தனிப்பட்டதா (நீங்கள் மற்றும் உங்கள் scripts மட்டும் பயன்படுத்துவது) அல்லது பொதுவானதா (இணையத்தில் உள்ள எவரும் பயன்படுத்தக்கூடியது) என்பதை நீங்கள் முடிவு செய்ய வேண்டும். இந்த முடிவு security settings-ஐ மாற்றும் என்பதால், எதையும் தட்டச்சு செய்வதற்கு முன்பே இதைத் தீர்மானிக்கவும். இயல்பான தேர்வு 'தனிப்பட்ட' (private) என்பதாகும்.

இதை இயக்குவதற்கு இரண்டாவது காரணமும் உள்ளது. SearXNG instance JSON வடிவில் தகவல்களைத் தரும். எனவே, நீங்கள் எழுதும் எந்த script அல்லது AI agent-க்கும் சொந்தமான search API கிடைக்கும். இதற்கு key தேவையில்லை, query-க்குக் கட்டணம் இல்லை, quota குறித்த மின்னஞ்சல்களும் வராது.

Docker Compose மூலம் SearXNG-ஐ நிறுவுதல்

இந்தத் திட்டம் ஒரு container image மற்றும் ஒரு Compose கோப்பை வெளியிடுகிறது. Docker Engine மற்றும் Compose plugin ஏற்கனவே உள்ள ஒரு புதிய Ubuntu 24.04 server-ல் இரண்டையும் பதிவிறக்கவும். Docker உங்களுக்குப் புதியது என்றால், VPS-ல் Docker Compose அடிப்படைகள் என்பதைப் படித்துவிட்டு மீண்டும் வரவும்.

sudo install -d -o "$USER" -g "$USER" -m 750 /opt/searxng
cd /opt/searxng
mkdir -p core-config
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 கோப்பு இரண்டு services-ஐ வரையறுக்கிறது. core என்பது SearXNG ஆகும், valkey என்பது rate limiting மற்றும் தற்காலிகத் தரவுகளுக்காகப் பயன்படுத்தப்படும் in-memory data store ஆகும். இது ./core-config/-ஐ container-க்குள் /etc/searxng/ என்ற பாதையில் mount செய்கிறது, எனவே நீங்கள் அமைக்கும் அனைத்தும் host-ல் உள்ள அந்த ஒரே கோப்பகத்தில் இருக்கும்.

இப்போது .env-ஐத் திருத்தவும். வழங்கப்பட்ட உதாரணத்தில் உள்ள அனைத்து வரிகளும் comment செய்யப்பட்டுள்ளன, அதனால்தான் container ஒவ்வொரு முகவரியிலும் port 8080-ல் தொடங்குகிறது. கீழே உள்ள மூன்றையும் uncomment செய்து அமைக்கவும்.

SEARXNG_VERSION=latest
SEARXNG_HOST=127.0.0.1
SEARXNG_PORT=8080

SEARXNG_HOST=127.0.0.1 என்பது மிக முக்கியமானது. இது Docker வெளியிடும் port-ஐ 127.0.0.1:8080:8080 என மாற்றுகிறது, இது வெறும் 8080:8080-க்கு பதிலாக அமைகிறது. Docker இதை ஒவ்வொரு முகவரியிலும் வெளியிடுவதால், container loopback முகவரியில் மட்டுமே பதிலளிக்கும், இணையத்திலிருந்து அதை நேரடியாக அணுக முடியாது. இதைத் தவிர்த்தால், container தொடங்கிய உடனேயே அது வெளிப்படும், ஏனெனில் Docker வெளியிடும் port உங்கள் firewall விதிகளை மீறிச் செயல்படும். அந்த ஆபத்தைப் பற்றி முழுமையாகப் படிக்கவும்: வெளியிடப்பட்ட Docker ports ufw-ஐத் தவிர்க்கின்றன.

நீங்கள் கற்றுக்கொள்ளும் வரை SEARXNG_VERSION=latest சரியாக இருக்கும். நீங்கள் பயன்படுத்தும் server-ல், tag-ஐ pin செய்யவும். அக்டோபர் 2026 நிலவரப்படி, release tags தேதியை அடிப்படையாகக் கொண்டு 2026.10.4-d48c4b555 என இருக்கும். எனவே, registry-ல் மாற்றம் ஏற்படும்போது தானாக மாறாமல், நீங்கள் முடிவு செய்யும்போது மட்டுமே deployment மேம்படுத்தப்படும். நீண்ட காலம் இயங்கும் பிற சேவைகளுக்கும் இதே ஒழுக்கத்தைப் பின்பற்றுவது நல்லது, அதனால்தான் self-hosted RustDesk relay அதன் image tags-ஐ pin செய்கிறது: தொலைநிலை அணுகல் சேவைக்குத் தானாக நடக்கும் மேம்படுத்தல், மிக மோசமான நேரத்தில் சிக்கலை ஏற்படுத்தலாம்.

settings.yml: கவனிக்க வேண்டிய பகுதிகள்

முதல் முறை தொடங்குவதற்கு முன்பே core-config/settings.yml-ஐ உருவாக்கவும். use_default_settings: true, SearXNG அதன் சொந்த default அமைப்புகளை ஏற்றிவிட்டு, நீங்கள் குறிப்பிட்ட keys-ஐ மட்டும் பயன்படுத்தச் சொல்கிறது. இதனால் உங்கள் கோப்பு சுருக்கமாக இருக்கும் மற்றும் புதிய வசதிகள் சேர்க்கப்படும்போது ஏற்படும் upgrades-ஐத் தாங்கி நிற்கும்.

முதலில் secret-ஐ உருவாக்கவும், ஏனெனில் அந்த மதிப்பு நேரடியாகக் கோப்பிற்குள் செல்லும்.

openssl rand -hex 32

use_default_settings: true

general:
  instance_name: "search.example.com"

server:
  base_url: "https://search.example.com/"
  secret_key: "paste-the-openssl-output-here"
  limiter: false
  public_instance: false
  image_proxy: true

valkey:
  url: valkey://valkey:6379/0

search:
  safe_search: 0
  autocomplete: "duckduckgo"
  formats:
    - html
    - json

secret_key என்பது session மற்றும் token தரவுகளைக் கையொப்பமிடுகிறது. வழங்கப்பட்ட default மதிப்பு ultrasecretkey என்ற literal string ஆகும். இதை அப்படியே விட்டால், அந்த default மதிப்பினை அறிந்த எவரும் tokens-ஐ உருவாக்க முடியும். இதை ஒருமுறை மாற்றிவிட்டு, பிறகு மாற்ற வேண்டாம்: பிற்காலத்தில் இதை மாற்றினால் சேமிக்கப்பட்ட அனைத்து விருப்பங்களும் (preferences) நீக்கப்படும்.

base_url என்பது பொதுவான HTTPS முகவரியாக இருக்க வேண்டும், இறுதியில் slash குறியீட்டுடன் இருக்க வேண்டும். SearXNG உருவாக்கும் இணைப்புகளில் இதுவே எழுதப்படும். இதை localhost என்று வைத்தால், தொலைதூர browser-ல் "அடுத்த பக்கம்" (next page) இணைப்பு பயனரின் சொந்த கணினியையே காட்டும், இதனால் அது தோல்வியடையும்.

formats என்பது web endpoint எந்த வகையான வெளியீடுகளை உருவாக்க வேண்டும் என்பதைத் தீர்மானிக்கிறது. json என்பது default பட்டியலில் இல்லை, எனவே நீங்கள் அதைச் சேர்க்கும் வரை JSON கோரிக்கைகள் 403 பிழையையே தரும். image_proxy: true என்பது தேடல் முடிவுகளின் thumbnails-ஐ உங்கள் server வழியாக அனுப்புகிறது, இதனால் அந்தப் படங்களை வழங்கும் தளங்கள் உங்கள் பார்வையாளர்களின் முகவரிகளைக் காண முடியாது.

valkey.url என்பது valkey என்ற hostname-ஐப் பயன்படுத்துகிறது, ஏனெனில் அது Compose கோப்பில் உள்ள service பெயர். Compose இரண்டு containers-ஐயும் ஒரே network-ல் வைப்பதால், service பெயர்கள் அங்கே அடையாளம் காணப்படுகின்றன. இதை localhost என்று மாற்றினால் limiter தோல்வியடையும், ஏனெனில் core container-க்குள் localhost என்பது அந்தக் container-ஐயே குறிக்கும்.

Secret ஒரு plain கோப்பில் இருப்பதால், அதைச் சுற்றியுள்ள directory-யையும் பாதுகாக்க வேண்டும். chmod 750 /opt/searxng மற்ற host பயனர்கள் உள்ளே நுழைவதைத் தடுக்கிறது. நீங்கள் core-config/settings.yml-ஐ 600 முறைக்கு மாற்றினாலும் எந்தப் பாதிப்பும் ஏற்படாது: அதிகாரப்பூர்வ container-ன் entrypoint root பயனராகத் தொடங்கி, FORCE_OWNERSHIP அதன் default மதிப்பிலேயே (true) இருக்கும்போது, SearXNG தொடங்குவதற்கு முன்பே mounted config directory-யை container-ன் சொந்த searxng பயனரிடம் ஒப்படைக்கிறது, எனவே அந்தக் கோப்பு அதற்குப் படிக்கக்கூடியதாகவே இருக்கும். இதன் பக்கவிளைவு host-ல் தெரியும்: அந்தச் செயல் core-config/-ன் உரிமையாளரை container-ன் பயனர் ID-க்கு மாற்றிவிடும், எனவே அதன் பிறகு sudo மூலம் கோப்பைத் திருத்த வேண்டியிருக்கும்.

Stack-ஐத் தொடங்கிச் சரிபார்க்கவும்.

cd /opt/searxng
docker compose up -d
docker compose ps
curl -I http://127.0.0.1:8080/

docker compose ps இரண்டு containers-ம் running நிலையில் இருப்பதைக் காட்ட வேண்டும். curl ஆனது HTTP/1.1 200 OK என்று பதிலளிக்க வேண்டும். அது எதையும் பதிலளிக்கவில்லை என்றால், docker compose logs core-ஐப் படிக்கவும், ஏனெனில் settings.yml-ல் உள்ள YAML பிழை அங்கே வரியைக் குறிப்பிட்டு parse error-ஆகக் காட்டப்படும்.

Nginx மற்றும் TLS மூலம் பாதுகாத்தல்

இந்த container loopback-ல் மட்டுமே இயங்குகிறது. எனவே, nginx மூலமாகவே இதை அணுக முடியும்; இதுவே transport layer security (TLS)-ஐயும் வழங்குகிறது. /etc/nginx/sites-available/searxng-ஐ உருவாக்கவும்.

server {
    listen 80;
    server_name search.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

sudo ln -s /etc/nginx/sites-available/searxng /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d search.example.com

nginx -t கட்டளையை இயக்கும்போது, reload செய்வதற்கு முன்பாக syntax is ok மற்றும் test is successful ஆகியவற்றை அது அச்சிடும். Certbot அதே கோப்பை மாற்றி எழுதி, 443 port-ல் certificate-உடன் இயங்கச் செய்யும் மற்றும் port 80-லிருந்து redirect-ஐயும் சேர்க்கும். search.example.com-க்கான DNS record ஏற்கனவே இந்த server-ஐச் சுட்டிக்காட்ட வேண்டும். ஏனெனில், certificate authority HTTP மூலம் ஒரு கோப்பைத் தரவிறக்கம் செய்து உரிமையாளர் யார் என்பதை உறுதிப்படுத்தும். renewal உட்பட முழுமையான வழிமுறைகளை Ubuntu 24.04-க்கான Certbot மற்றும் nginx வழிகாட்டி-ல் காணலாம்.

இங்குள்ள இரண்டு forwarding headers வெறும் அலங்காரத்திற்காக அல்ல. X-Forwarded-For மற்றும் X-Real-IP இல்லையென்றால், SearXNG-க்கு வரும் ஒவ்வொரு கோரிக்கையும் proxy முகவரியையே கொண்டிருக்கும். இதனால், அனைத்து traffic-உம் ஒரே client-லிருந்து வருவதாக rate limiter கருதும்; வெவ்வேறு பயனர்களை அதனால் அடையாளம் காண முடியாது.

ஸ்கிரிப்டுகள் மற்றும் ஏஜெண்டுகளுக்கு ஏன் JSON தேடல் API தேவைப்படுகிறது

json-ஐ formats-ல் பயன்படுத்தும்போது, பக்கத்தை உருவாக்கும் அதே endpoint கட்டமைக்கப்பட்ட தரவை (structured data) வழங்குகிறது.

curl -s 'http://127.0.0.1:8080/search?q=wireguard+mtu&format=json' \
  | jq -r '.results[0:5][] | .url'

நீங்கள் ஒரு results array கொண்ட object-ஐப் பெறுவீர்கள். அதில் ஒவ்வொரு பதிவும் url, title, content மற்றும் அதை வழங்கிய engine ஆகியவற்றைக் கொண்டிருக்கும். அதனுடன் answers, infoboxes மற்றும் suggestions ஆகியவையும் இருக்கும். ஒரு summariser, link checker அல்லது research loop-க்குத் தேவையான தரவு இதுவே. இந்த முடிவுகளை ஒரு language model-க்கு வழங்குவது பார்ப்பதற்கு எளிதாகத் தோன்றினாலும், அது ஒரு பெரிய படியாகும். ஏனெனில், தேடல் முடிவுகள் நம்பகத்தன்மையற்ற உரைகள், அவை தமக்கான கட்டளைகளைக் கொண்டிருக்கலாம். இதைத்தான் உங்கள் SearXNG instance-ஐ AI ஏஜெண்டிற்குப் பயன்படுத்துதல் விரிவாக விளக்குகிறது.

ஏஜெண்ட் வடிவிலான எதற்கும் இது முக்கியமானது. ஒரு language model-க்கு training cutoff இருப்பதால், தற்போதைய நிகழ்வுகள் குறித்த கேள்விகளுக்குப் பதிலளிக்க அதற்கு நேரடித் தேடல் தேவைப்படுகிறது. வணிக ரீதியான தேடல் API-கள் ஒவ்வொரு query-க்கும் கட்டணம் வசூலிப்பதோடு, கடுமையான rate limit-களையும் விதிக்கின்றன. ஒரு local instance-ஐ நீங்கள் ஏற்கனவே பணம் செலுத்தும் server-ல் ஒரு container-ஆக இயக்கலாம்; அதன் query-கள் அந்த server-ஐ விட்டு வெளியேறாது. நீங்கள் ஒரு model-உடன் கருவிகளை இணைக்கிறீர்கள் என்றால், அதே காரணத்திற்காகத்தான் VPS-ல் MCP server-களை இயக்குதல் பரிந்துரைக்கப்படுகிறது; இதில் தேடல் கருவிதான் பொதுவாக மக்கள் முதலில் சேர்க்கும் கருவியாகும்.

API பயன்பாட்டிற்கு இரண்டு விதிகள் உள்ளன. உங்கள் instance-ஐத் தனிப்பட்டதாக (private) வைத்திருங்கள். எனவே, API பகுதியை loopback address அல்லது private network-உடன் மட்டும் இணைத்து, உங்கள் hosts-க்கு மட்டும் அணுகல் வழங்குங்கள். சுயமாக ஹோஸ்ட் செய்யப்படும் location tracker தனது endpoint-க்குத் தனது இருப்பிடத்தை அனுப்பும்போதும் இதே பாதுகாப்பு முறையே தேவைப்படுகிறது. பிறகு, மென்மையாக query செய்யுங்கள். SearXNG உங்கள் கோரிக்கையை உண்மையான தேடல் பொறிகளுக்கு அனுப்புகிறது. எனவே, ஒரு வினாடிக்கு நூறு query-களை இயக்கும் ஸ்கிரிப்ட், உங்கள் server-ஐத் தடுக்குமாறு Google-க்கு அழைப்பு விடுப்பதாகும்.

Limiter மற்றும் பொதுப் பயன்பாட்டிற்கான instance-ல் செய்ய வேண்டிய மாற்றங்கள்

Limiter என்பது SearXNG-ன் bot பாதுகாப்பு அம்சமாகும். இது request headers, IP முகவரிகள் மற்றும் request விகிதங்களைக் கண்காணித்து, தானியங்கி முறையில் வரும் traffic-ஐத் தடுக்கிறது. இந்தத் தகவல்களைச் சேமிக்க Valkey தேவைப்படுகிறது, அதனால்தான் Compose கோப்பில் அது சேர்க்கப்பட்டுள்ளது.

தனிப்பட்ட (private) instance-ல் limiter: false-ஐ அப்படியே வைத்திருக்கவும். உங்கள் சொந்த scripts இயல்பாகவே தானியங்கி traffic என்பதால், நீங்கள் உருவாக்கிய JSON அழைப்புகளை limiter தடுத்துவிடும். அதற்குப் பதிலாக, access control-ஐ reverse proxy மூலம் கையாள வேண்டும்: nginx location-ல் ஒரு allow மற்றும் deny ஜோடி, HTTP basic authentication, அல்லது உங்கள் பிற server-களை மட்டும் அனுமதிக்கும் firewall ஆகியவற்றைப் பயன்படுத்தலாம். வெவ்வேறு நெட்வொர்க்குகளுக்கு இடையே நகரும் மடிக்கணினியிலிருந்து ஒரு private instance-ஐ அணுக வேண்டியிருந்தால், அதற்கு முன்னால் v3 onion முகவரியை அமைப்பது நான்காவது வழிமுறையாகும். ஏனெனில், tor நெட்வொர்க் இணையத்தில் எதையும் வெளிப்படுத்தாமல் அதே loopback port-க்கு இணைப்பை ஏற்படுத்தும்.

நீங்கள் மற்றவர்களுக்காக instance-ஐ பொதுவெளியில் வெளியிடுகிறீர்கள் என்றால், இரண்டு switches-ஐயும் ஆன் செய்யவும்.

server:
  limiter: true
  public_instance: true

துல்லியமான கட்டுப்பாடுகள் core-config/limiter.toml-ல் உள்ளன, இதை container /etc/searxng/limiter.toml-ல் படிக்கிறது. நீங்கள் மாற்ற விரும்பும் keys-ஐ மட்டும் இதில் எழுதவும். Proxy-க்கு பின்னால் இருக்கும்போது, proxy-ஐக் குறிப்பிட வேண்டும்; இல்லையெனில், உங்கள் nginx முகவரியையே தவறான traffic-ஐ உருவாக்கும் client-ஆக limiter கருதிவிடும்.

[botdetection]
trusted_proxies = [
  '127.0.0.0/8',
  '::1',
]

[botdetection.ip_limit]
link_token = true

link_token = true, உண்மையான browser session-ஆல் மட்டுமே பெறக்கூடிய ஒரு token-ஐ SearXNG வழங்கச் செய்கிறது; இது பெரும்பாலான எளிய scrapers-ஐத் தடுக்கும். ஒரு பொது instance-ஐத் தொடங்கிய சில நாட்களிலேயே scrapers-ன் வருகையை எதிர்பார்க்கலாம். அதேபோல், engine பிழைகளையும் எதிர்பார்க்க வேண்டும். ஏனெனில், நீங்கள் அதிக traffic-ஐ அனுப்ப அனுப்ப, upstream engines உங்கள் server முகவரிக்கு CAPTCHA-க்களை அனுப்பத் தொடங்கும். ஒரு பொது SearXNG instance-ஐ நிர்வகிப்பது தொடர்ச்சியான பணியாகும். ஆனால், ஒரு private instance-க்கு அந்தச் சிக்கல் இல்லை. அதனால்தான், 2026-ல் self-host செய்ய வேண்டியவை பட்டியலில் இது முன்னணியில் உள்ளது. அந்தப் பட்டியலில் உள்ள அனைத்தும் infrastructure சார்ந்தவை அல்ல: Jellyfin library-ஐ 90-களின் rental store போல மாற்றுவது அதே nginx block-க்கு பின்னால் உள்ள ஒரு container தான், ஆனால் அது வேலைக்கானது அல்ல, பொழுதுபோக்கிற்கானது.

தேடல்கள் ஏன் முடிவுகளைத் தருவதில்லை

உங்கள் instance-ல் /stats-ஐத் திறக்கவும். இது ஒவ்வொரு engine-ன் error rate மற்றும் response time ஆகியவற்றைப் பட்டியலிடுகிறது; தேடல் முடிவுகள் குறைவாகத் தெரிந்தால் முதலில் இதைப் பார்க்க வேண்டும்.

"Access denied" அல்லது "CAPTCHA" பிழைகளைக் காட்டும் ஒரு engine உங்கள் server முகவரியைத் தடுத்துள்ளது என்று பொருள். தரவு மையங்களின் (data centre) வரம்பில் உள்ள முகவரிகளுக்கு இது பொதுவானது, ஏனெனில் இவை scrapers என்று தேடல் பொறிகள் கருதுகின்றன. SearXNG அத்தகைய engine-ஐ மீண்டும் முயற்சிப்பதற்குப் பதிலாக ஒரு குறிப்பிட்ட காலத்திற்கு நிறுத்தி வைக்கும், எனவே தடுக்கப்பட்ட அந்த engine அமைதியாக உங்கள் முடிவுகளிலிருந்து நீக்கப்படும். அதை settings.yml-ல் முடக்கவும் அல்லது அந்த இழப்பை ஏற்றுக்கொள்ளவும். இவை மட்டுமே தீர்வுகள் அல்ல, ஏனெனில் சில CAPTCHA தடைகளுக்கு restart செய்தாலும் நீடிக்கும் தீர்வுகள் உள்ளன. மீதமுள்ள engine-கள் தொடர்ந்து பதிலளிக்கும். 429 என்பது தெளிவற்ற ஒரு நிலை, ஏனெனில் இது உங்கள் சொந்த limiter-லிருந்து வரலாம் அல்லது உங்கள் server-ஐ ஏற்கும் upstream engine-லிருந்து வரலாம். அமைப்புகளை மாற்றுவதற்கு முன், எந்தக் காரணத்தினால் பிழை ஏற்படுகிறது என்பதை log வரி உங்களுக்குத் தெரிவிக்கும்.

அனைத்து engine-களும் ஒரே நேரத்தில் தோல்வியடைந்தால், container-க்கு இணையத்துடன் தொடர்பு கொள்ளும் வசதி அல்லது outbound name resolution இல்லை என்று பொருள். அதை container-க்கு உள்ளே இருந்து சோதிக்கவும்.

docker compose exec core wget -qO- https://duckduckgo.com > /dev/null && echo ok

இந்தச் சோதனை தோல்வியடையும் போது அதைத் தெரிவிக்கும் வசதி எதிலும் இல்லை, எனவே அதை cron மூலம் இயக்கவும். முடிவுகள் குறைவதை நீங்கள் கவனிக்கும் வரை காத்திருக்காமல், தோல்வி ஏற்படும் போது உங்கள் சொந்த ntfy server மூலம் உங்கள் தொலைபேசிக்கு எச்சரிக்கை அனுப்பவும்.

FAQ

SearXNG எனது தேடல்களை அநாமதேயமாக்குகிறதா?

இது உங்கள் உலாவிற்குப் பதிலாக உங்கள் server-ஐக் கொண்டு தேடல் பொறிகளிடம் கோரிக்கைகளை விடுவதால், நீங்கள் யார் என்பதை அந்தப் பொறிகளிடமிருந்து மறைக்கிறது. ஆனால், உங்கள் server-லிருந்து தேடல் வினவலை இது மறைக்காது; அதேபோல், அந்தப் பொறிகளிடமிருந்து உங்கள் server-ஐயும் இது மறைக்காது. ஒரே ஒரு பயனர் மட்டுமே பயன்படுத்தும் instance-ல், அந்த IP முகவரியிலிருந்து வரும் அனைத்து traffic-ம் உங்களுடையது என்பதால், அந்த முகவரியே உங்களை அடையாளம் காட்டும் கருவியாக மாறிவிடும். உங்கள் உலாவிக்கும் உங்கள் instance-க்கும் இடையிலான traffic, TLS certificate மூலம் பாதுகாக்கப்படுகிறது. உங்கள் ISP, public instance-ஐ இயக்கும் நபர் மற்றும் தேடல் பொறிகள் ஆகியவற்றின் பார்வையில் உங்கள் நிலை என்ன என்பதை SearXNG உண்மையில் எதை மறைக்கிறது என்பதில் விரிவாகக் காணலாம்.

JSON கோரிக்கை ஏன் 403 Forbidden என்று காட்டுகிறது?

இதற்கு இரண்டு காரணங்கள் உள்ளன, இரண்டுமே configuration தொடர்பானவை. ஒன்று, settings.yml-ல் உள்ள search: பிரிவின் கீழ் formats பட்டியலில் json விடுபட்டிருக்கலாம் (இதுவே default நிலை). அல்லது, limiter செயல்பாட்டில் இருந்து உங்கள் script-ஐ ஒரு bot என்று வகைப்படுத்தியிருக்கலாம். முதலில் அந்த format-ஐச் சேர்த்து, docker compose restart core மூலம் restart செய்து மீண்டும் முயற்சிக்கவும். அப்படியும் தோல்வியுற்றால், limiter: false-ஐ அமைத்து, reverse proxy மட்டத்தில் access-ஐக் கட்டுப்படுத்தவும்.

limiter-ஐ அணைத்து வைத்திருந்தால் Valkey container தேவையா?

அதை இயங்க விடவும். அது இல்லாமலும் SearXNG இயங்கும், ஆனால் அதை இல்லாமல் limiter-ஐப் பிறகு இயக்க முடியாது; மேலும் இது குறுகிய காலத் தரவுகளையும் சேமிக்கிறது. இந்த container சிறியது மற்றும் cached தரவுகளை மட்டுமே சேமிப்பதால், அதை நீக்குவதால் பெரிய பயன் ஏதுமில்லை, ஆனால் எதிர்காலத் தேவைகளுக்கான வாய்ப்பை இழக்க நேரிடும்.

SearXNG-ஐ எப்படி update செய்வது?

/opt/searxng கோப்பகத்தில் docker compose pull கட்டளையையும், தொடர்ந்து docker compose up -d கட்டளையையும் இயக்கவும். image மாறிய எந்தவொரு container-ஐயும் Compose மீண்டும் உருவாக்கும், அதே சமயம் உங்கள் core-config/ கோப்பகம் மாற்றப்படாமல் இருக்கும், எனவே settings.yml அப்படியே இருக்கும். use_default_settings: true உங்கள் keys-ஐ default அமைப்புகளுடன் இணைப்பதால், upstream-ல் சேர்க்கப்படும் புதிய விருப்பங்கள் கோப்பைச் சிதைக்காமல், சரியான மதிப்புகளுடன் வந்து சேரும்.

பல நபர்கள் ஒரே instance-ஐப் பயன்படுத்தலாமா?

ஆம், அத்தகைய சூழலில் நீங்கள் limiter-ஐ இயக்கி, public_instance: true-ஐ அமைக்க வேண்டும். விருப்பத்தேர்வுகள் (preferences) ஒவ்வொரு பார்வையாளரின் உலாவியிலும் சேமிக்கப்படுவதால், கணக்குகளை (accounts) நிர்வகிக்க வேண்டிய அவசியமில்லை. இதைத் திறந்த பிறகு ஒரு வாரம் /stats-ஐக் கவனிக்கவும், ஏனெனில் தேடல் முடிவுகள் கிடைப்பதில் சிக்கல் ஏற்படுவதற்கு முன்பே, upstream தேடல் பொறிகள் உங்கள் server-ஐ நிராகரிக்கத் தொடங்கக்கூடும்.