راه اندازی Tor Bridge با obfs4 روی VPS

پل Tor چیست و چرا وجود دارد

پل Tor یک نقطهٔ ورود به شبکهٔ Tor است که آدرس آن در لیست عمومی رله‌ها منتشر نمی‌شود. آن لیست که consensus نامیده می‌شود، سندی امضاشده است که هر کسی می‌تواند آن را دانلود کند و سانسورچی نیز آن را دانلود می‌کند. مسدود کردن Tor از طریق آن لیست تنها یک بعدازظهر زمان می‌برد: consensus را دریافت کنید و سپس تمام آدرس‌های موجود در آن را در مرز شبکه مسدود کنید. پل‌ها به این دلیل وجود دارند که لیست منتشرشده، نقطهٔ ضعف شبکه است. آدرس‌های پل‌ها به‌صورت محدود و در هر نوبت به تعداد کمی ارائه می‌شوند، بنابراین هیچ درخواست واحدی کل مجموعه را لو نمی‌دهد.

یک آدرس ثبت‌نشده تنها نیمی از پاسخ است. بازرسی عمیق بسته (DPI) که ترافیک را بر اساس محتوا و نه آدرس طبقه‌بندی می‌کند، اتصال Tor را از روی شکل handshake پروتکل TLS (امنیت لایه انتقال) تشخیص می‌دهد. سانسورچی بدون داشتن لیست هم می‌تواند تشخیص دهد که «این شبیه Tor است» و اتصال را قطع کند. یک pluggable transport این سیگنال را حذف می‌کند. این ابزار جریان Tor را در سمت کلاینت در قالب دیگری بسته‌بندی می‌کند و پل شما آن را باز می‌کند.

obfs4 پروتکل انتقالی است که اکثر پل‌ها از آن استفاده می‌کنند. این ابزار جریان داده را به بایت‌هایی بدون هدر و بدون handshake ثابت تبدیل می‌کند، بنابراین DPI هیچ الگویی برای تطبیق پیدا نمی‌کند. این پروتکل همچنین کلاینت را احراز هویت می‌کند. مقدار cert= در خط تنظیمات پل، کلیدی است که کلاینت باید پیش از دریافت هرگونه پاسخ از پل، ثابت کند که آن را در اختیار دارد. این کار مانع از کاوش فعال (active probing) می‌شود: سانسورچی که به آدرس شما متصل می‌شود تا آزمایش کند آیا آن آدرس با پروتکل Tor صحبت می‌کند یا خیر، هیچ پاسخی دریافت نمی‌کند و چیزی متوجه نمی‌شود.

از کدام pluggable transport باید استفاده کنید؟

• obfs4 به یک VPS، دو پورت TCP و هیچ نام دامنه‌ای نیاز ندارد. این ساده‌ترین ابزار کاربردی است که می‌توانید راه‌اندازی کنید و موضوع این راهنما نیز همین است.
• WebTunnel اتصال را در دل ترافیک عادی HTTPS یک وب‌سایت واقعی پنهان می‌کند. پروژه Tor نیازمندی‌های آن را شامل یک آدرس IPv4 ثابت (در صورت امکان)، دامنه‌ای که تحت کنترل شماست، یک وب‌سرور فعال مانند NGINX یا Apache، یک گواهی TLS معتبر و حداقل 1 GB رم (با پیشنهاد 4 GB) می‌داند. این ابزار برای شبکه‌هایی مناسب است که در آن‌ها ترافیک با ظاهر تصادفی مشکوک تلقی می‌شود، زیرا کشوری که دسترسی به چیزی فراتر از وب‌گردی را محدود کرده، همچنان HTTPS را مجاز می‌شمارد.
• Snowflake یک نوع مشارکت متفاوت است. داوطلبان پروکسی‌های WebRTC کوتاه‌مدت اجرا می‌کنند، بنابراین نقاط ورود دائماً تغییر می‌کنند و هیچ آدرس پایداری برای مسدودسازی توسط سانسورچی وجود ندارد. شما برای این مورد یک bridge را مدیریت نمی‌کنید. شما یک پروکسی اجرا می‌کنید که به هیچ آدرس ثابتی نیاز ندارد.

با obfs4 شروع کنید. می‌توانید بعداً یک bridge از نوع WebTunnel روی آدرس دوم اضافه کنید: اجرای هر دو روی یک IP به این معنی است که با مسدود شدن یک آدرس، هر دو از دسترس خارج می‌شوند.

