SSD Nodes Learn Hosting plans →
गाइड Matt Connorलेखक: Matt Connor · अपडेट किया गया: 2026-08-21

Nginx में Onion-Location header कैसे जोड़ें

Nginx में Onion-Location header जोड़कर Tor Browser में अपनी साइट को प्रमोट करें। साथ ही, redirects और third-party assets के जरिए होने वाले डेटा लीक्स को रोकने के तरीके जानें।

Onion-Location header क्या करता है

Onion-Location header आपके clearnet vhost में एक लाइन है जो Tor Browser को आपके onion address के बारे में सूचित करती है। जो visitor Tor के माध्यम से https://example.com पर पहुँचता है, उसे address bar में एक purple pill दिखाई देती है जिस पर .onion available लिखा होता है, और एक क्लिक उन्हें आपके onion service पर ले जाता है। यह केवल एक discovery mechanism है और कुछ नहीं। यह header onion service को create नहीं करता है, और यह आपके बारे में कुछ भी छिपाता नहीं है।

यह गाइड मानती है कि दोनों हिस्से पहले से मौजूद हैं। आपके पास nginx के पीछे एक VPS पर एक साइट है, और आपके पास एक working v3 onion service है जो उस पर point कर रही है। यदि आपके पास अभी तक दूसरा हिस्सा नहीं है, तो पहले उसे बनाएँ: VPS पर onion साइट होस्ट करना में torrc लाइन्स और पहली hostname फाइल शामिल है। आगे जो बताया गया है वह इन दोनों को एक-दूसरे में leak किए बिना जोड़ने के बारे में है।

Tor Browser को header स्वीकार करने से पहले किन चीजों की आवश्यकता होती है

Tor Project तीन शर्तों का उल्लेख करता है। इन तीनों का पूरा होना आवश्यक है, अन्यथा pill दिखाई नहीं देगी।

  • Onion-Location मान एक वैध URL होना चाहिए जिसमें http: या https: स्कीम और .onion होस्टनेम हो।
  • header को परिभाषित करने वाला वेबपेज HTTPS के माध्यम से सर्व (serve) किया जाना चाहिए।
  • header को परिभाषित करने वाला वेबपेज स्वयं एक onion साइट नहीं होना चाहिए।

दूसरी शर्त वह है जहाँ अक्सर लोग गलती करते हैं, और तीसरी शर्त यह बताती है कि आप onion vhost पर यह header क्यों सेट नहीं करते हैं। एक चौथा नियम भी है जो लिखित दस्तावेजों में नहीं है लेकिन implementation में मौजूद है: Tor Browser केवल top-level document के लिए ही header पर कार्रवाई करता है। कोड कुछ भी करने से पहले load target की तुलना document से करता है, इसलिए stylesheet, image या API response पर लौटाया गया header अनदेखा कर दिया जाता है।

डिफ़ॉल्ट रूप से ब्राउज़र pill दिखाता है और क्लिक की प्रतीक्षा करता है। जो पाठक इसे स्वचालित रूप से जंप (jump) करवाना चाहते हैं, वे इसे Settings, फिर Privacy and Security, और उसके बाद Onion Services में जाकर सक्षम कर सकते हैं, जहाँ "Prioritize .onion sites when known" को "Always" पर सेट किया जा सकता है। आप इसे सर्वर साइड से बाध्य (force) नहीं कर सकते। header को एक प्रस्ताव मानें, न कि रीडायरेक्ट।

Nginx में Onion-Location हेडर जोड़ना

यह हेडर उस server ब्लॉक में होना चाहिए जो आपके clearnet डोमेन के लिए TLS termination का कार्य करता है। इसे port 80 वाले ब्लॉक में न रखें, क्योंकि वहां ऐसा करने से कुछ नहीं होगा; वह ब्लॉक केवल एक रीडायरेक्ट जारी करता है और आवश्यकता दो के अनुसार plain HTTP पेज पर परिभाषित हेडर मान्य नहीं होता।

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    add_header Onion-Location http://<your-onion-address>.onion$request_uri always;

    root /srv/example.com/public;
}

