Як запустити Tor relay на VPS: guard або middle

Що робить Tor relay на VPS

Tor relay — це демон Tor на машині з публічною IP-адресою, який пересилає зашифрований трафік для інших користувачів. Directory authorities публікують інформацію про нього, а клієнти Tor будують через нього ланцюжки. Guard relay або middle relay передає трафік лише іншому relay, тому не встановлює з’єднання з вебсайтом від імені сторонньої людини. Саме тому він не створює проблем зі скаргами на зловживання і підходить як внесок для звичайного VPS. Relay передає чужий трафік і не публікує власний контент. Якщо ви хочете розмістити власний сайт у мережі, а не пересилати для нього пакети, розгортання v3 onion service за nginx — це інше завдання для того самого tor daemon. Запуск relay також не забезпечує конфіденційність вашого власного вебперегляду. Це окрема проблема, і її можливості обмеженіші, ніж очікує більшість користувачів: що насправді приховує self-hosting SearXNG добре показує, наскільки розміщення сервісу на власному VPS змінює ситуацію.

Робота невелика: один пакет, п’ятнадцять рядків конфігурації, одне правило firewall і один restart. Решта цього посібника присвячена типовим проблемам. Йдеться про розрахунок пропускної здатності в тарифі з оплатою за обсяг трафіку та про причину, через яку абсолютно справний новий relay може залишатися непомітним протягом тижня.

Guard, middle, bridge чи exit: оберіть роль до встановлення

Один daemon виконує всі чотири ролі. Роль визначається вашою конфігурацією та directory authorities.

• Middle relay. Він отримує traffic від guard і передає його іншому relay. Він ніколи не підключається до сайту призначення. Кожен новий relay починає з цієї ролі.
• Guard relay. Це та сама конфігурація з додатковим flag. Directory authorities надають relay flag Guard, якщо він достатньо довго працює швидко та стабільно. Ви не обираєте цю роль. Її потрібно заслужити, а наведена нижче конфігурація допомагає це зробити.
• Bridge. Relay, який навмисно не публікується в загальному directory, а приватно передається користувачам у місцях, де Tor заблокований. Це найменший за обсягом зобов’язань варіант із чотирьох: низька пропускна здатність, відсутність у публічному directory і правильний перший крок, якщо ваш план невеликий. Поруч із daemon також має працювати proxy obfs4, а torrc потребує іншого набору рядків. У матеріалі налаштування bridge obfs4 на недорогому VPS описано цей процес, зокрема спосіб передати користувачам bridge line наприкінці.
• Exit relay. Останній hop, який відкриває підключення до сайту призначення. Кожен запит користувача виходить з вашої IP-адреси, тому повідомлення про зловживання та запити від поліції надходитимуть власнику цієї адреси.

Exit — єдина роль, яку не слід розміщувати на VPS загального призначення. Запускайте exit лише в провайдера, який заздалегідь погодився отримувати такі повідомлення, із власною IP-адресою та опублікованим abuse-контактом. Більшість стандартних умов хостингу це забороняє. Зазвичай ігнорування цієї вимоги призводить до призупинення роботи сервера та втрати IP-адреси. Якщо вам все одно потрібна саме ця роль, у матеріалі що насправді передбачає запуск exit relay описано пошук провайдера, лояльного до exit relay, налаштування exit policy і reverse DNS, а також обробку повідомлень після їх надходження. Guard або middle relay передає той самий traffic користувачів, але без такого рівня ризиків.

Усе нижче стосується guard/middle relay. ExitRelay 0 — це рядок, який залишає relay у цій ролі.

Що потрібно VPS перед початком

The Tor Project публікує жорсткі вимоги до relay. Станом на August 2026 вони такі: одна публічна IPv4-адреса для relay, пропускна здатність щонайменше 10 Mbit/s в обох напрямках, рекомендовано 16 Mbit/s, щонайменше 100 GB вихідного трафіку на місяць і 512 MB RAM за швидкості до 40 Mbit/s або 1 GB за вищої швидкості. Фіксованого правила щодо часу роботи немає, але relay, який працює менше двох годин на день, мало корисний для мережі.

