为什么SSH 443端口能稳定连接GitHub

说起SSH连GitHub这事，我真的有一肚子苦水要倒。以前用默认的22端口，每次推代码都像开盲盒——运气好时几秒搞定，运气不好就卡在“Connection timed out”上，尤其晚上八九点，基本别想顺利push。后来听人劝改了443端口，嘿，一下子就稳了，连带着我对GitHub的怨气都消了大半。但问题来了：为什么都是SSH，换个端口就天差地别？今天咱们就掰扯掰扯这背后的门道。

为什么22端口总是抽风？

说白了，22端口是SSH的“默认身份证”，运营商一看就知道你在搞远程连接。国内跨境网络本来就挤，运营商为了“优化”带宽，经常对22端口做特殊“关照”——要么限速，要么直接丢包，甚至整段拦截。你想想，Git推送本质上就是一条长连接，数据包在22端口上被反复折腾，超时、中断那都是家常便饭。更坑的是，有些防火墙看到22端口就直接“一刀切”，连握手的机会都不给。

443端口凭什么稳如泰山？

443是HTTPS的专用端口，全球互联网上99%的加密网页流量都走它。运营商敢动443？除非他们想让全国人民刷不出网页。所以443端口在跨境链路上基本是“绿灯通道”，极少被人工干预。GitHub官方也看准了这点，专门在ssh.github.com上开放了443端口的SSH服务。你只要在配置里把Hostname改成ssh.github.com，Port改成443，就能“借道”HTTPS的流量通道，享受和浏览网页一样的稳定性。再加上ServerAliveInterval这类保活参数，连接就很难被中途掐断。

配置简单到离谱，但效果立竿见影

说实话，改配置就两行命令的事（原文里写得很清楚，我就不重复贴了），但很多人就是卡在“懒得试”这一步。我当时改完后，第一次ssh -T git@github.com秒回“You've been authenticated”，心里那个爽啊。后来推一个几百MB的大项目，全程没断过，再也没见过“RPC failed”的报错。不过有个细节要注意：如果你本地开着代理软件，就别再给Git单独配代理了，否则两个虚拟通道叠在一起反而会卡。让SSH 443走自己那条直连的“高速公路”，代理只管浏览器，互不打扰，这才是最香的组合。

一点小提醒

千万别以为换了端口就万事大吉。如果你的网络环境本身特别烂（比如公司内网限制严格），443也可能被白名单过滤。这时候可以试试HTTPS协议配token，或者干脆用国内镜像仓库做跳板。但对我这样的普通开发者来说，SSH 443已经足够把GitHub从“薛定谔的可用”变成“日常稳定”了。毕竟，谁不想在深夜写代码时，能毫无心理负担地敲下git push呢？