क्या SearXNG सुरक्षित है? इसकी गोपनीयता की सच्चाई

क्या SearXNG सुरक्षित है? संक्षिप्त उत्तर

SearXNG एक दिशा में सुरक्षित है और दूसरी दिशा में असुरक्षित, इसलिए "क्या SearXNG सुरक्षित है" का उत्तर तभी दिया जा सकता है जब आप यह स्पष्ट करें कि आप किससे छिप रहे हैं। SearXNG एक मेटासर्च इंजन है: यह आपकी क्वेरी लेता है, उसे Google, Bing, DuckDuckGo और आपके द्वारा सक्षम किए गए अन्य इंजनों पर भेजता है, और फिर जो परिणाम वापस आते हैं उन्हें एक पेज पर मिला देता है। सर्च इंजन उस instance को देखते हैं। instance आपको देखता है।

किसी अजनबी द्वारा चलाए जा रहे public instance पर, वह अजनबी आपके द्वारा टाइप की गई हर क्वेरी को plain text में प्राप्त करता है, और उनके about पेज पर लिखी कोई भी बात यह साबित नहीं कर सकती कि वे इसका क्या करते हैं। अपने स्वयं के सर्वर पर, upstream इंजन आपके घर के पते के बजाय आपके सर्वर का पता देखते हैं। यह अदला-बदली ही गोपनीयता की पूरी कहानी है, और इसका मूल्य उतना ही है जितना उस सर्वर का जिस पर यह चलता है।

इसका कोई भी हिस्सा आपकी खोज को आपके अपने नेटवर्क से नहीं छिपाता है। आपका internet service provider (ISP) अभी भी instance से कनेक्शन देखता है। आपका DNS (domain name system) resolver अभी भी hostname को देखता है। बाकी लेख पढ़ते समय इस सीमा को ध्यान में रखें।

SearXNG सर्च रिक्वेस्ट में क्या बदलाव करता है

सीधे Google पर सर्च करने पर Google को आपका IP address, cookies, User-Agent header और वह पेज मिलता है जहाँ से आप आए हैं। यह सब एक ऐसी प्रोफाइल से जुड़ा होता है जो आपके सेशन के खत्म होने के बाद भी बनी रहती है। SearXNG बीच में एक मध्यस्थ के रूप में कार्य करता है। इसका documentation उन दो कार्यों का वर्णन करता है जो यह करता है: "सर्च सर्विसेज को जाने वाली रिक्वेस्ट से निजी डेटा हटाना" और "हर रिक्वेस्ट के लिए एक रैंडम ब्राउज़र प्रोफाइल बनाना"। आपकी cookies कभी भी किसी सर्च इंजन को फॉरवर्ड नहीं की जाती हैं। आपकी प्राथमिकताएं सर्वर पर किसी अकाउंट के बजाय आपके अपने ब्राउज़र में स्टोर होती हैं।

डिफ़ॉल्ट रूप से दो response headers भेजे जाते हैं, और दोनों ही महत्वपूर्ण कार्य करते हैं:

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

Referrer-Policy: no-referrer का अर्थ है कि जब आप किसी परिणाम पर क्लिक करते हैं, तो डेस्टिनेशन साइट को कभी पता नहीं चलता कि किस सर्च पेज ने आपको भेजा है, क्योंकि ब्राउज़र Referer हेडर को हटा देता है। X-Robots-Tag: noindex, nofollow आपके इंस्टेंस और उसके रिजल्ट पेजों को सर्च इंडेक्स से बाहर रखता है।

SearXNG जो नहीं बदलता, वह है स्वयं query। यह इंस्टेंस तक पूरी तरह और पठनीय रूप में पहुँचती है, क्योंकि TLS (transport layer security) वहीं terminate होता है। नीचे दिए गए सभी बिंदु इसी एक तथ्य पर आधारित हैं।

पब्लिक इंस्टेंस पर, ऑपरेटर हर क्वेरी देख सकता है

