Соединение с брокером Artemis, которое успешно с неверным паролем SOCKS, возможно, пропустило обработчик прокси. Проверьте назначение брокера, а не только socksHost.

Документация транспорта описывает loopback-адреса брокера, такие как localhost и 127.0.0.1, как адреса, обходящие конфигурацию SOCKS. Для обычного пути локального разрешения используйте предполагаемый не-loopback адрес брокера, когда соединение должно проходить через посредника. Другой alias, который всё ещё разрешается в loopback, может дать тот же результат.

Проверьте точное условие версии коннектора

Более новый исходный код коннектора upstream содержит явное исключение remote-DNS. Условие обработчика прокси:

socksEnabled && (socksRemoteDNS || !isTargetLocalHost())

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

Это меняет смысл имени хоста вроде localhost: когда оно передаётся серверу SOCKS для разрешения, оно указывает на представление прокси о назначении. Убедитесь, что это предполагаемое расположение брокера, прежде чем выбирать удалённое разрешение.

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

Похожие статьи