Olemasoleva Netty bootstrap/pipeline'i jaoks, kus SOCKS-server peaks sihtkoha lahendama:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

pipeline.addFirst(
    new Socks5ProxyHandler(new InetSocketAddress("127.0.0.1", 1080))
);

bootstrap.connect(
    InetSocketAddress.createUnresolved("example.com", 443)
);

Puhverserveri lõpp-punkt on kohalik port 1080; lahendamata ühenduse siht on example.com:443. Ärge kasutage puhverserveri aadressi mõlemas rollis ega lahendage nime enne, kui käitleja selle saab. Lubatud avaliku puhverserveri marsruudil olevate avalike sihtide jaoks pakub SOCKS5 puhverserverite loend kandidaate käitleja puhverserveri lõpp-punkti jaoks.

Asetage Socks5ProxyHandler enne käitlejaid, mis vahetavad sihtkoha liiklust. Oodake selle puhverserveri ühenduse future'it, mitte ainult kanalit, mis jõuab kuulajani. Tagasilükatud meetod või sihtkoht kuulub sellesse seadistusetappi.

HTTPS-i puhul kasutab järgmine TLS-kiht sihtkoha hostinime, nõutavat kontrolli ja usaldust—mitte SOCKS-i lõpp-punkti identiteeti. Alles siis algab HTTP/rakenduse vahetus.

Katkend ei paku sündmuste tsükleid, kanalitüüpe, TLS/HTTP käitlejaid ega tavalist vigade käsitlemist. Valige autentimisvajadustele vastav SOCKS-konstruktor; HTTP Basic käitleja on teine protokoll.

Kasutage no-op resolver'it ainult seal, kus see allavoolu käitleja omab hostinime lahendamist. Teistel ühendustel võib vaja minna kohalikku otsingut. Hoidke resolver'i väljund, puhverserveri future, TLS ja rakenduse tulemus tõrke diagnoosimisel eraldi.

Seotud artiklid