SearXNG कसे इन्स्टॉल करावे: स्वतःचे खाजगी सर्च इंजिन

तुम्ही काय तयार करत आहात

SearXNG स्वतःच्या सर्व्हरवर चालवल्यामुळे तुम्हाला एक खाजगी सर्च इंजिन मिळते. SearXNG हे एक मेटा-सर्च इंजिन आहे: ते तुमची क्वेरी घेते, Google, Bing, DuckDuckGo आणि Wikipedia सारख्या इतर इंजिनना विचारते आणि त्यानंतर आलेले निकाल एकत्र करून एका पेजवर दाखवते. यात कोणतीही प्रोफाईल तयार केली जात नाही आणि ट्रॅकिंग कुकी सेट केली जात नाही, कारण तुमची क्वेरी साठवणारे एकमेव मशीन तुमचे स्वतःचे असते. जर तुम्हाला Searx नावाच्या जुन्या गाईड्स सापडल्या असतील, तर हा तोच प्रकल्प आहे ज्यातून SearXNG तयार झाले आहे. सप्टेंबर 2023 पासून ते अनमेन्टेन (unmaintained) आहे, जेव्हा त्याच्या रिपॉझिटरीने Searx आता मेंटेन केले जाणार नाही असे जाहीर केले होते. त्यानंतर मे 2026 मध्ये झालेला एक कमिट हा केवळ डॉक्युमेंटेशनमधील बदल होता, त्यामुळे स्थिती बदललेली नाही. म्हणून कोणतीही गाईड फॉलो करण्यापूर्वी दोन्हीची स्थिती तपासा.

याचा स्टॅक लहान आहे. दोन कंटेनर, एक सेटिंग्स फाईल आणि एक रिव्हर्स प्रॉक्सी. हे एका लहान VPS वर आरामात चालू शकते, जे प्रत्येक self-hosted सेवेबाबत खरे नसते: PhotoPrism आणि Immich मधील फोटो लायब्ररी त्यांच्या इंडेक्सिंगमुळे जास्त RAM वापरतात. खरा निर्णय हा आहे की तुमची इन्स्टन्स खाजगी (private) असेल, म्हणजे फक्त तुम्ही आणि तुमचे स्क्रिप्ट्स वापरू शकाल, की सार्वजनिक (public) असेल, म्हणजे इंटरनेटवरील कोणीही ती वापरू शकेल. हा निर्णय सुरक्षेच्या सेटिंग्स बदलतो, त्यामुळे काहीही टाईप करण्यापूर्वी तो घ्या. डीफॉल्ट उत्तर खाजगी असे आहे.

हे चालवण्याचे दुसरे एक कारण आहे. SearXNG इन्स्टन्स JSON मध्ये संवाद साधते, त्यामुळे तुम्ही लिहिलेल्या कोणत्याही स्क्रिप्ट किंवा AI एजंटला एक स्वतःची सर्च API मिळते, ज्यासाठी कोणतीही की (key), प्रति-क्वेरी बिलिंग किंवा कोटाची मर्यादा नसते.

Docker Compose वापरून SearXNG इंस्टॉल करा

हा प्रकल्प एक कंटेनर इमेज आणि एक Compose फाईल प्रकाशित करतो. या दोन्ही गोष्टी एका नवीन Ubuntu 24.04 सर्व्हरवर डाउनलोड करा, ज्यावर आधीच Docker Engine आणि Compose प्लगइन इंस्टॉल केलेले आहे. जर तुम्ही Docker मध्ये नवीन असाल, तर आधी 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 फाईल दोन सेवा परिभाषित करते. core ही स्वतः SearXNG सेवा आहे आणि valkey हे इन-मेमरी डेटा स्टोअर आहे, ज्याचा वापर रेट लिमिटिंग आणि अल्पकालीन स्टेटसाठी केला जातो. हे कंटेनरच्या आत /etc/searxng/ वर ./core-config/ माउंट करते, त्यामुळे तुम्ही कॉन्फिगर केलेली सर्व माहिती होस्टवरील त्या एका डिरेक्टरीमध्ये राहते.

आता .env एडिट करा. दिलेल्या उदाहरणातील प्रत्येक ओळ कमेंट केलेली आहे, म्हणूनच कंटेनर प्रत्येक पत्त्यावर 8080 पोर्टवर सुरू होतो. या तीन ओळी अनकमेंट करा आणि सेट करा.

