Настройка сервера Shadowsocks начинается с конкретной реализации и совпадающего клиентского ключа. Универсального файла для любых проектов нет. Здесь фиксируется shadowsocks-rust, применяется один документированный метод 2022 и разграничиваются прокси отдельного приложения и охват всего устройства.

Ключевые выводы

Реализация, метод, ключ, адрес и транспорт должны совпадать.

Ключ 2022 не является произвольным запоминающимся паролем.

Проверяйте TCP и UDP отдельно, включая отказ неверному ключу.

Смена общего ключа отзывает всех клиентов со старым значением.

Что охватывает настройка сервера Shadowsocks?

По руководству об ответственности за свой узел спланируйте независимое управление и восстановление. Выбирая охват трафика, сравните полный туннель и прокси приложения. Пример затрагивает только явно настроенное тестовое приложение и управляемый слушатель UDP forwarding. Он не устанавливает TUN, не меняет общие маршруты и не предоставляет kill switch.

Обзор Shadowsocks объясняет границы протокола. Если обслуживание хоста не является вашей целью, сравните VPS и готовый выход. Парное развёртывание Hysteria2 использует иной UDP-транспорт и сертификаты; смешивать его поля с этой конфигурацией нельзя.

Применимость и доказательства: выделенный сервер Ubuntu 24.04 LTS x86-64, отдельный разрешённый Linux-клиент, публичный IPv4 и shadowsocks-rust v1.25.0 на обоих концах. Это Rust, а не Python, libev, панель или неназванное приложение. Сквозное авторское тестирование не заявлено. Ожидаемые результаты являются условиями приёмки читателем по официальным источникам. Другой архитектуре нужны соответствующие официальные файлы.［1］［2］［3］

Шаг 1: Сохраните доступ и установите сервер Shadowsocks Rust

Проверьте новое SSH-подключение и консоль провайдера независимо от прокси. Приватно запишите исходные слушатели, маршруты, DNS, владельцев межсетевых экранов, службы и расходы. Зарезервируйте TCP/UDP 8388 сервера, TCP 1080 и UDP 19001 клиента. При конфликте или существующем каталоге, unit либо пользователе shadowsocks-ops остановитесь, не присваивая чужой сервис.

Установите отсутствующие curl, ca-certificates, xz-utils и Python 3 из доверенных пакетов Ubuntu. В новом приватном рабочем каталоге загрузите точный официальный архив и соответствующую контрольную сумму. Выполняйте команды по одной и прекращайте работу при любой ошибке; до успешной проверки суммы ничего не распаковывайте и не запускайте.

umask 077
mkdir shadowsocks-1.25.0-reader
cd shadowsocks-1.25.0-reader
curl --fail --show-error --location \
  https://github.com/shadowsocks/shadowsocks-rust/releases/download/v1.25.0/shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz \
  -o shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz
curl --fail --show-error --location \
  https://github.com/shadowsocks/shadowsocks-rust/releases/download/v1.25.0/shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz.sha256 \
  -o shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz.sha256
sha256sum --check shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz.sha256

Сумма подтверждает совпадение с файлом официального выпуска, а не независимую подпись издателя. Дополнительно проверьте принадлежность проекта и доступное подтверждение происхождения. Просмотрите список архива на неожиданные пути, затем распакуйте без root. Бинарные файлы ожидаются в корне распаковки. При иной структуре остановитесь и исследуйте её, не угадывая команду привилегированного копирования.［1］［2］

tar -tf shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz
tar -xf shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz
./ssserver --version
./sslocal --version
./ssservice genkey -m "2022-blake3-aes-128-gcm"
sudo install -m 755 ssserver /usr/local/bin/ssserver-ops
sudo useradd --system --home /nonexistent --shell /usr/sbin/nologin shadowsocks-ops
sudo install -d -o root -g shadowsocks-ops -m 750 /etc/shadowsocks-ops

Обе команды версии должны показывать 1.25.0. Сохраните защищённые копии архива и сведений о проверке. Генератор выводит секрет: защищайте терминал и переносите значение прямо в менеджер паролей, не в публичное обсуждение или аргументы команд.

