Why Java Tests Miss java.net.useSystemProxies

Your application detects the system proxy, but a JUnit test does not. Before changing the detection code, identify which JVM runs each process and which arguments it received.

The JDK documents java.net.useSystemProxies as a property checked once at startup. Setting it inside a test method can be too late to change that startup decision.

An IDE application launcher, an IDE test runner, Maven itself, and a forked Surefire test process can all have different VM arguments. A proxy setting in one launcher is not evidence that another launcher passed it on.

Check the forked process configuration

Surefire's argLine supplies command-line JVM options for forked executions. A startup option can belong there when the tests run in such a fork:

<argLine>-Djava.net.useSystemProxies=true</argLine>

Merge the option into the project's existing configuration. Replacing an existing argLine can discard coverage agents or other required JVM settings. If the build uses no fork, inspect the JVM that actually hosts the tests instead; argLine is documented as effective only for forked executions.

A non-startup-sensitive property supplied through a test framework's property mechanism has a different lifecycle. Avoid assuming every property reaches the VM early enough merely because System.getProperty() returns the desired string during the test.

For a focused proxy-routing test, an explicitly configured client can also reduce dependence on desktop configuration. Java 11+ HttpClient can use a client-local HTTP ProxySelector for that purpose. Keep that choice visible in the test's intent: testing a client route and testing operating-system proxy discovery are different checks.