SEARXNG_VERSION=latest
SEARXNG_HOST=127.0.0.1
SEARXNG_PORT=8080

SEARXNG_HOST=127.0.0.1 ही महत्त्वाची ओळ आहे. हे पब्लिश केलेले पोर्ट 127.0.0.1:8080:8080 वर सेट करते, जे 8080:8080 ऐवजी वापरले जाते. Docker हे पोर्ट प्रत्येक पत्त्यावर पब्लिश करते, त्यामुळे कंटेनर फक्त लूपबॅक पत्त्यावर प्रतिसाद देतो आणि इंटरनेटवरून तो थेट उपलब्ध होत नाही. हे वगळल्यास, कंटेनर सुरू होताच तो उघड होतो, कारण पब्लिश केलेले Docker पोर्ट तुमच्या फायरवॉल नियमांच्या आधी लागू केले जाते. हा धोका पूर्णपणे समजून घेणे आवश्यक आहे: पब्लिश केलेले Docker पोर्ट ufw ला बायपास करतात.

तुम्ही शिकत असताना SEARXNG_VERSION=latest वापरणे ठीक आहे. मात्र, महत्त्वाच्या सर्व्हरवर इमेज टॅग पिन करा. ऑक्टोबर 2026 पर्यंत, रिलीज टॅग तारखेवर आधारित आहेत आणि ते 2026.10.4-d48c4b555 सारखे दिसतात. त्यामुळे, जेव्हा तुम्ही ठरवाल तेव्हाच डिप्लॉयमेंट अपग्रेड होईल, रजिस्ट्रीमध्ये बदल झाल्यावर आपोआप नाही. हीच शिस्त सर्व्हरवरील इतर दीर्घकालीन सेवांसाठीही फायदेशीर ठरते, म्हणूनच self-hosted RustDesk relay देखील त्याचे इमेज टॅग पिन करते: रिमोट ॲक्सेस सेवेचे अनपेक्षित अपग्रेड सर्वात चुकीच्या वेळी समस्या निर्माण करू शकते.

settings.yml: महत्त्वाचे भाग

पहिली वेळ सुरू करण्यापूर्वी core-config/settings.yml तयार करा. use_default_settings: true मुळे SearXNG स्वतःचे डीफॉल्ट लोड करते आणि त्यानंतर फक्त तुम्ही लिहिलेल्या की (keys) लागू करते, त्यामुळे तुमची फाईल लहान राहते आणि नवीन पर्याय जोडणाऱ्या अपग्रेड्सनंतरही ती सुरक्षित राहते.

सर्वात आधी 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 सेशन आणि टोकन डेटावर स्वाक्षरी करते. डीफॉल्ट म्हणून यात ultrasecretkey ही स्ट्रिंग असते, आणि ती तशीच ठेवल्यास, ज्याला हे डीफॉल्ट माहित आहे तो टोकन्स बनावट तयार करू शकतो. हे एकदा बदला आणि त्यानंतर ते तसेच राहू द्या: ते नंतर बदलल्यास सर्व जतन केलेल्या पसंती (preferences) नष्ट होतील.

base_url हा सार्वजनिक HTTPS पत्ता असावा, ज्याच्या शेवटी स्लॅश असावा. SearXNG जे लिंक्स तयार करते, त्यात हाच पत्ता वापरला जातो. हे localhost वर ठेवल्यास, रिमोट ब्राउझरमधील "next page" लिंक वाचकाच्या स्वतःच्या मशीनकडे निर्देश करेल आणि ती अयशस्वी होईल.

formats वेब एंडपॉइंट कोणत्या प्रकारचे आउटपुट देईल हे ठरवते. json डीफॉल्ट यादीत नसल्यामुळे, जोपर्यंत तुम्ही ते जोडत नाही तोपर्यंत JSON विनंतीला 403 एरर मिळेल. image_proxy: true रिझल्ट थंबनेल तुमच्या सर्व्हरद्वारे राउट करते, त्यामुळे त्या प्रतिमा होस्ट करणाऱ्या साइट्सना तुमच्या अभ्यागतांचे पत्ते कधीही दिसत नाहीत.

