Ang koneksyon sa broker ng Artemis na nagtagumpay gamit ang maling SOCKS password ay maaaring lumaktaw sa proxy handler. Suriin ang destinasyon ng broker, hindi lamang socksHost.

Inilalarawan ng dokumentasyon ng transport ang mga loopback broker address tulad ng localhost at 127.0.0.1 bilang mga address na lumalaktaw sa SOCKS configuration. Para sa normal na lokal na landas ng resolusyon, gamitin ang nilalayong non-loopback broker address kapag kailangang dumaan ang koneksyon sa intermediary. Ang ibang alias na nare-resolve pa rin sa loopback ay maaaring magbigay ng parehong resulta.

Suriin ang eksaktong kundisyon ng bersyon ng connector

Ang mas bagong upstream connector source ay may tahasang remote-DNS exception. Ang kundisyon ng proxy handler ay:

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

Kapag naka-enable ang socksRemoteDNS sa isang implementation na naglalaman ng kundisyong iyon, hinahayaan ng connector na hindi ma-resolve ang destinasyon at ini-install ang SOCKS handler kahit para sa destinasyong mukhang loopback. Sa dokumentadong default na false, mahalaga pa rin ang pagsubok sa lokal na address.

Binabago nito ang kahulugan ng hostname tulad ng localhost: kapag ipinasa sa isang SOCKS server para sa resolusyon, tumutukoy ito sa pananaw ng proxy sa destinasyon. Tiyakin na ito ang nilalayong lokasyon ng broker bago piliin ang remote resolution.

Itugma ang pag-uugali sa naka-install na Artemis client. Kapag nasa ruta na talaga ang handler, ibukod ang SOCKS authentication mula sa broker authentication at i-verify ang resultang landas ng koneksyon sa halip na ituring ang matagumpay na broker session bilang patunay na ginamit ang proxy credentials.

Kaugnay na mga artikulo