प्रोजेक्ट के अपने documentation में यह बात स्पष्ट रूप से कही गई है: public instance के users को "उस instance के administrator पर भरोसा करना होगा", और वे यह नहीं जान सकते कि "उनके requests को log, aggregate करके किसी third party को भेजा या बेचा जाता है या नहीं"। Landing page पर no-logs का दावा केवल एक दावा है। बाहर से इसे test करने का कोई तरीका नहीं है, इसलिए विकल्प भरोसा करना या कुछ भी न करना है। कुछ public instances अभी भी इस fork के बजाय original Searx चला रहे हैं। यह महत्वपूर्ण है, क्योंकि Searx ने 2023 के बाद कोई code commit नहीं किया है और unmaintained search software ऐसी एक और चीज है, जिस पर आपको बिना सत्यापन के भरोसा करना होगा।

लॉगिंग सबसे आसान रास्ता भी है, क्योंकि डिफ़ॉल्ट रूप से आपकी क्वेरी URL में ही रहती है:

server:
  method: "GET"

GET के साथ, क्वेरी रिक्वेस्ट लाइन में ?q=... के रूप में जाती है। कोई भी सामान्य reverse proxy उस रिक्वेस्ट लाइन को अपने access log में लिख लेता है, इसलिए क्वेरीज़ बिना किसी के रिकॉर्ड करने का निर्णय लिए ही रिकॉर्ड हो जाती हैं:

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)"

अपने खुद के इंस्टेंस पर, स्वयं देखें:

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

आपकी सर्च इसमें इसलिए हैं क्योंकि nginx का combined लॉग फॉर्मेट $request लिखता है, जो कि क्वेरी स्ट्रिंग सहित पूरी रिक्वेस्ट लाइन है। SearXNG का इसमें कोई नियंत्रण नहीं होता। इंस्टेंस को method: "POST" पर स्विच करने से क्वेरी रिक्वेस्ट बॉडी में चली जाती है, जिससे यह access log और ब्राउज़र हिस्ट्री में दिखना बंद हो जाती है। डॉक्यूमेंटेशन ईमानदारी से बताता है कि POST के नुकसान हैं जो "अंतिम उपयोगकर्ता के लिए उपयोग में आसानी को गंभीर रूप से प्रतिबंधित करते हैं", मुख्य रूप से ब्राउज़र के बैक बटन से संबंधित। यह एक ऐसा समझौता है जिसे आप जानबूझकर करते हैं।

किसी भी पब्लिक इंस्टेंस के लिए दो परिणाम निकलते हैं। ऑपरेटर आपकी क्वेरीज़ पढ़ सकता है, चाहे उसने उन्हें कलेक्ट करने का इरादा किया हो या नहीं। बैकअप या किसी सेंधमारी (break-in) की स्थिति में भी वही लॉग हाथ लगते हैं।

अपने VPS पर, सर्च इंजन आपको नहीं बल्कि आपके सर्वर को देखते हैं

अपने VPS (virtual private server) पर अपना instance चलाएं और बदलाव को समझना आसान है। Google को अब आपकी query के साथ आपका home IP address प्राप्त नहीं होता है। इसे आपकी query के साथ आपके सर्वर का IP address प्राप्त होता है। यह उस खोज को आपके logged-in account, आपके phone, या आपके household connection से जुड़े advertising profile से नहीं जोड़ सकता है। इस build की प्रक्रिया VPS पर अपना SearXNG instance चलाने की गाइड में दी गई है।

इस बात को स्पष्ट समझें कि क्या नहीं बदला है। सर्च इंजन अभी भी query text, समय, भाषा, आपके द्वारा मांगी गई region और महीनों तक आपके द्वारा खोजी गई हर चीज़ का पैटर्न देखते हैं, जो सभी एक स्थिर address के अंतर्गत grouped होते हैं। यदि आप एकमात्र उपयोगकर्ता हैं, तो वह address बिना किसी नाम के प्रति-व्यक्ति stream है। इस grouping को तोड़ने के लिए instance को outbound proxy या Tor के माध्यम से सर्च इंजन तक पहुंचना आवश्यक है, जिसे SearXNG सपोर्ट करता है और यह एक अलग कार्य है।

