Use a Proxy for One Git Repository

Set a repository-local HTTP proxy, inspect the configuration Git selects for the remote URL, and remove the override when it is no longer needed.

You do not need a global Git proxy just because one project needs a different connection. An existing checkout has its own local configuration, so you can keep the change with that repository.

These examples use the current git config set/get/unset commands. The project directory, remote URL, and documentation IP are placeholders. For a public-repository test where public proxies are permitted, select a candidate from the HTTP proxy list.

git -C project config set --local http.proxy http://203.0.113.10:8080
git -C project ls-remote origin

The proxy URL includes its transport scheme. An HTTPS remote can use an ordinary HTTP proxy that supports CONNECT; the remote's HTTPS scheme does not require changing the proxy URL to HTTPS.

Check what Git actually selected

If the result is unexpected, inspect the value selected for the actual remote URL:

git -C project config get --show-origin \
  --url=https://example.com/team/project.git http.proxy

Use your real HTTPS remote in that query. Git can have system, user, repository, command-line, and URL-specific settings. Looking only at a global http.proxy value can miss a more specific rule. The origin output helps identify the file or command-line source behind the result.

The local setting applies to HTTP-based access from that repository, not just to a particular branch. A repository with several HTTP remotes may therefore use it for more than the remote you first tested. URL-specific HTTP settings are available if you need narrower matching.

Before the checkout exists

For the initial clone, choose whether the override should persist; to limit it to that Git invocation, use:

git -c http.proxy=http://203.0.113.10:8080 \
  clone https://example.com/team/project.git

The command-line override does not itself become a permanent configuration entry in the new checkout. Set a local value afterward if later fetches should use that route.

An SSH remote is a different case

A remote beginning with git@host: or ssh:// uses SSH. Git's HTTP proxy setting does not turn it into an HTTP transfer. Check the remote's transport before replacing a working proxy IP simply because an SSH operation still fails.

When the local override is no longer wanted, remove just that key:

git -C project config unset --local http.proxy

Removing it exposes any applicable configuration from other sources again. It is not a command to erase every proxy setting on the machine.

Winndannde jowitiiɗe heen