A repeated 407 does not always mean Java sent the wrong password. The JDK reference implementation normally disables Basic authentication for HTTPS CONNECT tunneling. A proxy that offers only Basic can be rejected before your authentication callback supplies credentials.

Keep the credential callback scoped

Attach an Authenticator to the Java HTTP client and restrict it to the configured proxy:

String proxyHost = "203.0.113.10";
int proxyPort = 8080;
String password = System.getenv("PROXY_PASSWORD");
if (password == null) {
    throw new IllegalStateException("Set PROXY_PASSWORD");
}

java.net.Authenticator auth = new java.net.Authenticator() {
    @Override
    protected java.net.PasswordAuthentication getPasswordAuthentication() {
        if (getRequestorType() == RequestorType.PROXY
                && proxyHost.equals(getRequestingHost())
                && proxyPort == getRequestingPort()) {
            return new java.net.PasswordAuthentication(
                "proxy-user", password.toCharArray());
        }
        return null;
    }
};

java.net.http.HttpClient client = java.net.http.HttpClient.newBuilder()
    .proxy(java.net.ProxySelector.of(
        new java.net.InetSocketAddress(proxyHost, proxyPort)))
    .authenticator(auth)
    .connectTimeout(java.time.Duration.ofSeconds(5))
    .build();

This is setup code for a client, not a global default authenticator. Replace the documentation address and use credentials actually supplied for that service. The requestor type and endpoint checks prevent the same callback from casually offering the proxy account to a website challenge.

Check which authentication stage is failing

The JDK has separate disabled-scheme settings for ordinary HTTP proxying and CONNECT tunneling. The relevant names are jdk.http.auth.proxying.disabledSchemes and jdk.http.auth.tunneling.disabledSchemes.

This explains why HTTP traffic can authenticate while an HTTPS tunnel through the same proxy fails. Check the runtime's conf/net.properties and deployment policy rather than assuming another machine has the same effective defaults.

Clearing a disabled-scheme list globally is not a general proxy repair. Basic credentials sent to a cleartext HTTP proxy are not protected by the destination's later TLS connection. Review the proxy transport, authentication method, and deployment policy before approving a change.

The JDK's documented built-in authentication behavior is also not a promise to support every scheme that a proxy advertises. A manually supplied Authorization or Proxy-Authorization header changes the automatic authenticator flow, so inspect custom headers when callback behavior differs from the example.

Artihkkalat mat laktásit