اپنا نجی SearXNG سرچ انجن Docker Compose سے چلائیں

آپ کیا بنا رہے ہیں

SearXNG کو self-host کرنے سے آپ کو ایک نجی search engine ملتا ہے جو آپ کے اپنے server پر چلتا ہے۔ SearXNG ایک metasearch engine ہے: یہ آپ کی query لے کر Google، Bing، DuckDuckGo اور Wikipedia جیسے دوسرے engines سے نتائج طلب کرتا ہے، پھر موصولہ نتائج کو ایک result page میں یکجا کر دیتا ہے۔ کوئی profile نہیں بنائی جاتی اور کوئی tracking cookie set نہیں ہوتی، کیونکہ آپ کی query محفوظ رکھنے والی واحد machine آپ کی اپنی ہے۔ اگر آپ کو کسی ایسی چیز کے بارے میں پرانی guides ملی ہیں جسے صرف Searx کہا جاتا ہے، تو موجودہ project اسی سے fork کیا گیا تھا۔ یہ September 2023 سے unmaintained ہے، جب اس کی اپنی repository نے اعلان کیا تھا کہ Searx کی مزید maintenance نہیں کی جا رہی؛ اس کے بعد کا واحد commit، May 2026 میں documentation note، بھی اس صورت حال کو تبدیل نہیں کرتا۔ اس لیے دونوں کی حالت دیکھ کر ہی کسی ایک کو استعمال کریں۔

یہ stack چھوٹا ہے۔ دو containers، ایک settings file، اور ایک reverse proxy۔ یہ ایک چھوٹے VPS پر آسانی سے چل جائے گا، لیکن ہر self-hosted service کے لیے ایسا نہیں ہوتا: PhotoPrism اور Immich کے موازنے میں زیرِ غور photo libraries اپنی RAM کی کم از کم ضرورت web app کے بجائے indexer کے مطابق طے کرتی ہیں۔ اصل فیصلہ یہ ہے کہ instance private ہو، یعنی صرف آپ اور آپ کے اپنے scripts اس تک رسائی حاصل کریں، یا public ہو، یعنی internet پر موجود کوئی بھی شخص اس سے query کر سکے۔ یہ انتخاب security settings تبدیل کرتا ہے، اس لیے کچھ بھی type کرنے سے پہلے فیصلہ کر لیں۔ Default جواب private ہے۔

اسے چلانے کی ایک دوسری وجہ بھی ہے۔ SearXNG instance JSON میں جواب دیتا ہے، اس لیے آپ جو بھی script یا AI agent لکھیں، اسے ایسا search API ملتا ہے جو آپ کی ملکیت ہوتا ہے، جس کے لیے key، فی query billing یا quota سے متعلق کوئی email درکار نہیں ہوتی۔

Docker Compose کے ساتھ SearXNG انسٹال کریں

یہ project ایک container image اور Compose file جاری کرتا ہے۔ دونوں کو ایک نئے Ubuntu 24.04 server پر حاصل کریں، جس پر پہلے سے Docker Engine اور Compose plugin موجود ہوں۔ اگر 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 file میں دو services کی تعریف کی گئی ہے۔ core خود SearXNG ہے، جبکہ valkey ایک in-memory data store ہے جو rate limiting اور مختصر مدت کے state کے لیے استعمال ہوتا ہے۔ یہ ./core-config/ کو container کے اندر /etc/searxng/ پر mount کرتا ہے، اس لیے آپ کی تمام configuration host پر اسی ایک directory میں رہتی ہے۔

اب .env میں ترمیم کریں۔ فراہم کردہ example کی ہر لائن comment کی گئی ہے، اسی لیے container ہر address پر port 8080 پر شروع ہوتا ہے۔ ان تین settings کو uncomment کرکے values مقرر کریں۔

SEARXNG_VERSION=latest
SEARXNG_HOST=127.0.0.1
SEARXNG_PORT=8080

SEARXNG_HOST=127.0.0.1 اہم setting ہے۔ یہ published port کو 127.0.0.1:8080:8080 بناتی ہے، نہ کہ صرف 8080:8080۔ Docker صرف 8080:8080 کو ہر address پر publish کرتا ہے، اس لیے container صرف loopback address پر جواب دیتا ہے اور internet اس تک براہِ راست نہیں پہنچ سکتا۔ اگر یہ setting چھوڑ دیں تو container شروع ہوتے ہی exposed ہو جاتا ہے، کیونکہ published Docker port آپ کے firewall rules سے پہلے insert ہو جاتا ہے۔ اس مسئلے کی مکمل وضاحت یہاں موجود ہے: published Docker ports، ufw کو bypass کرتے ہیں۔

