Metti la negoziazione SOCKS di Netty prima del protocollo dell'applicazione
Ordina un gestore proxy SOCKS di Netty prima del traffico dell'applicazione e preserva una destinazione non risolta quando il DNS lato proxy è voluto.
Per un bootstrap/pipeline Netty esistente in cui il server SOCKS deve risolvere la destinazione:
bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);
pipeline.addFirst(
new Socks5ProxyHandler(new InetSocketAddress("127.0.0.1", 1080))
);
bootstrap.connect(
InetSocketAddress.createUnresolved("example.com", 443)
);L'endpoint del proxy è la porta locale 1080; la destinazione di connessione non risolta è example.com:443. Non usare l'indirizzo del proxy per entrambi i ruoli e non risolvere il nome prima che il gestore lo riceva. Per destinazioni pubbliche su una rotta proxy pubblica consentita, la lista di proxy SOCKS5 fornisce candidati per l'endpoint proxy del gestore.
Metti Socks5ProxyHandler prima dei gestori che scambiano traffico verso la destinazione. Attendi il future della connessione proxy, non solo un canale che raggiunge il listener. Un metodo o una destinazione rifiutati appartengono a questa fase di configurazione.
Per HTTPS, il livello TLS successivo usa il nome host della destinazione, la verifica e la fiducia richieste—non l'identità dell'endpoint SOCKS. Solo allora inizia lo scambio HTTP/applicazione.
Il frammento non fornisce event loop, tipi di canale, gestori TLS/HTTP o normale gestione degli errori. Scegli il costruttore SOCKS adatto alle esigenze di autenticazione; un gestore HTTP Basic è un altro protocollo.
Usa il resolver no-op solo dove questo gestore a valle possiede la risoluzione del nome host. Altre connessioni possono richiedere una ricerca locale. Mantieni separati l'output del resolver, il future del proxy, TLS e il risultato dell'applicazione durante la diagnosi di un guasto.