SearXNG কি নিরাপদ? আপনার query আসলে কে দেখে

SearXNG কি নিরাপদ? সংক্ষিপ্ত উত্তর

SearXNG এক দিক থেকে নিরাপদ এবং অন্য দিক থেকে অনিরাপদ। তাই “SearXNG কি নিরাপদ” প্রশ্নের উত্তর দিতে হলে আগে বলতে হবে, আপনি কার কাছ থেকে আপনার পরিচয় গোপন করতে চাইছেন। SearXNG একটি metasearch engine। এটি আপনার query নিয়ে Google, Bing, DuckDuckGo এবং আপনি সক্রিয় করা অন্যান্য engine-এ পাঠায়। এরপর সেগুলোর ফলাফল একত্র করে একটি results page দেখায়। Engine-গুলো instance-টিকে দেখে। Instance আপনাকে দেখে।

কোনো অপরিচিত ব্যক্তির পরিচালিত public instance ব্যবহার করলে আপনি যে প্রতিটি query লিখছেন, সেই ব্যক্তি তা plain text-এ পান। তাদের about page-এ লেখা কোনো তথ্যই প্রমাণ করতে পারে না যে তারা ওই query নিয়ে কী করেন। নিজের server ব্যবহার করলে upstream engine-গুলো আপনার বাড়ির address-এর বদলে আপনার server-এর address দেখে। এই address পরিবর্তনই privacy-এর পুরো বিষয়। এর মূল্য server-এর নিরাপত্তা ও নির্ভরযোগ্যতার সমান।

এতে আপনার নিজের network থেকে আপনার search গোপন হয় না। আপনার internet service provider (ISP) এখনও instance-এ একটি connection দেখতে পায়। আপনার DNS (domain name system) resolver এখনও hostname দেখতে পায়। বাকি অংশ পড়ার সময় এই সীমাটি মনে রাখুন।

সার্চ অনুরোধে SearXNG যে পরিবর্তন করে

Google-এ সরাসরি সার্চ করলে Google আপনার IP address, cookies, User-Agent header এবং আপনি যে page থেকে এসেছেন সেটি পায়। এগুলো এমন একটি profile-এর সঙ্গে যুক্ত থাকে, যা session শেষ হওয়ার পরও থেকে যায়। SearXNG মাঝখানে থাকে। এর documentation-এ এটি যে দুটি কাজ করে তা বলা হয়েছে: “search service-এ পাঠানো অনুরোধ থেকে private data সরিয়ে ফেলা” এবং “প্রতিটি অনুরোধের জন্য একটি random browser profile তৈরি করা”। আপনার cookies কোনো engine-এ forward করা হয় না। আপনার preferences server-এর account-এ নয়, আপনার নিজের browser-এ সংরক্ষিত থাকে।

ডিফল্টভাবে দুটি response header পাঠানো হয়। দুটিই কার্যকর ভূমিকা রাখে:

default_http_headers:
  X-Robots-Tag: noindex, nofollow
  Referrer-Policy: no-referrer

Referrer-Policy: no-referrer এর অর্থ হলো, আপনি কোনো result-এ click করলে destination site জানতে পারে না কোন search page থেকে আপনি সেখানে গেছেন, কারণ browser Referer header পাঠায় না। X-Robots-Tag: noindex, nofollow আপনার instance এবং এর result page-গুলোকে search index-এর বাইরে রাখে।

SearXNG যে বিষয়টি পরিবর্তন করে না, তা হলো query নিজেই। এটি instance-এ সম্পূর্ণ এবং পাঠযোগ্য অবস্থায় পৌঁছায়, কারণ TLS (transport layer security) সেখানেই terminate হয়। নিচের প্রতিটি বিষয় ওই একটি তথ্য থেকেই অনুসৃত হয়।

একটি public instance-এ operator প্রতিটি query দেখতে পান

