Зачем хостить сайт в tor

28.09.2026 · 5 мин

Недавно наткнулся на статью Давида Альвареса Росы — он перенёс свой блог в сеть Tor. Не для того, чтобы торговать чем-то нелегальным. Просто потому что ему интересна эта технология и он хочет поддержать право людей на приватность.

И знаете что? Меня это зацепило. Потому что обычно, когда слышишь «Tor» или «dark web», в голове сразу возникают какие-то мрачные ассоциации. А тут обычный разработчик, который просто хочет контролировать свою инфраструктуру.

Давайте разберёмся, как это работает и стоит ли вам тоже попробовать.

Чем это отличается от обычного хостинга

Обычный сайт живёт в «открытом интернете» (clearnet). У него есть домен, DNS-запись, IP-адрес, SSL-сертификат. Любой может посмотреть, кто владеет доменом, и примерно понять, где стоит сервер.

Onion-сервис (так правильно называется то, что работает в Tor) устроен иначе:

CLEARNET vs TOR HIDDEN SERVICE
═══════════════════════════════════════════════════════════════
CLEARNET:
┌──────────┐    DNS Lookup    ┌──────────┐    HTTPS    ┌──────────┐
│  Client  │ ───────────────▶ │   DNS    │ ──────────▶ │  Server  │
└──────────┘                  └──────────┘             └──────────┘
   │                              │                       │
   └── WHOIS, SSL cert ──────────┘                       │
          видимо всё

TOR HIDDEN SERVICE:
┌──────────┐                              ┌──────────┐
│  Client  │                              │  Server  │
└────┬─────┘                              └────┬─────┘
     │ Tor                                  │ Tor
     ▼                                      ▼
┌──────────┐    relay    ┌──────────┐    relay    ┌──────────┐
│  Entry   │◀────────────│   Mid    │────────────▶│   Exit   │
│  Guard   │             │  Relay   │             │  Relay   │
└──────────┘             └──────────┘             └──────────┘
     │                                              │
     └─────────── Circuit (encrypted) ─────────────┘

         Адрес = хеш публичного ключа сервера
Сравнение обычной цепочки запроса с цепочкой через Tor. В Tor нет DNS и WHOIS, адрес сервиса — это производная от ключа

То есть вы получаете бесплатное шифрование и анонимность «из коробки». Не надо покупать сертификаты, не надо париться о DNS.

Как это настраивается

Автор статьи описывает настройку для nginx. Выглядит это так:

  1. Устанавливаете Tor
  2. В конфиге /etc/tor/torrc указываете:
    • Директорию, где Tor будет хранить ключи (она должна принадлежать пользователю debian-tor)
    • Порт, на который проксировать запросы
  3. Tor генерирует адрес вроде dhevt6e4rtgbtr3jh53xrpwmgtilkah6onion. Этот адрес записывается в файл hostname — и всё, сервис доступен.
  4. nginx слушает локально на порту 8080 (только localhost!), никакого TLS — Tor и так шифрует.
server {
    listen 127.0.0.1:8080;
    server_name dhevt6e4rtgbtr3jh53...onion;
    root /srv/tor.david.alvarezrosa.com;
}

Всё. Рестартуете Tor, перезагружаете nginx — и сайт уже в сети.

Подводный камень: статические сайты

Тут начинается интересное. Статический генератор сайта (Hugo в случае автора) зашивает базовый URL в HTML-файлы при сборке. Если вы собираете сайт для clearnet, все ссылки будут указывать на обычный домен. Пользователи Tor будут кликать и перенаправляться… правильно, на обычный интернет.

Решение: билд-пайплайн запускает две сборки — одну для clearnet, одну для onion-сервиса, с разными --baseURL. Две директории, два деплоя, rsync синхронизирует контент.

$ hugo --minify --baseURL="http://dhevt6e4rtgbtr3jh53...onion/"

Это не rocket science, но требует автоматизации. Без неё вы будете постоянно забывать пересобирать Tor-версию.

Честные ограничения

Не буду приукрашивать. Tor — это компромиссы.

Скорость. Tor медленнее обычного интернета. Трафик проходит через несколько релеев, каждый слой шифрования добавляет задержку. Это не веб-приложение, которое должно отдавать контент за 200 мс.

Доступность. Пользователю нужен установленный Tor Browser. Это барьер. Большинство людей не будут его ставить ради вашего блога.

Мониторинг. Если ваш сервис упадёт, вы не узнаете об этом через обычные инструменты. Tor не интегрируется с привычным стеком.

Когда это оправдано: политическая организация, которая боится цензуры; журналист, работающий с чувствительными источниками; разработчик, который хочет поэкспериментировать с приватностью. Для обычного блога с рецептами — overkill.

КОГДА ИМЕЕТ СМЫСЛ vs КОГДА НЕТ
═══════════════════════════════════════════════════════════════
ИМЕЕТ СМЫСЛ:
│ Активизм и борьба за свободу слова         │
│ Журналистика и защита источников            │
│ Приватный доступ к своим сервисам           │
│ Образовательные проекты о сетевой безопасности│

НЕ ИМЕЕТ СМЫСЛ:
│ Обычный блог или портфолио                   │
│ E-commerce с платежами                       │
│ Приложения, требующие низкой задержки        │
│ Проекты, где важна discoverability (SEO)     │

КЛЮЧЕВОЕ: Tor не про "скрытность", а про "анонимность"
Это разные вещи.
Две стороны использования Tor: технология хороша, но подходит не для всех задач

Моя оценка

Мне нравится подход Давида. Он не превращает это в цирк с конями — не кричит «мы в dark web!», не использует это как маркетинг. Для него это инженерная задача: есть инструмент, у него есть плюсы и минусы, давайте разберёмся.

Технически статья грамотная. Правильно, что автор подчёркивает: не пытайтесь смешивать onion-директорию с вашим веб-рутом — Tor требует владеть своими ключами. Правильно, что упомянул Tor Project и призвал поддержать их.

Из минусов: статья предполагает, что читатель уже знаком с базовым администрированием Linux. Для новичка тут будет непонятно. Но это нормально — не каждую статью нужно писать для всех.

Практический вывод: если вы давно хотели попробовать onion-сервис — попробуйте. Поставьте Tor, поднимите что-нибудь простое, посмотрите, как это ощущается. Это не так страшно, как кажется. Но не делайте это основным каналом для чего-то, что требует массовой аудитории. Для этого Tor просто не создан.

Выводы

Tor — хороший инструмент для приватности, экспериментов и проектов, где анонимность важнее удобства. Но он медленнее, сложнее в поддержке и не подходит для массового доступа.

Если вам нужен опыт, понимание и контроль над инфраструктурой — попробовать стоит. Если нужна широкая аудитория и SEO — лучше остаться в обычном интернете.

Ссылки

Дмитрий Полухин — продуктовый дизайнер. Пишу про разработку, AI и дизайн интерфейсов. Обо мне, контакты и профили.