Более длинная цепочка SOCKS не скрывает следующий узел автоматически

Цепочка меняет того, кто открывает каждое соединение. Она не добавляет шифрование просто потому, что в список добавлен ещё один адрес SOCKS.

Рассмотрим клиент, который сам строит эту цепочку:

application → SOCKS A → SOCKS B → website

Сначала он просит A подключиться к B. Через этот поток он затем может договориться с B о соединении с сайтом. Если транспорт от клиента к A несёт оба согласования без шифрования, достаточно способный наблюдатель на этом звене может прочитать байты настройки, отправленные клиентом. Внешний адресат TCP — не единственное возможное свидетельство наблюдателя.

Отделяйте цепочку от защищённого обмена приложения

HTTPS может защитить содержимое приложения сайта после начала сеанса TLS. Он не шифрует задним числом более ранние сообщения настройки SOCKS. Аутентификация SOCKS5 по имени пользователя и паролю тоже не является шифрованным транспортом.

Шифрованная схема между клиентом и первым узлом меняет видимость на этом звене. У неё по-прежнему есть оператор и другая конечная точка, удерживающая расшифрованный поток. Опишите эту границу доверия вместо утверждения, что цепочку невозможно отследить.

Родительский маршрут, настроенный на сервере, — другая топология. Если A выбирает B внутри себя, клиент не обязательно отправил полный список посредников через своё первое соединение. Не утверждайте, что каждая цепочка раскрывает каждый узел одинаково.

Для полезной оценки приватности назовите наблюдателя, звено, согласование с прокси и границы TLS. Сайт, наблюдающий за выходом B, и наблюдатель сети доступа, следящий за первым соединением клиента, отвечают на разные вопросы. Один лишь подсчёт узлов не отвечает ни на один из них.