UPDATE and PLUGIN fail HTTP/1.1 407 But Advanced Test succeeds

I’ve installed Jenkins v2.479.3 from msi onto WinServer2019 also running MS OpenJdk jdk-21.0.6.7-hotspot.
I’ve read other posts about changing to these lines in the relevant net.properties

jdk.http.auth.proxying.disabledSchemes=
jdk.http.auth.tunneling.disabledSchemes=

Now if I navigate in the Jenkins UI to
Dashboard → Manage Jenkins → System
Scroll down to
HTTP Proxy Configuration
Enter the confirmed credentials I have for our proxy (as used on other applications)
and the under advanced use test URL of

and click “Validate Proxy” it returns 200 success

BUT if I then navigate to Dashboard → Manage Jenkins → Plugins

I get a red banner at base saying basically the content below from the jenkins.err.log

INFO hudson.util.Retrier#start: Calling the listener of the allowed exception ‘Unable to tunnel through proxy. Proxy returns “HTTP/1.1 407 Proxy Authentication Required”’ at the attempt #1 to do the action check updates server
INFO hudson.util.Retrier#start: Attempted the action check updates server for 1 time(s) with no success
SEVERE hudson.PluginManager#doCheckUpdatesServer: Error checking update sites for 1 attempt(s). Last exception was: IOException: Unable to tunnel through proxy. Proxy returns “HTTP/1.1 407 Proxy Authentication Required”

Did you change the lines in jenkins.xml in the < arguments > section?

to a degree… my understanding you need to prefix such with “-D” when I put one or either in the jenkins.xml section and restart the jenkins service there is no change. If I attempt to add both i.e.

-Djdk.http.auth.proxying.disabledSchemes= -Djdk.http.auth.tunneling.disabledSchemes=
or
-Djdk.http.auth.proxying.disabledSchemes="" -Djdk.http.auth.tunneling.disabledSchemes=""

Then the jenkins service fails to start and in the jenkins log is

Exception in thread "main" java.lang.IllegalArgumentException: Multiple command line argument specified .....

Jenkins bugs with proxy settings have been documented in JENKINS-58567, JENKINS-56498, JENKINS-56498
Check out what this user did:
From what i have seen they were able to add their proxy credentials in the argument and also add

-Dhttp.auth.preference=“basic”

And also instead of adding both

-Djdk.http.auth.proxying.disabledSchemes=
-Djdk.http.auth.tunneling.disabledSchemes=

they only added

-Djdk.http.auth.tunneling.disabledSchemes=

Check it out and tell me how it goes:
https://stackoverflow.com/questions/55215752/jenkins-ioexception-unable-to-tunnel-through-proxy-proxy-returns-http-1-1-40

Ta, I had seen that link and had tried I believe those options before, I note OP was linux and this is on Windows. But I tried again. When I add the additional argument options to the jenkins.xml the Jenkins Windows service fails to start. There is no entries in the Jenkins error log and the Windows Event log just says they service failed to start in a timely manner. I’ve had to uninstall, clean folder, and reinstall to get it running again though still with the 407 on update and plugins. The test url with proxy settings still gets success on the jenkins update url. Does the latter somehow not use java at all but the actual updates and plugin interaction relies on Java?

And if you change java’s net properties instead does it have the same effect?

It does seem like thats the case i cant find enough documentation on it. Could you try recreating all of this in a vm maybe spin up a linux vagrant vm and see if the proxy might work with the solutions others have maybe since getting no error log is very concerning?

The change to java’s net properties seem to have no effect before trying the jenkins argument change. Should I have removed them while trying the jenkins arguments change.

Does the disabled “Firewall exception” option on installation have any nearing on any of this?

Thinking trying to use some standalone Java code to test outside of Jenkins would be useful, to confirm if it is purely on the Java side the issue is.

Try and test any possibilities in isolation use vms to do it so that u can conclude whether its a java or firewall issue