প্রকল্পটির নিজস্ব documentation বিষয়টি স্পষ্টভাবে বলেছে: একটি public instance-এর ব্যবহারকারীদের “have to trust the administrator of that instance”, এবং তারা জানতে পারেন না “whether their requests are logged, aggregated, and sent or sold to a third party”। কোনো landing page-এ no-logs দাবি থাকলেই সেটি একটি দাবি মাত্র। বাইরে থেকে এটি পরীক্ষা করার কোনো উপায় নেই। তাই আপনাকে trust করতে হবে, নয়তো কিছুই নয়। কিছু public instance এখনও এই fork-এর পরিবর্তে মূল Searx চালায়। এটি গুরুত্বপূর্ণ, কারণ Searx 2023 সাল থেকে কোনো code commit গ্রহণ করেনি। Unmaintained search software এমন আরেকটি উপাদান, যেটির ক্ষেত্রে আপনাকে অন্ধভাবে trust করতে হবে।

Logging-ও সবচেয়ে সহজ পদ্ধতি, কারণ shipped default আপনার query-কে URL-এ রাখে:

server:
  method: "GET"

GET ব্যবহার করলে request line-এ query ?q=... হিসেবে যায়। যেকোনো সাধারণ reverse proxy সেই request line তার access log-এ লেখে। তাই কেউ আলাদাভাবে record করার সিদ্ধান্ত না নিলেও query record হয়ে যায়:

203.0.113.5 - - [20/Aug/2026:09:14:02 +0000] "GET /search?q=redundancy+pay+notice+period&category_general=1&language=en HTTP/1.1" 200 15321 "-" "Mozilla/5.0 (X11; Linux x86_64)"

নিজের instance-এ নিজেই পরীক্ষা করুন:

sudo tail -n 5 /var/log/nginx/access.log

সেখানে আপনার search রয়েছে, কারণ nginx-এর combined log format $request লেখে। এটি query string-সহ সম্পূর্ণ request line। SearXNG এ বিষয়ে কোনো নিয়ন্ত্রণ পায় না। Instance-কে method: "POST"-এ পরিবর্তন করলে query request body-তে চলে যায়। ফলে এটি access log বা browser history-তে আর দেখা যায় না। Documentation-এ সৎভাবে বলা আছে, POST-এর কিছু অসুবিধা রয়েছে, যা "severely restrict the ease of use for the end user"। এর প্রধান সমস্যা browser-এর back button নিয়ে। এটি একটি সচেতন trade-off।

যেকোনো public instance-এর ক্ষেত্রে এর দুটি পরিণতি রয়েছে। Operator আপনার query পড়তে পারেন, তারা সেগুলো collect করতে চেয়েছিলেন কি না তা নির্বিশেষে। Backup বা breach হলেও একই log-এ প্রবেশ করা যায়।

নিজের VPS-এ চালালে সার্চ ইঞ্জিনগুলো আপনার বদলে আপনার সার্ভার দেখতে পায়

VPS (virtual private server)-এ নিজের instance চালালে পরিবর্তনটি সহজে বলা যায়। আপনার query-এর সঙ্গে Google আর আপনার বাড়ির IP address পায় না। এর বদলে আপনার query-এর সঙ্গে আপনার server-এর IP address পায়। সেই search-কে আপনার logged-in account, আপনার phone বা আপনার household connection-এর সঙ্গে যুক্ত advertising profile-এর সঙ্গে মেলানো Google-এর পক্ষে সম্ভব হয় না। সম্পূর্ণ setup প্রক্রিয়া VPS-এ নিজের SearXNG instance চালানোর গাইড-এ দেওয়া আছে।

কী পরিবর্তন হয়নি, তা স্পষ্টভাবে বুঝুন। সার্চ ইঞ্জিনগুলো এখনও query text, সময়, আপনার চাওয়া language ও region এবং কয়েক মাস ধরে আপনার করা সব search-এর সামগ্রিক ধরন দেখতে পায়। এগুলো একটি স্থায়ী address-এর অধীনে একত্রিত থাকে। আপনি একমাত্র user হলে, সেই address-টি নাম ছাড়া একজন ব্যক্তির search stream হিসেবে কাজ করে। এই grouping ভাঙতে হলে instance-কে outbound proxy বা Tor-এর মাধ্যমে সার্চ ইঞ্জিনগুলোর কাছে পৌঁছাতে হবে। SearXNG উভয় পদ্ধতিই সমর্থন করে, তবে এটি আলাদা একটি কাজ।

আপনার ISP, resolver এবং host এখনও কী দেখতে পায়

