本文首发于 CSDN转载请注明出处。先说结论「GitHub 打不开」不是一个故障而是至少四类完全不同的故障——DNS 解析不出地址、TCP 连接超时、连接被中间设备重置、TLS 握手被打断。四种故障的表象都是「转圈然后失败」但报错原文不一样处理方式也不一样。所以排查的第一步不是去改 hosts而是先把报错原文看清楚。还有一条经常被忽略命令行和浏览器走的是两条路浏览器能打开不代表git clone能成功。第一步先把报错原文抄下来它对号入座不同层级的失败会吐出完全不同的字符串。先在下表里找到自己那句再往下看对应的处理。报错原文节选卡在哪一层典型原因Could not resolve host: github.comDNS 解析本地 DNS 返回了污染结果或解析超时Failed to connect to github.com port 443: Timed outTCP 连接到目标地址的 443 不通链路层面就不通Failed to connect ... after 21075 ms: Couldnt connect to serverTCP 连接同上新版 Git 换了措辞OpenSSL SSL_read: Connection reset by peer, errno 104连接被重置对端或中间设备发 RST常见于大仓库下载中途OpenSSL SSL_connect: Connection was reset in connection to github.com:443TLS 握手握手阶段就被重置比上面更早一步schannel: failed to receive handshake, SSL/TLS connection failedTLS 握手Windows 版 Git 走 schannel 后端时的同款问题SSL certificate problem: unable to get local issuer certificate证书链中间人解密设备的自签根证书没进系统信任链HTTP 403/API rate limit exceeded应用层触碰速率限制未认证 60 次/小时认证后 5000 次/小时这里有个关键区分超时Timed out和被重置reset是两种病。超时说明包发出去没有回应多为链路不可达被重置说明有设备主动发了 RST 把你掐断。后者的典型特征是「HTTPS 挂、SSH 通」——因为中间设备认 HTTPS 的特征不一定认 SSH。如果你拿到的报错不在上表里用这两条命令把原始日志打出来# 看 git 到底做了哪些 HTTP 请求GIT_CURL_VERBOSE1gitclone仓库地址# 只测连通性不下载curl-v-Ihttps://github.com第二步为什么「改 hosts」有时灵、有时一点用没有改 hosts 的原理是绕开 DNS直接把域名指向一个你认为可用的 IP。它只能解决第一层问题后面三层它一个都管不了——所以 DNS 正常但链路被重置的人改完 hosts 会发现毫无变化。它还有一个更隐蔽的副作用写死的 IP 过期之后hosts 本身就成了故障源。GitHub 官方在 API 文档里明确写了「文档里显示的 IP 值只是示例必须每次都直接查询接口拿最新值」——官方等于在承认 IP 会变。要拿当前的官方地址段可以查官方 meta 接口curl-L-HAccept: application/vnd.githubjson\-HX-GitHub-Api-Version: 2026-03-10\https://api.github.com/meta返回值里有web、api、git、pages、packages等字段各自是一组 CIDR 地址段。注意一个流传很广的误读返回结果里的ssh_keys不是 IP那是 GitHub 的 SSH 主机公钥把它当 IP 填进 hosts 是错的。改完 hosts 要刷 DNS 缓存否则可能还是走旧记录ipconfig /flushdns# Windowssudodscacheutil -flushcache;sudokillall-HUPmDNSResponder# macOS还有一处容易漏只改 github.com 是不够的。README 里的图片走的是raw.githubusercontent.comAPI 走api.github.com静态资源还有单独的 CDN 域名。只改主域名的人会遇到「网页能开但图片全裂」的情况。第三步官方支持的「SSH 走 443 端口」为什么该优先试GitHub 官方文档里有一篇专门的说明当防火墙不放行 SSH 时可以把 SSH 连接架在 HTTPS 端口上。这条是官方支持的方案比各种来路不明的加速手段可靠得多。官方文档里有一句必须看清楚的话——443 端口对应的主机名是ssh.github.com不是github.com。很多人照着博客写成 github.com 然后失败就是漏了这一点。# 先单独验证这条通道是否可用ssh-T-p443gitssh.github.com# 成功时输出Hi 你的用户名! Youve successfully authenticated...# 直接按这个形态克隆gitclone ssh://gitssh.github.com:443/OWNER/REPO.git如果长期要用写进 SSH 配置让它自动生效# ~/.ssh/config Host github.com Hostname ssh.github.com Port 443 User git首次连上会弹主机指纹确认核对一下更稳妥——官方公布了当前的三条指纹RSA 为SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2sECDSA 为SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQMEd25519 为SHA256:DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU。这条方案有两个官方标注的例外GitHub Enterprise Server 和带数据驻留的 GitHub Enterprise Cloud 不支持用企业版的同学别在这条上耗时间。第四步那些「GitHub 加速站」现在还能用吗这类站点生命周期普遍很短而网上流传的清单大多没有更新过。下面几条是当前已确认失效、但仍在大量教程里被推荐的曾经很流行的方案当前状态FastGit 系列hub.fastgit.org 等官方已发布关停公告全系不可用github.com.cnpmjs.org已失效把 ghproxy.com 当加速前缀该域名现已变成跳转落地页不再是原来的加速服务各种「GitHub 国内镜像站」多为个人公益项目随开随停不能长期依赖更稳的思路是换正规通道而不是找加速站代码托管侧把仓库导入到国内的托管平台做镜像同步这条路是官方支持的功能。要注意它有明确限制——不支持 Git LFS、大型仓库不建议用镜像。依赖下载侧pip、npm、Go、Maven 这些包管理器都有长期维护的国内镜像很多「上 GitHub 下个包」的需求其实可以完全绕开 GitHub。文件下载侧如果只是要 releases 里的某个文件能找到对应包管理器的渠道就优先走那边。最后一条安全提醒任何第三方加速站都不要用来登录账号。只读下载是它的使用边界输入密码就超出了。第五步浏览器能开为什么 clone 就是失败这是最容易让人误判的一种情况浏览器访问 GitHub 一切正常命令行却报错。原因是命令行工具默认不读系统代理设置。Git 和 GitHub CLI 都只认环境变量形态的代理配置# git 的代理配置gitconfig--globalhttp.proxy http://127.0.0.1:端口gitconfig--global--gethttp.proxy# 查看当前值gitconfig--global--unsethttp.proxy# 清掉# 环境变量形态git 与 gh 都认exportHTTPS_PROXYhttp://127.0.0.1:端口另外两个高频踩坑点VS Code 默认不继承系统代理要在设置里单独配http.proxyJetBrains 系列要在设置里手动配 HTTP 代理还要注意插件市场域名和 GitHub 域名经常一起失效。GitHub CLI 自带一套排查命令比反复猜要快gh--versiongh auth status# 看认证状态与具体错误gh api rate_limit# 判断是不是撞了速率限制GH_DEBUGapi gh api user# 打印真实 HTTP 请求与响应gh config list# 检查有没有残留的代理配置在打架GH_DEBUGapi这一条特别有用它会把真实的请求与响应打出来能直接看出失败发生在 DNS、连接还是 TLS 阶段不用再靠猜。把这五步走完绝大多数「打不开」都能定位到具体一层。真正难的不是方案本身而是先分清自己在哪一层——层错了方案再对也没用。常见问题Q改 DNS 到底有没有用只对「运营商 DNS 返回污染结果」这一类有效。超时、被重置、TLS 握手失败这三种换 DNS 不会改变结果。而且公共 DNS 本身在部分网络下并不稳定所以它是个基础动作不是万能解。QIPv6 是不是更好走不一定。官方在 meta 接口的说明里明确写了「并非所有功能都支持 IPv6」社区也普遍反馈国际 IPv6 互联质量参差。别把 IPv6 当首选方案。Q为什么昨天还能用今天就不行了最常见的原因是 hosts 里写死的 IP 过期了其次是网络环境变化换了出口、装了新的安全软件。先删掉 hosts 里的旧条目再测一遍能排掉一大半。Q企业网络下 SSH 22 端口也不通怎么办试试本文第三步的 443 端口方案。企业网络里常见的情况是 SSH 22 被拦、HTTPS 被 DPI 重置而 443 上的 SSH 往往能穿过。Q图片显示不出来但文章能看是同一个问题吗不完全是。README 图片走的是独立域名经常出现主站正常、图片域名单独失效的情况。这类要单独为图片域名做解析处理。Q装了安全软件之后开始失败怎么查先看报错里有没有SSL certificate problem或unable to get local issuer certificate。如果有基本可以确认是 HTTPS 解密扫描把证书链改坏了。临时停掉该功能验证确认后再决定是加信任还是关掉扫描。整套排查顺序、报错对照表和命令我都整理成了一份速查表存档换机器时直接照着走而不是重新摸一遍。写这类需要逐条核对官方原文与错误信息的稿子时我会用墨衍的AI 图文同步把内容一次推到多个平台留档集中更新的那几天靠发文额度提升不用排队发完再用批量 GEO 检测看看这些内容在 AI 搜索里的引用情况。墨衍会员权益 有需要可以了解。关于墨衍如果你也在多个平台发技术文章值得看看墨衍。三个最常用的权益——发文额度提升密集更新不再受限、批量 GEO 检测一次扫完全部文章的 AI 引用状态、AI 图文同步一稿多平台分发。点这里了解墨衍会员