Git proxy setup: HTTPS, config scope and safe removal

For an HTTP or HTTPS Git remote, start with a one-command http.proxy setting. Before making it permanent, check the remote transport and any URL-specific or remote-specific settings. Clearing the general setting can leave a more specific proxy active.

Examples use illustrative endpoints. Our downloadable lab uses loopback, invented credentials and a temporary repository. Its ten checks ran on Git 2.50.1 (Apple Git-155), Python 3.14.8 and macOS 15.7.4 on 12 October 2026. It verifies routing and repository contents; it does not measure a proxy provider or test HTTPS, SSH or push.

Check the remote transport

Inside an existing repository, inspect the remote locally:

git remote get-url origin

An https:// or http:// URL uses Git's HTTP transport. A remote such as git@github.com:OWNER/REPO.git or ssh://git@HOST/REPO.git uses SSH. http.proxy does not configure the SSH connection; follow your organization's SSH routing instructions for that transport. For a new clone, inspect the URL you intend to clone. Keep embedded credentials out of shared output. Git command and SSH documentation.

Try a proxy for one command

Have your environment supply GIT_PROXY_URL and GIT_REPO_URL. The latter is an HTTP/HTTPS remote you are authorized to access. The proxy value is its documented gateway URL, such as http://proxy.example:8080:

git -c http.proxy="$GIT_PROXY_URL" \
    -c http.lowSpeedLimit=1 -c http.lowSpeedTime=20 \
    ls-remote "$GIT_REPO_URL"

This leaves no persistent proxy entry. The low-speed options bound a stalled transfer; they are not a total command deadline. A refs response confirms a repository response, but success alone does not establish the route. To clone, replace ls-remote with clone and choose a new destination directory.

An HTTPS remote can use an HTTP gateway: the proxy URL's scheme describes the connection to the gateway. Use an https:// gateway only when it supports TLS. Git HTTP options, libcurl proxy protocols.

Proxy and repository credentials serve different purposes. Git documents obtaining a password through its credential mechanism when the proxy URL supplies a username without a password. Follow the gateway's supported authentication method. Keep real credential-bearing URLs out of shared configuration and redact diagnostic output. Git credentials.

Save the narrowest useful setting

Choose one setting after the temporary check works. These commands use a credential-free illustrative gateway:

A repository-local setting needs an existing repository; use command or URL-scoped user configuration for the first clone. URL matching and ordinary config precedence are separate decisions. A named remote adds another override. Git configuration scopes, remote proxy options.

What the routing fixture showed

The lab script creates a bare repository, HTTP origin and authenticated forwarding proxy. Successful clone/fetch cases verify the expected commit and exact file payload; direct cases require zero proxy requests. The recorded results retain commands, requests, failures and versions.

All ten cases met their acceptance criteria, including the deliberately rejected authentication case. Nine clone/fetch operations succeeded and verified their repository contents. These observations apply to the recorded local Git/libcurl environment.

Download the script and README into a new directory, then run:

python3 git_proxy_lab.py > local-results.json

The fixture requires Git with GIT_CONFIG_GLOBAL (introduced in Git2.32) and Python with ThreadingHTTPServer (introduced in Python3.7), with no Python packages. These feature requirements are documented; only the recorded Git2.50.1/Python3.14.8 environment was executed. See Git2.32 release notes and Python HTTP server documentation. It uses IPv4 loopback, dedicated Git config files and a baseline cleared of inherited proxy variables. Temporary repositories are removed afterward. Its dumb HTTP transport does not test smart HTTP, CONNECT, certificates, SOCKS, production authentication systems or SSH. Certificate advice below comes from documentation. The documentation was checked against Git2.56.0 sources; the executed binary was Apple Git2.50.1.

Find and remove the active setting

Inspect locally: configuration values can contain credentials.

git config --show-origin --show-scope --get-regexp \
  '^(http\..*proxy|remote\..*\.proxy)$'
git config --get-urlmatch http.proxy "$GIT_REPO_URL"

The first command locates general, URL-specific and remote-specific entries. The second reports HTTP URL matching; it does not incorporate the named remote or prove actual network routing. Also inspect the actual process's proxy/bypass variables using the environment variables guide.

Remove only the intended key and scope. For the example host entry:

git config --global --unset-all 'http.https://github.com/.proxy'

For the example named remote, run inside its repository:

git config --local --unset-all remote.origin.proxy

For the general user entry, use git config --global --unset-all http.proxy. A nonexistent key yields a nonzero status. Removal can expose a remaining setting, so inspect again and repeat your route check. Our fixture explains why clearing http.proxy alone can leave the matching URL proxy active.

Diagnose the failing layer

For an approved corporate interception CA, Git exposes http.sslCAInfo; TLS to an HTTPS proxy has a separate http.proxySSLCAInfo. Obtain trust material from your administrator and keep verification enabled. These are separate connections, and the HTTP lab does not test either. Windows Schannel may use its certificate store rather than a supplied CA file; follow the platform-specific policy. Git TLS options.

For a gateway baseline outside Git, use the bounded curl check. A successful curl request does not establish which route Git selects.

For a timeout, identify the stalled stage before increasing limits; see proxy timeout troubleshooting.

If you are evaluating ipvolt for future proxy workflows, Know when access opens. One email when access opens. Nothing else.