$request_uri में पाथ और क्वेरी स्ट्रिंग शामिल होती है, इसलिए https://example.com/guides/tor पर मौजूद पाठक को onion साइट पर भी वही पाथ मिलता है। यदि आप इसे हटा देते हैं, तो हर विज़िटर उस पेज के बजाय जिसे वे पढ़ रहे थे, onion होम पेज पर पहुँच जाएगा।

always महत्वपूर्ण है क्योंकि Nginx में इसकी एक निर्धारित सीमा है। add_header केवल तभी फ़ील्ड जोड़ता है जब रिस्पॉन्स कोड 200, 201, 204, 206, 301, 302, 303, 304, 307 या 308 हो। आपका 404 पेज सर्च परिणामों से आने वाला एक वास्तविक एंट्री पॉइंट है, और always के बिना इसमें कोई हेडर नहीं होगा।

Nginx में दूसरी समस्या इनहेरिटेंस (inheritance) की है, जो चुपचाप विफल हो जाती है। add_header डायरेक्टिव्स पिछले कॉन्फ़िगरेशन स्तर से तभी इनहेरिट होते हैं यदि वर्तमान स्तर पर कोई add_header डायरेक्टिव मौजूद न हो। इसलिए, एक location /assets/ { add_header Cache-Control ...; } ब्लॉक अपने अंतर्गत आने वाले हर URL के लिए सर्वर-स्तर के Onion-Location को हटा देता है। यदि आप कहीं भी प्रति-लोकेशन (per-location) हेडर सेट करते हैं, तो उन ब्लॉकों में से प्रत्येक के अंदर Onion-Location लाइन को दोहराएं। यदि यह व्यवहार आपके लिए नया है, तो Nginx सर्वर और लोकेशन ब्लॉक का चयन कैसे करता है को एक बार पढ़ना उपयोगी रहेगा।

कॉन्फ़िगरेशन को रिलोड करें और सामान्य पेज तथा अनुपलब्ध पेज दोनों की जाँच करें:

sudo nginx -t && sudo systemctl reload nginx
curl -sI https://example.com/ | grep -i onion-location
curl -sI https://example.com/no-such-page | grep -i onion-location

दोनों कमांड्स को एक onion-location: लाइन प्रिंट करनी चाहिए। दूसरी कमांड इस बात का प्रमाण है कि always सही ढंग से काम कर रहा है। यदि दूसरी कमांड से कोई आउटपुट नहीं मिलता है, तो इसका मतलब है कि फ्लैग गायब है या कोई location ब्लॉक डायरेक्टिव को ओवरराइड (shadow) कर रहा है।

जब आप headers सेट न कर सकें तो HTML meta tag का उपयोग

Static hosts और कुछ CDN dashboards आपको मनमाना response header जोड़ने की अनुमति नहीं देते हैं। यही मान document head में एक meta element के रूप में काम करता है, क्योंकि browser इसे document header data के माध्यम से पढ़ता है, चाहे वह HTTP के माध्यम से आया हो या http-equiv tag के रूप में।

<meta http-equiv="onion-location" content="http://<your-onion-address>.onion" />

तीनों आवश्यकताएं अभी भी लागू होती हैं। tag ले जाने वाला page HTTPS होना चाहिए और onion नहीं होना चाहिए। अंतर यह है कि tag में बिना path वाला एक निश्चित पता होता है, क्योंकि expand करने के लिए कोई server-side variable नहीं होता है। इसे ले जाने वाला प्रत्येक page onion home page प्रदान करता है। यह fallback की कीमत है, इसलिए जब भी आप server को नियंत्रित करते हैं तो header को प्राथमिकता दें।

Onion को उसके अपने nginx vhost से serve करें