Показник 10 Mbit/s описує пропускну здатність лінії, а не налаштування. Потрібен порт, який підтримує таку швидкість. Обсяг цієї пропускної здатності, який ви дозволите використовувати relay, — окреме рішення, що залежить від місячного ліміту передавання даних. Ознайомтеся зі своїм тарифним планом, перш ніж змінювати конфігурацію. Якщо ви ще обираєте сервер, у матеріалі скільки насправді коштує VPS на місяць пояснено, як продаються ліміти передавання даних, а матеріал як виміряти реальну пропускну здатність мережі VPS показує, як перевірити фактичну пропускну здатність лінії за допомогою iperf3 замість довіри до сторінки з описом тарифу.

Спочатку захистіть сервер. Relay — це публічний сервіс на публічній адресі, і цю адресу починають сканувати протягом кількох хвилин після публікації. Матеріал як обмежити SSH ключами та посиленою конфігурацією sshd допоможе виконати це за десять хвилин. Це потрібно зробити до запуску relay, а не після нього.

Встановлення tor з репозиторію Tor Project

Використовуйте власний apt-репозиторій Tor Project, а не пакет із репозиторію дистрибутива. Код relay оновлюється швидше, ніж стабільний реліз, тому виправлення спочатку потрапляють до цього репозиторію, а пакет дистрибутива відстає між релізами.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget

Додайте ключ підпису, а потім репозиторій. Codename зчитується з машини, тому цей самий блок працює в Ubuntu 24.04 (noble) і Debian 13 (trixie).

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

CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")
echo "$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: $CODENAME
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
tor --version

tor --version виводить версію, яку щойно встановлено. Якщо apt update натомість вивів помилку NO_PUBKEY, dearmored-ключ відсутній за шляхом, указаним у рядку Signed-By:, тому apt не має ключа для перевірки release-файлу. Пакет deb.torproject.org-keyring знадобиться пізніше: він постачає ключ підпису як звичайний пакет, тому apt продовжує працювати після ротації цього ключа.

Увімкніть автоматичні оновлення, а потім додайте нове джерело до їхньої конфігурації.

sudo apt install -y unattended-upgrades apt-listchanges

В Ubuntu додайте джерело Tor до блоку Allowed-Origins у файлі /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "TorProject:${distro_codename}";
};

У Debian той самий файл використовує Origins-Pattern. Додайте рядок "origin=TorProject";. Перевірте результат за допомогою sudo unattended-upgrade --debug --dry-run: команда виводить джерела, до яких вона застосовуватиметься, і нічого не записує.

Конфігурація torrc, яка має значення

Пакет встановлює великий файл /etc/tor/torrc із численними коментарями. Для relay важливі лише кілька рядків. Додайте їх у кінець файлу.

Nickname mynicerelay
ContactInfo relay-ops[at]example.com
ORPort 9001
ExitRelay 0
SocksPort 0

Nickname має містити від 1 до 19 символів, лише літери та цифри. Це ім’я не є унікальним у мережі й не є вашою ідентичністю — нею є fingerprint. За цим ім’ям ви шукатимете власний relay у пошуковому полі, тому виберіть назву, яку легко продиктувати телефоном.

ContactInfo публікується в descriptor relay. Це загальнодоступний документ, який може завантажити будь-хто, тому адресу збиратимуть автоматично. Використовуйте адресу, яку ви читатимете й через два роки, і за потреби замаскуйте її. Це єдиний канал, через який Tor Project може попередити вас про проблему з relay.

ORPort 9001 — це порт, до якого підключаються інші relay і клієнти. Порт 9001 є стандартним вибором. Інший поширений варіант — порт 443, оскільки деякі мережі з обмеженнями дозволяють лише вихідні підключення до 443. Тому relay, який слухає цей порт, буде доступний більшій кількості клієнтів. Обирайте 443 лише тоді, коли інші служби на сервері його не використовують.

SocksPort 0 вимикає локальний SOCKS proxy, який relay не використовує, і прибирає один listening socket із системи. ExitRelay 0 явно записує цей намір у файл: цей relay ніколи не підключатиметься до destination від імені користувача. Тому тому, хто пізніше читатиме конфігурацію, не доведеться визначати це за замовчуванням.

