In Artemis-brokerferbining dy't slagget mei it ferkearde SOCKS-wachtwurd hat miskien de proxy-handler oerslein. Kontrolearje it broker-doel, net allinnich socksHost.

De transportdokumintaasje beskriuwt loopback-brokeradressen lykas localhost en 127.0.0.1 as adressen dy't de SOCKS-konfiguraasje omsile. Brûk foar it normale lokale oplossingspaad it bedoelde net-loopback-brokeradres as de ferbining troch de tuskenpersoan moat. In oar alias dat noch altyd nei loopback oplost, kin itselde resultaat hawwe.

Kontrolearje de krekte betingst fan de connector-ferzje

Nijere upstream-connectorboarne befettet in eksplisite remote-DNS-útsûndering. De betingst fan de proxy-handler is:

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

As socksRemoteDNS ynskeakele is yn in ymplemintaasje mei dy betingst, hâldt de connector it doel ûnoplost en ynstallearret de SOCKS-handler sels foar in doel dat op loopback liket. Mei de dokumintearre standertwearde false bliuwt de test fan it lokale adres wichtich.

Dat feroaret de betsjutting fan in hostnamme lykas localhost: as dy nei in SOCKS-tsjinner stjoerd wurdt foar oplossing, ferwiist er nei de doelwerjefte fan de proxy. Befêstigje dat dit de bedoelde brokerlokaasje is foardat jo foar oplossing op ôfstân kieze.

Pas it gedrach oan op de ynstalleare Artemis-klient. Sadree't de handler echt yn 'e rûte sit, ûnderskied SOCKS-autentikaasje fan broker-autentikaasje en ferifiearje it resultearjende ferbiningspaad ynstee fan in slagge brokersesje te beskôgjen as bewiis dat proxy-gegevens brûkt binne.

Relatearre artikelen