connection refused 报错多因本地配置异常：代理残留（git config http.proxy）、hosts 文件错误映射、ssh 配置缺失 hostname 导致解析为 127.0.0.1；需分协议排查 http(s) 与 ssh 路径差异。
绝大多数 Connection refused 报错，根本不是 GitHub 或 GitLab 服务器挂了，而是你本地的网络路径被“卡”在了某个环节——最常见的是代理配置残留、/etc/hosts 错误映射、或 SSH 配置把请求导向了本地回环地址。
检查是否残留了失效的代理配置
Git 的 http.proxy 和 https.proxy 一旦设过，就会长期生效，哪怕你关掉了 Clash、Clash for Windows、Proxifier 或其他代理软件。只要代理进程没在监听指定端口（比如 7890、7897、31181），Git 就会尝试连 127.0.0.1:端口号，然后报 Connection refused。
执行这两条命令确认：
git config --global --get http.proxy<br>git config --global --get https.proxy
如果输出类似 http://127.0.0.1:7890 或 socks5://127.0.0.1:7890 这样的内容，说明代理还在生效。
- 直接取消：运行
git config --global --unset http.proxy和git config --global --unset https.proxy - 若只对当前仓库生效，去掉
--global，改用--local - 不确定是否还有其他层级（如系统级）配置？可加
--show-origin查看配置来源：git config --global --get --show-origin http.proxy
排查 /etc/hosts 或 C:\Windows\System32\drivers\etc\hosts 是否错误重定向
有些教程建议手动把 github.com 映射到某个 IP 来绕过 DNS 污染，但一旦该 IP 失效（GitHub 经常轮换 IP），或者你复制粘贴时多加了空格、用了中文符号，就会导致 Git 请求发向一个不可达地址，甚至被解析成 127.0.0.1 ——这时 ssh -T git@github.com 会显示 connect to address 127.0.0.1 port 22: Connection refused，而 ping github.com 却能通，非常迷惑。
打开 hosts 文件（Linux/macOS 在 /etc/hosts，Windows 在 C:\Windows\System32\drivers\etc\hosts），查找包含 github.com 或 gitlab.com 的行。
- 临时注释掉所有相关行（行首加
#），保存后重试git clone或ssh -T git@github.com - 不要盲目追加 IP；更稳妥的方式是先用
nslookup github.com或dig github.com +short获取当前有效 IP，再决定是否写入 - 注意：hosts 文件里不能有 IPv6 地址混用 IPv4 行（比如
::1 github.com和127.0.0.1 github.com同时存在，可能触发优先匹配本地回环）
验证 SSH 配置是否把 github.com 指向了 localhost
如果你改过 ~/.ssh/config，尤其加过 Host github.com 块，但漏写了 Hostname，OpenSSH 默认会把 Host 名当主机名解析，结果就是尝试连 github.com 的 A 记录——而如果你 hosts 里又把它指向了 127.0.0.1，就彻底闭环失败了。
运行 ssh -vT git@github.com，观察日志里出现的 Connecting to github.com [xxx.xxx.xxx.xxx] port 22 中的 IP 是什么：
- 如果是
[::1]或[127.0.0.1]，基本锁定是 hosts 或 SSH config 问题 - 正确配置应类似：
Host github.com<br> Hostname ssh.github.com<br> Port 443<br> User git
- 切记：修改完
~/.ssh/config后，必须用ssh -T git@github.com测试，而不是直接跑git clone；因为后者不走 SSH 配置里的Port，除非 URL 显式写成git@ssh.github.com:xxx/yyy.git
区分错误来源：HTTP(S) vs SSH 报错要分开看
Failed to connect to github.com port 443: Connection refused 和 ssh: connect to host github.com port 22: Connection refused 看似一样，实则路径完全不同：
- 前者走的是 Git 的 HTTP 客户端（libcurl），受
http.proxy、系统 DNS、防火墙出站策略影响 - 后者走的是 OpenSSH 客户端，受
~/.ssh/config、/etc/hosts、本地 SSH 服务状态（极少数情况）影响 - 同一台机器上，可能 HTTPS 克隆成功，但 SSH 失败；也可能反过来——所以别看到 “Connection refused” 就统一删代理，先看报错里明确写的协议和端口
真正容易被忽略的点：很多用户在公司网络或校园网下，22 端口被防火墙屏蔽，但 443 端口可用；此时只配 SSH 的 Port 443 不够，还必须确保 Hostname 指向 ssh.github.com，否则 OpenSSH 仍会尝试直连 github.com:443（这个地址不响应 SSH 握手）。