Якщо VPS має IPv6-адресу, додайте другий рядок ORPort. Tor не може прив’язатися до "any" IPv6-адреси так само, як до IPv4, тому вкажіть адресу в квадратних дужках.

ORPort 9001
ORPort [2001:db8::1]:9001

На VPS із 1 GB RAM додайте MaxMemInQueues 512 MB. Tor визначає ліміт черги за обсягом пам’яті, яку бачить у системі. На невеликому спільному сервері цей ліміт може бути більшим, ніж потрібно. Якщо задати ліміт вручну, tor під навантаженням відкидатиме клітинки в черзі. Relay продовжить працювати, замість того щоб збільшувати чергу, доки kernel не завершить процес.

Відкрийте ORPort у брандмауері

Для вхідних з’єднань ORPort має бути доступним з будь-якої точки інтернету. Для вихідних з’єднань залиште relay без обмежень: він встановлює з’єднання з тисячами інших relay через багато різних портів, а список дозволених вихідних з’єднань непомітно суттєво обмежить його роботу.

sudo ufw allow 9001/tcp comment 'tor ORPort'
sudo ufw status verbose

Потім перевірте власний мережевий брандмауер провайдера. Багато панелей керування запускають фільтр пакетів перед віртуальною машиною. Тому правило, додане через ufw, не діє на цьому рівні: порт виглядає відкритим на сервері, але закритим ззовні. Якщо ви раніше не працювали з ufw, у статті правила ufw, які потрібні на кожному VPS описано політику за замовчуванням і порядок перевірки правил.

Розрахуйте пропускну здатність відповідно до вашого тарифу

У посібнику RelayBandwidthRate описано як окреме token bucket, яке обмежує «середнє використання вхідної пропускної здатності для ретрансльованого трафіку на цьому вузлі до вказаної кількості байтів за секунду, а середнє використання вихідної пропускної здатності — до такого самого значення». Прочитайте це ще раз. Обмеження застосовується до кожного напрямку окремо. Relay, налаштований на 1 Mbit/s, може одночасно передавати 1 Mbit/s на вхід і 1 Mbit/s на вихід, а провайдер, який обліковує обидва напрямки, виставляє рахунок за їхню суму.

[
  {
    "label": "1 Mbit/s",
    "torrc_rate": "125 KBytes",
    "gb_per_day": 21.6,
    "gb_per_month": "648"
  },
  {
    "label": "2 Mbit/s",
    "torrc_rate": "250 KBytes",
    "gb_per_day": 43.2,
    "gb_per_month": "1,296"
  },
  {
    "label": "5 Mbit/s",
    "torrc_rate": "625 KBytes",
    "gb_per_day": 108,
    "gb_per_month": "3,240"
  },
  {
    "label": "10 Mbit/s",
    "torrc_rate": "1250 KBytes",
    "gb_per_day": 216,
    "gb_per_month": "6,480"
  },
  {
    "label": "20 Mbit/s",
    "torrc_rate": "2500 KBytes",
    "gb_per_day": 432,
    "gb_per_month": "12,960"
  }
]

Ці 5 рядків містять арифметичні розрахунки, а не результати вимірювань: вони показують, скільки трафіку накопичиться за певної швидкості, якщо relay підтримує її протягом усіх 30 днів в обох напрямках. Реальний relay більшу частину часу працює нижче свого ліміту, особливо протягом перших тижнів. Використовуйте таблицю, щоб відкинути налаштування, які не вкладаються в доступний обсяг, а не для прогнозування рахунку з точністю до гігабайта.

За швидкості 1 Mbit/s у кожному напрямку relay передає приблизно 21.6 GB на день, тому за 30-денний місяць це становить близько 648 GB тарифікованого трафіку. Цього достатньо для тарифу з лімітом 1 TB, і залишиться запас для оновлень та резервних копій. Якщо збільшити швидкість до 2 Mbit/s, за місяць буде використано 1,296 GB, що вже перевищує тариф із лімітом 1 TB. Для останнього рядка, 20 Mbit/s, потрібно 12,960 GB на місяць, тому його слід використовувати на порту без обмеження трафіку. Якщо провайдер обліковує лише вихідний трафік, поділіть кожне значення навпіл. З’ясуйте умови свого тарифу до встановлення швидкості, оскільки ці два варіанти відрізняються вдвічі.