Шаг 2: Как выполняется настройка Shadowsocks 2022 с ключом?

Выбран точный метод 2022-blake3-aes-128-gcm. Поле password содержит Base64-представление 16-байтового ключа, сгенерированного для этого метода. Обычное получение ключа AEAD из пароля и ключи 2022 имеют разные контракты. Не подставляйте привычный пароль, ключ 256-битного метода, многопользовательскую форму с двоеточиями или значение по умолчанию другого проекта.［2］［4］

Создайте /etc/shadowsocks-ops/server.json редактором root и замените заполнитель сгенерированным ключом. Заполнитель намеренно не является рабочим ключом. Соблюдайте синтаксис JSON: в этом строгом примере комментарии недопустимы.

{
  "server": "0.0.0.0",
  "server_port": 8388,
  "method": "2022-blake3-aes-128-gcm",
  "password": "REPLACE_WITH_GENERATED_2022_KEY",
  "mode": "tcp_and_udp"
}

0.0.0.0 обозначает серверный слушатель, но не адрес назначения клиента. Нативный пример не использует TLS-сертификаты и плагины. Общий ключ является обязательным секретом аутентификации, а не закрытым ключом сертификата. Не переключайтесь на none, plain или устаревшие потоковые шифры ради подключения ошибочного клиента.

AEAD-2022 проверяет временные метки для защиты от повторов. Проверьте часы обоих хостов через доверенную службу времени; неисправные часы нужно исправить, а не отключать защиту протокола.［4］

Шаг 3: Запустите ограниченную службу и откройте её порты

Сохраните следующий unit в /etc/systemd/system/shadowsocks-ops.service. Высокий порт 8388 допускает непривилегированного пользователя службы без сетевой capability root или привилегированного контейнера.

[Unit]
Description=Dedicated Shadowsocks Rust reader deployment
After=network-online.target
Wants=network-online.target

[Service]
User=shadowsocks-ops
Group=shadowsocks-ops
ExecStart=/usr/local/bin/ssserver-ops -c /etc/shadowsocks-ops/server.json
Restart=no
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=strict

[Install]
WantedBy=multi-user.target

Сохраните правила SSH и посторонних служб. Сначала разрешите только источнику тестового клиента TCP и UDP 8388 у фактических владельцев облачного и хостового межсетевых экранов. Если согласованная политика допускает лишь TCP, отметьте UDP как недоступный, не как успешный. Не очищайте правила и не открывайте локальный SOCKS ради доступности сервера.

sudo chown root:shadowsocks-ops /etc/shadowsocks-ops/server.json
sudo chmod 640 /etc/shadowsocks-ops/server.json
sudo systemctl daemon-reload
sudo systemctl start shadowsocks-ops
sudo systemctl status shadowsocks-ops --no-pager
sudo ss -lntup

Ожидаются активная выбранная служба и оба слушателя IPv4 на 8388. При сбое оставьте вход закрытым, разграничьте JSON, неподдерживаемый метод или формат ключа, права файлов, архитектуру, часы и конфликты портов по приватному журналу. Успешная привязка не доказывает совпадение ключей или передачу прикладного трафика.

Шаг 4: Настройте клиент, проверьте TCP и отказ

На отдельном Linux-клиенте получите и проверьте подходящий выпуск той же версии, сохранив sslocal и ssservice. Замените ss.example.com реальным доступным IPv4 или доменом сервера. Любая опубликованная AAAA должна соответствовать отдельно спроектированному IPv6-пути. Метод и ключ должны быть теми же, что на сервере.

Для UDP нужен разрешённый эхо-ответчик под вашим управлением вместо udp-check.example.net:9001, доступный с сервера. Пример не обозначает публичный тестовый сервис. Без ответчика приёмка UDP остаётся неподтверждённой. Убедитесь, что сборка поддерживает документированную функцию local-tunnel; при неподдерживаемом протоколе остановитесь, не меняя реализацию.［2］

