Introduction

HTTP 407 Proxy Authentication Required means Git reached the proxy but the proxy refused to forward the request until the client authenticated. This is different from a GitHub or GitLab login failure. The error happens before Git even reaches the remote server. To fix it, you need to give Git the right proxy settings or use the authentication mechanism your network expects.

What the Error Means

When Git uses HTTPS behind a corporate proxy, the request flow usually looks like this:

1. Git connects to the proxy
2. Git asks the proxy to open a tunnel with CONNECT
3. the proxy demands credentials
4. Git fails to satisfy that demand and receives 407

So the failure is between Git and the proxy, not between Git and the repository host.

Configure the Proxy in Git

If your network uses a standard authenticated HTTP proxy, configure it explicitly:

git config --global http.proxy http://username:[email protected]:8080
git config --global https.proxy http://username:[email protected]:8080

After that, retry a remote operation:

git ls-remote https://github.com/example/repo.git

If the password contains special characters, it must be URL-encoded. Otherwise the proxy URL is parsed incorrectly and authentication still fails.

Check for Wrong or Stale Proxy Settings

A surprising number of 407 problems come from old configuration left behind in one scope while you are debugging another. Inspect all relevant settings:

1git config --global --get http.proxy
2git config --global --get https.proxy
3git config --system --get http.proxy
4git config --system --get https.proxy
5env | grep -i proxy

If the values are wrong, clear them before retrying:

git config --global --unset http.proxy
git config --global --unset https.proxy

This matters because Git may inherit proxy settings from both Git config and environment variables, which can make debugging look inconsistent.

Authentication Method Matters

Some enterprise proxies expect more than a username and password in a URL. They may rely on integrated authentication, a local proxy helper, or a security product that injects certificates and credentials. In those environments, Git's simple proxy URL may not be enough by itself.

That is why the most useful diagnostic question is not "what repository am I cloning" but "how does this network expect proxy authentication to work."

Use Verbose Output Carefully

Git can show more detail during the handshake:

GIT_CURL_VERBOSE=1 git ls-remote https://github.com/example/repo.git

This often reveals whether:

• the proxy host is correct
• the request reaches the proxy
• the proxy immediately asks for authentication
• the credentials format is being rejected

Be careful with logs because proxy credentials can appear in command history or debug output.

Separate Proxy Problems From TLS Problems

Some corporate environments also intercept TLS traffic. That can produce certificate errors near the same point in the workflow, which leads people to misdiagnose everything as a proxy issue. A 407 is specifically an authentication failure at the proxy layer. Fix that first before chasing certificate configuration.

Common Pitfalls

• Assuming 407 means GitHub, GitLab, or the origin server rejected your credentials.
• Setting http.proxy but forgetting https.proxy for HTTPS remotes.
• Leaving stale proxy settings in environment variables or system config while testing new ones.
• Forgetting to URL-encode special characters in the password.
• Printing verbose logs or shell history that expose proxy credentials.

Summary

• HTTP 407 means the proxy requires authentication and Git did not provide acceptable credentials.
• The failure occurs before Git reaches the remote repository host.
• Configure the proxy in Git or through the network-approved authentication mechanism.
• Inspect both Git config and environment variables for stale or conflicting proxy values.
• Use verbose curl logging carefully to confirm where the handshake fails.