Artemis Can Bypass SOCKS for a Loopback Broker

An Artemis broker connection that succeeds with the wrong SOCKS password may have skipped the proxy handler. Check the broker destination, not just socksHost.

The transport documentation describes loopback broker addresses such as localhost and 127.0.0.1 as bypassing SOCKS configuration. For the normal local-resolution path, use the intended non-loopback broker address when the connection must go through the intermediary. A different alias that still resolves to loopback may have the same result.

Check the connector version’s exact condition

Newer upstream connector source includes an explicit remote-DNS exception. Its proxy-handler condition is:

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

With socksRemoteDNS enabled in an implementation containing that condition, the connector keeps the destination unresolved and installs the SOCKS handler even for a loopback-looking destination. With its documented default of false, the local-address test still matters.

That changes the meaning of a hostname such as localhost: when passed to a SOCKS server for resolution, it refers to the proxy’s destination view. Confirm that this is the intended broker location before selecting remote resolution.

Match the behavior to the installed Artemis client. Once the handler is actually in the route, distinguish SOCKS authentication from broker authentication and verify the resulting connection path instead of treating a successful broker session as proof that proxy credentials were used.