Здравствуйте, Stanislaw K, Вы писали:
SK>Он используется только в режиме клиента, когда shadowsocks подключается к (другому) серверу. тогда shadowsocks принимает запросы на локал порт и пересылает на server_ip:server_port.
Вы, как обычно, с уверенным видом несете ахинею — прямо-таки наглядная иллюстрация синдрома Даннинга-Крюгера. Сильно подозреваю, что многие свои высказывания Вы копируете непосредственно из выдачи ИИ.
Правильный ответ таков: использование shadowsocks в качестве SOCKS-сервера (по RFC 1928) возможно исключительно в виде связки ss_local и ss_server. Первый работает в режиме "front-end", реализуя собственно протокол для клиента, а второй — в режиме "back-end", выдавая запросы целевым узлам и возвращая результаты. Между ними устанавливается шифрованный канал связи — для чего, собственно, и нужно указание метода шифрования.
Эти серверы называются "local" и "remote" потому, что первоначальной идеей было поднимать ss_local непосредственно на компьютере или сервере локальной сети, а ss_remote — где-то ближе к целевым узлам, и маскировать трафик между ними (разработчиком оригинала был китаец, который сделал его для обхода "великого файрвола"). Именно поэтому ss_local и не поддерживает авторизации — она тупо не имеет особого смысла в такой модели. Можно поднимать оба сервера на одном узле, тогда это будет SOCKS в одном флаконе, только открытый для всех.
К сожалению, в "документации" этот принцип описан довольно мутно, там постоянно путаются смыслы понятий "server", "proxy", "local" и "remote", отчего действительно создается ощущение, будто ss_server — это "собственно SOCKS-сервер", а ss_local — это некий "клиент", "редиректор" или еще что. Догадайся составители "документации" выбрать адекватную терминологию — не приходилось бы гадать и экспериментировать.
SK>В их лексиконе нет слова "совместимость".