Тепер перейдемо до конфігурації. Спочатку обмеження швидкості, потім квота.

RelayBandwidthRate 125 KBytes
RelayBandwidthBurst 250 KBytes
AccountingMax 400 GBytes
AccountingRule sum
AccountingStart month 1 00:00

RelayBandwidthBurst — це розмір token bucket, тому він дозволяє короткочасні сплески вище встановленої швидкості, якщо середнє значення залишається в межах ліміту. Розмір, приблизно вдвічі більший за швидкість, є обґрунтованим значенням.

AccountingRule — це рядок, який найчастіше пропускають. Значення за замовчуванням — max. Воно порівнює з квотою більший із двох напрямків. За такого значення AccountingMax 400 GBytes дозволяє 400 GB вхідного та 400 GB вихідного трафіку, тобто 800 GB за умови обліку обох напрямків. AccountingRule sum додає операції читання та запису й зараховує їх до однієї квоти. Саме це відповідає фактичному обліку використаного обсягу трафіку.

Також вкажіть AccountingStart, а не залишайте лише AccountingMax. Квота визначає обсяг, а рядок start визначає період її скидання. Квота без періоду залишає relay у режимі гібернації, оскільки немає події, яка могла б його відновити.

Гібернація є грубим механізмом. Коли квоту вичерпано, tor записує це в журнал і припиняє приймати роботу:

Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted

Relay не відновлює роботу точно на початку наступного періоду. Tor відстежує, наскільки швидко було використано попередню квоту, і вибирає випадковий момент у межах нового інтервалу. Це запобігає одночасному поверненню тисяч relay у мережу. Relay, який зникає на останній тиждень кожного місяця, постійно втрачає стабільність, за якою його оцінюють directory authorities. Налаштуйте RelayBandwidthRate так, щоб ліміт ніколи не досягався, а AccountingMax залиште як резервний захист від перевищення обсягу в рахунку.

Запустіть relay і перевірте, чи доступний він

sudo systemctl restart tor@default
sudo systemctl status tor@default
sudo journalctl -u tor@default -n 50

Протягом кількох хвилин журнал має містити цей рядок:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

Це повідомлення означає, що інші relay підключилися до вашого ORPort і побудували через нього circuit. Поки цей рядок не з’явиться, relay ще немає в directory, і він взагалі не передає трафік. Помилка виглядає так:

Your server has not managed to confirm reachability for its ORPort(s) at 203.0.113.10:9001. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

Перевіряйте все по черзі. Чи відкритий ORPort у ufw? Чи відкритий він також в окремому мережевому firewall вашого провайдера? Чи є адреса в цьому повідомленні адресою, на яку вас фактично маршрутизує інтернет, а не приватною адресою з конфігурації NAT? Перевірте порт з іншої машини за допомогою nc -vz 203.0.113.10 9001. Tor самостійно повторює self-test, тому виявить виправлену конфігурацію firewall без додаткових дій, а перезапуск дає змогу виконати перевірку негайно.

Постійний ідентифікатор вашого relay — це його fingerprint:

sudo cat /var/lib/tor/fingerprint

Приблизно через три години після публікації descriptor relay з’явиться в Relay Search. Виконайте пошук за nickname або вставте fingerprint. Ця сторінка показує, як мережа бачить ваш relay: які flags він має, яку weight йому надають authorities і яку версію він публікує.

Чому новий ретранслятор Tor майже не отримує трафіку?

Тому що мережа ще не виміряла його, а вимірювання триває кілька тижнів. Tor Project описує цей процес у чотири етапи, але оператор, який не ознайомився з ним, робить висновок, що ретранслятор зламаний, і починає змінювати налаштування.

