Catcloud 猫云加速器 - 专业网络加速服务｜网络优化｜稳定连接返回首页

稳定连接 GitHub 的方法：从网页访问到 Clone、SSH 和下载排查

更新于 2026-10-26 · catcloud.buzz

简答：先打开 GitHub Status 排除平台故障，再按“网页—DNS—线路—Git—认证”顺序检查。网页能开但 clone 超时，优先测试 HTTPS 与 SSH 443；Release 下载中断，则单独测下载域名和持续速率，不要直接长期修改 Hosts 或使用来历不明的中转地址。

定义：稳定连接 GitHub，指在网页浏览、仓库 Clone、Push、Raw 文件和 Release 下载等具体场景中，DNS 可解析、目标端口可达、连接延迟和丢包可接受，且 Git 凭据不会被不必要地交给第三方。

先用这张表判断：你遇到的是哪一类 GitHub 连接问题？

先记录具体症状，再选择检查方法。不要把“网页加载慢”和“Git SSH 超时”当成同一个问题处理。

场景优先观察第一组检查推荐处理顺序
网页打不开或验证码反复失败DNS、浏览器扩展、组织网络规则nslookup github.com、浏览器无痕窗口检查服务状态→刷新 DNS→暂时停用影响页面的扩展→咨询网络管理员
网页能开但 Clone 超时HTTPS 或 SSH 端口是否可达git ls-remote https://github.com/OWNER/REPO.git先用 HTTPS，再测试 SSH 443
Push 失败或提示 publickey远程地址、SSH 密钥和认证状态git remote -v、ssh -T [email protected]核对远程地址→测试认证→必要时改用 HTTPS
Release 或 Raw 下载中断下载域名、持续速率、连接复用curl -L -o /dev/null -w "speed_download=%{speed_download} bytes/s\n" URL分别测试目标 URL→更换稳定线路→必要时使用断点续传工具
只有特定时段变慢网络拥塞和跨区域路径连续 ping 50 次、traceroute 或 tracert保留结果→更换网络时段或线路→向网络管理员或运营商反馈

GitHub 官方说明，连接故障常见原因包括防火墙、网络配置、组织网络和网络拥塞；官方也建议在 SSH 与 HTTPS 之间切换。可查看GitHub 连接问题故障排除。

第一步：先确认 GitHub 是否正在发生服务故障

打开GitHub Status，查看 Git Operations、Issues、Pull Requests、Packages 和 API Requests 等组件。如果对应组件显示异常，先等待官方恢复，不要急着改本机 DNS、Hosts 或 Git 全局配置。

如果状态页正常，再继续本地诊断。状态页只能说明 GitHub 官方组件的公开状态，不能替代你所在网络的连通性测试。

第二步：用 DNS、延迟、丢包和路径测试定位问题

Windows

以下命令在 PowerShell 或命令提示符中执行。目标方向使用 GitHub 域名；网关只用于判断本地 Wi-Fi 或网线是否异常。

  1. nslookup github.com
  2. nslookup github.com 1.1.1.1
  3. ping -n 50 github.com
  4. tracert github.com
  5. curl.exe -I -L -w "dns=%{time_namelookup}s connect=%{time_connect}s start=%{time_starttransfer}s total=%{time_total}s speed_download=%{speed_download} bytes/s\n" https://github.com/

macOS

以下命令在终端执行。macOS 默认终端通常使用 zsh，下面不依赖 Bash 的专用变量展开。

  1. nslookup github.com
  2. nslookup github.com 1.1.1.1
  3. ping -c 50 github.com
  4. traceroute github.com
  5. curl -I -L -w "dns=%{time_namelookup}s connect=%{time_connect}s start=%{time_starttransfer}s total=%{time_total}s speed_download=%{speed_download} bytes/s\n" https://github.com/

speed_download 的单位是字节/秒，不是兆字节/秒。若要换算为 MB/s，可用结果除以 1000000；这是十进制换算，不代表测速平台的带宽评分。

判断时重点看：不同 DNS 返回结果是否明显不同；50 次 ping 是否出现丢包；路径是否在某一跳开始持续超时；curl 的 DNS、连接和总耗时是否稳定。中间某一跳不回应不一定代表故障，应以最终目标是否丢包和应用层是否成功为准。

第三步：按使用场景选择 HTTPS、SSH 或 SSH 443

HTTPS Clone：优先作为基础方案

先执行不涉及写入的远程查询：

git ls-remote https://github.com/OWNER/REPO.git

git ls-remote 会读取远程仓库的引用，可用于判断 Git 是否能通过 HTTPS 与远端完成基本通信；其用途见Git 官方 git-ls-remote 文档。如果查询成功，再执行：

git clone https://github.com/OWNER/REPO.git

私有仓库需要正常的账号认证或凭据管理，不要把访问令牌直接写进 URL、脚本、Issue 或聊天记录。

SSH Clone：适合已经配置好密钥的用户

先测试：

ssh -T [email protected]

如果出现端口 22 超时，而 HTTPS 可用，可改用 HTTPS 克隆，或测试 GitHub 官方提供的 SSH 443 端口：

ssh -T -p 443 [email protected]

测试成功后，克隆地址使用：

git clone ssh://[email protected]:443/OWNER/REPO.git

GitHub 明确说明，SSH 443 使用的主机名是 ssh.github.com，不是 github.com；配置方法见使用 SSH 通过 HTTPS 端口连接。

持续使用 SSH 443

确认测试成功后，可在 ~/.ssh/config 中加入：

Host github.com
Hostname ssh.github.com
Port 443
User git

首次切换端口时，必须核对 GitHub 发布的主机指纹，再决定是否接受新的主机记录。若 SSH 报 Permission denied (publickey)，优先检查密钥是否已添加、使用的账号是否正确，而不是反复修改网络设置。

