代理配置残留是最常见原因，需先检查并清除全局及环境变量中的http.proxy、https.proxy设置；其次排查dns、ssl证书、ssh端口屏蔽、凭证失效或git版本过低等问题。
代理配置残留是最常见原因
绝大多数 fatal: unable to access 报错，其实不是网络不通，而是 Git 读到了错误或过期的代理设置。哪怕你没主动配过，某些代理软件（如 Clash、Clash for Windows、Surge、SSR 客户端）会静默写入系统环境变量或 Git 全局配置。
先查有没有残留：
-
git config --global --get http.proxy和git config --global --get https.proxy—— 有输出就说明被设过 -
env | grep -i proxy—— 看环境变量里是否混着http_proxy或https_proxy
只要任一地方有值，且你当前不需要代理（比如在家直连、公司内网），就该立刻清掉：
git config --global --unset http.proxygit config --global --unset https.proxy-
unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY（仅当前终端生效）
注意：git config --global --edit 打开后手动删掉 [http] 或 [https] 段里的 proxy = ... 行，比命令更稳妥——有些配置藏在局部仓库或系统级配置里，--global 命令未必覆盖全。
HTTPS 协议在部分网络下天然不稳定
国内不少校园网、企业防火墙、运营商出口会干扰 HTTPS 的 TLS 握手，尤其是对 github.com:443 的连接。这不是 Git 问题，是网络策略问题。此时 curl -v https://github.com 也常卡在 SSL_connect 或直接报 Connection reset。
绕过方式很直接：
- 改用 SSH 协议：
git remote set-url origin git@github.com:user/repo.git（前提是已配好 SSH 密钥） - 临时禁用 SSL 验证（仅调试用，不推荐长期）：
git config --global http.sslVerify false；验证完务必git config --global http.sslVerify true恢复 - 避免降级到 HTTP（
http://）——GitHub 已强制重定向到 HTTPS，且 HTTP 不再支持密码认证
SSH 方式最省心：一次配密钥，后续所有操作免输密码、不走 HTTPS 栈、不受 TLS 干扰。
Git 自身依赖缺失或版本太老
老系统（如 CentOS 7 默认 Git 1.8.x）或手动编译安装时漏装依赖，会导致 unable to access 后跟 Failed to connect to ... Could not resolve host 或干脆无细节。这不是配置问题，是底层库没链上。
重点检查三件事：
- 运行
git --version，低于2.17建议升级——旧版 libcurl 支持弱，易在 TLS 1.3 环境下握手失败 - 执行
git clone https://github.com/xxx/yyy.git失败后，立刻跑strace -e trace=connect,socket git clone https://github.com/xxx/yyy.git 2>&1 | tail -20，看是否卡在connect( ..., {sa_family=AF_INET, sin_port=htons(443), ...})—— 若没调用connect，大概率是 DNS 或 SSL 库问题 - 确认
libcurl和openssl版本够新：curl --version和openssl version；CentOS/RHEL 上补依赖：yum install curl-devel openssl-devel zlib-devel
别信“重装 Git 就行”——如果系统级 libcurl 还是旧的，新 Git 编译出来照样跪。
凭证失效或权限被 revoke
报错里带 403 Forbidden 或 Authentication failed 时，unable to access 实际是权限层拦截，不是连接层失败。常见于：
- GitHub 已停用账户密码登录，但你还存着旧凭据（
git credential store里记的是密码） - 个人访问令牌（PAT）过期、权限不足（缺
reposcope）、或被手动 revoke - 使用 SSO 的企业 GitHub，令牌未通过 SAML 单点登录授权
验证方式简单：
-
git ls-remote https://github.com/user/private-repo.git—— 直接触发认证流程，比clone更轻量 -
git credential reject，然后输protocol=httpshost=github.comusername=yourname
（空行）—— 主动删掉旧凭据 - 重新生成 PAT，勾选
repo和workflow（如需 CI），再用git clone https://<token>@github.com/user/repo.git</token>测试
最容易忽略的一点：GitHub 的 PAT 默认不带 workflow 权限，但如果你克隆的是含 Actions 的私有仓库，没这个权限照样 403。