سیکھنے کے دوران SEARXNG_VERSION=latest قابلِ قبول ہے۔ جس server کی آپ کو حفاظت کرنی ہو، وہاں tag کو pin کریں۔ October 2026 تک release tags تاریخ پر مبنی ہیں اور 2026.10.4-d48c4b555 جیسے دکھائی دیتے ہیں، اس لیے pinned deployment اسی وقت upgrade ہوتی ہے جب آپ فیصلہ کریں، نہ کہ اس وقت جب registry میں تبدیلی ہو۔ یہی اصول server پر طویل مدت تک چلنے والی دوسری چیزوں کے لیے بھی مفید ہے۔ اسی وجہ سے self-hosted RustDesk relay بھی اپنے image tags کو pin کرتا ہے: remote access service کی unattended upgrade بدترین ممکنہ وقت پر ظاہر ہوتی ہے۔

settings.yml: اہم حصے

پہلی بار start کرنے سے پہلے core-config/settings.yml بنائیں۔ use_default_settings: true، SearXNG کو پہلے اس کے فراہم کردہ default settings لوڈ کرنے اور پھر صرف آپ کی لکھی ہوئی keys لاگو کرنے کی ہدایت دیتا ہے۔ اس طرح آپ کی file مختصر رہتی ہے اور نئی options شامل ہونے والی upgrades کے بعد بھی برقرار رہتی ہے۔

پہلے secret generate کریں، کیونکہ اس کی value براہِ راست file میں جائے گی۔

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 data پر cryptographic signature لگاتا ہے۔ فراہم کردہ default literal string ultrasecretkey ہے۔ اسے برقرار رکھنے کا مطلب ہے کہ default جاننے والا کوئی بھی شخص یہ tokens forge کر سکتا ہے۔ اسے ایک بار replace کریں، پھر تبدیل نہ کریں۔ بعد میں اسے تبدیل کرنے سے محفوظ شدہ ہر preference ختم ہو جاتی ہے۔

base_url میں trailing slash سمیت public HTTPS address ہونا چاہیے۔ SearXNG render کیے جانے والے links میں یہی address لکھتا ہے۔ اگر اسے localhost پر رہنے دیں تو remote browser میں "next page" link قاری کی اپنی machine کی طرف point کرے گا اور fail ہو جائے گا۔

formats طے کرتا ہے کہ web endpoint کون سی output types فراہم کرے گا۔ json default list میں شامل نہیں ہے، اس لیے اسے شامل کرنے تک JSON request 403 واپس کرے گی۔ image_proxy: true result thumbnails کو آپ کے server کے ذریعے route کرتا ہے، اس لیے ان images کو host کرنے والی sites آپ کے visitors کے addresses نہیں دیکھیں گی۔

valkey.url hostname valkey استعمال کرتا ہے، کیونکہ Compose file میں service name یہی ہے، اور Compose دونوں containers کو ایک network پر رکھتا ہے جہاں service names resolve ہوتے ہیں۔ اسے localhost کی طرف point کرنے سے limiter fail ہو جاتا ہے، کیونکہ core container کے اندر localhost اسی container کو ظاہر کرتا ہے۔

Secret ایک plain file میں موجود ہے، اس لیے اس کے اردگرد موجود directory کو بھی protect کریں۔ chmod 750 /opt/searxng دوسرے host users کو اس directory سے باہر رکھتا ہے۔ آپ core-config/settings.yml کو mode 600 تک بھی محدود کر سکتے ہیں، اس سے کچھ نہیں ٹوٹے گا۔ Official container کا entrypoint root کے طور پر start ہوتا ہے اور، جب FORCE_OWNERSHIP کو اس کی default value true پر رہنے دیا جائے، تو SearXNG start ہونے سے پہلے mounted config directory کی ownership container کے اپنے searxng user کو دے دیتا ہے۔ اس لیے file اس user کے لیے readable رہتی ہے۔ اس کا اثر host پر ظاہر ہوتا ہے: یہی مرحلہ core-config/ کا owner container کے user ID میں تبدیل کر دیتا ہے، اس لیے اس کے بعد file edit کرنے کے لیے sudo استعمال کرنے کی توقع رکھیں۔