आपके ISP, आपके resolver और आपके host को अभी भी क्या दिखता है

चार पर्यवेक्षक इनमें से किसी से भी प्रभावित नहीं होते हैं।

• आपका ISP आपके instance के IP address के लिए एक TLS connection देखता है, और यह SNI (server name indication) field में hostname को देखता है, जिसे handshake के दौरान cleartext में भेजा जाता है। यह 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 रखने वाला कोई भी व्यक्ति सब कुछ देख सकता है। इसमें आप शामिल हैं, और इसमें वह भी शामिल है जो बाद में access प्राप्त करता है।

instance तक Tor onion service के रूप में पहुँचने से पहले दो बिंदु समाप्त हो जाते हैं, क्योंकि resolve करने के लिए कोई public hostname नहीं होता और पढ़ने के लिए कोई SNI field नहीं होती, और VPS में v3 onion service जोड़ने का walkthrough उस setup को उन leaks के साथ कवर करता है जो अन्यथा उस address को आपके server के public IP से जोड़ देते।

एक और बात है जिसे लोग भूल जाते हैं। आपके server के outbound requests server के अपने network से दिखाई देते हैं, इसलिए आपका provider देख सकता है कि आपकी machine दिन भर Google और Bing से बात करती है। यह एक query के बजाय traffic pattern है, और यह अभी भी कुछ कहता है।

यहीं पर VPN का प्रश्न आता है। एक VPN (virtual private network) आपके ISP के दृष्टिकोण को VPN कंपनी के दृष्टिकोण में बदल देता है। यह instance operator के बारे में कुछ नहीं बदलता और engines के बारे में भी कुछ नहीं बदलता, क्योंकि engines आपसे नहीं बल्कि आपके server से बात कर रहे होते हैं। इन दोनों की तुलना VPS बनाम VPN के विश्लेषण में उचित रूप से की गई है।

SearXNG आपको ब्लॉक क्यों करता है, और 429 का वास्तविक अर्थ क्या है

"SearXNG ने मुझे ब्लॉक कर दिया" कहने के पीछे दो अलग-अलग स्थितियाँ हो सकती हैं, और दोनों के समाधान अलग हैं।

पहली स्थिति वह है जब आपका अपना limiter आपको HTTP 429 के साथ जवाब देता है। यह SearXNG का bot protection है, और यह डिफ़ॉल्ट रूप से बंद रहता है:

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

अगस्त 2026 तक, limiter को एक Valkey डेटाबेस की आवश्यकता होती है और यह अपने नियम /etc/searxng/limiter.toml से पढ़ता है। यदि अनजान लोग वास्तव में आपके सर्वर का उपयोग करते हैं, तो server.public_instance: true को भी सेट करें, क्योंकि यह डिफ़ॉल्ट रूप से false पर होता है और सार्वजनिक उपयोग के लिए निर्धारित व्यवहार को नियंत्रित करता है।

Limiter कई probes चलाता है। http_user_agent एक unset User-Agent, या curl और wget जैसे ज्ञात टूल्स से मेल खाने वाले User-Agent को bot मानता है। http_accept उस अनुरोध को bot मानता है जिसके Accept हेडर में text/html शामिल नहीं होता है। link_token उस क्लाइंट को संदिग्ध मानता है जो कभी भी वह /client<token>.css URL नहीं खोलता जिसे एक वास्तविक ब्राउज़र लोड करता है। जब कोई probe सक्रिय होता है, तो SearXNG 429 लौटाता है और अपने botdetection लॉगर में एक ERROR लाइन लिखता है।

इसलिए यह विफल हो जाता है, और ऐसा होना ही चाहिए:

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