Clearnet साइट और onion को एक ही server block साझा नहीं करना चाहिए। Tor Browser Host: <your-onion-address>.onion भेजता है। यदि कोई server block उस नाम का दावा नहीं करता है, तो nginx default server पर वापस चला जाता है, जो कि आपका clearnet vhost है, और वह vhost जो भी URL generate करता है, उसमें आपके domain का नाम होता है।

Hidden service को ऐसे port पर point करें जिसका उत्तर केवल loopback interface देता है:

HiddenServiceDir /var/lib/tor/onion_site/
HiddenServicePort 80 127.0.0.1:8080

फिर उस port को उसका अपना vhost दें:

server {
    listen 127.0.0.1:8080;
    server_name <your-onion-address>.onion;

    absolute_redirect off;
    port_in_redirect off;

    root /srv/example.com/public;
}

listen 127.0.0.1:8080 इस vhost को आपके public IP से दूर रखता है, ताकि VPS address को scan करने वाला कोई व्यक्ति इसे fetch न कर सके और clearnet copy के साथ byte-by-byte तुलना न कर सके। absolute_redirect off nginx को relative Location values जारी करने के लिए कहता है, ताकि directory पर trailing-slash redirect, full URL के बजाय Location: /guides/ लौटाए। nginx पहले से ही server_name के बजाय Host header से absolute redirects बनाता है, क्योंकि server_name_in_redirect default रूप से off होता है, लेकिन एक relative redirect इस प्रश्न को पूरी तरह से समाप्त कर देता है।

ओनियन पेज अभी भी विजिटर्स को क्लियरनेट साइट पर क्यों भेज रहा है?

nginx शायद ही कभी इसका कारण होता है। आपकी एप्लीकेशन इसका कारण है। जो कुछ भी कॉन्फ़िगर किए गए साइट एड्रेस से एक एब्सोल्यूट URL बनाता है, वह आपके डोमेन का नाम ही देगा, चाहे रिक्वेस्ट किसी भी vhost द्वारा सर्व की गई हो।

  • एक rel="canonical" लिंक टैग जो https://example.com/... की ओर इशारा करता है। यह सबसे सामान्य कारण है, और यह सोर्स देखने वाले किसी भी व्यक्ति को सटीक क्लियरनेट पेज का नाम बता देता है।
  • nginx के बजाय फ्रेमवर्क द्वारा जनरेट किए गए रीडायरेक्ट, जैसे Django का SECURE_SSL_REDIRECT या WordPress के home और siteurl विकल्प।
  • og:url और अन्य सोशल कार्ड मेटा टैग्स।
  • साइटमैप और RSS एंट्रीज, जो स्पेसिफिकेशन के अनुसार एब्सोल्यूट होती हैं।
  • एप्लीकेशन एरर पेज, जिनमें आमतौर पर उसी सेटिंग से बना "होम पेज पर वापस जाएं" लिंक शामिल होता है।

इसका समाधान आपके स्टैक पर निर्भर करता है और कोई एक सामान्य समाधान नहीं है। इसकी जांच करने का तरीका सामान्य है। Tor के माध्यम से ओनियन पेज को फेच करें और रिस्पॉन्स में अपने डोमेन को सर्च करें।

curl -s --socks5-hostname 127.0.0.1:9050 http://<your-onion-address>.onion/ \
  | grep -i 'example\.com'

--socks5-hostname नाम को रिज़ॉल्यूशन के लिए tor के SOCKS पोर्ट पर भेजता है, जो आवश्यक है क्योंकि आपकी मशीन पर कोई भी चीज़ स्थानीय रूप से .onion नाम को रिज़ॉल्व नहीं कर सकती है। पोर्ट 9050 एक पैकेज्ड tor डेमन के लिए डिफ़ॉल्ट है। खाली रिज़ल्ट का मतलब है कि सब ठीक है। कोई भी हिट एक ऐसा पेज है जो हर ओनियन विजिटर को आपका क्लियरनेट डोमेन दे रहा है। इसे होम पेज पर चलाएं, फिर उस URL पर चलाएं जो 404 एरर देता है।

