W Javie 11 lub nowszej ustaw ProxySelector w konstruktorze klienta. Właściwości proxy całej JVM pozostaną nietknięte:

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());
    }
}

Zastąp przykładowy punkt dokumentacyjny swoim proxy HTTP; lista proxy HTTP udostępnia kandydatów do testów. ProxySelector.of przyjmuje adres gniazda: podaj host bez prefiksu http:// i port osobno. Wybierane jest proxy HTTP, a nie SOCKS na podstawie numeru portu. URI żądania pozostaje rzeczywistym celem.

HTTPS może przechodzić przez to proxy HTTP tunelem. Nie trzeba obniżać zabezpieczeń celu, a konfiguracja nie oznacza obsługi TLS przez sam punkt nasłuchu proxy.

Limit czasu połączenia w konstruktorze klienta obowiązuje podczas zestawiania połączenia; żądanie ma własny limit. Utrzymuj oba jawne, bo żądanie może ponownie wykorzystać istniejące połączenie. Wyjątek sieci, uwierzytelniania lub tunelu może wystąpić przed jakąkolwiek odpowiedzią celu, natomiast zwrócony status błędu nie musi powodować wyjątku.

Używaj klienta ponownie dla żądań z tą samą polityką trasowania, by aplikacja korzystała z jego zarządzania połączeniami.

Powiązane artykuły