域名解析失败时先用nslookup测试，dns异常则换公共dns或检查hosts；ssh失败优先验证端口连通性与私钥600权限；https证书错误应配置sslcainfo而非禁用验证；url需规范编码并核对git remote get-url结果。
域名解析失败：先确认 nslookup 或 ping 能否通
Git 报 unable to access 或直接卡在连接阶段，大概率不是 Git 本身问题，而是系统连域名都解析不出来。这时候别急着改 git remote set-url 或重配密钥。
直接在终端执行：nslookup git.example.com（把 git.example.com 换成你实际的远程域名）。如果返回 server can't find 或超时，说明 DNS 解析失败。
- 先试公共 DNS，比如
nslookup git.example.com 8.8.8.8，能通就说明本地 DNS 有问题 - 检查
/etc/hosts（macOS/Linux）或C:\Windows\System32\drivers\etc\hosts（Windows），删掉可能存在的错误映射 - 公司内网常见情况：该域名只在内网 DNS 可解析，切手机热点再试一次，能通就坐实是网络环境限制
ssh -T git@host 不成功？重点看端口和密钥权限
SSH 方式失败时，Permission denied (publickey) 很容易被误判为“密钥没加”，但更常踩的坑是端口不通或私钥权限太松。
运行 ssh -T -p 22 git@github.com（或你的实际 host），如果卡住或报 Connection timed out，大概率是 22 端口被防火墙屏蔽——尤其在企业网络、校园网或某些云主机出口策略下。
- 验证方式：用
telnet git.example.com 22测试端口连通性（若无 telnet，可用nc -zv git.example.com 22） - 私钥必须是
600权限：chmod 600 ~/.ssh/id_rsa，否则 OpenSSH 会直接拒绝加载 - 公钥是否已正确粘贴到平台？注意不要多空格、少换行，也不要用 GitHub 的“GitHub CLI”方式生成的密钥去配 GitLab/GitCode
HTTPS 报证书错误或凭据拒绝？别急着关 sslVerify
fatal: unable to access 'https://...': SSL certificate problem 这类错误，90% 出现在用了中间人代理（如企业防火墙）、自建 Git 服务或老旧 OpenSSL 版本的机器上。
直接执行 git config --global http.sslVerify false 是危险操作——尤其当你用账号密码认证时，后续所有 HTTPS 请求都会明文传密码。
- 更安全的做法：导出企业代理的根证书为 PEM 文件，然后指定路径：
git config --global http.sslCAInfo /path/to/company-ca.pem - 凭据失效常见于 Windows 凭据管理器存了旧密码，用
git credential reject清理（输入完回车后手动填protocol=https、host=git.example.com） - URL 中含
@或/？比如https://user@domain.com/repo.git，必须确保@已 URL 编码为%40，否则 Git 会截断认证信息
远程地址看似正确，但 git remote -v 显示异常？立刻核对真实值
复制粘贴仓库地址时，肉眼难辨的错误极多：漏 .git 后缀、混用 SSH/HTTPS 地址、中文全角符号、末尾多空格。这些不会报语法错，但会导致连接完全走错路径。
执行 git remote get-url origin 查看 Git 实际存储的 URL，而不是靠记忆或网页复制的内容。
- SSH 地址应形如：
git@gitcode.net:username/project.git，不是https://gitcode.net/username/project - HTTPS 地址必须带
.git后缀，且协议头明确写https://，不能是http://（多数平台已禁用） - 改地址用
git remote set-url origin <new-url></new-url>，别手动编辑配置文件，易引入不可见字符
真正卡住的地方，往往不在 Git 命令本身，而在它背后那层被忽略的网络链路：DNS → 端口可达性 → TLS 证书信任链 → 凭据缓存状态。每一步都得用对应工具直击验证，而不是靠“试试看”。
