The same repository works with git clone in a terminal and fails in an application using JGit. That is a comparison between two implementations, not necessarily between a working and a broken copy of the same client.

JGit's configuration reference says proxy configuration uses Java's standard mechanisms through java.net.ProxySelector. Do not assume every native Git HTTP option is implemented merely because both clients understand a Git configuration file.

Identify the application embedding JGit, its version, and its selected HTTP transport. The host application can provide settings or behavior beyond JGit's standalone defaults.

Then inspect the Java proxy configuration visible to that process. For a URLConnection-based HTTP transport, check the JVM host and port properties it consumes. A property entered into an unrelated terminal after the application started cannot reconfigure the running JVM. An IDE's native Git operation and its JGit operation can also use different paths.

Keep proxy authentication separate from route selection. Java proxy properties that identify a host and port do not automatically implement a proxy password scheme. Use the supported authentication mechanism of the embedding application.

The useful question is “which proxy did this JGit request select?” rather than “does my Git configuration contain a proxy line?” A native Git success is a valuable comparison, but it does not answer that implementation-specific question.

ХӀокхунах тера йаззамаш