{
  "server": "ss.example.com",
  "server_port": 8388,
  "method": "2022-blake3-aes-128-gcm",
  "password": "REPLACE_WITH_GENERATED_2022_KEY",
  "locals": [
    {
      "protocol": "socks",
      "local_address": "127.0.0.1",
      "local_port": 1080,
      "mode": "tcp_only"
    },
    {
      "protocol": "tunnel",
      "local_address": "127.0.0.1",
      "local_port": 19001,
      "forward_address": "udp-check.example.net",
      "forward_port": 9001,
      "mode": "udp_only"
    }
  ]
}

SOCKS-слушатель намеренно работает только с TCP, а отдельная запись tunnel задаёт путь проверки прикладного UDP. Оба привязаны только к loopback. Запустите клиент в приватном каталоге и убедитесь, что слушателя для LAN не появилось.

chmod 600 client.json
./sslocal -c client.json

Явно выберите SOCKS5 127.0.0.1:1080 в тестовом браузере, включая разрешение имён через прокси, если поддерживается. Выполните новый HTTPS-запрос, проверьте видимый IP выхода и сравните с известным выходом сервера. Одного слушателя или индикатора «подключено» недостаточно.

Для отрицательной проверки остановите клиент и приватно скопируйте конфигурацию. Тем же генератором и методом создайте другой ключ правильного формата, измените только password копии, сохранив адрес и метод. Запустите профиль и новый запрос через прокси: трафик не должен проходить. Ошибка Base64 до обращения к серверу не доказывает серверный отказ. Если запрос работает, закройте вход и проверьте прямой обход, другой запущенный профиль и фактический ключ сервера.

Шаг 5: Проверьте UDP и запишите границы охвата

Вернитесь к правильному профилю. Отправьте один управляемый UDP echo через 127.0.0.1:19001. Команда читателя ожидает идентичную полезную нагрузку от разрешённого ответчика; наблюдавшийся вывод здесь не заявлен.

python3 - <<'CHECK'
import socket
with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as sock:
    sock.settimeout(3)
    sock.sendto(b"reader-check", ("127.0.0.1", 19001))
    data, _ = sock.recvfrom(1024)
    assert data == b"reader-check", "Unexpected UDP reply"
CHECK

Проверка	Ожидаемые доказательства читателя	При неудаче
Прикладной TCP	Новый HTTPS-запрос через прокси и нужный выход	Разделите браузер, ключ, выход сервера и назначение
Прикладной UDP	Эхо совпадает с отправленным пакетом	Проверьте туннель, оба UDP-правила, режим сервера и обратный путь
DNS	Разрешение приложения следует выбранной политике	Изучите локальный и удалённый DNS независимо от IP
IPv6	Применимые пути явно включены или исключены	IPv4 не доказывает защиту всего устройства
Отключение	Приложение отказывает или переключается на резервный путь строго по настройке	Прекратите чувствительные действия до проверки нужной политики
Открытый прокси	Неверный ключ не ретранслирует трафик; SOCKS остаётся loopback	Немедленно закройте вход и исправьте привязку или auth

Повторите такой же управляемый UDP-запрос с профилем неверного ключа: аутентифицированного ответа ретрансляции быть не должно. Сам по себе тайм-аут неоднозначен, поэтому используйте рабочий правильный ключ до и после отрицательного теста. Ограничение источника дополняет аутентификацию: если каждый запрос блокирует межсетевой экран, это отдельно не доказывает отказ по ключу.

Шаг 6: Меняйте ключ, восстанавливайте и выводите сервис из эксплуатации

Перезапустите сервер в разрешённое окно и повторите правильный и неверный ключ для TCP/UDP. Включайте автозапуск только после приёмки и подтверждения чтения защищённой конфигурации после перезагрузки.

Для отзыва закройте вход этого развёртывания, сгенерируйте новый ключ выбранного метода, замените серверное значение и перезапустите для завершения сеансов. Обновите лишь сохранённых клиентов. Базовая схема отзывает всех пользователей старого ключа, а не отдельную метку устройства. Запишите смену отдельно от архива; после следующего перезапуска старый ключ должен отклоняться, разрешённый клиент — работать.

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

