游戏低延迟指南标志开始排查

GitHub 访问慢怎么解决？2026 年 10 月分层排查与修复

更新于 2026-10-20 · wangluowen.com

简答：GitHub 访问慢通常只慢在网页、Git 传输、Release 文件或 SSH 其中一环。先打开 GitHub Status，再用 curl.exe 和 git ls-remote 定位；网页正常但 clone 很慢时，优先试 git clone --depth 1 或 --filter=blob:none，SSH 端口 22 超时则测试官方的 ssh.github.com:443。

定义：GitHub 访问慢，是指 GitHub 网页、Git 仓库传输、Release 文件下载或 SSH 连接出现解析慢、连接超时、传输速度低或间歇性中断，不能只用网页能否打开来判断全部服务。

30 秒速查卡：先判断到底是哪一环慢

GitHub 访问慢的 30 秒速查卡

先不要修改 Hosts，也不要立即更换仓库地址。按下面顺序执行，通常可以先把问题分成网页、Git、Release 或 SSH 四类；命令只用于定位，不代表固定测速结果。

GitHub 访问慢的 30 秒速查卡
现象先执行判断与下一步
网页打不开或打开很慢curl.exe -I -L --connect-timeout 10 --max-time 30 https://github.com/若连接或响应阶段超时，检查网络、代理、防火墙和 DNS。
网页正常，git clone 很慢git ls-remote https://github.com/OWNER/REPOSITORY.git先试浅克隆或部分克隆，再检查 Git 的 http.proxy。
Release 文件下载中断curl.exe -I -L --connect-timeout 10 --max-time 60 "URL"观察是否发生重定向，并确认重定向后的对象存储域名也能通过当前网络访问。
SSH 端口 22 超时ssh -T -p 443 [email protected]若 443 可用，可按 GitHub 文档配置 SSH over HTTPS port。

GitHub 官方说明，连接问题常与防火墙、代理服务器、企业网络或其他网络配置有关；如果 GitHub 状态正常但特定网络持续变慢，应保留测试时间和命令输出，再向网络管理员或互联网服务提供商反馈。可查看 GitHub Status 和 GitHub 连接问题排查文档。

第一步：检查状态、DNS 和 HTTPS 连接阶段

先打开 GitHub Status，以你打开页面时显示的结果为准，不要把某一时刻的状态复制成长期结论。状态正常时，再检查本地网络到 GitHub 的连接阶段。

Windows PowerShell 建议明确使用 curl.exe：

重点看是否出现 Connected to、TLS 握手完成以及最终的 HTTP/2 200、HTTP/2 301 或其他 HTTP 响应。不同系统自带的 curl 功能可能不同；如果命令提示不支持 --http2，不要据此判定网络异常，直接删除该参数后重试。

如果需要检查域名解析，可执行：

解析成功不等于后续 HTTPS 一定正常。DNS 只负责把域名解析为地址，连接建立、TLS 握手、代理转发和 Git 数据传输仍可能单独失败，因此应结合 curl 输出判断问题阶段。遇到连接超时，可继续参考本站的连接超时错误排查方法。

第二步：git clone 很慢时，选择浅克隆还是部分克隆

如果只是查看当前代码、构建项目或临时排查，不一定需要下载完整历史。Git 官方文档说明，--depth=<depth> 会创建浅克隆，把历史截断到指定提交数量；它默认还会采用单分支方式。可以先执行：

浅克隆适合临时使用，但历史不完整。如果之后需要更多历史，可以执行 git fetch --unshallow，或按需要增加深度；Git 官方文档说明，浅仓库仍可继续 fetch、pull 或逐步补全历史。相关选项见 git clone 官方文档 和 git pull 官方文档。

如果你希望保留完整提交历史，但不想首次下载所有文件内容，可以尝试部分克隆：

Git 官方文档说明，--filter=blob:none 会暂时过滤文件内容，等 Git 需要时再获取。它与浅克隆的区别是：浅克隆减少历史范围，部分克隆保留更完整的提交和目录信息，但后续查看、切换或比较某些文件时可能继续产生下载请求。相关说明见 git clone 官方文档。

