VPS पर obfs4 Tor bridge कैसे सेटअप करें

Tor bridge क्या है, और यह क्यों मौजूद है

Tor bridge, Tor नेटवर्क में प्रवेश का एक ऐसा बिंदु है जिसका पता सार्वजनिक relay सूची में प्रकाशित नहीं होता है। उस सूची को, जिसे consensus कहा जाता है, एक हस्ताक्षरित दस्तावेज़ के रूप में कोई भी डाउनलोड कर सकता है, और सेंसर भी इसे डाउनलोड कर लेते हैं। Tor को इससे ब्लॉक करने में केवल एक दोपहर का समय लगता है: consensus को प्राप्त करें, और फिर उसमें मौजूद हर पते को बॉर्डर पर ड्रॉप कर दें। Bridges इसलिए मौजूद हैं क्योंकि प्रकाशित सूची ही सबसे कमज़ोर कड़ी है। Bridge के पते एक बार में कुछ ही दिए जाते हैं, इसलिए कोई भी एक अनुरोध पूरी सूची को उजागर नहीं करता है।

एक असूचीबद्ध पता समाधान का केवल आधा हिस्सा है। Deep packet inspection (DPI), जो ट्रैफ़िक को उसके पते के बजाय उसकी सामग्री के आधार पर वर्गीकृत करता है, Tor कनेक्शन को उसके TLS (transport layer security) हैंडशेक के आकार से पहचान लेता है। बिना सूची वाला सेंसर भी यह देख सकता है कि "यह Tor जैसा दिखता है" और कनेक्शन को ड्रॉप कर सकता है। एक pluggable transport इस संकेत को हटा देता है। यह क्लाइंट साइड पर Tor स्ट्रीम को किसी और चीज़ में लपेट देता है, और आपका bridge उसे खोल देता है।

obfs4 वह transport है जिसे अधिकांश bridges चलाते हैं। यह स्ट्रीम को ऐसे बाइट्स में बदल देता है जिनमें कोई हेडर और कोई निश्चित हैंडशेक नहीं होता, इसलिए DPI के पास मिलान करने के लिए कोई पैटर्न नहीं होता। यह क्लाइंट को प्रमाणित भी करता है। bridge लाइन के अंदर का cert= मान एक ऐसी key है जिसे क्लाइंट को यह साबित करना होता है कि वह उसके पास है, इससे पहले कि bridge कोई उत्तर दे। यह active probing को विफल कर देता है: एक सेंसर जो यह परीक्षण करने के लिए आपके पते से जुड़ता है कि क्या वह Tor बोलता है, उसे कोई उत्तर नहीं मिलता और वह कुछ भी नहीं जान पाता।

आपको कौन सा pluggable transport चलाना चाहिए?

• obfs4 के लिए एक VPS, दो TCP ports की आवश्यकता होती है और इसके लिए किसी domain name की जरूरत नहीं है। यह सबसे आसान उपयोगी चीज है जिसे आप चला सकते हैं, और यही इस गाइड का विषय है।
• WebTunnel कनेक्शन को एक वास्तविक वेबसाइट के सामान्य HTTPS traffic के भीतर छिपा देता है। Tor Project इसकी आवश्यकताओं को इस प्रकार सूचीबद्ध करता है: एक static IPv4 address, आपके नियंत्रण वाला एक domain, NGINX या Apache जैसा एक कार्यशील web server, एक वैध TLS certificate, और कम से कम 1 GB RAM (4 GB की अनुशंसा की जाती है)। यह उन networks के लिए उपयुक्त है जहाँ यादृच्छिक दिखने वाला traffic ही संदिग्ध होता है, क्योंकि जो देश web browsing से अधिक की अनुमति नहीं देते, वे भी HTTPS की अनुमति देते हैं।
• Snowflake एक अलग तरह का योगदान है। स्वयंसेवक अल्पकालिक WebRTC proxies चलाते हैं, इसलिए entry points लगातार बदलते रहते हैं और सेंसर के ब्लॉक करने के लिए कोई स्थिर पता नहीं होता है। आप इसके लिए bridge संचालित नहीं करते हैं। आप एक proxy चलाते हैं, और इसे किसी निश्चित पते की आवश्यकता नहीं होती है।

obfs4 से शुरुआत करें। आप बाद में दूसरे पते पर WebTunnel bridge जोड़ सकते हैं: एक ही IP पर दोनों को चलाने का मतलब है कि एक पता ब्लॉक होने पर दोनों बंद हो जाएंगे।

