绝大多数fatal: unable to access错误源于网络层阻塞，而非git故障；需依次排查url格式（含协议、编码、ssh/https匹配）、代理冲突（环境变量/.gitconfig/系统级三重检查）、dns解析失败及ssl证书验证问题。
绝大多数 fatal: unable to access 错误，不是 Git 本身坏了，而是它根本没发出去请求——卡在 DNS、代理、SSL 或 URL 解析环节。
检查远程 URL 是否被手动改错
很多人复制粘贴时漏掉 https:// 前缀，或把 @ 写成 %40 却没做 URL 编码，又或者混用了 SSH 和 HTTPS 格式却没配对应认证方式。
- 用
git remote get-url origin看真实值，别信自己“记得”的地址 - 如果输出是
git@github.com:user/repo.git但你没配 SSH 密钥，就必然失败；换成https://github.com/user/repo.git并确保有 PAT（个人访问令牌） - URL 中含
@、/、空格等字符？必须 URL 编码，比如邮箱user@example.com要写成user%40example.com
代理设置冲突是最常见的真凶
Git 会同时读取三处代理配置：环境变量（http_proxy、https_proxy）、.gitconfig 里的 http.proxy / https.proxy、以及系统级网络代理。只要其中一处指向了已关闭/错误的代理端口，就会卡死在连接阶段。
- 先查环境变量：
env | grep -i proxy，若输出非空，用unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY清掉 - 再查 Git 配置：
git config --global --get http.proxy和git config --global --get https.proxy，有输出就用--unset清除 - 注意：
http.proxy不影响 HTTPS 请求，https.proxy才管 HTTPS；两者都得清，不能只清一个 - 如果确实需要代理（如公司内网），务必确认代理服务正在运行，且端口（如
127.0.0.1:1080）可连：curl -x http://127.0.0.1:1080 -I https://github.com
DNS 失败和 SSL 证书问题要分开看
Could not resolve host 和 SSL certificate problem 是两类完全不同的底层错误，混在一起排查只会浪费时间。
- 看到
Could not resolve host：说明请求根本没发出去，本地连github.com的 IP 都查不到。立刻执行ping github.com或nslookup github.com。失败就查/etc/hosts（macOS/Linux）或C:\Windows\System32\drivers\etc\hosts（Windows），删掉所有指向github.com的异常行 - 看到
SSL certificate problem：说明 DNS 成功、TCP 连上了，但证书校验失败。优先更新系统 CA 证书包（Ubuntu：sudo apt install ca-certificates；macOS：brew install ca-certificates），再配git config --global http.sslCAInfo指向新证书路径；禁用验证（http.sslVerify false）仅限临时调试，切勿长期开启 - 企业内网常见中间人代理，此时必须导出其根证书 PEM 文件，并通过
http.sslCAInfo显式指定
真正难定位的是「看起来能通，但每次都在 recv 阶段断开」，比如报 Recv failure: Connection was reset。这往往意味着防火墙主动 RST 了连接——特别是公司出口策略只放行 443，而你用 SSH（端口 22）或自定义代理端口（如 1080/7890）时。这时候换 HTTPS + PAT、或改用 GitHub 支持的 SSH over HTTPS（ssh://git@ssh.github.com:443）更可靠。