两种 Git 下载优化的选择
方案主要减少什么适合场景限制
--depth 1较早的提交历史临时构建、查看当前代码旧提交、跨历史比较等操作受限
--filter=blob:none首次传输的文件内容大仓库、需要保留较完整历史后续操作可能按需下载文件内容

第三步：Git 代理为什么没生效，应该检查什么

浏览器能打开 GitHub，不代表 Git 命令会自动使用浏览器代理。Git 官方配置文档中，http.proxy 用于覆盖 Git 的 HTTP 代理设置，并同时影响通过 HTTP(S) 访问的远端；还可以使用按 URL 匹配的配置项。不要把不存在的 https.proxy 当作 Git 配置项。

先查看当前配置：

如果你有已确认可用的本地 HTTP 代理，可按实际端口配置：

PORT 必须替换成你自己的代理程序实际监听端口。若只希望 GitHub 使用代理，可以使用 URL 匹配配置：

排查结束后，如发现旧代理端口错误，可以删除全局配置：

然后重新执行 git ls-remote。Git 官方对 http.proxy、环境变量和 URL 匹配规则的说明见 git-config 官方文档。

第四步：Release 下载慢时，处理重定向、断点续传和校验

Release 文件下载慢，不能只看 GitHub 页面速度。GitHub 官方 API 文档说明，Release asset 下载可能返回重定向，也可能直接返回文件；客户端应能处理 200 或 302。因此，先复制发布页提供的真实下载地址，再检查重定向：

如果输出中出现新的对象存储域名，说明下载链路不只涉及 github.com；当前网络或代理也必须能够访问重定向后的域名。不要仅凭网页能打开，就判断 Release 文件一定能正常下载。相关说明见 GitHub Release assets API 文档。

文件下载到一半中断时，可以使用 curl 继续传输：

curl 官方文档说明，-C - 会根据已有文件位置尝试继续传输；是否能成功还取决于服务器是否支持对应的 Range 请求。下载完成后，应使用发布页提供的 SHA-256 或其他校验值核对文件，不要只按文件名判断完整性。curl 的续传说明见 curl 官方手册。

Hosts 与镜像能不能用：先讲风险，再给自查方法

Hosts 和第三方镜像并非完全不能使用，但不适合在没有核验来源时作为默认长期方案。Hosts 把域名固定到手工填写的地址，地址可能变化；镜像或中转服务还涉及可用性、隐私、文件完整性和登录信息风险。本站不提供未核实的 IP、镜像域名或可用性排名。

如果你曾经修改过 Hosts，建议先备份并检查是否存在针对 github.com、api.github.com 或其他 GitHub 域名的旧条目。Windows Hosts 文件通常位于 C:\Windows\System32\drivers\etc\hosts；修改前复制一份备份，排查完成后删除无法说明来源或已经失效的条目。macOS 和 Linux 通常检查 /etc/hosts。如果不确定某行是否应该保留，不要直接覆盖，先记录并咨询网络管理员。

如果必须评估第三方中转或镜像，至少完成三项核验：第一，确认服务方公开说明了用途、隐私和状态；第二，使用不含敏感凭据的小型公开仓库测试；第三，下载 Release 后与发布页公布的校验值核对，Git 仓库则保留原始远端地址并检查提交或标签来源。查不到公开状态或校验信息时，应标记为“未核实”，不要把它写成稳定方案。

企业网、校园网和家庭宽带，排查顺序有什么不同

不同网络环境的处理顺序
网络环境优先动作应避免的操作
家庭宽带，网页和 Git 都慢检查 GitHub Status，运行 curl.exe 和 git ls-remote，再用手机热点或其他网络对照。直接写入来源不明的 Hosts IP。
企业网络，网页可用但 SSH 超时询问管理员是否限制 22 端口，测试 HTTPS 或 SSH 443。关闭证书校验或绕过企业安全策略。
校园网，时快时慢在不同时间记录相同命令，并对比另一网络。用一次测试结果代表全天线路质量。
命令行慢、浏览器正常检查 Git 的 http.proxy、环境变量和代理监听端口。只修改浏览器代理设置。

GitHub 官方指出，企业或组织网络中的防火墙、代理服务器和网络配置可能造成连接问题；如果更换网络后恢复，应把命令输出、发生时间和网络环境交给管理员。本站的DNS 是否会改善网络延迟也可用于区分解析问题和后续传输问题。

