راه اندازی 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 Project

بسته‌های توزیع‌شده در مخازن رسمی معمولاً قدیمی هستند و یک 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 Project از آن نسخه پشتیبانی نمی‌کند. فایل /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 خود را به‌جای اجماع عمومی (public consensus)، به bridge authority ارسال کند. همین یک خط باعث می‌شود relay شما در لیست عمومی قرار نگیرد.

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

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

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

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

ContactInfo و Nickname هر دو عمومی هستند. آدرسی را وارد کنید که به آن دسترسی دارید، زیرا 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

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

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

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

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

هر دو پورت باید باز باشند. اکثر ارائه‌دهندگان سرویس، یک فایروال دوم در پنل مدیریتی خود دارند که ufw از آن بی‌اطلاع است. قانونی که روی سرور تعریف شده اما در پنل اعمال نشده باشد، منجر به ایجاد پلی می‌شود که هرگز در دسترس نخواهد بود و هیچ توصیف‌گری را منتشر نمی‌کند. اگر هر یک از این دو بخش برای شما تازگی دارد، قوانین ufw مورد نیاز برای یک VPS تازه و مفهوم واقعی پورت listening در لینوکس را مطالعه کنید. در همان حین، دسترسی SSH را با کلید و پیکربندی سخت‌گیرانه sshd محدود کنید. یک پل ثبت‌نشده روی سروری که از رمز عبور برای 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'

خط اول به این معنی است که تست دسترسی با موفقیت انجام شده و 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> را با اثر انگشت (fingerprint) هویتی که tor در دایرکتوری داده‌های خود نوشته است، جایگزین کنید:

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

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

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

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

• فرم وب در bridges.torproject.org/options که پس از حل یک کپچا، خطوط پل را ارائه می‌دهد.
• ارسال ایمیل به bridges@torproject.org از یک آدرس Gmail یا Riseup که در پاسخ، خطوط پل را برای شما می‌فرستد. محدودیت ارائه‌دهنده ایمیل به این دلیل اعمال شده است که حساب‌های رایگان نامحدود به یک سانسورچی اجازه می‌دهد تمام پل‌ها را فهرست کند.
• ربات تلگرام @GetBridgesBot. دستور /start و سپس /obfs4 یا /webtunnel را ارسال کنید.
• خودِ Tor Browser، در بخش Settings و سپس Connection، که در آن گزینه "Request bridges" پل‌ها را از طریق کانال moat دریافت می‌کند.

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

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

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

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

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

برنامه obfs4proxy نمی‌تواند روی پورت 443 متصل شود. قابلیت آن را با 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 به عنوان یک مورد خاص برخورد می‌کنند، بنابراین پیش از شروع، سیاست استفاده قابل‌قبول را مطالعه کنید و آدرسی که بررسی می‌کنید را در ContactInfo قرار دهید.

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

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

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

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

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

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

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

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