第四步：浏览器、Git 和下载工具要分别检查

浏览器能打开 GitHub，不代表命令行 Git、Release 下载或 SSH 一定可用；它们可能使用不同的连接方式和配置。

  • 浏览器：先使用无痕窗口复测，排除扩展、缓存和登录状态影响；企业网络出现拦截时，联系网络管理员确认规则。
  • Git HTTPS：查看当前远程地址：git remote -v；查看 Git 是否设置了 URL 重写：git config --global --get-regexp "^url\..*\.insteadof$"。
  • 撤销不需要的 URL 重写：先用上一步命令找出具体键名，再执行 git config --global --unset-all 键名；不要在不清楚键名时批量删除全部 Git 配置。
  • SSH：使用 ssh -vT [email protected] 查看实际连接到的主机和端口，注意不要把输出中的私钥内容分享给他人。
  • Release 或 Raw：使用 curl 对实际下载 URL 单独测试，记录总耗时和 speed_download。网页访问成功不等于大文件下载稳定。

Git 的 URL 重写和远程地址管理属于本地 Git 配置，相关命令可分别参考git-ls-remote 文档中的 URL 展开说明和Git 官方 git-remote 文档。

第五步：DNS、MTU 和 Hosts 只做可回滚的验证

刷新 DNS 缓存

Windows 可执行 ipconfig /flushdns；macOS 可执行 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder。刷新后重新运行两组 nslookup，比较默认 DNS 与指定 DNS 的解析结果和响应时间。

需要时做 MTU 递减测试

仅当出现特定网络下 HTTPS 握手异常、页面部分资源加载失败或大文件传输反复中断时再测试。Windows 从较大的数值开始递减，例如：

ping github.com -f -l 1472

macOS 使用：

ping -D -s 1472 github.com

逐步降低数值，记录从失败到成功的变化；不要把某一次成功值直接当成所有网络的固定配置。不同系统的报文参数和实际路径可能不同，测试结果只用于定位。

Hosts 不作为长期默认方案

手抄固定 IP 可能因地址变化、CDN 调度或证书校验变化而失效，也可能把请求导向错误地址。若必须验证 Hosts 是否影响解析，应先备份原文件，测试后删除新增行并恢复备份；不要把账号登录、私有仓库或带令牌请求交给未经核验的地址。

安全边界：不要为了连接稳定牺牲凭据和代码安全

  • 不安装来历不明的软件，不关闭系统防火墙；企业设备的扫描排除项应由管理员设置。
  • 公共中转地址不适合登录、访问私有仓库、发送 Token、下载内部构建产物或传输敏感代码。
  • 不要将 Token 放入命令历史、远程地址、Shell 脚本或公开日志；发现泄露时应立即撤销并重新生成。
  • 遇到证书警告、SSH 主机指纹变化或下载文件哈希不一致，应停止操作，先核对来源和校验值。
  • 如果更换网络后问题消失，保留两组测试结果，提交给网络管理员或运营商，而不是反复修改多个变量。

据此判断，稳定连接的优先级应是“确认服务状态—定位 DNS/端口/路径—选择官方支持的 HTTPS 或 SSH 方式—最后才做局部网络参数验证”，而不是直接依赖固定地址或未知中转服务。

本页含一处本项目自有产品的推荐入口，其余为通用说明，不针对任何第三方品牌。

常见问题

GitHub 网页打不开，但其他网站正常，先检查什么？

先查看 GitHub Status，再执行 nslookup github.com 和 nslookup github.com 1.1.1.1 对比解析结果；随后用浏览器无痕窗口复测，排除扩展和缓存。如果组织网络存在访问规则，应联系网络管理员确认。

git clone 一直卡住，应该改用 HTTPS 还是 SSH？

先运行 git ls-remote https://github.com/OWNER/REPO.git%E3%80%82HTTPS 查询成功时优先使用 HTTPS；如果 HTTPS 不通但已配置 SSH 密钥，可测试 ssh -T -p 443 [email protected]。SSH 443 也失败时，不要只改端口，应继续检查 DNS、路径和网络规则。

SSH 报 Permission denied (publickey) 是网络不稳定吗？

不一定。该提示通常说明服务器拒绝了当前密钥认证，应检查 SSH 使用的账号、密钥是否已加载、公开密钥是否添加到对应账号，以及远程仓库地址是否正确。可用 ssh -vT [email protected] 查看认证过程，但不要公开私钥或完整敏感日志。

网页能打开，为什么 Release 下载仍然中断？

网页和大文件下载可能涉及不同的资源地址与传输过程。请对实际下载 URL 使用 curl -L，并用 -w 输出 total 和 speed_download；若 DNS、连接时间或持续速率明显波动，应单独排查下载路径，不要据网页能打开就判断下载一定稳定。

要不要修改 Hosts 才能稳定连接 GitHub？

不建议把修改 Hosts 作为默认方案。固定地址可能随服务调度变化而失效，也可能造成错误解析。只有在备份、临时验证和可回滚的前提下才测试；验证结束后恢复原文件，并重新执行 nslookup 和 curl。

如何判断是本地 Wi-Fi 问题还是 GitHub 方向的问题？

分别 ping 本地网关和 github.com 各 50 次。网关丢包说明应先检查 Wi-Fi、网线或局域网；网关稳定而 GitHub 方向丢包，则继续看 DNS、tracert 或 traceroute，以及 HTTPS 和 SSH 的端口测试。中间路径某一跳不回应不能单独证明目标故障。

相关阅读

参考资料

  1. 连接问题故障排除
  2. GitHub Status
  3. 使用 SSH 通过 HTTPS 端口连接
  4. 错误：文件编号错误
  5. git-ls-remote Documentation
  6. git-remote Documentation