SSH 端口 22 超时：测试 GitHub 官方的 443 方案

如果使用 SSH 克隆时出现端口 22 超时，可以先测试：

如果 22 端口被网络策略阻断，GitHub 官方提供了通过 HTTPS 端口建立 SSH 连接的方法：

主机名必须是 ssh.github.com，不是把 github.com 简单改成 443 端口。若测试成功，可在 ~/.ssh/config 写入：

首次切换主机名或端口时，SSH 可能提示核对主机指纹。应与 GitHub 发布的指纹进行比对，无法核对时不要盲目确认。GitHub 的完整命令和配置见 使用 HTTPS 端口进行 SSH 连接的官方文档。

常见错误与最后的排查顺序

  1. Could not resolve host：先检查域名解析，再检查系统 DNS、代理客户端 DNS 和企业网络策略。解析失败不等于 GitHub 服务故障。
  2. connection timed out：区分 22 端口和 HTTPS 443。SSH 22 超时可测试 ssh.github.com:443；HTTPS 也超时则检查防火墙、代理和当前网络。
  3. RPC failed 或 early EOF：先用小仓库执行 git ls-remote，再用 git clone --depth 1 判断是否与传输量有关；不要为了修复而关闭 http.sslVerify。
  4. Permission denied (publickey)：这通常是 SSH 密钥认证问题，不等同于网络速度慢。先检查公钥、SSH Agent 和远端账户，再测试 SSH 连接。
  5. 只在晚间变慢：记录至少两个时间段的相同命令输出，并换网络复测。若仅某个运营商或网络环境异常，按网络问题通用排查顺序整理证据后反馈管理员或运营商。

长期处理时，保留原始 Git URL、保留直连回退路径，并把网页、Git、Release 和 SSH 分开记录。这样即使某项配置失效，也能快速撤销，而不是反复更换未经核验的地址。

常见问题

GitHub 访问慢，改 DNS 就能解决吗？

不一定。DNS 只影响域名解析，无法直接修复 TLS、代理、Git 传输或网络拥塞。先用 curl.exe 和 git ls-remote 区分解析、连接与传输阶段，再决定是否调整 DNS。

GitHub 网页能打开，但 git clone 很慢怎么办？

先执行 git ls-remote 判断 Git 端点是否正常，再尝试 git clone --depth 1；如果需要保留更完整历史，可尝试 git clone --filter=blob:none。仍然慢时检查 Git 的 http.proxy 和环境变量。

git clone --depth 1 以后还能 git pull 吗？

可以。浅克隆不是完全不能更新，只是历史不完整；后续可以继续 pull 或 fetch，需要完整历史时执行 git fetch --unshallow。

Release 文件下载到一半中断怎么办？

先用 curl.exe -I -L 检查重定向，再使用 curl.exe -L -C - -O "URL" 尝试续传。下载完成后，应与发布页提供的 SHA-256 或其他校验值核对。

浏览器已经设置代理，为什么 Git 还是访问慢？

浏览器代理和 Git 代理相互独立。Git 应检查 http.proxy、http.https://github.com.proxy/ 以及 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 等环境变量，并确认代理端口真实可用。

要不要直接修改 Hosts 或使用 GitHub 镜像？

不建议把来源不明的 IP 或第三方镜像作为默认长期方案。Hosts 地址可能变化，镜像还涉及隐私和文件完整性；如必须评估，应先核验公开状态，用不含敏感信息的公开仓库测试，并校验 Release 文件。

SSH 连接 GitHub 超时，必须改用 HTTPS 吗？

不一定。先测试 ssh -T -p 443 [email protected]；如果可用，可按 GitHub 官方文档配置 SSH over HTTPS port。企业代理或防火墙仍可能影响该连接。

相关阅读

参考资料

  1. GitHub Status（githubstatus.com）
  2. GitHub 连接问题排查文档
  3. GitHub 使用 HTTPS 端口进行 SSH 连接
  4. GitHub Release assets API 文档
  5. git clone 官方文档（git-scm.com）
  6. git pull 官方文档（git-scm.com）
  7. git-config 官方文档（git-scm.com）
  8. curl 官方手册（curl.se）
读者交流群（Steam · 主机 NAT · 丢包交流）：t.me/wangluowen_chat