За постоечки Netty bootstrap/pipeline каде SOCKS серверот треба да ја реши дестинацијата:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

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

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

Крајната точка на проксито е локалниот порт 1080; нерешената цел на врската е example.com:443. Не користете ја адресата на проксито за двете улоги и не решавајте го името пред ракувачот да го прими. За јавни цели на дозволена јавна прокси рута списокот со SOCKS5 прокси нуди кандидати за крајната точка на проксито на ракувачот.

Поставете Socks5ProxyHandler пред ракувачите што разменуваат сообраќај кон дестинацијата. Чекајте го future на прокси врската, не само канал што стигнува до слушателот. Одбиен метод или дестинација припаѓа на оваа фаза на поставување.

За HTTPS, следниот TLS слој го користи името на домаќинот на дестинацијата, потребната проверка и доверба—не идентитетот на SOCKS крајната точка. Само тогаш започнува размената HTTP/апликација.

Извадокот не обезбедува настани циклуси, типови канали, TLS/HTTP ракувачи или нормално ракување со грешки. Изберете SOCKS конструктор што одговара на потребите за автентикација; HTTP Basic ракувачот е друг протокол.

Користете no-op resolver само таму каде овој долен ракувач го поседува решавањето на името на домаќинот. Други врски може да бараат локално пребарување. Држете ги одвоени излезот на resolver, прокси future, TLS и резултатот на апликацијата при дијагностицирање на дефект.

Поврзани статии