ब्रिज चलाने की लागत क्या है?

[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

अगस्त 2026 तक, Tor Project एक ब्रिज के लिए कम से कम 1 Mbit/s की अपस्ट्रीम और डाउनस्ट्रीम बैंडविड्थ की अपेक्षा करता है। एक गार्ड या मिडिल रिले के लिए 10 Mbit/s की अपेक्षा की जाती है, जिसमें 16 Mbit/s की अनुशंसा की जाती है। ये प्रकाशित आवश्यकताएं हैं, न कि मापन। एक नया ब्रिज आमतौर पर हफ्तों तक अपने न्यूनतम स्तर से काफी नीचे रहता है। वही आवश्यकता पृष्ठ एक रिले के लिए प्रति माह कम से कम 100 GByte आउटबाउंड ट्रैफ़िक मांगता है, जिसे सबसे छोटे प्लान पहले ही पूरा कर लेते हैं, इसलिए किसी बड़े प्लान को चुनने से पहले एक छोटे VPS की वास्तविक मासिक लागत के बारे में पढ़ें।

दुरुपयोग (abuse) की संभावना कम है, और यही वह हिस्सा है जिसे लोग गलत समझते हैं। एक ब्रिज पहला हॉप होता है। आपके सर्वर से निकलने वाला ट्रैफ़िक किसी अन्य Tor रिले पर जाता है, न कि उस वेबसाइट पर जिसे उपयोगकर्ता ने चुना है। आपका IP पता कभी भी किसी अजनबी के वेब लॉग में अनुरोध के स्रोत के रूप में दिखाई नहीं देता है, इसलिए जो शिकायत ईमेल एग्जिट रिले ऑपरेटरों को मिलते हैं, वे यहाँ नहीं आते हैं। फिर भी अपने प्रदाता की 'एक्सेप्टेबल यूज़ पॉलिसी' की जाँच करें, क्योंकि कुछ होस्ट किसी भी Tor सेवा को विशेष श्रेणी में रखते हैं। इस संबंध में एक ब्रिज और एक onion सेवा एक-दूसरे के विपरीत हैं: एक ब्रिज केवल इसलिए उपयोगी है क्योंकि उसका पता पहुंच योग्य है और अंततः वितरित किया जाता है, जबकि उसी प्रकार के VPS पर एक v3 onion सेवा केवल तब उपयोगी होती है जब आपका सार्वजनिक IP छिपा रहता है।

एक काम जो नहीं करना है: किसी मौजूदा सार्वजनिक रिले को उसी पते पर ब्रिज में न बदलें। इस मामले के लिए Tor Project की सलाह है कि "IP पता, नाम और फिंगरप्रिंट" बदलें, क्योंकि पुराना पता पहले से ही उस कंसेंसस में है जिसे सेंसर डाउनलोड करते हैं। जो ब्रिज पिछले सप्ताह एक सार्वजनिक रिले था, वह ऐसा ब्रिज है जो पहले से ही ब्लॉकलिस्ट में है।

स्पीड से अधिक अपटाइम मायने रखता है। रिले की आवश्यकताओं में कहा गया है कि "यदि आपका रिले दिन में 2 घंटे से अधिक समय तक नहीं चल रहा है, तो इसकी उपयोगिता सीमित है", और इस मामले में एक ब्रिज की स्थिति रिले से भी खराब होती है, क्योंकि प्रत्येक क्लाइंट के पास एक पता होता है और कोई फॉलबैक नहीं होता है। रीस्टार्ट करने पर उस पर मौजूद सभी उपयोगकर्ता डिस्कनेक्ट हो जाते हैं। obfs4 पोर्ट के लिए Uptime Kuma में TCP पोर्ट चेक सेट करें ताकि आपको उस दिन पता चल सके जब यह प्रतिक्रिया देना बंद कर दे।

Tor Project repository से Tor इंस्टॉल करें

Distribution packages पुराने हो जाते हैं, और bridge एक ऐसा security software है जिसे हमेशा अद्यतित (current) रहना चाहिए। सबसे पहले project का अपना repository जोड़ें।

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

अब source file लिखें। Suites: line में आपके release का codename होना चाहिए, इसलिए इसे याद रखने के बजाय system से पढ़ें।

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring obfs4proxy

यदि apt update यह रिपोर्ट करता है कि repository में आपके codename के लिए कोई Release file नहीं है, तो इसका मतलब है कि Tor Project उस release को support नहीं करता है। /etc/apt/sources.list.d/tor.sources को delete करें, sudo apt update को फिर से चलाएं, और वह tor package इंस्टॉल करें जो आपकी distribution प्रदान करती है। नीचे दी गई बाकी प्रक्रिया समान है।

obfs4proxy package सीधे Debian और Ubuntu से आता है (अगस्त 2026 तक, Debian 13 में version 0.0.14)। यह पुष्टि करें कि binary कहाँ इंस्टॉल हुई है, क्योंकि इसका path config में डालना होगा:

command -v obfs4proxy || command -v lyrebird

Upstream ने project का नाम बदलकर lyrebird कर दिया है, इसलिए हो सकता है कि नया package इसके बजाय /usr/bin/lyrebird इंस्टॉल करे। वह path उपयोग करें जो वह command print करती है।

/etc/tor/torrc में bridge को कॉन्फ़िगर करें

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

इनमें से प्रत्येक लाइन के साथ एक संभावित विफलता जुड़ी है, इसलिए एक-एक करके इनका ध्यान रखें।

BridgeRelay 1 tor को निर्देश देता है कि वह अपने descriptor को public consensus के बजाय bridge authority को भेजे। यही वह एकमात्र लाइन है जो relay को unlisted बनाती है।

ORPort वास्तविक Tor port है। इसे internet से reachable होना चाहिए, क्योंकि tor इसका परीक्षण करता है और जब तक वह परीक्षण सफल नहीं हो जाता, तब तक descriptor प्रकाशित करने से मना कर देता है।

ServerTransportPlugin tor को चलाने के लिए कमांड देता है। tor, obfs4proxy को एक child process के रूप में शुरू करता है और एक pipe के माध्यम से उससे बात करता है, इसलिए obfs4proxy की अपनी कोई service unit नहीं होती और यह कभी भी systemctl status में दिखाई नहीं देता।

ServerTransportListenAddr उस port को निर्धारित करता है जिस पर obfs4proxy listen करता है। यदि आप इस लाइन को हटा देते हैं, तो obfs4proxy startup पर एक free port चुन लेगा, और अधिकांश restarts के बाद एक अलग port चुन लेगा। इसका परिणाम यह होगा कि आपके द्वारा बांटी गई प्रत्येक bridge line ऐसे port की ओर इशारा करेगी जहाँ कुछ भी listen नहीं कर रहा है। उन clients को connection refused का error मिलेगा और वे प्रयास करना बंद कर देंगे।

ExtORPort auto extended ORPort को खोलता है, जो एक loopback channel है। obfs4proxy इसका उपयोग client के address के साथ पूर्ण connections को वापस tor तक पहुँचाने के लिए करता है। The Tor Project की setup guide में इसे हर bridge पर शामिल किया गया है, क्योंकि इसके बिना transport उस address को tor को रिपोर्ट नहीं कर सकता।

ContactInfo और Nickname दोनों सार्वजनिक हैं। एक ऐसा address उपयोग करें जिसे आप नियमित रूप से पढ़ते हैं, क्योंकि इसी के माध्यम से The Tor Project आपसे broken bridge के बारे में संपर्क करता है। एक ऐसा nickname चुनें जो आपकी पहचान उजागर न करे, यदि आप गुमनाम रहना चाहते हैं।

BridgeDistribution यह चुनता है कि कौन सा distributor आपका address उपयोगकर्ताओं को देगा। स्वीकृत मान https, email, telegram, settings, none और any हैं। पहली bridge के लिए any का उपयोग करें और सिस्टम को निर्णय लेने दें। निजी bridge के लिए none का उपयोग करें जिसे आप स्वयं वितरित करते हैं, जो address को पूरी तरह से सार्वजनिक वितरण से दूर रखता है।

पोर्ट का चयन क्यों महत्वपूर्ण है

दोनों पोर्ट के लिए 9001 का उपयोग न करें। Tor Project सीधे तौर पर ऐसा करने से मना करता है, क्योंकि 9001 पारंपरिक ORPort है और सेंसर इसे खोजने के लिए इंटरनेट को स्कैन करते हैं। दोनों पोर्ट एक-दूसरे से अलग होने चाहिए, क्योंकि tor और obfs4proxy दोनों अपने स्वयं के listener bind करते हैं।

सबसे प्रभावी obfs4 पोर्ट 443 है। लगभग हर प्रतिबंधित नेटवर्क पर आउटबाउंड 443 खुला रहता है, और इससे बना लंबे समय तक चलने वाला कनेक्शन एक सामान्य वेब सत्र जैसा दिखता है। 1024 से नीचे के पोर्ट को bind करने के लिए एक अतिरिक्त चरण की आवश्यकता होती है, क्योंकि obfs4proxy root के रूप में नहीं चलता है:

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

खुलने वाले प्रत्येक एडिटर में ये दो लाइनें जोड़ें:

[Service]
NoNewPrivileges=no

केवल यह capability पर्याप्त नहीं है। systemd का NoNewPrivileges किसी प्रक्रिया को ऐसी कोई भी privilege प्राप्त करने से रोकता है जो उसके parent के पास नहीं थी, और file capability बिल्कुल वही है, इसलिए जब यह सेटिंग चालू रहती है तो obfs4proxy 443 को bind करने में विफल रहता है।

यदि आप उस चरण को छोड़ना चाहते हैं, तो कोई सामान्य high port चुनें और उसे नोट कर लें। आप जो भी चुनें, बाद में obfs4 पोर्ट न बदलें। एक bridge line एड्रेस, पोर्ट, फिंगरप्रिंट और सर्टिफिकेट को एक साथ जोड़ती है, इसलिए पोर्ट बदलते ही उपयोगकर्ता के ब्राउज़र में मौजूद हर कॉपी काम करना बंद कर देगी।

दोनों फायरवॉल पर पोर्ट खोलें

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

दोनों पोर्ट खुले होने चाहिए। अधिकांश प्रदाता अपने कंट्रोल पैनल में एक दूसरा फायरवॉल भी चलाते हैं जिसके बारे में ufw को कोई जानकारी नहीं होती। जो नियम सर्वर पर मौजूद है लेकिन पैनल में नहीं, वह एक ऐसा ब्रिज बनाता है जो कभी भी पहुँच योग्य नहीं होता और न ही कोई डिस्क्रिप्टर पब्लिश करता है। यदि इनमें से कोई भी विषय आपके लिए नया है, तो एक नए VPS के लिए आवश्यक ufw नियम और Linux पर लिसनिंग पोर्ट वास्तव में क्या होता है में इसकी जानकारी दी गई है। साथ ही, SSH को कीज़ और हार्डन्ड sshd कॉन्फ़िगरेशन के साथ सुरक्षित करें। पासवर्ड-आधारित SSH वाले सर्वर पर एक अनलिस्टेड ब्रिज का मतलब है कि वह सर्वर अभी भी पासवर्ड-आधारित SSH का उपयोग कर रहा है।

इसे start करें, फिर log पढ़ें

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian और Ubuntu दो units के साथ आते हैं। tor.service एक छोटा wrapper है और tor@default.service वह process है जो वास्तविक काम करती है, यही कारण है कि journalctl -u tor लगभग खाली दिखता है जबकि वह log जिसे आप देखना चाहते हैं, tor@default के अंतर्गत होता है।

दो पंक्तियाँ दर्शाती हैं कि यह काम कर गया:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

पहली पंक्ति का अर्थ है कि reachability test सफल रहा और descriptor bridge authority के पास चला गया। यदि यह कभी दिखाई नहीं देता है, तो internet और आपके server के बीच कुछ ऐसा है जो ORPort के traffic को drop कर रहा है। दूसरी पंक्ति में वह port दिखना चाहिए जिसे आपने configure किया है। वहाँ एक अलग port दिखने का मतलब है कि tor ने ServerTransportListenAddr को लागू नहीं किया है, और इसका सामान्य कारण transport name का मेल न खाना है: इसे दोनों directives पर obfs4 पढ़ा जाना चाहिए।

पुष्टि करें कि दोनों listeners मौजूद हैं:

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

मेरी bridge line कहाँ है?

obfs4proxy, tor की data directory में एक template लिखता है:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

यह directory tor user की है और इसका mode 700 है, इसलिए sudo के बिना आपको Permission denied प्राप्त होगा। इस file में इस आकार की एक line होती है:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

<IP ADDRESS> को अपने सर्वर के public address से, <PORT> को ORPort के बजाय obfs4 port से, और <FINGERPRINT> को उस identity fingerprint से बदलें जिसे tor ने अपनी data directory में लिखा है:

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

पहली file में आपका nickname और वह identity fingerprint होता है जो bridge line में होना चाहिए। दूसरी file में hashed fingerprint होता है, जिसे आप Relay Search में paste करते हैं ताकि यह देख सकें कि आपकी bridge चल रही है या नहीं और लगभग कितने clients उस तक पहुँच रहे हैं। ये दोनों एक-दूसरे के स्थान पर इस्तेमाल नहीं किए जा सकते। hashed value वाली bridge line उस identity key से मेल नहीं खाती जो आपकी bridge प्रस्तुत करती है, इसलिए client द्वारा अभी-अभी खोला गया connection अस्वीकार कर दिया जाता है।

एक bridge वास्तव में उपयोगकर्ताओं तक कैसे पहुँचता है?

आप अपनी bridge line किसी को भी खुद नहीं देते हैं। एक बार जब descriptor bridge authority तक पहुँच जाता है, तो distribution system (rdsys, जो BridgeDB का उत्तराधिकारी है) आपकी bridge को एक distributor को सौंप देता है, और उपयोगकर्ता उस distributor से bridge मांगते हैं। अगस्त 2026 तक, इसके मार्ग इस प्रकार हैं:

• bridges.torproject.org/options पर स्थित वेब फॉर्म, जो captcha के बाद bridge lines प्रदान करता है।
• Gmail या Riseup पते से bridges@torproject.org पर भेजा गया ईमेल, जो bridge lines के साथ उत्तर देता है। प्रदाता पर यह प्रतिबंध इसलिए है क्योंकि असीमित मुफ्त खातों के माध्यम से कोई सेंसर हर bridge की सूची बना सकता है।
• Telegram bot @GetBridgesBot। /start भेजें, फिर /obfs4 या /webtunnel का उपयोग करें।
• स्वयं Tor Browser, Settings के अंतर्गत Connection में, जहाँ "Request bridges" विकल्प moat channel के माध्यम से उन्हें प्राप्त करता है।

एक नई bridge सेटअप के लगभग तीन घंटे बाद Relay Search में दिखाई देती है। उपयोगकर्ताओं को जुड़ने में काफी अधिक समय लगता है: Tor Project का स्वयं का कहना है कि "उपयोगकर्ताओं का एक स्थिर समूह देखने में आपको कई दिन या सप्ताह लग सकते हैं।" शुरुआत के दो सप्ताह शांत रहना सामान्य है, यह कोई त्रुटि नहीं है।

BridgeDistribution none सेट करने से आप इन सभी वितरण प्रणालियों से बाहर हो जाते हैं। इसके बाद bridge line पूरी तरह से आपकी होती है, जिसे आप उन लोगों को भेज सकते हैं जिन्हें इसकी आवश्यकता है, ऐसे माध्यम से जिसे सेंसर पढ़ नहीं रहा है।

जब कोई चीज़ काम न करे

लॉग में कोई self-testing लाइन नहीं है। ORPort तक पहुँचा नहीं जा सकता। इसे किसी अन्य मशीन से nc -vz your.ip 8443 का उपयोग करके टेस्ट करें। हैंग होने का मतलब है कि पैकेट ड्रॉप किए जा रहे हैं, इसलिए ufw और प्रोवाइडर के पैनल की जाँच करें। रिफ्यूज़ल (refusal) का मतलब है कि tor लिसन नहीं कर रहा है, इसलिए ss -lntp की जाँच करें और कॉन्फ़िगरेशन त्रुटि के लिए लॉग पढ़ें।

रजिस्टर्ड ट्रांसपोर्ट वह पोर्ट दिखाता है जिसे आपने नहीं चुना था। tor ने ServerTransportListenAddr को अनदेखा कर दिया। ट्रांसपोर्ट का नाम ServerTransportPlugin में दिए गए नाम से बिल्कुल मेल खाना चाहिए, और दोनों obfs4 होने चाहिए।

obfs4proxy पोर्ट 443 पर बाइंड नहीं होगा। getcap /usr/bin/obfs4proxy के साथ क्षमता (capability) की पुष्टि करें, फिर पुष्टि करें कि ओवरराइड यूनिट तक पहुँच गया है, इसके लिए systemctl show tor@default -p NoNewPrivileges का उपयोग करें। यदि यह NoNewPrivileges=yes प्रिंट करता है, तो आपका ड्रॉप-इन ऐसी यूनिट पर गया है जो चल नहीं रही है।

/var/lib/tor/pt_state/ के अंदर कुछ भी नहीं है। tor ने ट्रांसपोर्ट कभी शुरू नहीं किया, जिसका अर्थ है कि ServerTransportPlugin में दिया गया पाथ गलत है। इसकी तुलना command -v obfs4proxy के आउटपुट से करें।

बदलाव के बाद क्लाइंट्स ने कनेक्ट करना बंद कर दिया। एड्रेस या obfs4 पोर्ट में कोई भी बदलाव पहले से वितरित की गई हर ब्रिज लाइन को अमान्य कर देता है। जाँचें कि क्या सर्वर का पब्लिक IP भी बदल गया है, जो कुछ प्रोवाइडर्स के साथ रीबिल्ड करने पर होता है।

tor बिल्कुल भी शुरू नहीं होगा। sudo -u debian-tor tor --verify-config -f /etc/tor/torrc चलाएँ। यह फ़ाइल को पार्स करता है, उस लाइन को प्रिंट करता है जिस पर उसे आपत्ति है, और चल रही सर्विस को प्रभावित नहीं करता है।

FAQ

क्या मेरा VPS प्रदाता Tor bridge के बारे में शिकायत करेगा?

एक bridge एक entry point है, इसलिए आपके सर्वर से निकलने वाला traffic अन्य Tor relays तक जाता है, न कि उस साइट तक जिसे उपयोगकर्ता ने चुना है। आपका IP address किसी के भी web log में request के स्रोत के रूप में दिखाई नहीं देता है, और यही वह कारण है जिससे exit relay ऑपरेटरों को शिकायतें मिलती हैं। होस्टिंग नियम अलग-अलग होते हैं, और कुछ प्रदाता किसी भी Tor service को एक विशेष मामले के रूप में देखते हैं, इसलिए शुरू करने से पहले acceptable use policy पढ़ें और ContactInfo में वह पता डालें जिसे आप नियमित रूप से देखते हैं।

एक Tor bridge कितना bandwidth उपयोग करता है?

प्रकाशित न्यूनतम सीमा 1 Mbit/s अप और डाउन है, जबकि guard या middle relay के लिए यह 10 Mbit/s है। वास्तविक उपयोग शून्य के करीब से शुरू होता है, क्योंकि आपका bridge केवल उन उपयोगकर्ताओं के लिए traffic ले जाता है जिन्हें एक वितरक (distributor) इसे भेजता है। यदि आप एक सख्त सीमा (hard ceiling) चाहते हैं, तो torrc में RelayBandwidthRate और RelayBandwidthBurst सेट करें।

मेरे नए bridge से कोई क्यों नहीं जुड़ा है?

एक bridge को Relay Search में दिखाई देने में लगभग तीन घंटे लगते हैं, और Tor Project का मार्गदर्शन यह है कि उपयोगकर्ताओं का एक स्थिर समूह बनने में कई दिन या सप्ताह लगते हैं। जाँचें कि descriptor प्रकाशित हुआ है या नहीं, जो journalctl -u tor@default में self-testing लाइन है, Relay Search में अपने hashed fingerprint को देखें, और पुष्टि करें कि BridgeDistribution को none पर सेट नहीं किया गया है।

क्या मुझे obfs4 चलाना चाहिए या WebTunnel?

यदि यह आपका पहला bridge है तो obfs4 चलाएं: एक VPS, दो ports, कोई domain नहीं, कोई certificate नहीं। WebTunnel तब चलाएं जब random दिखने वाला traffic भी block हो, क्योंकि इसके लिए एक domain, एक वास्तविक web server, एक वैध TLS certificate और कम से कम 1 GB RAM की आवश्यकता होती है। यदि आप दोनों चलाते हैं तो उन्हें अलग-अलग IP addresses पर रखें, क्योंकि एक block हुआ IP अन्यथा एक साथ दो bridges को हटा देगा।

यदि मैं बाद में obfs4 port बदल दूँ तो क्या होगा?

वितरित की गई हर bridge लाइन काम करना बंद कर देगी। एक bridge लाइन address, port, fingerprint और certificate को एक साथ जोड़ती है, इसलिए पुरानी लाइन वाला क्लाइंट उस port पर connection खोलने की कोशिश करता है जहाँ कुछ भी listen नहीं कर रहा होता है और वह प्रयास छोड़ देता है। यही बात तब भी लागू होती है जब सर्वर का public IP बदल जाता है। सेटअप के दौरान port चुनें और उसे न बदलें।