रीडायरेक्ट चेन की अलग से जांच करें, क्योंकि रीडायरेक्ट बॉडी आमतौर पर खाली होती है:

curl -sI --socks5-hostname 127.0.0.1:9050 http://<your-onion-address>.onion/guides \
  | grep -i '^location'

example.com को नाम देने वाला एक Location मान यह दर्शाता है कि एक रीडायरेक्ट आपके ओनियन विजिटर को वापस क्लियरनेट पर धकेल रहा है, एक एग्जिट नोड के माध्यम से, ऐसी रिक्वेस्ट पर जिसे वे मानते थे कि वह Tor के अंदर ही रही।

Onion पर अपना clearnet certificate प्रस्तुत न करें

एक v3 onion address सेवा की अपनी public key से उत्पन्न होता है, इसलिए कोई भी HTTP request भेजे जाने से पहले Tor उस विशिष्ट सेवा के लिए circuit को authenticate और encrypt करता है। Onion service के भीतर plain HTTP सामान्य configuration है, और यह इंटरनेट पर मौजूद plain HTTP के समान नहीं है।

यदि आप clearnet vhost की नकल करके onion vhost बनाते हैं, तो आप उसके साथ ssl_certificate की भी नकल कर लेते हैं। अब onion एक ऐसा certificate प्रस्तुत करता है जिसकी subject alternative names सूची में example.com होता है। यहाँ दो समस्याएँ होती हैं। ब्राउज़र एक name mismatch दिखाता है, क्योंकि URL onion address है और certificate उसे cover नहीं करता है। और जो भी visitor इसे स्वीकार करके आगे बढ़ता है, उसे एक हस्ताक्षरित बयान मिलता है कि ये दोनों साइटें एक ही मशीन हैं। Onion vhost को अपनी अलग file में अपने स्वयं के server_name के साथ रखें, जो इसे Certbot nginx plugin से भी दूर रखता है, क्योंकि वह plugin उस server block को edit करता है जो आपके द्वारा certificate के लिए अनुरोध किए गए domain से मेल खाता है।

कौन सा tor पैकेज चुनें, और सर्विस की (service key) को सुरक्षित रखना

Ubuntu आर्काइव में मौजूद tor पैकेज इसके लिए काम करता है और इसमें किसी अतिरिक्त सेटअप की आवश्यकता नहीं होती। यह वर्तमान स्टेबल सीरीज से थोड़ा पीछे रहता है, इसलिए यदि आप ऐसी सर्विस चलाना चाहते हैं जो लंबे समय तक चलती रहे, तो Tor Project के अपने Debian रिपॉजिटरी का उपयोग करें और apt को इसे बाकी सभी चीजों के साथ अपग्रेड करने दें। अगस्त 2026 तक, दस्तावेजीकृत चरण इस प्रकार हैं:

sudo apt install apt-transport-https
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

/etc/apt/sources.list.d/tor.sources लिखें, और suite को lsb_release -c से अपने रिलीज़ कोडनेम के साथ बदलें:

Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: noble
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
sudo apt update
sudo apt install tor deb.torproject.org-keyring

deb.torproject.org-keyring पैकेज साइनिंग की (signing key) को अपडेट रखता है, ताकि रिपॉजिटरी एक साल बाद वेरिफिकेशन करना बंद न करे। एक ही सोर्स चुनें और उसी पर बने रहें। आर्काइव पैकेज और रिपॉजिटरी पैकेज के वर्ज़न अलग-अलग होते हैं, और यदि दोनों इनेबल्ड हैं, तो अपग्रेड के दौरान apt आपको एक से दूसरे पर ले जा सकता है।