এই সবকিছুর পরও চারজন পর্যবেক্ষকের দৃষ্টিতে কোনো পরিবর্তন হয় না।

• আপনার ISP আপনার instance-এর IP address-এ একটি TLS connection দেখতে পায়। Handshake চলাকালে cleartext-এ পাঠানো SNI (server name indication) field-এ hostname-ও দেখতে পায়। তবে query দেখতে পায় না।
• আপনার DNS resolver ওই hostname-এর lookup দেখতে পায়। Page load করার সময় client-এ sudo tcpdump -ni any port 53 দিয়ে এটি monitor করুন। তখন আপনার instance-এর A record-এর request দেখা যাবে।
• আপনার VPS provider hardware পরিচালনা করে। তাই virtual machine-এর disk এবং memory পড়তে পারে। ভাড়া নেওয়া VM-এর ভেতরে disk encryption ব্যবহার করলেও এটি বন্ধ হয় না, কারণ চলমান system-এর কাছে key থাকে।
• Instance-এ root access থাকা যে কেউ সবকিছু দেখতে পায়। এর মধ্যে আপনি নিজেও আছেন, এবং পরে যে কেউ system-এ প্রবেশ করতে পারে সেও আছে।

Tor onion service হিসেবে instance-এ পৌঁছালে প্রথম দুটি বিষয় আর থাকে না। কারণ resolve করার মতো কোনো public hostname থাকে না এবং পড়ার মতো কোনো SNI field-ও থাকে না। VPS-এ v3 onion service যোগ করার নির্দেশিকা-তে setup এবং এমন leak সম্পর্কেও বলা হয়েছে, যেগুলো অন্যথায় ওই address-কে আপনার server-এর public IP-এর সঙ্গে যুক্ত করতে পারে।

আরেকটি বিষয় মানুষ প্রায়ই ভুলে যায়। আপনার server-এর outbound request server-এর নিজস্ব network থেকেই দেখা যায়। তাই provider দেখতে পারে যে আপনার machine সারাদিন Google এবং Bing-এর সঙ্গে যোগাযোগ করছে। এটি query নয়, একটি traffic pattern। তবু এটি কিছু তথ্য প্রকাশ করে।

এখানেই VPN নিয়ে প্রশ্ন আসে। VPN (virtual private network) আপনার ISP যে দৃশ্য দেখতে পায়, তা VPN কোম্পানির দৃশ্যে স্থানান্তর করে। এটি instance operator সম্পর্কে কিছু পরিবর্তন করে না। Engines সম্পর্কেও কিছু পরিবর্তন করে না, কারণ engines আপনার সঙ্গে নয়, আপনার server-এর সঙ্গে যোগাযোগ করে। দুটির যথাযথ তুলনা VPS এবং VPN-এর তুলনামূলক বিশ্লেষণ-এ দেওয়া হয়েছে।

SearXNG কেন আপনাকে block করে এবং 429 আসলে কী বোঝায়

দুটি ভিন্ন ঘটনাকেই অনেকে “SearXNG আমাকে block করেছে” বলে বর্ণনা করেন। এদের সমাধানও আলাদা।

প্রথমটি হলো আপনার নিজের limiter-এর HTTP 429 উত্তর। এটি SearXNG-এর bot protection, এবং default অবস্থায় এটি বন্ধ থাকে:

server:
  limiter: true
valkey:
  url: valkey://localhost:6379/0

August 2026 অনুযায়ী limiter-এর জন্য একটি Valkey database দরকার এবং এটি /etc/searxng/limiter.toml থেকে rules পড়ে। অপরিচিত লোকজন সত্যিই এই box ব্যবহার করলে server.public_instance: true-ও সেট করুন, কারণ default অবস্থায় এটি false এবং public use-এর জন্য নির্ধারিত আচরণ নিয়ন্ত্রণ করে।

