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

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

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

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

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

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

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

डिफ़ॉल्ट रूप से दो 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 जिस चीज़ को नहीं बदलता, वह है स्वयं क्वेरी। यह इंस्टेंस तक पूरी तरह से और पठनीय (readable) रूप में पहुँचती है, क्योंकि TLS (transport layer security) वहीं समाप्त (terminate) हो जाती है। नीचे दिए गए सभी बिंदु इसी एक तथ्य पर आधारित हैं।

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

प्रोजेक्ट का अपना डॉक्यूमेंटेशन इसे स्पष्ट रूप से कहता है: पब्लिक इंस्टेंस के उपयोगकर्ताओं को "उस इंस्टेंस के एडमिनिस्ट्रेटर पर भरोसा करना पड़ता है", और वे यह नहीं जान सकते कि "क्या उनकी रिक्वेस्ट लॉग की जाती हैं, एग्रीगेट की जाती हैं, और किसी तीसरे पक्ष को भेजी या बेची जाती हैं"। लैंडिंग पेज पर 'नो-लॉग्स' का दावा केवल एक दावा है। बाहर से इसे जांचने का कोई तरीका नहीं है, इसलिए यह पूरी तरह भरोसे पर निर्भर है।

लॉगिंग सबसे आसान रास्ता भी है, क्योंकि डिफ़ॉल्ट रूप से आपकी क्वेरी 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 प्राप्त होता है। यह उस search को आपके logged-in account, आपके फोन, या आपके household connection से जुड़े advertising profile से नहीं जोड़ सकता है। इसका निर्माण VPS पर अपना SearXNG instance चलाने की गाइड में कवर किया गया है।

इस बारे में स्पष्ट रहें कि क्या नहीं बदला है। सर्च इंजन अभी भी query text, समय, भाषा, वह क्षेत्र जिसके लिए आपने पूछा है, और महीनों तक आपके द्वारा खोजी गई हर चीज़ का स्वरूप देखते हैं, जो सभी एक स्थिर पते के अंतर्गत समूहित होते हैं। यदि आप एकमात्र उपयोगकर्ता हैं, तो वह पता बिना किसी नाम के प्रति-व्यक्ति स्ट्रीम है। इस समूहीकरण को तोड़ने के लिए 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 इसे नहीं रोकता है, क्योंकि running system के पास key होती है।
• instance पर root access रखने वाला कोई भी व्यक्ति सब कुछ देख सकता है। इसमें आप शामिल हैं, और इसमें वह भी शामिल है जो बाद में access प्राप्त करता है।

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

Limiter कई probes चलाता है। http_user_agent एक unset User-Agent, या curl और wget जैसे ज्ञात tools से मेल खाने वाले User-Agent को bot मानता है। http_accept उस request को bot मानता है जिसके Accept header में text/html शामिल नहीं होता है। link_token एक client को तब संदिग्ध चिह्नित करता है जब वह कभी भी /client<token>.css URL को fetch नहीं करता है जिसे एक वास्तविक browser load करता है। जब कोई probe सक्रिय होता है, तो SearXNG 429 लौटाता है और अपने botdetection logger में एक 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 एक साथ मेल खाते हैं। यही कारण है कि scripts और AI agents को उस instance से 429 मिलता है जो browser में ठीक काम करता है, और किसी agent की search skill को अपने instance की ओर मोड़ने से पहले इसे ठीक करना आवश्यक है। कारणों और सेटिंग्स का पूरा विवरण SearXNG rate limits और 429 errors के लिए गाइड में मौजूद है।

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

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

डिफ़ॉल्ट सूची उसी host पर स्थित proxy को कवर करती है। एक अलग Docker network में स्थित proxy 172.18.0.5 जैसे address से आता है, जो सूची में नहीं है, इसलिए प्रत्येक visitor को एक ही client के रूप में गिना जाता है और पहला व्यस्त user बाकी सभी को lock out कर देता है। उस subnet को trusted_proxies में जोड़ें।

दूसरे प्रकार का block upstream होता है। एक engine यह तय करता है कि बहुत सारी searches करने वाला datacenter address एक scraper है और वह आपके सर्वर को उत्तर देना बंद कर देता है। इसके लिए आपको 429 नहीं मिलता है। आपको एक results page मिलता है जिसमें उस engine के परिणाम गायब होते हैं और उसके विरुद्ध विफलता दर्ज होती है, और बार-बार विफलता के बाद SearXNG उस engine को कुछ समय के लिए निलंबित कर देगा। इसका कारण वह address है जिस पर आपका VPS स्थित है, इसलिए इसके समाधान limiter में कुछ बदलने के बजाय engine का चयन करना और धैर्य रखना है।

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

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

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

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

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

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

जो बदलता है, वह है आप पर लागू होने वाली प्रोसेसिंग। कोई भी आपकी क्वेरी से विज्ञापन प्रोफाइल नहीं बनाता है, और कोई भी आपके पिछले सप्ताह के क्लिक के आधार पर परिणामों को फिर से व्यवस्थित नहीं करता है। यह दोनों तरफ काम करता है, क्योंकि पर्सनलाइजेशन में स्थानीय जानकारी (local intent) भी शामिल होती है। "pharmacy open now" जैसी सर्च SearXNG के माध्यम से कमजोर परिणाम देती है, क्योंकि इंजन के पास आपके सर्वर के लिए डेटासेंटर के अलावा कोई लोकेशन सिग्नल नहीं होता है। जब स्थानीय परिणाम महत्वपूर्ण हों, तो प्रेफरेंस में क्षेत्र (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 प्रकाशित कर दी है, जो आपके सर्वर के पते को उन इंजनों द्वारा ब्लॉक करवाने का सबसे तेज़ तरीका है जिन पर आप निर्भर हैं। इसे बंद रखें, या इसे ऑथेंटिकेशन के पीछे रखें।

जहाँ 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-driven reordering हट जाती है और local intent भी हट जाता है, इसलिए location-sensitive searches के परिणाम तब तक कमजोर रहते हैं जब तक आप preferences में अपना region set नहीं करते।