HiddenServiceDir आपकी सर्विस की पहचान (identity) को सुरक्षित रखता है। उस डायरेक्टरी में मौजूद hs_ed25519_secret_key फाइल ही आपका onion एड्रेस है, क्योंकि यह एड्रेस उस की-पेयर (key pair) का पब्लिक हिस्सा होता है। यदि यह फाइल खो गई, तो एड्रेस हमेशा के लिए खत्म हो जाएगा, क्योंकि इसे दोबारा जारी करने वाली कोई अथॉरिटी नहीं है। यदि आप इस फाइल को कहीं असुरक्षित जगह कॉपी करते हैं, तो जिसके पास भी वह कॉपी होगी, वह आपकी onion सर्विस चला सकता है।

tor ऐसी किसी भी डायरेक्टरी का उपयोग करने से मना कर देता है जिसे अन्य यूज़र्स पढ़ सकते हैं। किसी और चीज की जांच करने से पहले मोड और ओनर की जांच करें:

sudo ls -ld /var/lib/tor/onion_site
sudo -u debian-tor cat /var/lib/tor/onion_site/hostname

लिस्टिंग में drwx------ दिखना चाहिए, जिसका ओनर और ग्रुप Debian और Ubuntu पर debian-tor होना चाहिए। यदि परमिशन इससे अधिक खुली हैं, तो tor Permissions on directory /var/lib/tor/onion_site/ are too permissive. जैसा लॉग दर्ज करेगा और सर्विस स्टार्ट नहीं होगी। इसे sudo chown -R debian-tor:debian-tor /var/lib/tor/onion_site के बाद sudo chmod 700 /var/lib/tor/onion_site चलाकर ठीक करें, sudo systemctl restart tor के साथ रीस्टार्ट करें, और sudo journalctl -u tor@default -n 30 के साथ परिणाम पढ़ें।

इस डायरेक्टरी का बैकअप उसी तरह लें जैसे आप किसी प्राइवेट की (private key) का बैकअप लेते हैं: सर्वर से बाहर और एन्क्रिप्टेड। इसे कभी भी उस रिपॉजिटरी में कमिट न करें जिसमें आपकी साइट का कोड है। यदि उसी सर्वर पर Tor के माध्यम से एडमिनिस्ट्रेटिव एक्सेस की भी आवश्यकता है, तो onion सर्विस के जरिए SSH तक पहुंचना पब्लिक साइट पर मैनेजमेंट पाथ खोलने की तुलना में अधिक सुरक्षित और अलग तरीका है।

Analytics और third-party assets हेडर से कहीं अधिक जानकारी लीक करते हैं

यह सबसे महत्वपूर्ण हिस्सा है, और इसका Onion-Location से कोई लेना-देना नहीं है। आपका पेज जिन भी third-party assets को reference करता है, वे सभी ऐसी requests हैं जिन्हें visitor का browser onion से बाहर निकालता है और exit node के माध्यम से clearnet पर भेजता है। public CDN से कोई font, कोई hosted analytics script, embedded video player, या comment widget: इनमें से प्रत्येक third party को यह बताता है कि कोई व्यक्ति आपका पेज लोड कर रहा है, और वह भी उस session पर जिसे पाठक ने जानबूझकर Tor के माध्यम से route किया है।

इसके दो परिणाम होते हैं। third party को visit के बारे में पता चल जाता है। और चूंकि आपकी clearnet copy भी उन्हीं providers से वही assets लोड करती है, इसलिए किसी भी पक्ष पर नजर रखने वाला व्यक्ति बिना किसी प्रयास के दोनों properties को आपस में जोड़ सकता है।

सब कुछ एक ही origin से serve करें। अपने fonts को self-host करें। hosted analytics tag को हटा दें, या उसे अपने सर्वर पर ले आएं, जहाँ self-hosted analytics on a VPS request को onion के भीतर ही रखता है। यह मानकर चलें कि Tor Browser की default settings किसी भी analytics tool द्वारा collect किए जाने वाले अधिकांश डेटा को block या flatten कर देंगी, जो कि सही परिणाम है। यदि कोई पेज किसी third-party script के बिना काम नहीं कर सकता है, तो उस पेज को onion पर publish न करें।

एक पेज वास्तव में क्या pull करता है, इसकी सूची बनाएं:

curl -s --socks5-hostname 127.0.0.1:9050 http://<your-onion-address>.onion/ \
  | grep -oE '(src|href)="https?://[^"]+"' | sort -u

यह जो भी लाइन print करता है, वह एक absolute URL है जिसे आपका पेज browser से fetch करने के लिए कहता है। जो कुछ भी आपका अपना onion address नहीं है, वह एक outbound clearnet request है जिसे आप अपने पाठकों से अपनी ओर से करने के लिए कह रहे हैं।

खतरे का मॉडल, स्पष्ट शब्दों में

Onion-Location एक onion service को ढूंढना आसान बनाता है, और यह केवल इतना ही करता है। यह एक ऑपरेटर के रूप में आपको गुमनाम नहीं बनाता है, क्योंकि आपके clearnet domain में अभी भी registrar रिकॉर्ड, DNS रिकॉर्ड, Certificate Transparency लॉग में प्रकाशित एक सर्टिफिकेट, और आपके बिलिंग विवरण के साथ एक VPS अकाउंट मौजूद होता है। यह onion को भी गुमनाम नहीं बनाता है, क्योंकि आपने अभी-अभी उस clearnet domain से एक स्थायी सार्वजनिक घोषणा की है कि ये दोनों पते एक ही साइट के हैं। इसका लाभ पाठक को मिलता है: जो कोई Tor के माध्यम से आता है, वह Tor के भीतर ही रह सकता है, जिसमें रास्ते में कोई exit node नहीं होता और आपके डोमेन के लिए कोई DNS lookup नहीं होता। यदि आपका लक्ष्य एक ऐसी onion service है जिससे कोई भी आपसे जुड़ न सके, तो इस header को प्रकाशित न करें, और एक ही मशीन पर दोनों प्रतियां न चलाएं।

यहाँ दो संबंधित प्रश्न उठते हैं और दोनों के अपने उत्तर हैं। Tor और VPN के बीच का अंतर यह तय करता है कि आप अपने स्वयं के ट्रैफ़िक के लिए क्या उपयोग करते हैं, जो कि आप क्या प्रकाशित करते हैं, इससे एक अलग निर्णय है। और यदि सेंसर किए गए नेटवर्क में पाठक clearnet साइट तक बिल्कुल नहीं पहुँच सकते हैं, तो वे कभी भी header नहीं देख पाते हैं, जहाँ bridges और pluggable transports इस पृष्ठ पर मौजूद किसी भी अन्य चीज़ से अधिक मायने रखते हैं।

पूरे सेटअप की एक बार पुष्टि करें

इन्हें क्रम में चलाएँ। प्रत्येक का एक उत्तर है जिसे आप देख सकते हैं।

  1. curl -sI https://example.com/ | grep -i onion-location हेडर को प्रिंट करता है।
  2. 404 एरर देने वाले URL पर यही कमांड चलाने पर भी यह हेडर प्रिंट होता है।
  3. curl -s --socks5-hostname 127.0.0.1:9050 http://<your-onion-address>.onion/ आपके पेज को लौटाता है।
  4. उस आउटपुट में अपने clearnet डोमेन को grep करने पर कुछ भी नहीं मिलता है।
  5. https://example.com पर Tor Browser, .onion available पिल (pill) दिखाता है।

यदि चरण 1 से 4 सफल होते हैं और चरण 5 नहीं होता है, तो इसका कारण लगभग हमेशा वह स्थान होता है जहाँ से हेडर सर्व किया जा रहा है, न कि स्वयं हेडर। पुष्टि करें कि ब्राउज़र ने वास्तव में HTTPS पेज लोड किया है न कि कोई कैश्ड रीडायरेक्ट, फिर उस सटीक URL पर curl -sI चलाएँ जिसे आपने खोला था, क्योंकि उस विशिष्ट पाथ पर लगा location ब्लॉक सर्वर-स्तरीय निर्देश को हटा सकता है।

FAQ

Tor Browser में ".onion available" पिल (pill) क्यों नहीं दिखाई देती है?