Limiter কয়েকটি probe চালায়। http_user_agent-এ User-Agent unset থাকলে, অথবা curl ও wget-এর মতো পরিচিত tool-এর সঙ্গে মিললে, সেটিকে bot হিসেবে গণ্য করা হয়। http_accept-এ কোনো request-এর Accept header-এ text/html না থাকলে সেটিকে bot হিসেবে গণ্য করা হয়। কোনো বাস্তব browser যে /client<token>.css URL load করে, কোনো client কখনও সেটি fetch না করলে link_token client-টিকে সন্দেহজনক হিসেবে চিহ্নিত করে। কোনো probe সক্রিয় হলে SearXNG 429 উত্তর দেয় এবং তার botdetection logger-এ একটি ERROR line লেখে।

তাই এটি ব্যর্থ হয়, এবং এটাই প্রত্যাশিত আচরণ:

curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test'

curl User-Agent: curl/8.5.0 এবং Accept: */* পাঠায়, তাই একই সময়ে দুটি probe মিলে যায়। এ কারণেই browser-এ ঠিকমতো কাজ করা কোনো instance থেকে script ও AI agent 429 পায়। নিজের instance-এ কোনো agent-এর search skill নির্দেশ করার আগে এটিই ঠিক করতে হবে। কারণ ও settings-এর সম্পূর্ণ তালিকা SearXNG rate limit এবং 429 error-এর guide-এ রয়েছে।

একটি limiter-সংক্রান্ত সমস্যা আলাদাভাবে উল্লেখ করা দরকার। reverse proxy-এর পেছনে trusted proxy সেট না করা থাকলে SearXNG visitor-এর address-এর বদলে proxy-এর address দেখে:

[botdetection]
ipv4_prefix = 32
ipv6_prefix = 48
trusted_proxies = ['127.0.0.0/8', '::1']

[botdetection.ip_limit]
link_token = false

[botdetection.ip_lists]
pass_ip = []
block_ip = []

Default list-এ একই host-এ থাকা proxy অন্তর্ভুক্ত থাকে। আলাদা Docker network-এর proxy 172.18.0.5-এর মতো কোনো address থেকে request পাঠায়, যা list-এ নেই। ফলে প্রত্যেক visitor-কে একই client হিসেবে গণনা করা হয়, এবং প্রথম ব্যস্ত user অন্য সবাইকে access থেকে বঞ্চিত করে। trusted_proxies-এ ওই subnet যোগ করুন।

দ্বিতীয় ধরনের block upstream-এ ঘটে। কোনো engine মনে করতে পারে যে অনেক search চালানো datacenter address থেকে scraper কাজ করছে, এবং আপনার server-কে উত্তর দেওয়া বন্ধ করতে পারে। এ ক্ষেত্রে আপনি 429 পাবেন না। আপনি এমন একটি results page পাবেন যেখানে ওই engine-এর results অনুপস্থিত থাকবে এবং engine-টির বিরুদ্ধে একটি failure উল্লেখ থাকবে। বারবার failure হলে SearXNG কিছু সময়ের জন্য engine-টি suspend করবে। কারণটি আপনার VPS যে address ব্যবহার করে সেটি। তাই সমাধান limiter-এর settings নয়; engine নির্বাচন এবং অপেক্ষা করা।

অপরিচিত ব্যক্তিদের সঙ্গে একটি instance ভাগ করলে কি উপকার হয়, নাকি ক্ষতি?

দুই দিকেই প্রভাব পড়ে। তাই এর উত্তর সরল নয়। Anonymity একটি crowd effect। ব্যস্ত public instance-এ আপনার query হাজারো অন্য ব্যক্তির query-এর সঙ্গে একই address থেকে যায়। তাই কোনো engine-ই সেগুলোর মধ্য থেকে আপনার query আলাদা করে শনাক্ত করতে পারে না। আপনার single-user instance-এ ওই address থেকে আসা প্রতিটি query আপনার। ফলে engine-গুলো নামবিহীন, এক ব্যক্তির একটি পরিষ্কার stream পায়।

Operator-এর দিকটি এর বিপরীত। বড় crowd-এর অর্থ হলো, একজন অপরিচিত ব্যক্তি সেই crowd-এর plain text query ধরে রাখে, যার মধ্যে আপনার query-ও আছে। নিজের box ব্যবহার করলে আপনার query আপনার কাছেই থাকে, অন্য কারও query থাকে না।

তাই আপনার প্রকৃত threat অনুযায়ী সিদ্ধান্ত নিন। Ad profiling এবং cross-site tracking নিয়ে উদ্বিগ্ন? Crowd এ ক্ষেত্রে ভালোভাবে সুরক্ষা দেয়, আর operator-এর ঝুঁকি কম। কোনো নির্দিষ্ট ব্যক্তি বা company আপনার করা কোনো নির্দিষ্ট search পড়ে ফেলতে পারে—এটি নিয়ে উদ্বিগ্ন? Crowd কোনো সাহায্য করে না, কারণ operator raw text দেখতে পায়। একটি ভালো মধ্যপন্থা হলো আপনার পরিচিত অল্প কয়েকজনের জন্য একটি instance চালানো। এতে ছোট একটি crowd পাবেন এবং operator-কে যাচাই করতে পারবেন, কারণ operator আপনি নিজেই।

Google-এর চেয়ে SearXNG-এর ফলাফল কি ভালো?

না। SearXNG-এর নিজস্ব কোনো index নেই। তাই পৃষ্ঠার প্রতিটি ফলাফল upstream engine থেকে এসেছে। ফলাফলের মান সর্বোচ্চ যে স্তরে পৌঁছাতে পারে, আপনি যে engine-গুলো সক্রিয় করেছেন সেই স্তরই তার সীমা। Google এবং Bing নিষ্ক্রিয় করলে একই দিনেই মান কমে যায়, কারণ সাধারণ web-এর অধিকাংশ coverage এই engine-গুলো থেকেই এসেছে।

যা পরিবর্তিত হয়, তা হলো আপনার ওপর প্রয়োগ করা processing। Query থেকে কোনো কিছুই advertising profile তৈরি করে না। আপনি গত সপ্তাহে কোন ফলাফলে click করেছেন, তার ভিত্তিতেও কোনো কিছু ফলাফল পুনর্বিন্যাস করে না। এতে সুবিধা ও অসুবিধা দুটিই আছে, কারণ personalisation স্থানীয় search intent-ও সরবরাহ করে। "pharmacy open now"-এর মতো search SearXNG-এর মাধ্যমে তুলনামূলক দুর্বল ফল দেয়, কারণ আপনার server যে datacenter-এ রয়েছে সেটি ছাড়া engine-এর কাছে আপনার অবস্থান সম্পর্কে কোনো signal নেই। স্থানীয় ফলাফল প্রয়োজন হলে preferences-এ region নির্ধারণ করুন।

আপনি ফলাফল পড়ার সময় আপনার instance কতটা তথ্য প্রকাশ করবে, তা দুটি setting নির্ধারণ করে। image_proxy ডিফল্টভাবে false থাকে। তাই thumbnail সরাসরি সেগুলো host করা site থেকে load হয়, এবং সেই site-গুলো আপনার browser-এর address দেখতে পায়। image_proxy: true নির্ধারণ করলে thumbnail instance-এর মাধ্যমে পাঠানো হয়। এর বিনিময়ে bandwidth এবং memory বেশি লাগে। আর formats শুধু html হিসেবেই ship করা হয়। তাই JSON (JavaScript object notation) request 403 Forbidden দিয়ে প্রত্যাখ্যাত হয়:

curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test&format=json'

একটি public instance-এ json সক্রিয় করলে আপনি একটি free scraping API প্রকাশ করে ফেলবেন। আপনার নির্ভর করা engine-গুলোর কাছে server-এর address block হওয়ার দ্রুততম উপায় এটি। এটি বন্ধ রাখুন, অথবা authentication-এর আড়ালে রাখুন।

SearXNG-এর গোপনীয়তা সুরক্ষার সীমা

SearXNG search engine-গুলোর কাছ থেকে কে অনুসন্ধান করছে তা আড়াল করে। কিন্তু আপনার network-এ আপনি কী করছেন, তা আড়াল করে না। এর ফলে 4টি সীমা থাকে।

• Search box ছাড়া অন্য সব ক্ষেত্রে আপনার traffic অপরিবর্তিত থাকে। মেশিনটি যা কিছু করে, সব আগের মতোই আপনার network ছেড়ে যায়।
• একটি server-এ একজন user প্রতিটি engine-এর কাছে একটি স্থায়ী identifier হিসেবে থাকে। এই identifier-এ কোনো নাম থাকে না, এবং এটাই এর সম্পূর্ণ সুবিধা।
• যেকোনো instance-এর operator query-টি plain text হিসেবে পড়তে পারেন। আপনি নিজেই operator হলে কেবল এই বিষয়টি যাচাই করতে পারবেন।
• আপনার নিজের access log-ই সেই record আবার তৈরি করে, যা আপনি এড়াতে চেয়েছিলেন। Log পড়ুন, আর সেগুলো খালি রাখতে চাইলে method: "POST"-এ switch করুন।

SearXNG observer-কে বদলে দেয়। Observation সরিয়ে দেয় না। কোন observer আপনাকে বেশি উদ্বিগ্ন করে তা নির্ধারণ করুন, সেই অনুযায়ী instance বেছে নিন, এবং search front end-কে anonymity software হিসেবে বিবেচনা করবেন না।

FAQ

কোনো public instance-এ SearXNG ব্যবহার করা কি নিরাপদ?

Search engine-এর দিক থেকে এটি নিরাপদ, কিন্তু operator-এর দিক থেকে নিরাপদ নয়। আপনার query plain text হিসেবে সেই server-এ পৌঁছায়। Project-এর documentation-এ বলা আছে, ব্যবহারকারীদের "have to trust the administrator of that instance" এবং "whether their requests are logged, aggregated, and sent or sold to a third party" তা তারা জানতে পারেন না। method: "GET"-এর shipped default ব্যবহৃত হলে query-টি request line-এর অংশ হিসেবে reverse proxy-এর access log-এও লেখা হয়, operator তা চান কি না সেটি বিবেচ্য নয়। Ad profiling নিয়ে উদ্বেগ থাকলে সাধারণ searching-এর জন্য public instance ব্যবহার করুন। এমন কোনো instance-এ এমন তথ্য লিখবেন না, যা আপনি তার owner-কে দিতে চাইবেন না।

SearXNG কি আমার search-গুলো internet provider-এর কাছ থেকে আড়াল করে?

Query text আড়াল থাকে। তবে activity আড়াল থাকে না। আপনার provider আপনার instance-এর address-এ একটি TLS connection এবং handshake-এর cleartext SNI field-এ hostname দেখতে পায়। আপনার DNS resolver ওই hostname-এর lookup-ও দেখতে পায়। Connection encrypted হওয়ায় তারা আপনি কী search করেছেন তা দেখতে পারে না। SearXNG কোনো VPN নয়। আপনার machine-এর অন্য কোনো traffic-কে এটি সুরক্ষা দেয় না।

SearXNG 429 error ফেরত দেয় কেন?

429 আসে instance-এর নিজস্ব limiter থেকে। এটি bot protection, Google-এর পাঠানো কোনো message নয়। এর probe এমন request শনাক্ত করে যার Accept header-এ text/html নেই। User-Agent unset থাকলেও বা curl ও wget-এর মতো tool-এর সঙ্গে মিলে গেলেও এটি শনাক্ত হয়। তৃতীয় probe, link token, এমন client শনাক্ত করে যা browser load করা /client<token>.css URL কখনো fetch করে না। /etc/searxng/limiter.toml-এর trusted_proxies-এ reverse proxy-এর address না থাকলে প্রত্যেক visitor-কে একই client হিসেবে গণনা করা হয়। ফলে একজন ব্যস্ত user বাকি সবাইকে block করতে পারে। এর পরিবর্তে কোনো upstream engine আপনার server-কে block করলে, সেই engine-এর result page থেকে শুধু অদৃশ্য হয়ে যায় এবং আপনি কোনো 429 পান না।

SearXNG self-hosting করলে কি আমার search result খারাপ হয়?

কখনো কখনো হয়। এর দুটি কারণ জানা গুরুত্বপূর্ণ। Result upstream engine থেকে আসে। তাই engine-গুলো যদি datacenter address throttle করে, তাহলে কম engine উত্তর দেয় এবং page-এ result কম থাকে। Personalised ranking-ও থাকে না। এতে ad-driven reordering দূর হয়, কিন্তু local intent-ও বাদ যায়। ফলে preferences-এ region সেট না করা পর্যন্ত location-sensitive search-এ দুর্বল উত্তর পাওয়া যায়।