Artemis puede omitir SOCKS para un broker de loopback
Compruebe el destino del broker y el comportamiento de socksRemoteDNS cuando una conexión de Artemis tiene éxito pese a credenciales SOCKS deliberadamente incorrectas.
Una conexión al broker de Artemis que tiene éxito con la contraseña SOCKS incorrecta puede haber omitido el controlador de proxy. Compruebe el destino del broker, no solo socksHost.
La documentación del transporte describe las direcciones de broker de loopback, como localhost y 127.0.0.1, como direcciones que omiten la configuración de SOCKS. Para la ruta normal de resolución local, use la dirección de broker no loopback prevista cuando la conexión deba pasar por el intermediario. Otro alias que siga resolviéndose a loopback puede dar el mismo resultado.
Compruebe la condición exacta de la versión del conector
El código fuente más reciente del conector upstream incluye una excepción explícita de remote-DNS. La condición del controlador de proxy es:
socksEnabled && (socksRemoteDNS || !isTargetLocalHost())Con socksRemoteDNS habilitado en una implementación que contenga esa condición, el conector mantiene el destino sin resolver e instala el controlador SOCKS incluso para un destino que parece loopback. Con su valor predeterminado documentado false, la prueba de dirección local sigue importando.
Eso cambia el significado de un nombre de host como localhost: cuando se pasa a un servidor SOCKS para que lo resuelva, se refiere a la vista del destino del proxy. Confirme que esta es la ubicación prevista del broker antes de elegir la resolución remota.
Ajuste el comportamiento al cliente Artemis instalado. Una vez que el controlador está realmente en la ruta, distinga la autenticación SOCKS de la autenticación del broker y verifique la ruta de conexión resultante en lugar de tratar una sesión de broker exitosa como prueba de que se usaron las credenciales del proxy.