I Java 11 eller nyere sætter du en ProxySelector på klientbyggeren. Dermed forbliver proxyegenskaber for hele JVM'en uændrede:

import java.net.InetSocketAddress;
import java.net.ProxySelector;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.time.Duration;

public class ProxyExample {
    public static void main(String[] args) throws Exception {
        HttpClient client = HttpClient.newBuilder()
            .proxy(ProxySelector.of(
                new InetSocketAddress("203.0.113.10", 8080)))
            .connectTimeout(Duration.ofSeconds(5))
            .build();

        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create("https://example.com/"))
            .timeout(Duration.ofSeconds(15))
            .GET()
            .build();

        HttpResponse<String> response = client.send(
            request, HttpResponse.BodyHandlers.ofString());
        System.out.println(response.statusCode());
        System.out.println(response.body());
    }
}

Erstat dokumentationsendepunktet med din HTTP-proxy; HTTP-proxylisten giver kandidater at teste. ProxySelector.of tager en socketadresse: brug værten uden et http://-præfiks, og angiv porten separat. Den vælger en HTTP-proxy, ikke SOCKS ud fra portnummeret. Anmodningens URI er stadig den rigtige destination.

HTTPS kan passere denne HTTP-proxy gennem en tunnel. Destinationen skal ikke nedgraderes, og opsætningen betyder ikke, at proxyens lytter selv understøtter TLS.

Klientbyggerens forbindelsestimeout gælder ved oprettelse af en forbindelse; anmodningen har sin egen timeout. Hold begge tydelige, fordi en anmodning kan genbruge en eksisterende forbindelse. En netværks-, godkendelses- eller tunnelundtagelse kan opstå før noget svar fra destinationen, mens en returneret fejlstatus ikke nødvendigvis udløser en undtagelse.

Genbrug klienten til anmodninger med samme rutepolitik, så programmet kan drage fordel af dens forbindelsesstyring.

Relaterede artikler