port 22 connection timed out 表示ssh连接被网络阻断，非认证问题；主因是防火墙或企业网屏蔽22端口，可改用443端口（ssh -t -p 443 git@ssh.github.com）或切https协议解决。
port 22 Connection timed out 表示 Git 尝试走 SSH 协议（默认端口 22）连接远程服务器时，网络层面根本没通——不是认证失败，是连不上。常见于防火墙拦截、公司网络屏蔽 22 端口、或 GitHub/GitLab 等平台在某些地区对 SSH 的访问受限。
确认是否真在用 SSH 协议
很多人以为自己配置了 SSH，其实 git remote -v 显示的仍是 HTTPS 地址。SSH URL 长这样：git@github.com:user/repo.git；HTTPS 则是 https://github.com/user/repo.git。如果显示 HTTPS，那报 port 22 Connection timed out 就很奇怪——它根本不该连 22 端口。
检查方式：
- 运行
git remote -v，看输出里 origin 是不是以git@开头 - 如果不是，说明你压根没切到 SSH，错误提示可能是误读或缓存残留（比如之前手动改过 URL 又回退了）
- 如果是，继续往下排查
验证 SSH 连接是否可达
别跳过这步。直接测 SSH 通不通，能快速定位是本地网络问题还是服务端限制：
- 执行
ssh -T -p 22 git@github.com（GitHub）或ssh -T -p 22 git@gitlab.com（GitLab） - 如果卡住几秒后报
Connection timed out，说明 22 端口被阻断，不是密钥或权限问题 - 如果返回
Permission denied (publickey)，说明端口通，但密钥没配好——那是另一类问题 - 注意：有些网络会放行 443 端口的 SSH 流量（GitHub 支持），可尝试
ssh -T -p 443 git@ssh.github.com测试替代路径
绕过 22 端口：强制走 443 或切回 HTTPS
很多企业/校园网明确封了 22，但允许 443（HTTPS 和部分 SSH over TLS）。GitHub 官方支持通过 ssh.github.com:443 走 SSH：
- 先测试连通性：
ssh -T -p 443 git@ssh.github.com - 如果成功，修改远程地址：
git remote set-url origin ssh://git@ssh.github.com:443/username/repo.git - 更省事的办法是直接切回 HTTPS：
git remote set-url origin https://github.com/username/repo.git，然后配合代理或调大超时参数（见下条）
切 HTTPS 后，若仍超时，重点调这两个配置：http.lowSpeedLimit 设为 0，http.lowSpeedTime 设为 999999——这是防“慢速传输中断”的关键，不是单纯延长时间。
代理和 DNS 常被忽略的细节
即使开了代理，Git 也可能不走——因为 SSH 不受 http.proxy 控制，只影响 HTTPS 流量。所以：
- 用 SSH 时，代理要配在系统级或 SSH config 里，例如在
~/.ssh/config中加：
Host ssh.github.com ProxyCommand nc -X 5 -x 127.0.0.1:1080 %h %p
- DNS 解析失败也会表现为“超时”。可以手动查 IP：
nslookup github.com，如果失败，改用8.8.8.8或114.114.114.114作为 DNS - hosts 文件偶尔会残留旧解析，检查
/etc/hosts（macOS/Linux）或C:\Windows\System32\drivers\etc\hosts（Windows）有没有硬编码的 github.com 条目
真正卡在 port 22 的场景，90% 是网络策略限制，而不是 Git 自身配置问题。优先验证端口连通性，再决定是换协议、换端口，还是换网络环境。
