Unha conexión ao broker de Artemis que ten éxito co contrasinal SOCKS incorrecto pode ter omitido o xestor de proxy. Comprobe o destino do broker, non só socksHost.

A documentación do transporte describe os enderezos de broker de loopback, como localhost e 127.0.0.1, como enderezos que omiten a configuración de SOCKS. Para a ruta normal de resolución local, use o enderezo de broker non loopback previsto cando a conexión deba pasar polo intermediario. Outro alias que aínda se resolva a loopback pode dar o mesmo resultado.

Comprobe a condición exacta da versión do conector

O código fonte máis recente do conector upstream inclúe unha excepción explícita de remote-DNS. A condición do xestor de proxy é:

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

Con socksRemoteDNS activado nunha implementación que conteña esa condición, o conector mantén o destino sen resolver e instala o xestor SOCKS mesmo para un destino que parece loopback. Co seu valor predeterminado documentado false, a proba de enderezo local segue importando.

Iso cambia o significado dun nome de host como localhost: cando se pasa a un servidor SOCKS para resolvelo, refírese á visión do destino do proxy. Confirme que esta é a localización prevista do broker antes de escoller a resolución remota.

Axuste o comportamento ao cliente Artemis instalado. Unha vez que o xestor está realmente na ruta, distinga a autenticación SOCKS da autenticación do broker e verifique a ruta de conexión resultante en lugar de tratar unha sesión de broker exitosa como proba de que se usaron as credenciais do proxy.

Artigos relacionados