Stack start کریں اور اسے check کریں۔

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

docker compose ps میں دونوں containers کی state running دکھائی دینی چاہیے۔ curl کو HTTP/1.1 200 OK کا جواب دینا چاہیے۔ اگر کوئی جواب نہ ملے تو docker compose logs core پڑھیں، کیونکہ settings.yml میں YAML کی غلطی وہاں line کا نام بتانے والے parse error کے طور پر ظاہر ہوتی ہے۔

اسے TLS کے ساتھ nginx کے پیچھے رکھیں

Container صرف loopback پر listen کرتا ہے، اس لیے اسے قابل رسائی بنانے کا کام nginx کرتا ہے۔ 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 اسی file کو دوبارہ لکھ کر certificate کے ساتھ 443 پر listen کرنے کی configuration بناتا ہے اور port 80 سے redirect بھی شامل کرتا ہے۔ search.example.com کا DNS record پہلے ہی اس server کی طرف point کرنا چاہیے، کیونکہ certificate authority HTTP کے ذریعے ایک file fetch کر کے ملکیت کی تصدیق کرتی ہے۔ Renewal سمیت مکمل طریقہ Ubuntu 24.04 کے لیے Certbot اور nginx گائیڈ میں موجود ہے۔

یہ دونوں forwarding headers محض ظاہری چیز نہیں ہیں۔ X-Forwarded-For اور X-Real-IP کے بغیر SearXNG تک پہنچنے والی ہر request میں proxy address شامل ہوتا ہے۔ اس لیے rate limiter پورا traffic ایک ہی client کی طرف سے آتا ہوا دیکھتا ہے اور مختلف visitors میں فرق نہیں کر سکتا۔

اسکرپٹس اور agents کو JSON search API کیوں درکار ہوتی ہے

json کو formats میں فعال کرنے پر، page render کرنے والا یہی endpoint structured data واپس کرتا ہے۔

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

آپ کو ایک object واپس ملتا ہے جس میں results array شامل ہوتا ہے۔ اس کی ہر entry میں url، title، content اور اسے فراہم کرنے والا engine، نیز answers، infoboxes اور suggestions شامل ہوتے ہیں۔ یہ data summariser، link checker یا research loop کو دینے کے لیے کافی ہے۔ ان نتائج کو language model کے حوالے کرنا بظاہر معمولی مگر اہم قدم ہے، کیونکہ search results غیر معتبر متن ہوتے ہیں اور ان میں اپنی ہدایات بھی شامل ہو سکتی ہیں۔ AI agent کو اپنی SearXNG instance سے جوڑنا اسی مسئلے کو تفصیل سے حل کرتا ہے۔

یہ بات agent جیسے کسی بھی نظام کے لیے اہم ہے۔ language model کی training cutoff ہوتی ہے، اس لیے موجودہ حالات سے متعلق سوالات کے جواب دینے کے لیے اسے live search درکار ہوتی ہے۔ تجارتی search APIs فی query معاوضہ لیتی ہیں اور rate limit بھی سخت رکھتی ہیں۔ Local instance کی لاگت پہلے سے زیرِ استعمال server پر ایک container تک محدود رہتی ہے، اور queries اس server سے باہر نہیں جاتیں۔ اگر آپ model میں tools شامل کر رہے ہیں تو یہی منطق VPS پر MCP servers چلانے کے لیے بھی ہے، جہاں search tool عموماً سب سے پہلے شامل کیا جاتا ہے۔

API استعمال کرنے کے لیے دو اصول اپنائیں۔ Instance کو private رکھیں۔ API side کو loopback address یا private network پر bind کریں اور صرف اپنے hosts کو اس تک رسائی دیں۔ یہی طریقہ self-hosted location tracker کے اس endpoint کے لیے بھی ضروری ہے جس پر آپ کا phone اپنی location report کرتا ہے۔ پھر queries محدود رفتار سے بھیجیں۔ SearXNG آپ کی request حقیقی search engines کو forward کرتا ہے، اس لیے اگر script ہر second میں 100 queries چلائے گی تو آپ اپنے server کو block کروانے کے لیے Google سے کہہ رہے ہوں گے۔

محدودکنندہ، اور public instance کے لیے کیا تبدیل ہوتا ہے

