导致端口22被拒的原因其实不难排查：可能是公司防火墙默认拦截了22端口（很多企业内网都有这个限制），也可能是本地SSH密钥没正确添加到GitHub账号，或是config配置文件遗漏了关键参数。去年帮同事处理这个问题时，他折腾了一下午，最后发现只是少了一行端口转发设置。
本文将用最直观的方式帮你解决问题：先通过3个小实验快速判断是网络环境还是配置问题，再详解3种高效修复方案——包括零基础也能操作的端口443切换法（不用改防火墙设置）、SSH密钥全流程检查清单（附GitHub密钥验证工具），以及config文件3行代码修改模板。每个步骤都有具体命令和效果对比，确保你跟着做5分钟内恢复连接。无论你是刚接触Git的新人，还是需要快速解决团队问题的技术负责人，这些方法都经过实战验证，帮你绕过“端口被拒”的坑，让代码管理回归顺畅。
你知道吗，第一次改SSH配置文件的时候，我还真琢磨过要不要重启电脑——毕竟以前改系统设置总习惯重启生效。后来试了才发现完全不用，SSH这东西特别“聪明”，配置文件是实时读取的。你在~/.ssh/config里写完那几行端口设置后，直接回到终端，重新敲一遍连接命令就行，比如“ssh -T git@github.com”，系统会自动加载新的配置，根本不用关终端或者重启电脑。我上次帮实习生改完配置，他还紧张地问“要不要保存退出编辑器？”，其实只要用Ctrl+S保存了文件，哪怕编辑器还开着，重新执行命令就能生效，快得很。
要是重新执行命令后还是提示“Connection refused”，别慌，这时候“-v”参数就派上用场了。你在命令前面加个“-v”，变成“ssh -v git@github.com”，终端会像“说悄悄话”一样把整个连接过程都打印出来——从用哪个端口连接、加载了哪个密钥文件，到和GitHub服务器的每一步交互，都看得清清楚楚。我上次遇到个情况，明明改了443端口，日志里却显示还在用22端口，后来才发现是config文件里多打了个空格，导致配置没被正确识别。你顺着日志往下找，看到“Connecting to github.com port 443”或者“Authenticated to github.com”，就说明配置生效了；要是看到“port 22: Connection refused”，那肯定是配置没加载对，回去检查一下文件路径和格式就行。
为什么SSH连接GitHub时会出现端口22被拒的错误？
常见原因包括：网络防火墙（如公司内网）拦截22端口访问、本地SSH密钥未正确关联GitHub账号、SSH配置文件（config）缺少端口转发参数，或网络环境对标准端口的特殊限制。这些问题会导致SSH客户端无法通过默认22端口与GitHub服务器建立连接，从而触发“Connection refused”提示。
除了端口443，还有其他端口可以用于SSH连接GitHub吗？
目前GitHub官方主要支持22（标准SSH端口）和443（HTTPS端口）用于SSH连接。其中443端口因常用于网页访问，被防火墙拦截的概率较低，是替代22端口的首选方案。其他端口（如80）未被GitHub官方开放用于SSH服务，不 尝试。
如何验证SSH密钥是否正确添加到GitHub账号？
可通过两步验证：①本地终端执行命令“ssh -T git@github.com”，若返回“Hi [用户名]! You’ve successfully authenticated…”则说明密钥有效；②登录GitHub账号，进入“Settings > SSH and GPG keys”，检查已添加的密钥列表中是否包含本地生成的公钥（可通过“cat ~/.ssh/id_rsa.pub”查看公钥内容并比对）。
公司防火墙拦截端口22时，除了切换端口还有其他解决办法吗？
除切换至443端口外，可联系公司IT部门申请临时开放22端口访问权限（适合长期固定环境），或使用SSH代理工具（如ProxyChains）通过允许的端口转发流量。但从操作便捷性和成功率来看，修改配置文件切换至443端口是最快速的临时解决方案，无需额外工具或权限申请。
修改SSH配置文件后需要重启电脑吗？
不需要重启电脑。修改~/.ssh/config文件后，只需在终端重新执行SSH连接命令（如“ssh -T git@github.com”）即可让新配置生效。若仍提示错误，可通过“ssh -v git@github.com”查看详细连接日志，定位配置是否正确加载。