sudo systemctl stop shadowsocks-ops
sudo install -d -m 700 /root/shadowsocks-backup-20261011
sudo cp -a /etc/shadowsocks-ops /root/shadowsocks-backup-20261011/
sudo cp -a /usr/local/bin/ssserver-ops /root/shadowsocks-backup-20261011/
sudo cp -a /etc/systemd/system/shadowsocks-ops.service /root/shadowsocks-backup-20261011/
sudo chmod -R go-rwx /root/shadowsocks-backup-20261011
sudo systemctl start shadowsocks-ops

С планом восстановления сохраните правила межсетевого экрана, клиентскую сборку, владельцев и режимы файлов, внешний журнал смены ключа. Зашифруйте архив до ограниченного хранения вне хоста: внутри есть ключ аутентификации, поэтому публичная или общедоступная копия недопустима.

Восстанавливайте на изолированной замене той же версии при закрытом входе. Верните бинарный файл и unit по указанным путям, создайте служебного пользователя, скопируйте каталог в /etc/shadowsocks-ops. До запуска восстановите каталог root:shadowsocks-ops с режимом 750, конфигурацию root:shadowsocks-ops с 640, бинарный файл 755, unit 644. Примените текущий ключ из отдельного журнала, перечитайте systemd, запустите службу. До открытия повторите положительные, отрицательные, UDP- и перезапусковые проверки: старый архив не должен оживить отозванный ключ.

При выводе закройте только TCP/UDP-правила сервиса, остановите и отключите shadowsocks-ops, остановите клиент, верните прежний прокси приложения. Убедитесь, что локальные слушатели 1080/19001 исчезли. После решения о хранении удалите лишь созданные unit, бинарный файл, каталог и пользователя; перечитайте systemd, отдельно рассмотрите DNS и облачные ресурсы. Проверьте новое SSH-подключение и исходные службы. Удаление не отменяет оплату; при неподтверждённом восстановлении остановите изменения.

Итоги

Согласуйте версию Rust, точный метод и сгенерированный ключ обоих концов.
Принимайте TCP, UDP, DNS, IPv6 и поведение при сбое отдельно.
Отклоняйте старые ключи после перезапуска и восстановления, удаляя только свои ресурсы.

Часто задаваемые вопросы (FAQ)

Подойдёт ли знакомый пароль для метода 2022?

Нет. Метод требует Base64-представления ключа заданной длины. Используйте генератор реализации с указанием метода и защищайте полученное значение как секрет.

Можно ли без изменений взять конфигурацию libev или Python?

Возможности и контракты реализаций различаются. Здесь Rust v1.25.0 фиксирован на обоих концах; совместимость другого варианта проверяется отдельно до смешивания примеров.

Доказывает ли работающий браузер поддержку UDP?

Нет. UDP требует своего режима клиента, настройки сервера, правил межсетевого экрана и управляемого ответчика. Записывайте его приёмку отдельно от браузерного запроса.

Защищены ли все приложения устройства?

Охвачены лишь явно настроенные приложения и показанный forwarding-слушатель. Маршрутизация всего устройства и kill switch требуют отдельного проекта и проверки.

Может ли сервер с одним ключом отозвать одно устройство?

В этой схеме все клиенты используют один серверный ключ. Его смена затрагивает каждого; отдельным идентичностям нужна другая поддерживаемая конфигурация и приёмка.

Означает ли открытый TCP-порт появление открытого прокси?

Доступность зашифрованного слушателя не доказывает ретрансляцию без разрешения. Проверьте отказ неверному ключу и привязку SOCKS, сохраняя контроль с правильным ключом.

Выполнил ли автор развёртывание и восстановление?

Сквозное тестирование не заявлено. Команды задают проверки читателя: до приёмки запишите фактические версии, разрешённые ресурсы, сеть, результаты и доказательства восстановления.

Источники:

shadowsocks-rust v1.25.0 — https://github.com/shadowsocks/shadowsocks-rust/releases/tag/v1.25.0
shadowsocks-rust v1.25.0 — README — https://github.com/shadowsocks/shadowsocks-rust/blob/v1.25.0/README.md
Shadowsocks — Deploying — https://shadowsocks.org/doc/deploying.html
Shadowsocks 2022 — Specification — https://shadowsocks.org/doc/sip022.html

Sources checked 11 октября 2026 г.

Рекомендуемые статьи:

Настройка сервера Shadowsocks: ключи и проверка трафика