محدودکنندہ SearXNG کا bot defence ہے۔ یہ request headers، addresses اور request rates کی نگرانی کرتا ہے اور ایسی network traffic کو روک دیتا ہے جو automated معلوم ہو۔ اپنی state محفوظ رکھنے کے لیے اسے Valkey درکار ہوتا ہے، اسی لیے Compose file میں یہ شامل ہے۔

Private instance پر limiter: false برقرار رکھیں۔ آپ کی اپنی scripts تعریف کے مطابق automated traffic ہیں، اس لیے محدودکنندہ بالکل وہی JSON calls روک دے گا جن کے لیے آپ نے instance بنایا ہے۔ اس کے بجائے access control reverse proxy کی ذمہ داری ہے: nginx location میں allow اور deny کا جوڑا، HTTP basic authentication، یا ایسا firewall جو صرف آپ کے دوسرے servers سے آنے والی traffic قبول کرے۔ اگر آپ کو مختلف networks کے درمیان منتقل ہونے والے laptop سے private instance تک رسائی درکار ہو تو اس کے سامنے v3 onion address رکھنا چوتھا اختیار ہے، کیونکہ tor نئی چیز کو internet پر ظاہر کیے بغیر اسی loopback port سے connect کرتا ہے۔

اگر آپ instance کو دوسرے لوگوں کے لیے public کرتے ہیں تو دونوں switches آن کریں۔

server:
  limiter: true
  public_instance: true

مزید باریک control core-config/limiter.toml میں ہوتا ہے، جسے container /etc/searxng/limiter.toml سے پڑھتا ہے۔ صرف وہی keys لکھیں جنہیں آپ تبدیل کرنا چاہتے ہیں۔ Proxy کے پیچھے آپ کو proxy declare کرنا ہوگا، ورنہ محدودکنندہ آپ کے nginx address کو ایک ہی abusive client سمجھے گا۔

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

[botdetection.ip_limit]
link_token = true

link_token = true سے SearXNG ایسا token جاری کرتا ہے جسے صرف ایک حقیقی browser session fetch کرے گا، اور اس سے زیادہ تر سادہ scrapers رک جاتے ہیں۔ توقع رکھیں کہ public instance چند دنوں میں scrapers کی توجہ حاصل کر لے گا۔ Engine errors کی بھی توقع رکھیں، کیونکہ آپ جتنی زیادہ traffic آگے forward کریں گے، upstream engines اتنی ہی جلد آپ کے server address کو CAPTCHAs واپس کرنا شروع کر دیں گے۔ Public SearXNG instance مسلسل انتظامی کام ہے۔ Private instance ایسا نہیں، اسی لیے یہ 2026 میں self-hosting کے قابل چیزوں کی بیشتر مختصر فہرستوں میں شامل ہوتا ہے۔ ان فہرستوں کی ہر entry infrastructure بھی نہیں ہوتی: Jellyfin library کو walkable 90s rental store کے طور پر دوبارہ بنانا بھی اسی nginx block کے پیچھے موجود اسی ایک container کا استعمال ہے، مگر اس کا مقصد workflow کے بجائے ایک شام ہے۔

تلاشوں کے نتائج خالی کیوں آتے ہیں

اپنے instance پر /stats کھولیں۔ اس میں ہر engine کی error rate اور response time درج ہوتی ہے، اور جب نتائج ناکافی محسوس ہوں تو یہی پہلی جگہ ہے جسے دیکھنا چاہیے۔

جس engine کے سامنے "Access denied" یا "CAPTCHA" error دکھائی دے، اس نے آپ کے server address کو block کر دیا ہے۔ Data centre ranges کے addresses کے لیے یہ عام بات ہے، کیونکہ search engines فرض کرتے ہیں کہ یہ addresses scrapers کے ہیں۔ اس کے بعد SearXNG ناکام engine کو دوبارہ کوشش کرنے کے بجائے کچھ مدت کے لیے suspend کر دیتا ہے۔ یوں ایک blocked engine خاموشی سے نتائج سے خارج ہو جاتا ہے۔ اسے settings.yml میں disable کریں یا اس engine کے نتائج سے محروم رہیں۔ یہ واحد دو راستے نہیں ہیں، کیونکہ کچھ CAPTCHA blocks کا ایسا حل موجود ہے جو restart کے بعد بھی برقرار رہتا ہے۔ باقی engines بدستور جواب دیتے رہتے ہیں۔ 429 مبہم صورت ہے، کیونکہ یہ آپ کے اپنے limiter سے بھی آ سکتا ہے یا upstream engine کی جانب سے آپ کے server کو مسترد کرنے سے بھی۔ Settings تبدیل کرنے سے پہلے log line بتاتی ہے کہ ان دونوں میں سے کون سی صورت درپیش ہے۔

