Introduction

Git does not have one universal switch that means "always use IPv4" for every network transport. Git can talk over HTTPS or SSH, and each path is configured differently.

So the first step is to identify the remote type. An HTTPS remote and an SSH remote do not use the same underlying network stack, which means the IPv4 workaround also lives in a different place.

Check which transport your remote uses

Run:

git remote -v

If the remote looks like this:

https://github.com/example/project.git

then Git is using an HTTP transport.

If it looks like this:

[email protected]:example/project.git

then Git is using SSH.

For HTTPS remotes, use GIT_CURL_IPRESOLVE=4

For Git traffic that goes through libcurl, the usual override is:

GIT_CURL_IPRESOLVE=4 git fetch

You can use it with other network commands too:

GIT_CURL_IPRESOLVE=4 git clone https://github.com/example/project.git
GIT_CURL_IPRESOLVE=4 git pull
GIT_CURL_IPRESOLVE=4 git push

If you want that behavior in your shell by default, export it:

export GIT_CURL_IPRESOLVE=4

That works well for environments where HTTPS remotes consistently fail over IPv6.

For SSH remotes, configure the SSH command

For SSH-style remotes, IPv4 preference belongs in the SSH layer. One option is your SSH config:

Host github.com
    AddressFamily inet

Another option is to let Git invoke SSH with -4 directly:

git config --global core.sshCommand "ssh -4"

That tells Git to use SSH with IPv4 by default for SSH remotes. If you only want the setting for one repository, omit --global.

Pick the narrowest workaround that solves the problem

A practical guide is:

• use GIT_CURL_IPRESOLVE=4 for HTTPS remotes
• use core.sshCommand "ssh -4" or AddressFamily inet for SSH remotes
• use a per-command override first if you are still diagnosing the issue

This is usually better than forcing broad changes before you know where IPv6 is actually failing.

Verify that IPv6 is the real issue

Before making the workaround permanent, check whether the actual problem is name resolution, firewalling, or a bad proxy setup.

Useful commands include:

GIT_CURL_VERBOSE=1 git ls-remote https://github.com/example/project.git
ssh -v [email protected]

If the output shows a clean IPv6 connection, forcing IPv4 is unnecessary. If the failure happens only on IPv6 addresses, then an IPv4 preference makes sense.

Make the override persistent only where it matters

If the problem exists only in one CI job, one office network, or one development machine, keep the workaround local to that environment. A per-repository core.sshCommand, a shell export in one runner, or a host-specific SSH stanza is usually better than a blanket system-wide rule.

That keeps healthy environments on dual-stack networking while still unblocking the systems that genuinely need IPv4-only behavior.

Common Pitfalls

The most common mistake is looking for a single .gitconfig key that covers both HTTPS and SSH. Git does not abstract that far because the transports are different underneath.

Another issue is applying an HTTPS-specific fix to an SSH remote, or the other way around. GIT_CURL_IPRESOLVE=4 does nothing for SSH remotes.

Developers also sometimes set an aggressive global workaround before checking whether the network problem is temporary or local to one host. A targeted fix is often safer.

Finally, remember that IDEs, CI runners, and GUI Git clients may not inherit your shell environment. If you rely on an exported variable, make sure the tool that runs Git actually sees it.

Summary

• Git does not have one universal IPv4-only setting for all transports.
• For HTTPS remotes, GIT_CURL_IPRESOLVE=4 is the usual workaround.
• For SSH remotes, use core.sshCommand "ssh -4" or AddressFamily inet.
• Diagnose the failure first so the workaround matches the actual transport problem.
• Keep the scope as narrow as possible until you know the issue is persistent.