git clone拉不下来，终端里最常见的就两类：一类根本没连上，另一类连上了但不信任对端证书。两类都是fatal开头带一个unable to access，长得很像，排查方向却完全不同。先分清再动手，能省掉一半时间。
分诊的办法是看冒号后面那半句。
带port 443、Connection timed out、Couldn't connect to server的，属于连接类；带SSL certificate problem或server certificate verification failed的，属于证书类。
先看现场：版本和配置是从哪来的
动手之前先确认两件事。一是Git版本，老版本的libcurl和OpenSSL出过一批网络相关的坑，实测从老版本升上来之后，有一部分报错自己就消失了。
git --version
官网当前维护的版本是Git 2.54.0、2.55.0、2.56.0，其中2.56.0发布于2026年9月28日，2.54.0发布于2026年4月20日。手上这台机器还是2.20.1的话，先升级，不要急着改配置。
二是配置的来源。同一个http.proxy可能在三处被设过，只查global会漏：
git config --list --show-origin
这条会把文件路径一起打出来，系统级的/etc/gitconfig、用户级的~/.gitconfig、仓库级的.git/config分得清清楚楚。之前碰到过一台构建机，全局配置里干干净净，系统级配置里却躺着一个三年前写死的旧代理地址，Git就一直往那个已经不存在的地址上撞。
连接类：先证明网络本身通不通
别在Git里打转，用curl把链路先测明白：
curl -I https://github.com curl -vI https://github.com 2>&1 | head -30
curl也超时，那就是网络或DNS的事，跟Git配置没关系，去查DNS、hosts、出口防火墙。curl秒回200而Git超时，问题基本出在Git自己的代理或协议配置上。
代理：配了比没配更容易出事
需要走代理的场合（公司内网出口、本机开着科学上网工具），把地址明确写进去：
git config --global http.proxy http://127.0.0.1:7890 git config --global https.proxy http://127.0.0.1:7890
不想用了就撤掉：
git config --global --unset http.proxy git config --global --unset https.proxy
这里有个容易漏的点：Git同时认配置项和环境变量，http_proxy、HTTP_PROXY、https_proxy、HTTPS_PROXY四个都会被读。遇到过全局配置已经unset干净，shell里却export着一个http_proxy，Git照走那个代理，看起来就像配置没生效。用env | grep -i proxy把环境变量也扫一遍。
只想让GitHub走代理、内网GitLab直连，可以对单个host单独设：
git config --global http.https://github.com.proxy http://127.0.0.1:7890
代理地址里带用户名密码时，@、:、#这些字符必须做百分号编码，否则URL会被截断解析，报出来的错还特别具有误导性。
HTTP/2握手失败：改回HTTP/1.1试试
这一条见过太多次，也最容易被忽略。Git从2.27.0起把http.version的默认值改成了HTTP/2，而部分企业防火墙、透明代理、老旧的代理软件处理HTTP/2的帧时会有问题，表现就是连接卡住几十秒，然后报Couldn't connect to server。
git config --global http.version HTTP/1.1
改完再clone，一批"网络时好时坏"的怪现象当场消失。要恢复就写git config --global http.version HTTP/2。
想看Git在传输层到底干了什么，开verbose：
GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone https://github.com/x/y.git
输出里能看到实际连的IP、TLS握手过程、代理CONNECT请求，比猜快得多。仓库太大、拉到一半断掉的，用浅克隆先把代码拿到手：
git clone --depth 1 https://github.com/x/y.git
证书类：unable to get local issuer certificate
这类报错的原文通常是：
fatal: unable to access 'https://github.com/x/y.git/': SSL certificate problem: unable to get local issuer certificate
在部分Linux发行版上长成另一副样子：
fatal: unable to access 'https://...': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
意思都是Git找不到能签发对端证书的根证书。最常见的原因是ca-certificates包太久没更新，或者精简过的容器镜像里压根没装。Ubuntu 22.04、24.04，与Rocky Linux 9上包名都一样：
apt install -y ca-certificates && update-ca-certificates dnf reinstall -y ca-certificates
装完还不行，就把CA文件路径显式指给Git。Debian系在/etc/ssl/certs/ca-certificates.crt，RHEL系在/etc/pki/tls/certs/ca-bundle.crt：
git config --global http.sslCAInfo /etc/ssl/certs/ca-certificates.crt
公司内网的自签证书
流量被内部SSL审计设备重新签名的环境里，浏览器没事（它读系统证书库），Git却报unable to get local issuer certificate。把公司根证书加进信任列表就行：
cp corp-ca.crt /usr/local/share/ca-certificates/ update-ca-certificates git config --global http.sslCAInfo /etc/ssl/certs/ca-certificates.crt
Windows上Git for Windows默认用schannel，读的是Windows证书存储，把根证书装到"受信任的根证书颁发机构"即可；装Git时如果选了OpenSSL，就得显式指定：git config --global http.sslCAInfo "C:/ca/corp-ca.pem"。sslBackend可以在openssl与schannel之间切换，但同一台机器上别在三处配置里各设一遍，会报Could not set SSL backend to 'schannel': already set。
临时绕过，以及它的代价
赶时间的时候可以关掉校验：
GIT_SSL_NO_VERIFY=true git clone https://github.com/x/y.git git config --global http.sslVerify false
只建议在确认网络环境可信、且只是临时拉一次代码时用。全局关掉之后，中间人攻击就完全没有防线了，用完记得git config --global --unset http.sslVerify改回来。
还有一个看着像证书问题、其实是时间问题的报错：SSL certificate problem: certificate is not yet valid。主板电池没电、容器没做时间同步，系统时间回到出厂日期，任何证书都会被判"还没生效"。date看一眼，对不上就用chronyd或ntpdate同步。
版本号与发布日期截至2026年9月。排查顺序就按上面这个走：先用报错串分诊，再验网络，再查代理，末了才动证书。