اگر تمام engines ایک ہی وقت میں ناکام ہوں تو container میں outbound name resolution کام نہیں کر رہی یا internet تک کوئی route موجود نہیں ہے۔ یہ test container کے اندر سے کریں۔

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

Box میں کوئی چیز آپ کو نہیں بتائے گی کہ یہ check کب ناکام ہونا شروع ہوا۔ اس لیے اسے cron سے چلائیں اور failure کو اپنے phone پر اپنے ntfy server کے ذریعے alert بھیجنے دیں، بجائے اس کے کہ نتائج کم ہونے کا خود اندازہ ہونے تک انتظار کریں۔

FAQ

کیا SearXNG میری تلاشوں کو گمنام بناتا ہے؟

یہ ان engines سے آپ کی شناخت چھپا دیتا ہے جنہیں یہ query بھیجتا ہے، کیونکہ انہیں درخواست آپ کے browser کے بجائے آپ کے server سے موصول ہوتی ہے۔ یہ query آپ کے server سے نہیں چھپاتا، اور نہ ہی آپ کے server کو ان engines سے چھپاتا ہے۔ Single-user instance میں اس address سے آنے والا تمام traffic آپ کا ہوتا ہے، اس لیے خود address شناخت کنندہ بن جاتا ہے۔ آپ کے browser اور instance کے درمیان traffic TLS certificate کے ذریعے محفوظ ہوتا ہے۔ آپ کے ISP، public instance کے operator اور خود engines کے سامنے اس صورتِ حال کے اثرات کی وضاحت SearXNG حقیقت میں کیا چھپاتا ہے میں کی گئی ہے۔

JSON request کے جواب میں 403 Forbidden کیوں آتا ہے؟

اس کی دو وجوہات ہیں، اور دونوں configuration سے متعلق ہیں۔ یا تو json، settings.yml میں search: کے تحت موجود formats فہرست میں شامل نہیں، جو default حالت ہے، یا limiter فعال ہے اور اس نے آپ کے script کو bot سمجھ لیا ہے۔ پہلے format شامل کریں، پھر docker compose restart core کے ساتھ restart کریں اور دوبارہ کوشش کریں۔ اگر مسئلہ برقرار رہے تو limiter: false set کریں اور access کو reverse proxy پر control کریں۔

اگر limiter بند رکھوں تو کیا Valkey container ضروری ہے؟

اسے running رہنے دیں۔ SearXNG اس کے بغیر کام کرتا ہے، لیکن اس کے بغیر limiter کو بعد میں فعال نہیں کیا جا سکتا، اور یہ دیگر مختصر مدت کے state کو بھی محفوظ رکھتا ہے۔ یہ container چھوٹا ہے اور صرف cached data store کرتا ہے، اس لیے اسے ہٹانے سے بہت کم بچت ہوتی ہے اور بعد میں اسے فعال کرنے کا اختیار ختم ہو جاتا ہے۔

SearXNG کو update کیسے کروں؟

/opt/searxng میں پہلے docker compose pull، پھر docker compose up -d چلائیں۔ Compose اس container کو دوبارہ بناتا ہے جس کی image تبدیل ہوئی ہو، اور آپ کی core-config/ directory کو untouched رکھتا ہے، اس لیے settings.yml برقرار رہتا ہے۔ چونکہ use_default_settings: true آپ کی keys کو shipped defaults پر merge کرتا ہے، اس لیے upstream میں شامل ہونے والے options file کو توڑے بغیر مناسب values کے ساتھ آ جاتے ہیں۔

کیا کئی لوگ ایک instance شیئر کر سکتے ہیں؟

ہاں، اور یہی وہ صورت ہے جس میں آپ limiter فعال کرتے ہیں اور public_instance: true set کرتے ہیں۔ Preferences ہر visitor کے اپنے browser میں محفوظ ہوتی ہیں، اس لیے manage کرنے کے لیے accounts نہیں ہوتے۔ اسے public کرنے کے بعد ایک ہفتے تک /stats monitor کریں، کیونکہ upstream engines آپ کے server کے results غائب ہونے کا احساس ہونے سے بہت پہلے requests مسترد کرنا شروع کر دیتے ہیں۔