Сокету .NET нужно SOCKS-рукопожатие

Указание Socket.Connect() на SOCKS-сервере открывает TCP-соединение с этим сервером. Следующие байты всё ещё должны говорить на SOCKS. Немедленная отправка протокола вашего приложения оставляет сервер в ожидании другого разговора.

В SOCKS5 установление соединения включает согласование метода, любой выбранный обмен аутентификации и запрос с указанием пункта назначения. Только успешный ответ открывает путь для байтов приложения. Эти этапы определены в RFC 1928.

Держите согласование на уровне соединения

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

Написанная вручную реализация, которая читает один буфер фиксированного размера и предполагает успех, хрупка. TCP не сохраняет границы сообщений SOCKS. Прочитайте полный ответ, описанный его типом адреса, прежде чем начинать протокол приложения. Читатель ответов CONNECT в .NET 7+ иллюстрирует этот шаг.

Если поддерживаемая библиотека уже предоставляет этот уровень соединения, проверьте поддерживаемые версии SOCKS, методы аутентификации и целевую платформу. Ссылка на форум десятилетней давности — это отправная точка для исследования, а не доказательство текущей совместимости.

Конфигурация HTTP-клиента имеет отдельную область

Настройка прокси HTTP-клиента настраивает этот HTTP-клиент. Она не изменяет каждый необработанный сокет в процессе. API Socket принимает сетевую конечную точку и оставляет согласование более высокого уровня вызывающему.

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