Shadowsocks на сервере: частые ошибки и решения

MAATRIX

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

С чего начинать

При любой проблеме первым делом смотрите статус сервиса и его журнал: там видно, поднялся ли сервер и не падает ли он с ошибкой.

systemctl status shadowsocks-libev
journalctl -u shadowsocks-libev -n 40 --no-pager

Дальше проверьте, слушает ли сервер нужный порт и на каком адресе. Это отсекает половину гипотез: если процесс не слушает порт, проблема на сервере; если слушает, но снаружи не отвечает — проблема в фаерволе или на стороне клиента.

ss -lntup | grep 8388

Приучите себя к этой связке: статус, лог, слушающий порт. Она за минуту показывает, на каком этапе рвётся цепочка, и дальше вы чините конкретное звено, а не всё сразу.

Клиент не подключается

Самая частая жалоба. Причин несколько, и они легко проверяются. Первое и главное — несовпадение параметров: метод шифрования, порт и пароль на клиенте должны в точности совпадать с конфигом сервера. Опечатка в методе (например, aes-256-gcm против aes-256-cfb) или лишний пробел в пароле рвут подключение без внятной ошибки. Второе — закрытый порт во внешнем фаерволе облака: сервис слушает, но security groups провайдера не пропускают трафик. Третье — сервер слушает только localhost из-за неверного server в конфиге; для внешних подключений там должно быть 0.0.0.0. Проверьте доступность порта снаружи с другой машины и сверьте все три параметра — в подавляющем большинстве случаев виновато именно одно из этого.

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

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

Сервис не стартует

Сервер не поднимается или падает сразу после запуска. Обычно причина — ошибка в JSON-конфиге: пропущенная запятая, лишняя скобка, неверная кавычка. Shadowsocks строг к формату и при битом JSON просто не стартует. Проверьте синтаксис конфига любым валидатором JSON или внимательно перечитайте /etc/shadowsocks-libev/config.json. Вторая причина — занятый порт: если на нём уже что-то слушает, сервер не поднимется. Найдите конфликт:

ss -lntp | grep 8388

Третья причина — указан метод шифрования, которого нет в вашей версии библиотеки. Если в логе жалоба на неизвестный method, замените его на актуальный aes-256-gcm или chacha20-ietf-poly1305 и перезапустите сервис.

Не работает UDP

TCP-трафик идёт, а игры, голос или DNS через прокси не работают — значит не поднят UDP. В конфиге должен стоять "mode":"tcp_and_udp", иначе сервер обслуживает только TCP. Кроме того, UDP-порт нужно открыть в фаерволе отдельно — про него забывают чаще всего, потому что TCP открыли, а UDP нет. Добавьте правило для UDP и в ufw, и во внешней панели облака, затем перезапустите сервис. Проверьте, что порт слушается именно по UDP (в выводе ss -lntup строка с udp). Без этого приложения, которым нужен UDP, будут молча работать вполсилы. Особенно это заметно на голосовых звонках и в играх, где TCP-режима недостаточно, а пользователь долго не понимает, почему «интернет вроде есть, а звонок не идёт».

Соединение рвётся

Канал то есть, то пропадает. Первая причина — нестабильный или перегруженный сервер: на ноде с плавающей полосой обрывы неизбежны независимо от настроек. Вторая — мобильная сеть, где NAT закрывает неактивные сессии; тут помогает клиент с автопереподключением. Третья, более неприятная, — активное вмешательство фильтров, которые распознают и подрезают Shadowsocks-трафик: соединение живёт минуту-другую и рвётся. Если обрывы начались резко и совпали с усилением блокировок, дело именно в этом. Проверьте, пингуется ли сам сервер напрямую: если да, а прокси рвётся — трафик подрезают, и нужен обфускатор.

Блокируют трафик

Раньше работало, теперь нет, сервер жив и пингуется — классический признак блокировки протокола или IP. Если распознают сам Shadowsocks по сигнатуре, добавьте плагин-обфускатор вроде v2ray-plugin, который заворачивает трафик в TLS или веб-сокеты и делает его неотличимым от обычного HTTPS. Если же заблокирован сам IP (сервер не отвечает даже на прямой пинг), никакой плагин не поможет — нужен новый чистый адрес. Репутация и происхождение IP тут решают всё: адрес, уже засвеченный в блокировках, обходить ими же бессмысленно. Под устойчивый обход берите VPS с чистым, не забаненным IP — у MAATRIX его можно арендовать в США или Европе с оплатой из России картой, СБП или криптой.

Полезно уметь отличать блокировку от обычной поломки, чтобы не чинить не то. Если сервер не пингуется даже напрямую и SSH до него тоже не идёт — это блокировка IP на сетевом уровне. Если сервер пингуется и SSH работает, но именно Shadowsocks-трафик рвётся — подрезают протокол, и спасает обфускатор. Если же и пинг есть, и протокол вроде проходит, но всё дико тормозит — узкое место в канале ноды, а не в блокировках. Три простых наблюдения — пинг, SSH, поведение прокси — раскладывают проблему по трём разным корзинам, и для каждой своё решение, так что диагностика перестаёт быть гаданием.

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