How to fix fatal: unable to access: Proxy CONNECT aborted in Git

First, identify exactly which proxy settings Git is using and at which level. Settings can come from Git config (system/global/local) or from environment variables, and they can conflict.

# Git-specific proxy settings at each level
git config --global --get http.proxy
git config --global --get https.proxy
git config --system --get http.proxy
git config --system --get https.proxy
git config --get http.proxy   # repo-local
git config --get https.proxy  # repo-local

# Environment variables (note: lower-case and upper-case both apply)
echo "$http_proxy"  ; echo "$HTTP_PROXY"
echo "$https_proxy" ; echo "$HTTPS_PROXY"
echo "$no_proxy"    ; echo "$NO_PROXY"

Make note of everything found. If a setting exists at multiple levels, Git config takes precedence over the environment, and a repo-local value overrides global and system.

Turn on verbose tracing so you can see exactly where the CONNECT exchange fails. The HTTP status code the proxy returns tells you the real cause.

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

Key lines to look for:
- * Connected to <proxy> - reached the proxy host/port
- > CONNECT github.com:443 HTTP/1.1 - CONNECT request was sent
- < HTTP/1.1 200 Connection established - tunnel succeeded
- < HTTP/1.1 407 Proxy Authentication Required - missing/incorrect proxy credentials (go to step 4)
- < HTTP/1.1 403 Forbidden - the proxy is blocking the host (go to step 5)
- < HTTP/1.1 502/504 - the proxy cannot reach the destination

On Windows cmd:

set GIT_TRACE=1
set GIT_CURL_VERBOSE=1
git ls-remote https://github.com/git/git.git

Confirm the proxy host and port are correct and that the proxy itself can open a tunnel, independent of Git.

# Is the proxy port even open?
nc -zv proxy.company.com 8080

# Ask the proxy to tunnel to GitHub directly with curl
curl -v -x http://proxy.company.com:8080 https://github.com

Then set Git's proxy with the correct syntax. Use the http:// scheme even when the destination is HTTPS — the scheme describes how Git talks to the proxy, not the final destination.

git config --global http.proxy  http://proxy.company.com:8080
git config --global https.proxy http://proxy.company.com:8080

If curl -x succeeds but Git still fails, the problem is in Git's config layering (step 7), not the proxy itself.

A 407 in step 2 means the proxy needs credentials. Prefer keeping credentials out of your Git config and shell history.

Preferred: store credentials in a protected `~/.netrc`. libcurl reads it automatically for proxy auth.

# ~/.netrc  (on Windows: %USERPROFILE%\_netrc)
machine proxy.company.com
    login your_username
    password your_password

Then lock the file down so other users cannot read your credentials, and configure the proxy without embedding them:

chmod 600 ~/.netrc
git config --global http.proxy  http://proxy.company.com:8080
git config --global https.proxy http://proxy.company.com:8080

Alternative (only if `.netrc` is not an option): embed credentials in the proxy URL. This writes your password in cleartext into ~/.gitconfig, so treat it as a fallback and URL-encode special characters (@=%40, :=%3A, #=%23, !=%21).

git config --global http.proxy http://john.doe:p%[email protected]:8080

Windows NTLM/Kerberos proxies: Git's built-in client does not speak NTLM well. Run a local authenticating relay such as cntlm (or px) that holds your domain credentials, then point Git at the relay:

# cntlm listens on localhost:3128 and handles NTLM upstream
git config --global http.proxy http://localhost:3128

If the verbose trace shows a 403 (or the tunnel is dropped) only for certain hosts, the proxy is blocking those destinations. Confirm with IT whether the host is permitted; if direct egress is available for some hosts, bypass the proxy for them.

# Bypass the proxy for specific Git hosts (empty per-host proxy)
git config --global http.https://github.com.proxy ""
git config --global http.https://gitlab.com.proxy ""

# Or use NO_PROXY for a broader set of hosts
export NO_PROXY="github.com,gitlab.com,bitbucket.org,.internal.company.com"

# Conversely, route only an internal host through the proxy
git config --global http.https://internal-git.company.com.proxy http://proxy.company.com:8080

If the host is genuinely blocked by policy and not reachable directly, this is a network-policy decision for IT (step 8); there is no client-side workaround.

Some proxies perform TLS inspection (a man-in-the-middle): they terminate the TLS session, re-sign it with a corporate CA, and Git fails because it does not trust that CA. The correct fix is to trust the corporate CA, never to disable verification.

Obtain the corporate root CA certificate from IT (or export the chain shown in your browser at https://github.com), then point Git at it or add it to the system trust store:

# Point Git at the corporate CA bundle
git config --global http.sslCAInfo /path/to/corporate-ca-bundle.crt

# Or install it system-wide (Debian/Ubuntu)
sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

# RHEL/CentOS/Fedora
sudo cp corporate-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Do NOT use git config --global http.sslVerify false or GIT_SSL_NO_VERIFY=1 to work around this. Disabling certificate verification removes all protection against impersonation and credential theft over the connection, and it does not actually fix the underlying trust problem. Adding the CA is both safer and permanent.

If settings exist at several levels (step 1), wipe them and set a single authoritative configuration. Mismatched http vs https proxy values, or a stale environment variable overriding your intended config, frequently cause the tunnel to be aborted.

# Remove Git proxy settings at every level (ignore 'not set' errors)
git config --global --unset http.proxy
git config --global --unset https.proxy
git config --system --unset http.proxy
git config --system --unset https.proxy
git config --unset http.proxy
git config --unset https.proxy

# Clear environment variables for the current shell
unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY

On Windows PowerShell:

Remove-Item Env:HTTP_PROXY  -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue

Then set both schemes to the same correct proxy:

git config --global http.proxy  http://proxy.company.com:8080
git config --global https.proxy http://proxy.company.com:8080

If HTTPS through the proxy is blocked by policy, SSH may take a different network path. Check whether outbound SSH is permitted first.

git remote -v
git remote set-url origin [email protected]:username/repository.git
ssh -T [email protected]

If port 22 is blocked, GitHub also accepts SSH over port 443:

# ~/.ssh/config
Host github.com
    HostName ssh.github.com
    Port 443
    User git

Note that many corporate networks block outbound SSH entirely; in that case correctly configured HTTPS-through-proxy (steps 4-6) is the only path.

If authentication, allow-listing, and CA trust are all correct and the proxy still aborts the tunnel, the policy or proxy itself is at fault. Collect the evidence and raise it with your network team.

# Settings in effect
git config --list | grep -i proxy
env | grep -i proxy

# Captured failure (status line shows the real cause)
GIT_CURL_VERBOSE=1 git ls-remote https://github.com/git/git.git 2>&1 | head -50

Questions for IT:
1. What is the correct proxy host, port, and authentication scheme (Basic, NTLM, Kerberos)?
2. Is GitHub/GitLab/Bitbucket on the proxy allow-list?
3. Does the proxy permit the CONNECT method to port 443?
4. Is there a PAC file or VPN profile that developer machines must use?
5. Is there a designated egress path for developer/Git traffic?