सबसे पहले तीन निर्धारित आवश्यकताओं की जाँच करें। मान (value) एक पूर्ण URL होना चाहिए जिसमें http: या https: स्कीम और .onion होस्ट हो, इसलिए बिना स्कीम वाला केवल पता काम नहीं करेगा और कोई त्रुटि भी नहीं दिखाएगा। पेज को HTTPS के माध्यम से सर्व किया जाना चाहिए, इसलिए आपके port 80 रीडायरेक्ट ब्लॉक पर सेट किया गया हेडर कभी नहीं पढ़ा जाता है। और पेज स्वयं एक onion नहीं होना चाहिए। इसके बाद, nginx को देखें: मेल खाते location ब्लॉक के भीतर कोई भी add_header सर्वर स्तर से आने वाले प्रत्येक add_header को हटा देता है, और always फ्लैग के बिना यह हेडर 404 और 500 रिस्पॉन्स में अनुपस्थित रहता है। ब्राउज़र में लोड किए गए सटीक URL पर curl -sI चलाएं और पुष्टि करें कि हेडर वास्तव में नेटवर्क पर मौजूद है।

क्या मुझे अपनी onion साइट के लिए TLS सर्टिफिकेट की आवश्यकता है?

नहीं। एक v3 onion पता सर्विस की पब्लिक की (public key) से प्राप्त होता है, इसलिए सर्किट उस विशिष्ट सर्विस के लिए प्रमाणित होता है और कोई भी HTTP अनुरोध भेजे जाने से पहले एंड-टू-एंड एन्क्रिप्टेड होता है। onion सर्विस के भीतर सादा HTTP ही सामान्य कॉन्फ़िगरेशन है। आपको जो नहीं करना चाहिए, वह है अपनी clearnet साइट का सर्टिफिकेट onion पर प्रस्तुत करना। इसके subject alternative names में आपका डोमेन सूचीबद्ध होता है, जो ब्राउज़र में नाम बेमेल (name mismatch) की चेतावनी को ट्रिगर करता है और प्रत्येक विज़िटर को यह पुष्टि करता है कि दोनों साइटें एक ही मशीन पर चल रही हैं।

क्या Onion-Location प्रकाशित करने से मेरी साइट गुमनाम हो जाती है?

नहीं। यह हेडर आपके clearnet डोमेन की ओर से एक सार्वजनिक घोषणा है कि एक विशेष onion पता आपका है, और कोई भी इसे प्राप्त कर सकता है। इसका लाभ पाठक को मिलता है, जो onion में जाकर अपने पाथ से एग्जिट नोड और DNS लुकअप को हटा सकता है। एक ऑपरेटर के रूप में आपको कोई गुमनामी नहीं मिलती है, और आप स्थायी रूप से दोनों पतों को लिंक कर देते हैं। एक onion सर्विस जिसे आपसे ट्रेस नहीं किया जाना चाहिए, उसे कहीं और प्रकाशित किया जाना चाहिए, ऐसे हार्डवेयर पर जो clearnet साइट के साथ कुछ भी साझा न करता हो।

क्या मैं HTTP हेडर के बजाय मेटा टैग का उपयोग कर सकता हूँ?

हाँ, जब आप रिस्पॉन्स हेडर सेट नहीं कर सकते, जो कि एक स्टैटिक होस्ट पर सामान्य स्थिति है। डॉक्यूमेंट हेड में <meta http-equiv="onion-location" content="http://youraddress.onion" /> डालें। वही तीन आवश्यकताएं लागू होती हैं, इसलिए पेज HTTPS होना चाहिए और onion नहीं होना चाहिए। एकमात्र वास्तविक अंतर यह है कि टैग में बिना पाथ वाला एक निश्चित पता होता है, जबकि nginx हेडर $request_uri को जोड़ सकता है और विज़िटर को होम पेज के बजाय onion पर वही पेज प्रदान कर सकता है।

#tor#onion-service#nginx#privacy#headers