Перші три дні ретранслятор не має виміряної пропускної здатності. Він повідомляє результат власного самотестування, але directory authorities все одно обмежують опубліковану вагу значенням 20 KB, тому клієнти майже ніколи його не обирають. Приблизно з третього до восьмого дня bandwidth authorities вимірюють його фактичну пропускну здатність, і вага зростає. Однак ретранслятор використовують лише як middle hop, оскільки жоден клієнт не готовий зробити щойно створений ретранслятор першим вузлом у ланцюжку.

Приблизно на восьмий день ретранслятор отримує право на прапорець Guard. Після отримання цього прапорця трафік зменшується, що дивує багатьох операторів: під час вибору middle hop клієнти пропускають guard-вузли, припускаючи, що guard уже зайнятий. Тому ретранслятор втрачає middle-трафік раніше, ніж починає отримувати guard-трафік. Трафік відновлюється лише в міру того, як клієнти змінюють свої набори guard-вузлів, а це триває кілька тижнів. Приблизно на 68-й день досягається стабільний стан: кількість клієнтів, які перестають використовувати ретранслятор, урівноважується кількістю клієнтів, які починають його використовувати.

Тому реалістичні очікування такі: протягом перших трьох днів — нічого, через тиждень — певний трафік, а через два місяці — помітне навантаження. Змініть одне налаштування, а потім зачекайте тиждень, щоб оцінити результат. Сторінка стану self-hosted Uptime Kuma із TCP-перевіркою порту 9001 — кращий спосіб використати це занепокоєння: вона відповідає на запитання, яке ви справді можете контролювати, а саме чи продовжує порт приймати з’єднання.

Перегляд relay за допомогою nyx

nyx — це термінальний монітор для запущеного relay. Він взаємодіє з control port Tor, тому спочатку увімкніть його у torrc:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort прослуховує лише 127.0.0.1, а cookie authentication означає, що програма повинна прочитати секретний файл, перш ніж зможе виконувати команди. Tor записує цей cookie у /run/tor/control.authcookie від імені користувача debian-tor з mode 600, тому інші користувачі не можуть його прочитати. CookieAuthFileGroupReadable 1 відкриває доступ до нього для групи. Завдяки цьому ваш обліковий запис може запускати nyx без sudo.

sudo apt install -y nyx
sudo adduser "$USER" debian-tor
sudo systemctl restart tor@default

Вийдіть із системи та увійдіть знову, а потім запустіть nyx. Нова група має бути застосована під час входу, тому запуск nyx у тому самому сеансі shell спричинить помилку доступу до cookie file, навіть якщо конфігурація правильна. nyx показує поточну пропускну здатність, час роботи, потік журналу та список з’єднань. У перші тижні стежте за тим, щоб графік пропускної здатності залишався нижче вашого RelayBandwidthRate.

Запуск кількох relay: MyFamily і family keys

Якщо у вас лише один relay, пропустіть цей розділ. Два або більше relay, якими керує один оператор, мають оголосити один одного. Це не дає клієнтам побудувати circuit, який входить у вашу мережу та виходить із неї через ваші машини. Інакше один оператор міг би бачити обидва кінці цього circuit.

Тривалий час для цього використовували MyFamily у torrc кожного relay, указуючи fingerprint усіх інших relay:

MyFamily AAAAAAAAAA,BBBBBBBB

Кожен relay указує всі інші relay. Тому додавання четвертого relay потребує редагування чотирьох файлів. У Tor 0.4.9 цей підхід замінили family key. Згенеруйте один key, а потім поширте його:

tor --keygen-family myfamily

Ця команда записує myfamily.secret_family_key і виводить рядок FamilyId. Скопіюйте файл key на кожен relay у підкаталог keys каталогу DataDirectory (/var/lib/tor/keys у Debian і Ubuntu), зберігши суфікс .secret_family_key. Додайте виведений рядок FamilyId до кожного torrc і виконайте reload за допомогою sudo systemctl reload tor@default. Поки що також залиште список MyFamily. Клієнти, які ще не підтримують family certificates, продовжують читати legacy list. Tor Project повідомить, коли його можна буде видалити.

Що ламається після запуску

Версія застаріває. Unattended upgrades замінює пакет, але запущений процес продовжує використовувати binary, з яким його було запущено, доки щось не перезапустить процес. Порівняйте tor --version на сервері з версією, указаною на сторінці Relay Search ретранслятора. Якщо вони відрізняються, мережа все ще бачить стару версію, тому перезапустіть service.