valkey.url मध्ये valkey हे होस्टनेम वापरले जाते कारण Compose फाईलमध्ये ते सर्व्हिसचे नाव आहे आणि Compose दोन्ही कंटेनर्सना एकाच नेटवर्कवर ठेवते जिथे सर्व्हिसची नावे रिझॉल्व्ह होतात. हे localhost कडे निर्देश केल्यास, लिमिटर अयशस्वी होतो, कारण core कंटेनरच्या आत localhost म्हणजे तो कंटेनर स्वतः असतो.

हे secret एका साध्या फाईलमध्ये असते, म्हणून त्याभोवतीची डिरेक्टरी देखील सुरक्षित ठेवा. chmod 750 /opt/searxng इतर होस्ट वापरकर्त्यांना बाहेर ठेवते. तुम्ही core-config/settings.yml ला 600 मोडवर सेट करून अधिक सुरक्षित करू शकता, यामुळे काहीही बिघडत नाही: अधिकृत कंटेनरचा entrypoint root म्हणून सुरू होतो आणि FORCE_OWNERSHIP डीफॉल्ट true वर राहिल्यास, SearXNG सुरू होण्यापूर्वी तो माउंट केलेली कॉन्फिग डिरेक्टरी कंटेनरच्या स्वतःच्या searxng वापरकर्त्याला देतो, त्यामुळे फाईल त्याला वाचता येते. याचा एक परिणाम होस्टवर दिसतो: हीच प्रक्रिया core-config/ चा मालक कंटेनरच्या वापरकर्ता ID मध्ये बदलते, त्यामुळे त्यानंतर sudo वापरून फाईल एडिट करण्याची तयारी ठेवा.

स्टॅक सुरू करा आणि तपासा.

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

docker compose ps मध्ये दोन्ही कंटेनर्स running स्थितीत दिसले पाहिजेत. curl ने HTTP/1.1 200 OK असे उत्तर दिले पाहिजे. जर काहीच उत्तर मिळत नसेल, तर docker compose logs core वाचा, कारण settings.yml मधील YAML मधील चूक तिथे पार्स एरर म्हणून ओळीच्या क्रमांकासह दिसते.

Nginx आणि TLS च्या मागे ठेवा

कंटेनर फक्त loopback वर ऐकतो (listens), त्यामुळे 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 त्याच फाईलला पुन्हा लिहिते (rewrites) जेणेकरून ती प्रमाणपत्रासह 443 पोर्टवर ऐकेल आणि पोर्ट 80 वरून redirect जोडेल. search.example.com साठीचा DNS record आधीच या सर्व्हरकडे निर्देशित (point) असणे आवश्यक आहे, कारण certificate authority HTTP द्वारे फाईल मिळवून मालकी सिद्ध करते. नूतनीकरणासह (renewal) संपूर्ण माहिती Ubuntu 24.04 साठी Certbot आणि Nginx मार्गदर्शिका मध्ये दिली आहे.

दोन forwarding headers केवळ सजावट नाहीत. X-Forwarded-For आणि X-Real-IP शिवाय, SearXNG कडे येणारी प्रत्येक विनंती proxy चा पत्ता घेऊन येते, त्यामुळे rate limiter ला सर्व ट्रॅफिक एकाच क्लायंटकडून येत असल्याचे दिसते आणि तो अभ्यागतांमध्ये फरक करू शकत नाही.

स्क्रिप्ट्स आणि एजंट्सना JSON सर्च API ची गरज का असते

json मधील formats मध्ये, जो एंडपॉईंट पेज रेंडर करतो, तोच एंडपॉईंट स्ट्रक्चर्ड डेटा देखील देतो.

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

तुम्हाला एक ऑब्जेक्ट मिळतो ज्यामध्ये results ॲरे असतो. प्रत्येक एन्ट्रीमध्ये url, title, content आणि तो डेटा पुरवणारे इंजिन असते, तसेच त्यासोबत answers, infoboxes आणि suggestions देखील असतात. समरायझर (summariser), लिंक चेकर किंवा रिसर्च लूप चालवण्यासाठी ही माहिती पुरेशी असते. हे रिझल्ट्स लँग्वेज मॉडेलला देणे हे वरकरणी वाटते त्यापेक्षा मोठे पाऊल आहे, कारण सर्च रिझल्ट्स हे अनट्रस्टेड टेक्स्ट असतात ज्यामध्ये स्वतःच्या सूचना असू शकतात. यावर तुमच्या SearXNG इन्स्टन्सवर AI एजंट पॉइंट करणे या लेखात सविस्तर चर्चा केली आहे.

