sbt can need the network before your build definition has done anything useful. Its launcher must obtain components, and the build can later contact repositories through additional libraries. A proxy setting hidden inside a task may arrive too late for the first download.

Start with the JVM that actually runs sbt. For a launcher that reads the project's .jvmopts, basic endpoint properties can be:

-Dhttp.proxyHost=proxy.example.net
-Dhttp.proxyPort=8080
-Dhttps.proxyHost=proxy.example.net
-Dhttps.proxyPort=8080

These values separate a hostname and port; they are not full proxy URLs. For permitted public repository downloads, the HTTP proxy list supplies candidate values for those fields. An HTTPS repository can still be reached through an HTTP proxy using CONNECT.

Notice which download failed

Launcher bootstrap, build-tool components, plugins, and dependencies do not necessarily use the same configuration layer. Identify the failing URL and stage before editing repository declarations.

Repository selection answers where artifacts are obtained. Proxy configuration answers how a network client reaches that endpoint. Replacing a repository with an internal mirror can be a separate supported choice, but it does not configure a network proxy for every other destination.

Proxy authentication is another check. Do not assume every Java downloader treats an arbitrary proxyUser property as a supported login mechanism. Use the authentication arrangement documented for the installed launcher and relevant resolver.

Finally, check the effective launcher environment rather than copying a variable from a guide for another runner. A DNS failure, unavailable repository, and refused proxy login can all appear during dependency resolution while requiring very different fixes.

Related articles