GitHub SSH 走代理与 443 端口配置
git clone 走 HTTPS 时通常能自动继承系统代理，但换成 SSH 协议后常常超时。原因有两个：SSH 不识别 http_proxy/https_proxy 环境变量，默认直连目标主机；而 GitHub SSH 的标准入口 22 端口又可能被网络封锁或限制。本文给出一段 ~/.ssh/config 配置，同时解决这两个问题：用 ProxyCommand 把 SSH 流量交给本地代理转发，并改走 GitHub 官方提供的 443 端口 SSH 入口。适用于在受限网络环境下通过 SSH 协议访问 GitHub 的开发者。
原理
两个独立的问题，各对应一个手段：
| 问题 | 手段 |
|---|---|
| SSH 不走系统代理 | ProxyCommand 指定代理命令，由它代替 SSH 建立到目标的 TCP 连接 |
| 22 端口被封或被限 | 改连 ssh.github.com:443，GitHub 官方提供的 HTTPS 端口 SSH 入口 |
ssh.github.com:443 是 GitHub 官方文档明确支持的连接方式，功能与标准 22 端口入口相同。注意两点限制：GitHub Enterprise Server 不支持此方式；首次连接 443 入口时会出现新的主机指纹确认提示，与 GitHub 官方公布指纹比对一致后确认即可。
配置
Linux / macOS（nc 版）
编辑 ~/.ssh/config：
ssh
Host github.com
Hostname ssh.github.com
Port 443
User git
# 假设代理端口为 7890，根据实际情况修改
ProxyCommand nc -X 5 -x 127.0.0.1:7890 %h %p逐行说明：
Host github.com：对目标为github.com的 SSH 连接生效。使用git@github.com:user/repo.git地址的仓库无需改动远程地址。Hostname ssh.github.com+Port 443：实际连接指向 GitHub 的 443 端口 SSH 入口。ProxyCommand：建立连接前先执行该命令，由命令负责与目标建立 TCP 通道；%h、%p分别展开为目标主机和端口。nc -X 5 -x 127.0.0.1:7890：-X 5指定 SOCKS5 协议，-x指定代理地址，按本地代理实际端口修改。
-X/-x 是 OpenBSD netcat 的选项。多数发行版的 /usr/bin/nc 已指向 openbsd-netcat；如果环境里只有 Nmap 的 ncat，等价写法是 ProxyCommand ncat --proxy 127.0.0.1:7890 --proxy-type socks5 %h %p。
Windows（Git Bash，connect 版）
Git for Windows 自带 connect 代理工具（位于 mingw64/bin，Git Bash 内可直接调用），无需额外安装：
ssh
Host github.com
Hostname ssh.github.com
Port 443
User git
ProxyCommand connect -S 127.0.0.1:7890 %h %p-S 指定 SOCKS 代理；本地代理是 HTTP 类型时改用 -H。
验证
bash
ssh -T git@github.com认证成功时 GitHub 返回 Hi <username>! You've successfully authenticated...，同时提示不提供 shell 访问，属正常输出。至此 git clone、git push 等 SSH 协议操作都会走这条通道。
结语
配置的核心是三件事：ProxyCommand 让 SSH 流量过本地代理，ssh.github.com:443 绕开 22 端口封锁，Host github.com 别名保证现有仓库的远程地址一行都不用改。三个部分相互独立：网络只封锁端口时，仅用 443 入口即可；SSH 直连本就不通时，仅靠代理转发也能解决。