एजंट-आधारित कोणत्याही गोष्टीसाठी हे महत्त्वाचे आहे. लँग्वेज मॉडेलचे ट्रेनिंग एका ठराविक तारखेला थांबलेले असते, त्यामुळे वर्तमानातील प्रश्नांची उत्तरे देण्यासाठी त्याला लाइव्ह सर्चची गरज असते. व्यावसायिक सर्च API प्रति क्वेरी शुल्क आकारतात आणि त्यावर कडक रेट लिमिट्स असतात. स्थानिक इन्स्टन्ससाठी तुम्ही आधीच पैसे भरत असलेल्या सर्व्हरवर फक्त एक कंटेनर लागतो आणि क्वेरीज सर्व्हरच्या बाहेर जात नाहीत. जर तुम्ही मॉडेलमध्ये टूल्स जोडत असाल, तर VPS वर MCP सर्व्हर्स चालवणे यामागेही हेच तर्क आहे, जिथे सर्च टूल हे सहसा पहिले जोडले जाणारे टूल असते.

API वापरासाठी दोन नियम आहेत. इन्स्टन्स खाजगी ठेवा, म्हणजे API साईडला लूपबॅक ॲड्रेस किंवा खाजगी नेटवर्कवर बाइंड करा आणि फक्त तुमच्या स्वतःच्या होस्ट्सना तिथे पोहोचू द्या. सेल्फ-होस्टेड लोकेशन ट्रॅकर साठी ज्या एंडपॉईंटवर तुमचा फोन त्याचे लोकेशन रिपोर्ट करतो, त्यालाही अशीच सुरक्षा आवश्यक असते. त्यानंतर, क्वेरीज जपून करा. SearXNG तुमची विनंती प्रत्यक्ष सर्च इंजिन्सना फॉरवर्ड करते, त्यामुळे एका सेकंदाला शंभर क्वेरीज चालवणारी स्क्रिप्ट Google ला तुमचा सर्व्हर ब्लॉक करण्यास भाग पाडू शकते.

लिमिटर आणि सार्वजनिक इन्स्टन्ससाठी होणारे बदल

लिमिटर हे SearXNG चे बॉट संरक्षण आहे. हे रिक्वेस्ट हेडर्स, आयपी पत्ते आणि रिक्वेस्ट रेट्सवर लक्ष ठेवते आणि स्वयंचलित वाटणारी ट्रॅफिक नाकारते. ही स्थिती साठवण्यासाठी त्याला Valkey ची गरज असते, म्हणूनच Compose फाईलमध्ये ते समाविष्ट केलेले असते.

खाजगी इन्स्टन्सवर limiter: false सुरू ठेवा. तुमची स्वतःची स्क्रिप्ट्स व्याख्येनुसार स्वयंचलित ट्रॅफिक असते, त्यामुळे लिमिटर नेमके तेच JSON कॉल्स ब्लॉक करेल ज्यासाठी तुम्ही इन्स्टन्स तयार केला आहे. त्याऐवजी, ॲक्सेस कंट्रोलचे काम रिव्हर्स प्रॉक्सीचे आहे: nginx location मध्ये allow आणि deny ची जोडी, HTTP बेसिक ऑथेंटिकेशन किंवा फक्त तुमच्या इतर सर्व्हर्सना परवानगी देणारा फायरवॉल वापरा. जर तुम्हाला वेगवेगळ्या नेटवर्कवर फिरणाऱ्या लॅपटॉपवरून खाजगी इन्स्टन्स ॲक्सेस करायचा असेल, तर त्याच्या समोर v3 onion पत्ता ठेवणे हा चौथा पर्याय आहे, कारण tor इंटरनेटवर काहीही नवीन उघड न करता त्याच लूपबॅक पोर्टशी जोडले जाते.

जर तुम्ही इन्स्टन्स इतर लोकांसाठी सार्वजनिक करत असाल, तर दोन्ही स्विचेस चालू करा.

server:
  limiter: true
  public_instance: true