اجرای یک bridge چه هزینه‌ای برای شما دارد؟

[
  {
    "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 برای یک bridge حداقل 1 مگابیت بر ثانیه پهنای باند آپلود و دانلود درخواست می‌کند. برای یک guard یا middle relay، حداقل 10 مگابیت بر ثانیه درخواست شده و 16 مگابیت بر ثانیه توصیه می‌شود. این‌ها الزامات اعلام‌شده هستند، نه اندازه‌گیری‌های واقعی. یک bridge جدید معمولاً تا هفته‌ها بسیار کمتر از حداقلِ خود فعالیت می‌کند. همان صفحه الزامات، برای یک relay حداقل 100 گیگابایت ترافیک خروجی در ماه را درخواست می‌کند که کوچک‌ترین پلن‌های سرور مجازی (VPS) نیز آن را پوشش می‌دهند؛ بنابراین پیش از انتخاب هر پلن بزرگ‌تری، هزینه واقعی یک VPS کوچک در ماه را مطالعه کنید.

سطح سوءاستفاده (abuse) بسیار کم است و این همان بخشی است که افراد در مورد آن دچار اشتباه می‌شوند. یک bridge اولین گام (hop) است. ترافیکی که از سرور شما خارج می‌شود به یک relay دیگر در شبکه Tor می‌رود و هرگز مستقیماً به وب‌سایتی که کاربر انتخاب کرده ارسال نمی‌شود. آدرس IP شما هرگز در لاگ وب‌سایت‌های دیگر به عنوان منبع درخواست ظاهر نمی‌شود، بنابراین ایمیل‌های شکایتی که مدیران exit relay دریافت می‌کنند، برای شما ارسال نخواهد شد. با این حال، سیاست استفاده قابل‌قبول (AUP) ارائه‌دهنده خود را بررسی کنید، زیرا برخی از میزبان‌ها با هر نوع سرویس Tor به عنوان یک مورد خاص برخورد می‌کنند. یک bridge و یک onion service از این نظر تصاویر آینه‌ای یکدیگر هستند: یک bridge تنها زمانی مفید است که آدرس آن در دسترس باشد و در نهایت در اختیار کاربران قرار گیرد، در حالی که یک v3 onion service روی همان نوع VPS تنها زمانی مفید است که IP عمومی شما مخفی بماند.

یک کار را نباید انجام دهید: تبدیل یک relay عمومی موجود به یک bridge در همان آدرس. توصیه پروژه Tor برای این مورد، تغییر «آدرس IP، نام و اثر انگشت (fingerprint)» است، زیرا آدرس قدیمی قبلاً در لیست consensus که سانسورچی‌ها دانلود می‌کنند، وجود دارد. bridgeای که تا هفته گذشته یک relay عمومی بوده، bridgeای است که از قبل در لیست سیاه قرار دارد.

پایداری (uptime) اهمیت بیشتری نسبت به سرعت دارد. الزامات relay بیان می‌کند که «اگر relay شما بیش از 2 ساعت در روز فعال نباشد، کارایی آن محدود است» و وضعیت یک bridge در این مورد حتی بدتر از relay است، زیرا هر کلاینت تنها یک آدرس دارد و هیچ جایگزینی برای آن وجود ندارد. هر بار راه‌اندازی مجدد (restart)، تمام کاربران متصل به آن را قطع می‌کند. برای اطلاع از روزی که سرویس پاسخ‌دهی را متوقف می‌کند، یک بررسی پورت TCP در Uptime Kuma برای پورت obfs4 تنظیم کنید.

نصب Tor از مخزن پروژه Tor

بسته‌های توزیع‌شده در مخازن رسمی معمولاً قدیمی هستند و یک bridge نرم‌افزاری امنیتی است که باید همیشه به‌روز باشد. ابتدا مخزن رسمی پروژه را اضافه کنید.

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

اکنون فایل منبع را بنویسید. خط Suites: باید شامل نام رمز (codename) توزیع شما باشد، بنابراین آن را به‌جای تایپ دستی، از سیستم بخوانید.

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 گزارش داد که مخزن فاقد فایل Release برای نام رمز سیستم شما است، یعنی پروژه Tor آن نسخه را پشتیبانی نمی‌کند. فایل /etc/apt/sources.list.d/tor.sources را حذف کنید، sudo apt update را دوباره اجرا کنید و بسته tor موجود در مخازن توزیع خود را نصب کنید. تمام مراحل زیر یکسان باقی می‌مانند.

بسته obfs4proxy مستقیماً توسط Debian و Ubuntu ارائه می‌شود (نسخه 0.0.14 در Debian 13، تا اکتبر 2026). بررسی کنید که فایل اجرایی در کجا قرار گرفته است، زیرا مسیر آن در فایل پیکربندی استفاده خواهد شد:

command -v obfs4proxy || command -v lyrebird

توسعه‌دهندگان پروژه را به lyrebird تغییر نام داده‌اند، بنابراین ممکن است در نسخه‌های جدیدتر، بسته /usr/bin/lyrebird نصب شود. از هر مسیری که دستور فوق نمایش می‌دهد استفاده کنید.

پیکربندی bridge در /etc/tor/torrc

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 خود را به‌جای انتشار در consensus عمومی، به bridge authority ارسال کند. همین یک خط باعث می‌شود relay شما در لیست عمومی قرار نگیرد.

ORPort پورت اصلی Tor است. این پورت باید از طریق اینترنت در دسترس باشد، زیرا tor آن را تست می‌کند و تا زمانی که این تست با موفقیت انجام نشود، از انتشار descriptor خودداری می‌کند.

ServerTransportPlugin دستور اجرایی را به tor می‌دهد. tor برنامه obfs4proxy را به‌عنوان یک child process اجرا کرده و از طریق یک pipe با آن ارتباط برقرار می‌کند؛ بنابراین obfs4proxy واحد سرویس (service unit) مستقلی ندارد و هرگز در systemctl status دیده نمی‌شود.

ServerTransportListenAddr پورتی که obfs4proxy روی آن گوش می‌دهد را ثابت می‌کند. اگر این خط را حذف کنید، obfs4proxy در هر بار راه‌اندازی یک پورت آزاد را به‌صورت تصادفی انتخاب می‌کند؛ در نتیجه پس از هر بار restart، تمام bridge lineهایی که قبلاً توزیع کرده‌اید به پورتی اشاره می‌کنند که هیچ سرویسی روی آن فعال نیست. کلاینت‌ها با خطای refused connection مواجه شده و تلاش برای اتصال را متوقف می‌کنند.

ExtORPort auto پورت ORPort توسعه‌یافته را باز می‌کند؛ یک کانال loopback که obfs4proxy از آن برای تحویل اتصالات تکمیل‌شده به tor، همراه با آدرس کلاینت، استفاده می‌کند. راهنمای راه‌اندازی The Tor Project این مورد را برای تمام bridgeها توصیه می‌کند، زیرا بدون آن، transport نمی‌تواند آدرس کلاینت را به tor گزارش دهد.

ContactInfo و Nickname هر دو عمومی هستند. از آدرسی استفاده کنید که آن را چک می‌کنید، زیرا The Tor Project از این طریق در صورت خرابی bridge با شما تماس می‌گیرد. همچنین نام مستعاری (nickname) انتخاب کنید که اگر مایل به ناشناس ماندن هستید، هویت شما را فاش نکند.

BridgeDistribution تعیین می‌کند که کدام توزیع‌کننده (distributor) آدرس شما را به کاربران ارائه دهد. مقادیر پذیرفته‌شده عبارتند از https، email، telegram، settings، none و any. برای اولین bridge خود از any استفاده کنید و اجازه دهید سیستم تصمیم بگیرد. برای bridge خصوصی که خودتان به‌صورت دستی توزیع می‌کنید از none استفاده کنید؛ این گزینه آدرس شما را به‌طور کامل از توزیع عمومی خارج نگه می‌دارد.

چرا انتخاب پورت اهمیت دارد

از انتخاب پورت 9001 برای هر دو مورد خودداری کنید. پروژه Tor مستقیماً به این موضوع اشاره کرده است، زیرا 9001 پورت سنتی ORPort است و سانسورچی‌ها اینترنت را برای یافتن آن اسکن می‌کنند. این دو پورت همچنین باید با یکدیگر متفاوت باشند، زیرا tor و obfs4proxy هر کدام listener اختصاصی خود را bind می‌کنند.

بهترین پورت برای obfs4، پورت 443 است. ترافیک خروجی 443 تقریباً در تمام شبکه‌های محدود باز است و یک اتصال طولانی‌مدت به آن، شبیه به یک نشست وب معمولی به نظر می‌رسد. bind کردن روی پورت‌های زیر 1024 به یک گام اضافی نیاز دارد، زیرا obfs4proxy با دسترسی root اجرا نمی‌شود:

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

این دو خط را در هر ویرایشگری که باز می‌شود، اضافه کنید:

[Service]
NoNewPrivileges=no

این قابلیت به تنهایی کافی نیست. تنظیم NoNewPrivileges در systemd مانع از آن می‌شود که یک پردازش، امتیازی فراتر از امتیاز والد خود کسب کند و قابلیت فایل (file capability) دقیقاً چنین چیزی است؛ بنابراین تا زمانی که این تنظیم فعال باشد، obfs4proxy در bind کردن پورت 443 با شکست مواجه می‌شود.

اگر ترجیح می‌دهید از این مرحله صرف‌نظر کنید، یک پورت بالا و غیرمعمول انتخاب کرده و آن را یادداشت کنید. هر چه انتخاب می‌کنید، پورت obfs4 را بعداً تغییر ندهید. یک خط bridge، آدرس، پورت، اثر انگشت (fingerprint) و گواهی را به هم متصل می‌کند؛ بنابراین به محض تغییر پورت، تمام نسخه‌هایی که در مرورگر کاربران ذخیره شده است، از کار می‌افتد.

باز کردن پورت‌ها روی هر دو فایروال

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

هر دو پورت باید باز باشند؛ اکثر ارائه‌دهندگان سرویس، یک فایروال دوم در پنل مدیریتی خود دارند که ufw از آن بی‌اطلاع است. قانونی که روی سرور وجود دارد اما در پنل اعمال نشده است، منجر به ایجاد پلی می‌شود که هرگز در دسترس نخواهد بود و هرگز descriptor منتشر نمی‌کند. اگر هر یک از این دو بخش برای شما جدید است، قوانین ufw مورد نیاز برای یک VPS تازه و مفهوم واقعی پورت listening در لینوکس را مطالعه کنید. در همان حین، دسترسی SSH را با استفاده از کلیدها و پیکربندی سخت‌گیرانه sshd محدود کنید. یک پل ثبت‌نشده روی سروری که از رمز عبور برای SSH استفاده می‌کند، همچنان سروری است که با رمز عبور SSH در دسترس است.

آن را اجرا کرده و سپس لاگ را بخوانید

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

توزیع‌های Debian و Ubuntu دو واحد (unit) ارائه می‌دهند. tor.service یک wrapper کوچک است و tor@default.service فرآیندی است که کار اصلی را انجام می‌دهد؛ به همین دلیل است که journalctl -u tor تقریباً خالی به نظر می‌رسد، در حالی که لاگ مورد نیاز شما در 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 ارسال شده است. اگر این خط ظاهر نشد، یعنی چیزی در مسیر بین اینترنت و سرور شما، ترافیک ورودی به ORPort را مسدود می‌کند. خط دوم باید پورتی را که پیکربندی کرده‌اید نشان دهد. اگر پورت متفاوتی در آنجا مشاهده می‌کنید، یعنی tor دستور ServerTransportListenAddr را اعمال نکرده است؛ دلیل معمول این اتفاق، عدم تطابق نام transport است: این نام باید در هر دو دستور دقیقاً obfs4 باشد.

تأیید کنید که هر دو listener فعال هستند:

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

خط بریج من کجاست؟

برنامه obfs4proxy یک قالب را در دایرکتوری داده‌های tor می‌نویسد:

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

آن دایرکتوری متعلق به کاربر tor است و دسترسی آن روی 700 تنظیم شده است، بنابراین بدون sudo با خطای Permission denied مواجه می‌شوید. این فایل شامل خطی با این ساختار است:

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

عبارت <IP ADDRESS> را با آدرس عمومی سرور خود، <PORT> را با پورت obfs4 (نه ORPort) و <FINGERPRINT> را با اثر انگشت هویتی (identity fingerprint) که tor در دایرکتوری داده‌های خود نوشته است، جایگزین کنید:

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

فایل اول شامل نام مستعار (nickname) و اثر انگشت هویتی است که باید در خط بریج قرار گیرد. فایل دوم شامل اثر انگشت هش‌شده است که باید آن را در Relay Search وارد کنید تا ببینید آیا بریج شما در حال اجراست و تقریباً چند کلاینت به آن متصل شده‌اند. این دو مورد قابل جایگزینی با یکدیگر نیستند. خط بریجی که حاوی مقدار هش‌شده باشد با کلید هویتی که بریج شما ارائه می‌دهد مطابقت ندارد، بنابراین کلاینت اتصالی را که به‌تازگی باز کرده است، رد می‌کند.

یک bridge چگونه واقعاً به دست کاربران می‌رسد؟

شما نباید خط bridge خود را شخصاً به کسی بدهید. هنگامی که descriptor به bridge authority می‌رسد، سیستم توزیع (rdsys، جایگزین BridgeDB) bridge شما را به یکی از توزیع‌کننده‌ها اختصاص می‌دهد و کاربران از آن توزیع‌کننده درخواست bridge می‌کنند. از اکتبر 2026، مسیرهای دسترسی به شرح زیر است:

• وب‌سایت bridges در آدرس bridges.torproject.org/options، که در آن گزینه "Just give me bridges!" بلافاصله خطوط obfs4 را ارائه می‌دهد. در اینجا هیچ کپچایی وجود ندارد: پروژه Tor پس از جایگزینی BridgeDB با rdsys، کپچا را حذف کرد؛ تغییری که در دسامبر 2024 اعلام شد.
• ارسال ایمیل به bridges@torproject.org از یک حساب Gmail یا Riseup، که در پاسخ خطوط bridge را ارسال می‌کند. محدودیت ارائه‌دهنده ایمیل به این دلیل است که حساب‌های رایگان نامحدود به سانسورچی اجازه می‌دهد تمام bridgeها را فهرست کند.
• ربات تلگرام @GetBridgesBot. دستور /start را ارسال کنید و سپس /obfs4 یا /webtunnel را انتخاب کنید.
• خودِ Tor Browser، در بخش Settings و سپس Connection، که در آن گزینه "Request bridges" آن‌ها را از طریق کانال moat دریافت می‌کند.

یک bridge جدید حدود سه ساعت پس از راه‌اندازی در Relay Search ظاهر می‌شود. اما رسیدن کاربران به آن زمان بسیار بیشتری می‌برد: طبق اعلام رسمی پروژه Tor، «ممکن است چندین روز یا هفته طول بکشد تا شاهد تعداد ثابتی از کاربران باشید.» سکوت در دو هفتهٔ اول طبیعی است و نشان‌دهنده خطا نیست.

تنظیم BridgeDistribution none باعث می‌شود bridge شما از تمام سیستم‌های توزیع خودکار خارج شود. در این صورت، مسئولیت ارسال خط bridge به افرادی که به آن نیاز دارند، بر عهده شماست و باید این کار را از طریق کانالی انجام دهید که توسط سانسورچی نظارت نمی‌شود.

هنگامی که چیزی کار نمی‌کند

عدم وجود خط خودآزمایی در لاگ. پورت ORPort در دسترس نیست. آن را از یک ماشین دیگر با nc -vz your.ip 8443 تست کنید. توقف (hang) به معنای مسدود شدن بسته‌هاست، بنابراین ufw و پنل مدیریت ارائه‌دهنده سرور را بررسی کنید. رد اتصال (refusal) به این معناست که tor در حال گوش دادن نیست، پس ss -lntp را بررسی کرده و لاگ را برای یافتن خطای پیکربندی بخوانید.

ترنسپورت ثبت‌شده پورتی را نشان می‌دهد که شما انتخاب نکرده‌اید. برنامه tor مقدار ServerTransportListenAddr را نادیده گرفته است. نام ترنسپورت باید دقیقاً با نام موجود در ServerTransportPlugin مطابقت داشته باشد و هر دو باید obfs4 باشند.

برنامه obfs4proxy نمی‌تواند پورت 443 را bind کند. قابلیت آن را با getcap /usr/bin/obfs4proxy تأیید کنید، سپس تأیید کنید که override به unit رسیده است یا خیر، با استفاده از systemctl show tor@default -p NoNewPrivileges. اگر خروجی NoNewPrivileges=yes را چاپ کرد، یعنی drop-in شما به unitای اعمال شده که در حال اجرا نیست.

هیچ چیزی داخل /var/lib/tor/pt_state/ وجود ندارد. برنامه tor هرگز ترنسپورت را شروع نکرده است، که به این معنی است که مسیر در ServerTransportPlugin اشتباه است. آن را با خروجی command -v obfs4proxy مقایسه کنید.

اتصال کلاینت‌ها پس از یک تغییر متوقف شده است. هرگونه تغییر در آدرس یا پورت obfs4، تمام خطوط bridge توزیع‌شده قبلی را باطل می‌کند. بررسی کنید که آیا IP عمومی سرور نیز تغییر کرده است یا خیر؛ این اتفاق در برخی ارائه‌دهندگان هنگام بازسازی (rebuild) سرور رخ می‌دهد.

برنامه tor اصلاً اجرا نمی‌شود. دستور sudo -u debian-tor tor --verify-config -f /etc/tor/torrc را اجرا کنید. این دستور فایل را پارس کرده، خطی که با آن مشکل دارد را چاپ می‌کند و سرویس در حال اجرا را دست‌نخورده باقی می‌گذارد.

FAQ

آیا ارائه‌دهنده VPS من بابت یک Tor bridge شکایت خواهد کرد؟

یک bridge نقطهٔ ورود است، بنابراین ترافیکی که از سرور شما خارج می‌شود به سایر relayهای شبکهٔ Tor می‌رود و هرگز به سایتی که کاربر انتخاب کرده است نمی‌رسد. آدرس IP شما در لاگ وب هیچ‌کس به‌عنوان منبع درخواست ظاهر نمی‌شود؛ این همان موضوعی است که باعث ایجاد شکایت برای اپراتورهای exit relay می‌شود. قوانین میزبانی همچنان متفاوت هستند و برخی ارائه‌دهندگان با هر سرویس Tor به‌عنوان یک مورد خاص برخورد می‌کنند، بنابراین پیش از شروع، سیاست استفادهٔ قابل‌قبول (AUP) را مطالعه کنید و آدرسی که بررسی کرده‌اید را در ContactInfo قرار دهید.

یک Tor bridge چقدر پهنای باند مصرف می‌کند؟

حداقل مقدار اعلام‌شده 1 مگابیت بر ثانیه برای آپلود و دانلود است، در حالی که این مقدار برای یک guard یا middle relay برابر با 10 مگابیت بر ثانیه است. مصرف واقعی نزدیک به صفر شروع می‌شود، زیرا bridge شما فقط ترافیک کاربرانی را حمل می‌کند که توزیع‌کننده به آن می‌فرستد. اگر می‌خواهید سقف مشخصی تعیین کنید، RelayBandwidthRate و RelayBandwidthBurst را در torrc تنظیم کنید.

چرا هیچ‌کس به bridge جدید من متصل نشده است؟

حدود سه ساعت طول می‌کشد تا یک bridge در Relay Search ظاهر شود و طبق راهنمایی Tor Project، جذب مجموعه‌ای پایدار از کاربران چندین روز یا هفته زمان می‌برد. بررسی کنید که descriptor منتشر شده باشد (این همان خط self-testing در journalctl -u tor@default است)، اثر انگشت (fingerprint) هش‌شدهٔ خود را در Relay Search جستجو کنید و مطمئن شوید که BridgeDistribution روی none تنظیم نشده باشد.

آیا باید obfs4 اجرا کنم یا WebTunnel؟

اگر این اولین bridge شماست، obfs4 را اجرا کنید: یک VPS، دو پورت، بدون دامنه و بدون گواهی. اگر در محیطی هستید که ترافیک‌های با ظاهر تصادفی مسدود می‌شوند، از WebTunnel استفاده کنید؛ زیرا این روش به دامنه‌ای که کنترل می‌کنید، یک وب‌سرور واقعی، یک گواهی TLS معتبر و حداقل 1 گیگابایت رم نیاز دارد. اگر هر دو را اجرا می‌کنید، آن‌ها را روی آدرس‌های مجزا قرار دهید، زیرا در غیر این صورت مسدود شدن یک IP باعث از دسترس خارج شدن هم‌زمان دو bridge می‌شود.

اگر بعداً پورت obfs4 را تغییر دهم چه اتفاقی می‌افتد؟

تمام خطوط bridge که قبلاً توزیع شده‌اند از کار می‌افتند. یک خط bridge آدرس، پورت، اثر انگشت و گواهی را به هم متصل می‌کند؛ بنابراین کاربری که خط قدیمی را دارد، اتصالی به پورتی برقرار می‌کند که هیچ سرویسی روی آن گوش نمی‌دهد و در نهایت تلاش خود را متوقف می‌کند. همین موضوع در مورد تغییر IP عمومی سرور نیز صدق می‌کند. پورت را در زمان راه‌اندازی انتخاب کنید و آن را تغییر ندهید.