我遇到了同样的问题，我尝试了几种解决方案，直到我发现在我的情况下，这是防火墙。我的是“免费防火墙”，我注意到，即使授权的软件和连接，它仍然不可能有一个连接到远程仓库。我禁用了它，它没有解决它，只有当我卸载它，问题得到解决，我可以正常使用Git。

我的机器上也有同样的问题（git version 2.28.0.windows.1）。这个问题似乎与HTTP请求的DNS解析有关：
这是我的原始远程URL：

git remote set-url origin http://<FQDN>:<http_port>/<repository>.git

结果与问题相同：

$ git pull
fatal: unable to access 'http://<FQDN>:<http_port>/<repository>.git/': getaddrinfo() thread failed to start

将URL更改为解析的IP时：

$ ahost <FQDN>
<FQDN>                               <IP>

$ git remote set-url origin http://<IP>:<http_port>/<repository>.git

Git连接正常：

$ git pull
Already up to date.

此外，当使用SSH而不是HTTP时，解决方案也没有问题：

$ git remote set-url origin ssh://<username>@<FQDN>:<ssh_port>/<repository>.git
$ git pull
Already up to date.

curl 在我的MINGW64环境中也不起作用：

$ ahost www.google.com
www.google.com                          172.217.2.100
    
$ adig www.google.com
id: 64322
flags: qr rd ra
opcode: QUERY
rcode: NOERROR
Questions:
        www.google.com .                A
Answers:
        www.google.com .        49      A       172.217.2.100
NS records:
Additional records:

$ curl www.google.com -v
* getaddrinfo() thread failed to start

* Couldn't resolve host 'www.google.com'
* Closing connection 0
curl: (6) getaddrinfo() thread failed to start

如果你在系统中安装了任何杀毒软件或防火墙，要么关闭git访问，要么完全卸载并重新启动。我遇到了同样的问题，卸载了防火墙。它工作得很好。

$ git remote set-url origin http://<IP>:<http_port>/<repository>.git
or
$ git remote set-url origin ssh://<username>@<FQDN>:<ssh_port>/<repository>.git

我的问题是解决使用以上的方式！！

fatal: unable to access <link> getaddrinfo() thread failed to start

这个错误显示它意味着你的电脑防火墙不允许进行这种操作，所以只要禁用它从你的系统，也从你的防病毒和使用你的git正常.希望它会为你工作.

我突然在Gitlab CI服务器上得到了这个，在一个构建Docker映像的工作中。

error: failed retrieving file 'core.db' from geo.mirror.pkgbuild.com : getaddrinfo() thread failed to start

经过大量的挖掘（最终在CI作业中运行strace docker build），我发现这个问题是由一个名为clone3的阻塞系统调用引起的。

clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, child_tid=0x7f6cb634c990, parent_tid=0x7f6cb634c990, exit_signal=0, stack=0x7f6cb5b4c000, stack_size=0x7fff80, tls=0x7f6cb634c6c0}, 88) = -1 EPERM (Operation not permitted)

稍后再找，我想
Docker为所有Docker未知的系统调用注入SCMP_ACT_ERRNO（EPERM）规则。因此，当glibc尝试调用clone 3（）时，内核会根据Docker的seccomp配置文件引发EPERM（“不允许操作”）错误。
我发现20.10.10之前的Docker映像会受此影响，而我的Gitlab runner被配置为使用20.10.8-因此，在我的情况下，解决方案是重新配置runner以使用20.10.10映像。