अधिक सूक्ष्म नियंत्रण core-config/limiter.toml मध्ये असते, जे कंटेनर /etc/searxng/limiter.toml वर वाचते. तुम्हाला जे कीज बदलायचे आहेत फक्त तेच लिहा. प्रॉक्सीच्या मागे असताना तुम्हाला प्रॉक्सी घोषित करणे आवश्यक आहे, अन्यथा लिमिटर तुमच्या nginx पत्त्यालाच एक गैरवापर करणारा क्लायंट मानून ब्लॉक करेल.

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

[botdetection.ip_limit]
link_token = true

link_token = true मुळे SearXNG एक टोकन जारी करते जे फक्त एक वास्तविक ब्राउझर सेशनच मिळवू शकते, ज्यामुळे बहुतेक साधे स्क्रॅपर्स थांबतात. सार्वजनिक इन्स्टन्सवर काही दिवसांतच असे स्क्रॅपर्स येतील हे गृहीत धरा. इंजिन एरर्सचीही अपेक्षा ठेवा, कारण तुम्ही जितकी जास्त ट्रॅफिक फॉरवर्ड कराल, तितक्या लवकर अपस्ट्रीम इंजिन्स तुमच्या सर्व्हरच्या पत्त्यावर CAPTCHAs पाठवू लागतील. सार्वजनिक SearXNG इन्स्टन्स चालवणे हे एक निरंतर काम आहे. खाजगी इन्स्टन्स तसे नाही, म्हणूनच ते 2026 मध्ये सेल्फ-होस्ट करण्यासारख्या गोष्टींच्या बहुतेक लहान याद्यांमध्ये समाविष्ट असते. त्या यादीतील प्रत्येक गोष्ट इन्फ्रास्ट्रक्चर नसते: Jellyfin लायब्ररीला 90 च्या दशकातील रेंटल स्टोअरसारखे बनवणे हे त्याच nginx ब्लॉकच्या मागे असलेल्या त्याच एका कंटेनरचे काम आहे, जे कामाच्या प्रवाहापेक्षा मनोरंजनासाठी अधिक वापरले जाते.

सर्च रिझल्ट्स का मिळत नाहीत

तुमच्या इन्स्टन्सवर /stats उघडा. यामध्ये प्रत्येक इंजिनचा एरर रेट आणि रिस्पॉन्स टाइम दिलेला असतो. जेव्हा सर्च रिझल्ट्स कमी वाटतात, तेव्हा ही पहिली जागा आहे जिथे तुम्ही तपासले पाहिजे.

ज्या इंजिनसमोर "Access denied" किंवा "CAPTCHA" एरर दिसतो, त्याने तुमच्या सर्व्हरचा पत्ता ब्लॉक केला आहे. डेटा सेंटर रेंजमधील पत्त्यांसाठी हे सामान्य आहे, कारण सर्च इंजिन्सना असे वाटते की हे पत्ते स्क्रेपर्सचे आहेत. अशा वेळी SearXNG त्या इंजिनला पुन्हा प्रयत्न करण्याऐवजी काही काळासाठी निलंबित (suspend) करते, त्यामुळे एक ब्लॉक झालेले इंजिन शांतपणे तुमच्या रिझल्ट्समधून निघून जाते. याला settings.yml मध्ये डिसेबल करा किंवा हे नुकसान स्वीकारून पुढे जा. हे दोनच पर्याय नाहीत, कारण काही CAPTCHA ब्लॉक्सवर असा उपाय आहे जो रीस्टार्टनंतरही टिकतो. उरलेली इंजिन्स अजूनही उत्तरे देतात. 429 हा एक संदिग्ध प्रकार आहे, कारण तो तुमच्या स्वतःच्या लिमिटरकडून किंवा तुमच्या सर्व्हरला नाकारणाऱ्या अपस्ट्रीम इंजिनकडून येऊ शकतो. सेटिंग्ज बदलण्यापूर्वी लॉग लाइन तुम्हाला सांगते की तुम्ही यापैकी कशाचा सामना करत आहात.

जर सर्व इंजिन्स एकाच वेळी निकामी झाली, तर कंटेनरकडे बाह्य नेम रिझोल्यूशन (outbound name resolution) नाही किंवा इंटरनेटसाठी कोणताही मार्ग (route) उपलब्ध नाही. कंटेनरच्या आतून याची चाचणी घ्या.

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

