One Git configuration can serve two quite different routes: an external host reached through an approved proxy and an internal host reached directly. You do not have to keep editing the global default every time you switch repositories.

Git supports URL-specific HTTP configuration. For example:

[http]
    proxy = http://proxy.example:8080
[http "https://git.office.example/"]
    proxy =

For an external public repository where public proxies are permitted, the HTTP proxy list offers candidates for the default endpoint. The empty value is an explicit override for the matching URL. It is different from deleting that more-specific key, which can expose the generic proxy again.

Match the URL Git uses

The scheme, hostname, port, path, and optional username participate in documented matching rules. Do not treat the URL subsection as a general shell wildcard expression. A narrower path rule can beat a broader host rule.

For a read-only look at the matching proxy configuration:

git config --get-urlmatch http.proxy https://git.office.example/team/project.git

This inspects configuration matching. It is not a network test and does not establish that the route is reachable. Also account for other configuration scopes and relevant environment settings.

A redirect is not a new configuration match

Git's documentation says the matched URLs are those supplied directly to Git commands; URLs visited because of a redirect do not participate in that matching. Keep that limitation in mind if the first host redirects downloads elsewhere.

The route should also match the transport. An SSH remote is not governed by an HTTP URL subsection simply because the same service offers an HTTPS website.

Use a few intentional rules, then inspect the result for representative URLs. A long accumulation of global, repository-local, and URL-specific proxy entries is much harder to reason about than the network distinction you were trying to express.

Erthyglow kevrennek