url中多写@符号会导致git将@后内容误判为主机名，如https://@git.corp.shiqiao.com会被解析为域名"@git.corp.shiqiao.com"而非"git.corp.shiqiao.com"，属url语法错误，常见于空变量拼接或ssh转https时误留@。
检查 URL 中是否多写了 @ 符号
这是最常被忽略的根源：比如你写 git clone https://@git.corp.shiqiao.com/repo.git，Git 会把 @git.corp.shiqiao.com 当作主机名去解析，而不是 git.corp.shiqiao.com。它不是 DNS 故障，是语法错误。
常见场景包括：
- CI 脚本里
$USER变量为空，拼出https://@domain - 从 SSH 格式（
user@git.corp）误迁到 HTTPS 地址时多留了@ - IDE 自动生成 clone URL 逻辑有 bug，未过滤空用户名
验证方式：手动执行 nslookup git.corp.shiqiao.com 或 ping git.corp.shiqiao.com，如果能通，基本可锁定是 URL 写错了。
确认 Git 是否被代理干扰（尤其是 socks5 类错误）
报错里出现 Could not resolve host: socks5，说明 Git 正在尝试把 socks5 当成域名解析——这几乎一定是代理配置残留导致的。
执行以下命令清理：
git config --global --unset http.proxygit config --global --unset https.proxy- 如需保留代理，应设为合法地址，例如：
git config --global https.proxy http://127.0.0.1:7890
注意：socks5://127.0.0.1:1080 这类写法在旧版 Git（proxy-command 配置。
绕过 DNS：用 IP 直连 + hosts 映射
当确认域名本身无法被系统解析（比如内网 Git 服务没配 DNS、或公共平台如 github.com 被拦截），可用 IP 替代方案。
操作步骤：
- 先
ping github.com或nslookup github.com拿到真实 IP（如140.82.112.3） - 编辑系统
hosts文件：
– Windows：C:\Windows\System32\drivers\etc\hosts
– macOS/Linux：/etc/hosts - 追加一行：
140.82.112.3 github.com（IP 和域名间用 Tab 或空格分隔）
注意：修改 hosts 需管理员权限；某些安全软件会锁定该文件，需临时禁用再编辑。
企业内网环境要额外验证 DNS 解析路径
如果你在公司内网，Could not resolve host 很可能不是你本地的问题，而是 DNS 查询被截断或转发失败。
关键检查点：
- 运行
cat /etc/resolv.conf（Linux/macOS）或ipconfig /all（Windows），看当前 DNS 服务器是否为企业指定地址 - 尝试用内网 DNS 服务器直接查：
nslookup git.corp.shiqiao.com 10.10.10.1（把10.10.10.1换成你们 IT 提供的 DNS IP） - 有些企业用内部 hosts 重定向或 HTTP 代理网关，此时即使 ping 不通，
curl -v https://git.corp.shiqiao.com可能反而成功——说明走的是代理而非直连 DNS
真正麻烦的情况是：DNS 能解析、curl 能通、但 git clone 仍报错。这时候大概率是 Git 的 SSL/TLS 握手被中间设备干扰，得配合 git -c http.sslVerify=false clone ... 测试（仅临时诊断，勿长期关闭校验）。