ही तपासणी कधी निकामी होते हे सांगणारी कोणतीही यंत्रणा बॉक्सवर नाही, म्हणून ती cron द्वारे चालवा. रिझल्ट्स कमी होईपर्यंत वाट पाहण्यापेक्षा, एखादी त्रुटी आढळल्यास तुमच्या स्वतःच्या ntfy सर्व्हरवरून तुमच्या फोनवर अलर्ट पाठवा.

FAQ

SearXNG माझ्या शोधांना निनावी (anonymous) बनवते का?

हे ज्या सर्च इंजिन्सना विनंती करते, त्यांच्यापासून तुमची ओळख लपवते, कारण त्यांना तुमच्या ब्राउझरऐवजी तुमच्या सर्व्हरवरून विनंती आल्याचे दिसते. हे तुमच्या सर्व्हरपासून तुमची क्वेरी लपवत नाही आणि त्यांच्यापासून तुमचा सर्व्हरही लपवत नाही. सिंगल-युजर इन्स्टन्सवर त्या पत्त्यावरून येणारी सर्व ट्रॅफिक तुमचीच असते, त्यामुळे तो पत्ता स्वतःच एक ओळख बनतो. तुमच्या ब्राउझर आणि इन्स्टन्स मधील ट्रॅफिक TLS प्रमाणपत्राद्वारे सुरक्षित असते. तुमच्या ISP, पब्लिक इन्स्टन्सचा ऑपरेटर आणि सर्च इंजिन्सच्या संदर्भात तुमची स्थिती काय असेल, हे SearXNG नक्की काय लपवते यामध्ये स्पष्ट केले आहे.

JSON विनंती 403 Forbidden का देते?

याची दोन कारणे आहेत आणि दोन्ही कॉन्फिगरेशनशी संबंधित आहेत. एकतर settings.yml मधील search: अंतर्गत असलेल्या formats यादीतून json गहाळ आहे, जी डीफॉल्ट स्थिती आहे, किंवा लिमिटर चालू आहे आणि त्याने तुमच्या स्क्रिप्टला बॉट म्हणून वर्गीकृत केले आहे. आधी फॉरमॅट जोडा, docker compose restart core वापरून रीस्टार्ट करा आणि पुन्हा प्रयत्न करा. तरीही अपयश येत असल्यास, limiter: false सेट करा आणि रिव्हर्स प्रॉक्सी स्तरावर ॲक्सेस नियंत्रित करा.

जर मी लिमिटर बंद ठेवला, तर मला Valkey कंटेनरची गरज आहे का?

तो चालू ठेवा. SearXNG त्याशिवाय काम करते, परंतु त्यानंतर लिमिटर चालू करता येत नाही आणि तो इतर अल्पकालीन स्टेट (short-lived state) देखील साठवतो. हा कंटेनर लहान आहे आणि फक्त कॅश केलेला डेटा साठवतो, त्यामुळे तो काढून टाकल्याने फारसा फायदा होत नाही आणि तुमचा पर्यायही संपतो.

मी SearXNG अपडेट कसे करू?

/opt/searxng मध्ये आधी docker compose pull आणि नंतर docker compose up -d चालवा. Compose ज्या इमेज बदलल्या आहेत असे कंटेनर पुन्हा तयार करते आणि तुमची core-config/ डिरेक्टरी तशीच ठेवते, त्यामुळे settings.yml सुरक्षित राहते. कारण use_default_settings: true तुमच्या कीजला मूळ डीफॉल्ट्सवर मर्ज करते, त्यामुळे अपस्ट्रीममध्ये जोडलेले पर्याय फाईल न बिघडवता योग्य व्हॅल्यूजसह येतात.

अनेक लोक एकच इन्स्टन्स वापरू शकतात का?

हो, आणि अशा परिस्थितीत तुम्ही लिमिटर चालू करून public_instance: true सेट करणे आवश्यक आहे. प्राधान्ये (preferences) प्रत्येक अभ्यागताच्या स्वतःच्या ब्राउझरमध्ये साठवली जातात, त्यामुळे व्यवस्थापित करण्यासाठी कोणतेही अकाउंट्स नसतात. इन्स्टन्स सर्वांसाठी खुला केल्यानंतर एक आठवडा /stats वर लक्ष ठेवा, कारण निकाल मिळणे बंद झाल्याचे तुमच्या लक्षात येण्यापूर्वीच अपस्ट्रीम इंजिन्स तुमच्या सर्व्हरला नाकारण्यास सुरुवात करू शकतात.