curl User-Agent: curl/8.5.0 और Accept: */* भेजता है, इसलिए दो probes एक साथ मेल खाते हैं। यही कारण है कि स्क्रिप्ट्स और AI एजेंट्स को उस इंस्टेंस से 429 मिलता है जो ब्राउज़र में ठीक काम करता है, और किसी एजेंट की सर्च स्किल को अपने इंस्टेंस की ओर मोड़ने से पहले इसे ठीक करना आवश्यक है। कारणों और सेटिंग्स का पूरा विवरण SearXNG रेट लिमिट्स और 429 एरर्स की गाइड में उपलब्ध है।

Limiter की एक खामी का उल्लेख करना आवश्यक है। Reverse proxy के पीछे, SearXNG को आगंतुक (visitor) के बजाय प्रॉक्सी का पता दिखाई देता है, जब तक कि उस प्रॉक्सी को trusted न माना जाए:

[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 = []

डिफ़ॉल्ट सूची उसी होस्ट पर मौजूद प्रॉक्सी को कवर करती है। एक अलग Docker नेटवर्क में मौजूद प्रॉक्सी 172.18.0.5 जैसे पते से आता है, जो सूची में नहीं है, इसलिए हर आगंतुक को एक ही क्लाइंट के रूप में गिना जाता है और पहला व्यस्त उपयोगकर्ता बाकी सभी को लॉक कर देता है। उस सबनेट को trusted_proxies में जोड़ें।

दूसरे प्रकार का ब्लॉक upstream होता है। एक सर्च इंजन यह तय करता है कि बहुत सारी सर्च करने वाला डेटासेंटर एड्रेस एक स्क्रैपर है और वह आपके सर्वर को जवाब देना बंद कर देता है। इसके लिए आपको 429 नहीं मिलता है। आपको एक परिणाम पृष्ठ मिलता है जिसमें उस इंजन के परिणाम गायब होते हैं और उसके खिलाफ विफलता दर्ज होती है, और बार-बार विफलता के बाद SearXNG उस इंजन को कुछ समय के लिए निलंबित कर देगा। इसका कारण वह पता है जिस पर आपका VPS स्थित है, इसलिए इसके समाधान इंजन का चयन और धैर्य रखना है, न कि limiter में कुछ बदलना।

क्या अजनबियों के साथ instance साझा करना फायदेमंद है या नुकसानदेह?

यह दोनों है, विपरीत दिशाओं में, इसीलिए इसका उत्तर अस्पष्ट लगता है। गुमनामी एक भीड़ का प्रभाव है। एक व्यस्त public instance पर आपकी query हजारों अन्य लोगों की queries के समान पते से निकलती है, इसलिए कोई भी engine आपकी query को उस ढेर से अलग नहीं कर सकता। आपके single-user instance पर उस पते से आने वाली हर query आपकी होती है, और engines को बिना किसी नाम के एक साफ-सुथरा, एक व्यक्ति का stream प्राप्त होता है।

operator का पक्ष दूसरी दिशा में काम करता है। एक बड़ी भीड़ का मतलब है कि कोई अजनबी उस भीड़ की plain text queries को देख सकता है, जिसमें आपकी queries भी शामिल हैं। आपके अपने box का मतलब है कि आप अपनी queries को नियंत्रित करते हैं और किसी और की नहीं।

इसलिए उस खतरे के आधार पर चुनाव करें जो वास्तव में आपके सामने है। क्या आप ad profiling और cross-site tracking को लेकर चिंतित हैं? भीड़ इसे अच्छी तरह संभाल लेती है और operator का जोखिम कम होता है। क्या आप इस बात से चिंतित हैं कि कोई विशिष्ट व्यक्ति या कंपनी आपके द्वारा की गई किसी विशिष्ट search को पढ़ सकती है? भीड़ इसमें बिल्कुल भी मदद नहीं करती, क्योंकि operator raw text देख सकता है। एक अच्छा मध्यम मार्ग उन लोगों के लिए एक instance बनाना है जिन्हें आप जानते हैं। आपको एक छोटी भीड़ मिलती है और एक ऐसा operator जिसे आप verify कर सकते हैं, क्योंकि वह operator आप स्वयं हैं।

क्या SearXNG के परिणाम Google से बेहतर हैं?

नहीं। SearXNG का अपना कोई इंडेक्स नहीं है, इसलिए पेज पर दिखने वाला हर परिणाम किसी अपस्ट्रीम इंजन से आता है, और परिणामों की गुणवत्ता की सीमा उन इंजनों पर निर्भर करती है जिन्हें आपने सक्षम (enable) किया है। यदि आप Google और Bing को अक्षम (disable) करते हैं, तो गुणवत्ता उसी दिन गिर जाएगी, क्योंकि सामान्य वेब कवरेज का अधिकांश हिस्सा उन्हीं से आता है।

जो बदलता है वह है आप पर लागू होने वाली प्रोसेसिंग। आपकी क्वेरी से कोई भी विज्ञापन प्रोफ़ाइल नहीं बनाई जाती है, और पिछले सप्ताह आपने किस पर क्लिक किया था, इसके आधार पर परिणामों को फिर से व्यवस्थित नहीं किया जाता है। यह दोनों तरफ काम करता है, क्योंकि वैयक्तिकरण (personalization) में स्थानीय संदर्भ (local intent) भी शामिल होता है। "pharmacy open now" जैसी खोज SearXNG के माध्यम से कमजोर परिणाम देती है, क्योंकि इंजन के पास आपके सर्वर के लिए उस डेटासेंटर के अलावा कोई स्थान संकेत (location signal) नहीं होता है जहाँ वह स्थित है। जब स्थानीय परिणाम महत्वपूर्ण हों, तो प्राथमिकताओं (preferences) में क्षेत्र (region) सेट करें।

दो सेटिंग्स यह तय करती हैं कि उन परिणामों को पढ़ते समय आपका इंस्टेंस कितना डेटा लीक करता है। image_proxy डिफ़ॉल्ट रूप से false होता है, इसलिए थंबनेल सीधे उन साइटों से लोड होते हैं जो उन्हें होस्ट करती हैं और वे साइटें आपके ब्राउज़र का पता देख लेती हैं। image_proxy: true सेटिंग उन्हें इंस्टेंस के माध्यम से रूट करती है, जिससे बैंडविड्थ और मेमोरी की खपत बढ़ती है। और formats केवल html के रूप में आता है, इसलिए JSON (JavaScript object notation) अनुरोध को 403 Forbidden के साथ अस्वीकार कर दिया जाता है:

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

सार्वजनिक इंस्टेंस पर json को सक्षम करें और आपने एक मुफ्त स्क्रैपिंग API प्रकाशित कर दिया है, जो आपके सर्वर के पते को उन इंजनों द्वारा ब्लॉक करवाने का सबसे तेज़ तरीका है जिन पर आप निर्भर हैं। इसे बंद रखें, या इसे प्रमाणीकरण (authentication) के पीछे रखें।

जहाँ SearXNG की गोपनीयता की कहानी समाप्त होती है

SearXNG सर्च इंजनों से यह छिपाता है कि कौन खोज कर रहा है। यह आपके नेटवर्क से यह नहीं छिपाता कि आप क्या कर रहे हैं। इसके परिणामस्वरूप चार सीमाएँ सामने आती हैं।

• सर्च बॉक्स को छोड़कर हर जगह आपका ट्रैफिक अपरिवर्तित रहता है। मशीन जो कुछ भी करती है, वह आपके नेटवर्क से बिल्कुल पहले की तरह ही बाहर जाता है।
• एक सर्वर पर एक उपयोगकर्ता हर इंजन के लिए एक स्थिर पहचानकर्ता (identifier) होता है। इस पहचानकर्ता में कोई नाम नहीं होता है, और यही इसका एकमात्र लाभ है।
• किसी भी instance का ऑपरेटर क्वेरी को plain text के रूप में पढ़ता है। स्वयं ऑपरेटर बनना ही इसका एकमात्र संस्करण है जिसे आप सत्यापित कर सकते हैं।
• आपके अपने access logs उस रिकॉर्ड को फिर से बना देते हैं जिसे आप टालने की कोशिश कर रहे थे। उन्हें पढ़ें, और यदि आप चाहते हैं कि वे खाली रहें तो method: "POST" पर स्विच करें।

SearXNG केवल पर्यवेक्षक (observer) को बदलता है। यह अवलोकन को समाप्त नहीं करता है। तय करें कि आप किस पर्यवेक्षक से बचना चाहते हैं, उसके अनुसार instance चुनें, और सर्च फ्रंट एंड को anonymity software न समझें।

FAQ

क्या public instance पर SearXNG का उपयोग करना सुरक्षित है?

यह search engines से तो सुरक्षित है, लेकिन operator से नहीं। आपकी query उस सर्वर तक plain text में पहुँचती है, और project के documentation के अनुसार, users को "उस instance के administrator पर भरोसा करना होगा" और वे यह नहीं जान सकते कि "क्या उनके requests को log किया जा रहा है, इकट्ठा किया जा रहा है, या किसी तीसरे पक्ष को भेजा या बेचा जा रहा है"। method: "GET" की default setting के साथ, query reverse proxy के access log में request line के हिस्से के रूप में दर्ज हो जाती है, चाहे operator ऐसा चाहे या न चाहे। सामान्य खोज के लिए public instance का उपयोग करें जहाँ चिंता ad profiling की हो। ऐसी किसी भी चीज़ को वहां न लिखें जिसे आप उसके मालिक को नहीं सौंपना चाहेंगे।

क्या SearXNG मेरे internet provider से मेरी खोजों को छिपाता है?

Query text छिपी रहती है, लेकिन activity नहीं। आपका provider आपके instance के address से एक TLS connection और handshake के cleartext SNI field में hostname को देख सकता है, और आपका DNS resolver उस hostname के लिए lookup देख सकता है। दोनों में से कोई भी यह नहीं देख सकता कि आपने क्या खोजा है, क्योंकि connection encrypted है। SearXNG एक VPN नहीं है, और यह आपके machine द्वारा की जाने वाली किसी अन्य गतिविधि को सुरक्षा प्रदान नहीं करता है।

SearXNG 429 error क्यों देता है?

429 error instance के अपने limiter से आता है, जो कि Google का संदेश होने के बजाय bot protection है। इसके probes उस request को flag करते हैं जिसके Accept header में text/html की कमी होती है, और जिसका User-Agent unset हो या curl और wget जैसे tools से मेल खाता हो। एक तीसरा probe, link token, उस client को flag करता है जो कभी भी उस /client<token>.css URL को fetch नहीं करता जिसे browser load करता है। यदि reverse proxy /etc/searxng/limiter.toml में trusted_proxies से गायब है, तो हर visitor को एक ही client गिना जाता है, इसलिए एक व्यस्त user बाकी सबको block कर देता है। जब कोई upstream engine आपके सर्वर को block करता है, तो उस engine के results बस page से गायब हो जाते हैं और आपको कोई 429 error नहीं मिलता।

क्या SearXNG को self-host करने से मेरे search results खराब हो जाते हैं?

कभी-कभी, दो कारणों से जिन्हें जानना महत्वपूर्ण है। Results upstream engines से आते हैं, इसलिए datacenter का address जिसे engines throttle करते हैं, उसका मतलब है कि कम engines जवाब दे रहे हैं और page पर जानकारी कम है। साथ ही, personalised ranking हट जाती है, जिससे ad-आधारित reordering खत्म हो जाती है और local intent भी हट जाता है, इसलिए location-sensitive खोजों के परिणाम तब तक कमजोर रहते हैं जब तक आप preferences में अपना region set नहीं करते।