“Repository not found”是远程服务明确拒绝请求，非本地Git故障；需逐层排查：①检查remote URL拼写、大小写及.git后缀；②清除过期凭据并用PAT重认证；③验证SSH密钥是否绑定正确账户；④排除代理/DNS劫持导致的请求转发。
“Repository not found”不是 Git 本身找不到命令，而是远程服务（GitHub/GitLab/自建 Git 服务器）明确拒绝了你的请求——它压根没认出你要访问的仓库，或者根本没让你进门。直接改 URL 或删凭据往往治标不治本，得按真实链路一层层筛。
检查 remote URL 是否拼错或大小写不符
Git 对远程仓库地址极其敏感：路径多一个空格、少一个 .git 后缀、用户名或仓库名大小写不对（尤其在 GitLab 或自建服务上），都会返回 “Repository not found”。浏览器能打开 ≠ Git 能访问，因为浏览器走的是网页端，而 Git 走的是 API 或 SSH 端口。
- 运行
git remote -v查看当前配置的fetch和push地址，确认是否和仓库主页显示的克隆地址完全一致 - 对比时注意：
https://github.com/USER/repo.git和https://github.com/user/repo.git是两个不同仓库（GitHub 虽不区分用户名大小写，但部分私有 Git 服务会严格校验） - 如果用的是 HTTPS 地址，确保结尾带
.git；SSH 地址如git@github.com:USER/repo.git中的冒号后是路径，不能写成斜杠
确认凭据是否过期或绑定错误账号
2021 年 8 月起 GitHub 已全面禁用密码认证，GitLab 也普遍要求 Personal Access Token（PAT）或 OAuth Token。如果你之前保存过旧凭据，Git 会自动复用——结果就是用 A 账号的 token 去访问 B 账号下的私有仓库，服务端直接返回 “Repository not found”，而非 “Authentication failed”。
- Windows：打开「凭据管理器」→「Windows 凭据」→ 删除所有含
github.com、gitlab.com或你公司 Git 域名的条目 - macOS：打开「钥匙串访问」→ 搜索域名 → 删除对应「互联网密码」条目
- Linux：执行
echo -e "protocol=https\nhost=github.com" | git credential reject（把github.com替换为实际域名） - 删完后执行
git fetch，系统会重新弹出登录框——此时密码栏必须填 PAT（不是登录密码），且该 token 需有repo权限
验证 SSH 密钥是否生效且关联正确账户
用 SSH 克隆却报 “Repository not found”，大概率不是网络问题，而是服务端压根没把你的公钥和目标账户绑定。Git 服务器收到 SSH 连接后，会查密钥对应的用户，再查该用户是否有权访问那个仓库——中间任一环断掉，都返回同样错误。
- 运行
ssh -T git@github.com（或你的 Git 服务商域名），成功应返回类似Hi username! You've successfully authenticated... - 如果提示
Permission denied (publickey)，说明本地没加载密钥，或~/.ssh/config配置有误 - 如果返回
Hi other_user! You've successfully authenticated...，说明你当前 SSH key 绑定的是另一个账号——需生成新密钥并添加到正确账户，或在~/.ssh/config中为不同域名指定不同密钥 - GitLab 自建实例还需确认：SSH host 是否配置为
git@gitlab.example.com，而非root@gitlab.example.com（后者常见于误配）
排查是否因网络代理或 DNS 导致请求被劫持/转发
某些企业网络或校园网会拦截或重写 Git 请求，尤其是 HTTPS 协议下，可能把你的 https://gitlab.company.com 请求悄悄转到内网镜像站，而该镜像未同步目标仓库，就返回 “Repository not found”。
- 临时关闭代理：运行
git config --global --unset http.proxy和git config --global --unset https.proxy - 加
-v参数看真实请求路径：git -c core.sshCommand="ssh -v" ls-remote git@github.com:user/repo.git（SSH）或curl -v https://github.com/user/repo.git/info/refs?service=git-upload-pack（HTTPS） - 对比 curl 输出中的
HTTP/2 404或跳转地址，确认是否被中间设备改写 - 若公司使用自签名证书，还需配置
git config --global http.sslVerify false（仅限可信内网，勿用于公网）
最容易被忽略的一点：这个错误永远不来自本地 Git 客户端本身，它只是个信使。真正决定成败的是远程服务的路由规则、权限模型和认证链路——所以别急着重装 Git 或重装 IDEA，先搞清你发出去的请求，到底被谁、以什么身份、在哪个环节拒之门外。