Годинник розходиться. Документи консенсусу та сертифікати мають обмежений строк дії, тому машина зі значно неточним часом відхиляє консенсус і припиняє публікацію. timedatectl має повідомляти, що системний годинник синхронізований. Якщо це не так, увімкніть systemd-timesyncd або встановіть chrony.

IP-адреса змінюється. Descriptor містить адресу, і клієнти не можуть підключитися до адреси, яка змінилася. Після міграції до іншого провайдера або будь-якої зміни адреси перезапустіть tor і знову стежте за рядком self-test.

Пропускна здатність ретранслятора нижча за передбачену тарифним планом. Криптографічні операції Tor ефективні на сучасних процесорах, а Tor Project оцінює пропускну здатність процесора з підтримкою AES-NI приблизно у 400–450 Mbit/s у кожному напрямку. Значно раніше за досягнення цієї межі обмеженням стають швидкість порту та доступний обсяг передавання даних. Саме тому наведений вище розділ про accounting важливіший за апаратне забезпечення.

FAQ

Скільки пропускної здатності використовує Tor relay?

Стільки, скільки ви дозволите, і не більше. RelayBandwidthRate окремо обмежує ретрансляційний трафік у кожному напрямку, тому relay із лімітом 1 Mbit/s може одночасно передавати 1 Mbit/s вхідного та 1 Mbit/s вихідного трафіку. Це становить приблизно 21.6 GB на день або 648 GB за місяць тривалістю 30 днів, якщо враховувати обидва напрямки. Додайте AccountingMax із AccountingRule sum як жорстку місячну квоту для цього ліміту.

Чи отримуватиму я скарги на зловживання, якщо запущу Tor relay?

Guard relay або middle relay передає трафік лише іншим Tor relay і не підключається до вебсайту від імені користувача. Тому скарги щодо дій, виконаних через Tor, надходять оператору exit relay, а не вам. Ви можете побачити сканування та окремі записи до IP reputation lists, оскільки адресу публічно вказано як relay. Саме exit relay отримують листи про зловживання та юридичні повідомлення. Їм потрібен провайдер, який заздалегідь погодився їх опрацьовувати. Перед запуском будь-якого з цих типів relay ознайомтеся з умовами вашого провайдера.

Чому мій новий Tor relay не отримує трафік?

Тому що нові relay навмисно обмежуються, доки їх не виміряють. Протягом перших трьох днів directory authorities обмежують опубліковану вагу значенням 20 KB, тому клієнти майже ніколи не вибирають такий relay. Bandwidth authorities починають вимірювати його приблизно з третього дня. Приблизно на восьмий день relay отримує право на прапорець Guard, після чого трафік знову зменшується, оскільки під час вибору middle hop клієнти уникають guard relay. Повне навантаження з’являється приблизно на 68-й день. Переконайтеся, що в журналі є повідомлення "Self-testing indicates your ORPort is reachable from the outside", а потім не втручайтеся в роботу relay.

Чи можна запустити Tor relay на VPS із лімітом передачі 1 TB?

Так, приблизно по 1 Mbit/s у кожному напрямку, що становить RelayBandwidthRate 125 KBytes. Якщо провайдер обліковує обидва напрямки, це приблизно 648 GB на місяць, і залишиться запас для оновлень та резервних копій. Додайте AccountingMax 400 GBytes із AccountingRule sum і AccountingStart month 1 00:00, щоб relay переходив у режим гібернації, а не перевищував ліміт тарифу. Якщо провайдер тарифікує лише вихідний трафік, ліміт можна подвоїти.

Чи потрібно налаштовувати MyFamily, якщо я запускаю лише один relay?

Ні. Оголошення сімейства потрібні для того, щоб клієнти не будували circuit через два relay, якими керує один оператор. Для одного relay це не має сенсу. Налаштуйте цей параметр одразу після додавання другого relay: вкажіть fingerprint кожного relay у рядку MyFamily кожного relay або використайте family key, який Tor 0.4.9 запровадив для передавання одного FamilyId замість списку, що постійно зростає.