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

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

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

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

এতে আপনার নিজের network-এর কাছ থেকে searching গোপন হয় না। আপনার 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-এ SearXNG-এর দুটি কাজ বর্ণনা করা হয়েছে: “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-এর ব্যবহারকারীদের “ওই instance-এর administrator-কে trust করতে হয়” এবং তারা জানতে পারেন না “তাদের request log, aggregate করে, অন্য কোনো third party-কে পাঠানো বা বিক্রি করা হয় কি না”। Landing page-এ no-logs দাবি শুধু একটি দাবি। বাইরে থেকে এটি পরীক্ষা করার কোনো উপায় নেই। তাই এখানে একমাত্র বিকল্প হলো trust করা।

Logging সবচেয়ে কম পরিশ্রমের পথও বটে, কারণ shipped default আপনার query-কে URL-এ রাখে:

server:
  method: "GET"

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

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-এর কিছু অসুবিধা আছে, যা “end user-এর ব্যবহারের সহজতা গুরুতরভাবে সীমিত করে”; প্রধান সমস্যা browser-এর back button নিয়ে। এটি একটি সচেতন trade-off।

যেকোনো public instance-এর ক্ষেত্রে এর দুটি ফল রয়েছে। Operator query সংগ্রহ করার ইচ্ছা না রাখলেও সেগুলো পড়তে পারেন। Backup বা breach হলেও একই log-এ পৌঁছানো যায়।

নিজের VPS-এ চালালে search engine আপনার বদলে সার্ভারটি দেখতে পায়

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

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

আপনার 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 ব্যবহার করলেও এটি বন্ধ হয় না, কারণ running system-এর কাছে key থাকে।
• Instance-এ root access থাকা যে কেউ সবকিছু দেখতে পায়। এর মধ্যে আপনি আছেন, এবং পরে যে কেউ access পেলে সেও আছে।

আরেকজনকে অনেকে ভুলে যান। আপনার 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, এবং ডিফল্টভাবে এটি বন্ধ থাকে:

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

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

Limiter বেশ কয়েকটি probe চালায়। http_user_agent unset User-Agent, অথবা curl ও wget-এর মতো পরিচিত tool-এর সঙ্গে মেলা User-Agent-কে bot হিসেবে গণ্য করে। http_accept এমন request-কে bot হিসেবে গণ্য করে যার Accept header-এ text/html নেই। কোনো বাস্তব 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 থেকে scripts এবং AI agents 429 পায়। নিজের instance-এ কোনো agent-এর search skill নির্দেশ করার আগে এটিই ঠিক করতে হবে। কারণ ও setting-এর সম্পূর্ণ তালিকা SearXNG rate limits এবং 429 errors-এর guide-এ আছে।

একটি limiter-সংক্রান্ত সমস্যার নাম আলাদা করে বলা দরকার। Reverse proxy-এর পেছনে থাকলে, সেই proxy trusted না হলে SearXNG visitor-এর বদলে 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 = []

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

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

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

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

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

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

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

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

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

ফল পড়ার সময় আপনার instance কতটা তথ্য প্রকাশ করবে, তা দুটি setting নির্ধারণ করে। image_proxy ডিফল্টভাবে false থাকে। তাই thumbnail সরাসরি সেগুলো host করা site থেকে load হয়, এবং সেই site-গুলো আপনার browser-এর address দেখতে পায়। image_proxy: true সেট করলে thumbnail instance-এর মাধ্যমে route হয়। এতে 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 enable করলে আপনি একটি বিনামূল্যের scraping API প্রকাশ করেন। আপনার নির্ভর করা engine-গুলো যাতে আপনার server-এর address block করে, তার দ্রুততম উপায় এটি। এটি off রাখুন, অথবা authentication-এর পেছনে রাখুন।

SearXNG-এর privacy সুরক্ষার সীমা

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

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

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

FAQ

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

Search engine-এর দিক থেকে এটি নিরাপদ, কিন্তু operator-এর দিক থেকে নিরাপদ নয়। আপনার query plain text হিসেবে সেই server-এ পৌঁছায়। Project-এর documentation-এ বলা হয়েছে, ব্যবহারকারীদের “এই instance-এর administrator-কে বিশ্বাস করতেই হবে” এবং “তাদের request log, aggregate করে কোনো third party-কে পাঠানো বা বিক্রি করা হচ্ছে কি না, তা জানা সম্ভব নয়”। method: "GET"-এর shipped default চালু থাকলে query-টি request line-এর অংশ হিসেবে reverse proxy-এর access log-এও লেখা হয়, operator তা চাইলেও বা না চাইলেও। Ad profiling নিয়ে উদ্বেগ থাকলে সাধারণ search-এর জন্য public instance ব্যবহার করুন। এমন কোনো তথ্য সেখানে লিখবেন না, যা আপনি instance-এর owner-কে দিতে চাইবেন না।

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

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

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 যে /client<token>.css URL load করে, তা কখনও fetch করে না। /etc/searxng/limiter.toml-এর trusted_proxies-এ reverse proxy অনুপস্থিত থাকলে প্রত্যেক visitor-কে একই client হিসেবে গণনা করা হয়। ফলে একজন ব্যস্ত user অন্য সবাইকে block করে। কোনো upstream engine আপনার server-কে block করলে পরিস্থিতি আলাদা। সেই engine-এর result page থেকে নিঃশব্দে বাদ যায়, কিন্তু আপনি কোনো 429 পান না।

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

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