type
status
date
slug
summary
tags
category
icon
password
昨天还能提交，今天突然就不行了。
看到这行报错的时候，我第一反应是——我改了什么？
回想了一遍，什么都没动。SSH key 没变，网络也没断，GitHub 也没挂。那问题出在哪？
22 端口，说封就封
140.82.114.3 是 GitHub 的服务器 IP。22 是 SSH 的默认端口。Connection closed，意思是连接被主动关闭了，不是超时，不是拒绝，是直接切断。
这个行为有一个经典名字：GFW 的随机性。
国内对 GitHub 22 端口的干扰一直存在，但不是完全封死的那种。它是时断时续的——昨天通，今天不通，明天可能又通了。运营商的路由策略会变，高峰时段的拥塞也会导致连接成功率骤降。
所以这不是你的问题，也不是 GitHub 的问题。是网络环境的问题。
但抱怨没用，得修。
排查过程
先确认问题是否真的在 SSH 连接层面：
返回：
确认了。22 端口在当前网络环境下不可用。
解决思路很简单：GitHub 提供了一个备用地址
ssh.github.com，走 443 端口。443 是 HTTPS 的标准端口，基本不会被封。配置方式是在
~/.ssh/config 里加一段：意思是：所有发往
github.com 的 SSH 连接，实际上走 ssh.github.com:443。对上层工具（git、Sourcetree）完全透明，不需要改 remote URL。找到正确的密钥
配置写好之后，再跑
ssh -T git@github.com，这次报了另一个错：443 端口通了，但认证失败了。
Sourcetree 之前自动生成过一个叫
ichangyou-GitHub 的密钥对，但这个文件已经不在了。~/.ssh/ 目录下实际存在的是 id_rsa 和 id_ed25519。逐一试：
id_ed25519 的注释是 564448895@qq.com，对应另一个 GitHub 账号，不是仓库所在的 ichangyou 账号。id_rsa 才是对的。把配置里的 IdentityFile 改成 ~/.ssh/id_rsa，问题彻底解决。三步总结
第一步：确认是端口问题，不是代码或权限问题
第二步：在
~/.ssh/config 里配置 443 端口第三步：确认哪个密钥对应 GitHub 账号
一个值得记住的事
很多开发者在遇到
Permission denied (publickey) 时，第一反应是去重新生成密钥、重新注册，折腾半小时。但实际上，很多时候密钥本身没问题。问题只是：密钥没有被加载进 SSH agent（
ssh-add 漏做了），或者配置文件指向了不存在的路径。排查 SSH 问题的正确顺序是：
- 先确认端口是否可达
- 再确认密钥是否加载（
ssh-add -l）
- 最后才考虑密钥是否正确
按这个顺序来，大多数问题很快就能定位。
443 端口的方案不是临时补丁，是长期可靠的做法。配一次，以后不用再管这个问题。
2026.03.04 19:38
沪 · 汇金路KFC
Catalog