Outline VPN или Shadowsocks: что выбрать

MAATRIX

Нужно поднять сервер для обхода блокировок, но непонятно, ставить ли Outline с красивым менеджером или разворачивать Shadowsocks вручную командами. На первый взгляд это разные инструменты, хотя по факту Outline — это Shadowsocks с обвязкой: тот же протокол внутри, но другой опыт установки и раздачи доступов. Разберёмся, где заканчивается сходство и начинается разница, которая реально влияет на выбор.

Что на самом деле скрывается под капотом Outline

Outline Server, который делает команда Jigsaw (подразделение Google), — это Docker-контейнер с процессом shadowsocks-libev внутри плюс собственный management API поверх него. Когда вы разворачиваете Outline через официальный скрипт, на сервере поднимается два порта: один — сам туннель для клиентов, второй — защищённый API на случайном порту с самоподписанным сертификатом, через который Outline Manager на вашем компьютере создаёт, удаляет и переключает пользователей.

Ключевая идея Outline — управление ключами доступа как отдельными объектами: у каждого пользователя свой порт и свой пароль, с индивидуальным лимитом трафика при необходимости, и всё это без единой команды в терминале — только клики в Outline Manager. Клиентские приложения (Outline Client) есть под все платформы и по сути представляют собой обёртку над shadowsocks-клиентом с генерацией ss:// ссылки из QR-кода или текста.

Из этого следует главное: Outline не добавляет ничего нового в протокол шифрования — это тот же AEAD-шифр (по умолчанию chacha20-ietf-poly1305), что и в чистом Shadowsocks. Разница целиком в слое управления и удобства, а не в устойчивости к блокировкам или скорости.

Что вы получаете с голым Shadowsocks

Ручная установка Shadowsocks (через shadowsocks-libev или Rust-реализацию shadowsocks-rust) даёт полный контроль над каждым параметром: метод шифрования, порт, таймауты, плагины обфускации, mode (tcp_and_udp), fast_open. Конфиг — это один JSON-файл:

{
  "server": "0.0.0.0",
  "server_port": 8388,
  "password": "замените-на-длинный-пароль",
  "method": "chacha20-ietf-poly1305",
  "mode": "tcp_and_udp",
  "timeout": 300
}

Запуск через systemd, без Docker, без лишнего процесса-прослойки, без API на отдельном порту. Если у вас один пользователь (вы сами) или несколько человек, которым проще один раз прислать ss:// ссылку в мессенджере, чем объяснять, как ставить Outline Manager, — голый Shadowsocks выигрывает по простоте инфраструктуры: меньше процессов, меньше точек отказа, меньше зависимостей от Docker Hub при обновлениях образа.

Второй плюс — гибкость с плагинами обфускации. К голому Shadowsocks можно подключить obfs-plugin или v2ray-plugin, чтобы завернуть трафик под HTTPS или WebSocket и усложнить DPI-детекцию. Outline такой плагин напрямую не поддерживает — его архитектура заточена под стандартный SIP002-профиль без дополнительной прослойки, и добавить obfs-plugin в контейнер можно только руками, вне штатного сценария, что ломает совместимость с Outline Manager.

Установка: сколько шагов и что нужно на сервере

Таблица показывает разницу в требованиях к серверу и в количестве действий:

Если у вас уже есть пошаговая установка Outline через Docker, она подробно разобрана в статьях про установку Outline на Ubuntu 24.04 через Docker и на Debian 12. Для голого Shadowsocks — отдельная инструкция как установить и настроить Shadowsocks на VPS, там разобран сам процесс без Docker-обвязки.

На практике время до первого рабочего подключения у Outline меньше — один скрипт, который сам ставит Docker, если его нет, поднимает контейнер и в конце печатает ss:// ссылку для первого доступа. У Shadowsocks придётся вручную поставить пакет, отредактировать JSON, включить systemd-юнит и сгенерировать ссылку самому (или через связку с shadowsocks-qr).

Управление пользователями: один человек или команда

Если сервер только для вас — разница в управлении почти не ощущается: что там менять один пароль в JSON, что один ключ в Outline Manager. Разница проявляется, когда пользователей больше двух-трёх.

Outline Manager даёт:

• добавление/удаление ключа доступа без остановки сервиса остальным пользователям (каждый ключ — свой порт и пароль, поэтому отключить одного не задевает других);
• переименование ключей понятными именами («Иван», «бухгалтерия», «резервный»);
• лимит трафика на ключ (полезно, если делите один сервер с коллегами и хотите избежать перекоса потребления);
• визуальную статистику по трафику за период, без парсинга логов вручную.

Голый Shadowsocks с одним конфигом — это один пароль на всех, либо несколько экземпляров ss-server на разных портах, если нужна изоляция пользователей. Второй вариант технически возможен (несколько systemd-юнитов с разными портами и конфигами), но управляется руками: добавить пользователя — значит создать новый юнит-файл, открыть порт в firewall, перезапустить демон.

Для нетехнической команды (менеджеры, маркетологи, кто угодно без опыта работы в терминале) Outline снимает необходимость объяснять, что такое JSON и как перезапустить systemd-сервис — люди просто получают ссылку или QR-код и открывают её в Outline Client. Для DevOps-команды, которая и так работает через терминал, эта разница не так критична, а вот гибкость obfs-плагинов может оказаться важнее.

Производительность и накладные расходы

По самому протоколу разницы в скорости нет — оба используют одну и ту же реализацию shadowsocks-libev (или совместимую) под капотом, один и тот же AEAD-шифр. Разница — в накладных расходах инфраструктуры вокруг:

• Docker добавляет слой виртуализации сети (обычно bridge-режим с NAT), что на слабых VPS (1 vCPU, 512 МБ - 1 ГБ RAM) может давать заметный прирост задержки по сравнению с процессом, запущенным напрямую в hostNetwork;
• management API Outline держит отдельный TLS-listener постоянно активным, даже если вы не открываете Outline Manager неделями — это фоновая нагрузка, обычно небольшая, но она есть;
• при большом числе одновременных подключений (десятки пользователей) многопортовая архитектура Outline (каждый ключ = отдельный слушающий сокет) расходует больше файловых дескрипторов, чем один процесс ss-server с несколькими паролями через plugin.

На практике для 1-15 пользователей разница в производительности едва ли будет заметна на глаз — упрётесь скорее в канал самого сервера или в ограничения провайдера, чем в накладные расходы Docker. Ориентируйтесь на этот порядок величин, а не на точные цифры — на конкретном железе и с конкретным провайдером результат у вас будет отличаться.

Что касается устойчивости к блокировкам — оба варианта одинаково уязвимы к активному DPI-анализу трафика по статистическим признакам, если используется голый Shadowsocks-профиль без обфускации. Здесь у голого Shadowsocks преимущество за счёт совместимости с obfs-plugin/v2ray-plugin — если в вашем регионе провайдер блокирует именно паттерн Shadowsocks, Outline такую защиту штатно не даёт. Сравнение самого протокола с альтернативой разобрано в статье Shadowsocks или VLESS: что выбрать — если DPI в вашем регионе агрессивный, стоит сначала прочитать её.

Безопасность и обновления

Outline автоматически подтягивает образ контейнера при переустановке, но не обновляет его сам по расписанию — обновление версии shadowsocks-libev внутри контейнера требует пересоздания контейнера с новым тегом образа вручную (docker pull + docker compose up -d заново, либо повторный запуск install-скрипта). Голый Shadowsocks обновляется штатным менеджером пакетов (apt update && apt upgrade shadowsocks-libev), что для многих проще встроить в общий цикл обновления сервера.

Отдельный момент — поверхность атаки. У Outline это Docker-демон (запущен от root, слушает unix-сокет) плюс management API на отдельном порту с самоподписанным сертификатом — если порт API случайно остаётся открытым наружу без ограничения по IP, это дополнительная точка входа, которой нет у голого Shadowsocks. Проверьте, что порт API закрыт файрволом для всех, кроме вашего IP:

ufw allow from ВАШ_IP to any port ПОРТ_API proto tcp
ufw deny ПОРТ_API/tcp

Порт клиентского туннеля у обоих вариантов открыт всем — это нормально, так и должно быть, риск не в этом, а именно в непреднамеренно открытом API-порту управления.

Если сомневаетесь между Shadowsocks и другим протоколом для конкретно вашей задачи обхода блокировок, полезно сравнить и с WireGuard/OpenVPN — там другая модель угроз и другие компромиссы, разбор есть в статье WireGuard или OpenVPN: что выбрать для сервера.

Частые вопросы