Artemis は loopback broker に対して SOCKS をバイパスできる
意図的に誤った SOCKS 認証情報でも Artemis 接続が成功する場合、broker の接続先と socksRemoteDNS の動作を確認してください。
誤った SOCKS パスワードで成功する Artemis broker 接続は、proxy ハンドラをスキップしている可能性があります。socksHost だけでなく broker の接続先を確認してください。
transport のドキュメントでは、localhost や 127.0.0.1 のような loopback broker アドレスは SOCKS 設定をバイパスすると説明されています。通常のローカル解決パスでは、接続が intermediary を経由する必要がある場合に意図した非 loopback の broker アドレスを使用します。loopback に解決される別の alias でも同じ結果になる可能性があります。
connector バージョンの正確な条件を確認する
新しい upstream connector のソースには、明示的な remote-DNS 例外が含まれています。proxy ハンドラの条件は次のとおりです。
socksEnabled && (socksRemoteDNS || !isTargetLocalHost())
その条件を含む実装で socksRemoteDNS が有効な場合、connector は接続先を未解決のままにし、loopback に見える接続先でも SOCKS ハンドラをインストールします。文書化されたデフォルト値 false では、ローカルアドレスの判定が依然として重要です。
これは localhost のようなホスト名の意味を変えます。解決のために SOCKS サーバーへ渡すと、proxy から見た接続先を指します。リモート解決を選ぶ前に、これが意図した broker の場所であることを確認してください。
動作をインストール済みの Artemis クライアントに合わせてください。ハンドラが実際に経路に入ったら、SOCKS 認証と broker 認証を区別し、broker セッションの成功を proxy 認証情報が使われた証拠と見なすのではなく、結果の接続経路を検証してください。