★ FEATURED ARTICLE 刚装好的 Ubuntu 24.04兴致勃勃想 clone 一个开源项目练手结果git clone一敲下去光标停在Enumerating objects之前就再也不动了换个浏览器打开 github.com也只能看着转圈发呆。这个场景我处理过太多次可以负责任地说系统大概率没坏也不需要重装问题基本都出在网络栈的某一层。GitHub 本身在很多网络环境下访问就忽快忽慢Ubuntu 这边又会叠加 DNS 配置、IPv6 策略、证书时间校验这些变量所以症状五花八门。这篇文章我会按排查顺序把从 DNS 到 hosts、再到 git 协议层的几种常见解法完整走一遍适合刚装好 Ubuntu、遇到 GitHub 相关操作失败的读者直接照着抄。1. 先定位访问 GitHub 到底卡在哪一步1.1 别拿 ping 当探针很多教程上来就让你 ping github.com但我强烈建议你不要用 ping 判断。GitHub 的服务器在很多网络环境里是屏蔽 ICMP 请求的也就是说就算你的网络完全正常ping 也可能 100% 丢包这会带来极大的误导。我自己实测过在某条正常的宽带下ping github.com直接超时但curl -I https://github.com三秒钟就返回 200。正确的探针是 curl 或 wget它们走的是 TCP 443这才是你真正要用的通道。# 只看响应头最多等 10 秒 curl -I -m 10 https://github.com # 列出关键耗时 curl -o /dev/null -s -w HTTP:%{http_code} 连接:%{time_connect}s 总耗时:%{time_total}s\n https://github.com输出里如果HTTP:200那就什么都好说只是慢如果卡在connect阶段多半是网络连通问题如果返回Could not resolve host那就是 DNS 解析出了岔子。拿到 curl 的报错你就能知道该往哪个方向使劲。1.2 用一张表理清症状对应的层级GitHub 访问失败不是单一原因我习惯把问题分成四层DNS 解析、TCP 连通、TLS 证书、以及页面静态资源加载。每一层出问题表现都不一样。现象大概率卡住的层优先处理curl: Could not resolve hostDNS 解析第 2 节卡在connect to ... port 443TCP 连通第 3、4 节SSL/TLS 握手失败、证书报错证书、系统时间第 5 节首页能开但样式全丢、资源加载失败静态资源子域第 5 节git clone超时但浏览器能开git 协议层第 4 节这个分类不是绝对但足够覆盖 90% 的现象。遇到问题先别急着改这改那跑一条 curl对照表格找准位置效率会高很多。1.3 顺手看一眼系统时间系统时间和网络完全无关但遇到证书报错的概率有一半是它引起的。GitHub 返回的 TLS 证书有有效期Ubuntu 系统时间如果偏离太多openssl 会认为证书不在有效期内直接拒绝握手。你先跑timedatectl确认System clock synchronized: yes。如果显示no执行sudo timedatectl set-ntp true等十几秒再查一次。这一步成本极低能排除一个很隐蔽的坑。2. 第一板斧把 DNS 换成国内公共 DNS2.1 为什么默认 DNS 经常解析出错Ubuntu 装好后默认走 DHCP 从路由器拿 DNS而很多路由器的上游 DNS 解析 GitHub 相关域名时会给出异常结果常见表现是getent hosts github.com返回空或者把域名解析到一个根本不通的 IP。原理其实不复杂DNS 查询走的是一条按区域划分的递归链路某个节点一旦出错整个链路就直接返回错误结果你的浏览器和 git 客户端拿到的就是一个不可用的地址。根解法是绕过这条链路使用能稳定返回正确结果的公共递归 DNS。推荐三组阿里223.5.5.5、腾讯119.29.29.29、114.114.114.114。这三组在国内链路延迟极低对 Ubuntu 用户最省心。2.2 Ubuntu 24.04 / 22.04 修改 DNS 的三种姿势先找出你的网卡名执行ip a一般有线网卡叫eth0、ens33或者enp3s0记住这个名字。如果是纯命令行环境用 netplan 改最稳。编辑/etc/netplan/00-installer-config.yamlnetwork: version: 2 ethernets: eth0: dhcp4: true nameservers: addresses: [223.5.5.5, 119.29.29.29]执行sudo netplan try # 先试一下别直接 apply sudo netplan applynetplan try是很实用的设计它会在应用后倒计时确认如果配置错误导致网络断开会自动回滚不会把你关在门外。桌面版 Ubuntu 更简单直接在“设置-网络-有线-IPv4”里把 DNS 改成手动填上上面那组地址断开重连一次就行。如果你不想碰 netplan 文件也可以用resolvectl临时指定网卡 DNSsudo resolvectl dns eth0 223.5.5.5 119.29.29.29 resolvectl status这种方式适合快速验证效果但重启后可能失效。注意一点Ubuntu 22.04 以上版本的系统 DNS 由 systemd-resolved 管理/etc/resolv.conf是符号链接直接用echo nameserver去覆盖它属于应急手段重启大概率被还原不是长久之计。2.3 改完怎么验证dig short github.com 223.5.5.5 getent hosts github.com如果你没装 dig先执行sudo apt install dnsutils。看到返回一个 140.82.x.x 或者 185.199.x.x 之类具体 IP说明解析链路已经正常。注意getent hosts读的是系统当前生效的解析结果如果它仍然显示旧 IP你就需要在第 3 节里处理缓存或者 hosts 的问题。3. 第二板斧hosts 文件直接给 GitHub 指路3.1 hosts 的原理DNS 是系统先向服务器查询域名对应的 IP查到以后再建立连接而/etc/hosts文件是在这一步之前直接写死 IP系统根本不会发起 DNS 查询。对于 github.com 这种解析容易出问题的域名给 hosts 加一行就能让所有程序跳过有问题的解析链路。但要注意 hosts 也不是万能的一旦某些 CDN 节点迁移、IP 变更你写死的记录就失效了所以下面会先教你怎么拿到当前有效 IP再动手改。3.2 用 dig 获取当前有效 IP别急着复制网上七零八落的 hosts 模板花一分钟拿到你网络环境下能用的 IP 才是正道。方法很简单用国内公共 DNS 直接解析这些子域名dig short github.com 223.5.5.5 dig short api.github.com 223.5.5.5 dig short raw.githubusercontent.com 223.5.5.5 dig short gist.github.com 223.5.5.5 dig short codeload.github.com 223.5.5.5 dig short objects.githubusercontent.com 223.5.5.5每个域名可能返回多个 IP取第一个在 hosts 里用即可。对于 raw、codeload、objects 这几个域名的185.199.108.x-111.x段我会比较信任因为那是 GitHub 常用的 CDN IP 段基本稳定。github.com 主站是 140.82.x.x 段偶尔会换我实际用下来 140.82.114.3 和 140.82.112.3 都比较稳。3.3 一份可直接改的 hosts 模板执行sudo nano /etc/hosts把下面这段追加到文件尾部# GitHub 相关记录2025-04 校验 140.82.114.3 github.com 140.82.114.3 www.github.com 140.82.112.6 api.github.com 185.199.108.133 raw.githubusercontent.com 185.199.109.133 gist.github.com 185.199.110.133 codeload.github.com 185.199.108.133 objects.githubusercontent.com 185.199.108.133 avatars.githubusercontent.com再次强调以上 IP 是我目前可用的例子你写入前最好还是dig一下以你自己查到的为准。如果某个域名查出来和模板里的不一样听 dig 的别听模板的。3.4 改完后刷新 DNS 缓存hosts 是 glibc 直接读取的理论上改完马上下一次查询就会生效但系统里还有一层缓存所以稳妥起见刷新一下sudo resolvectl flush-caches # 22.04 / 24.04 sudo systemd-resolve --flush-caches # 18.04 及更早 curl -I -m 10 https://github.com如果这之后 curl 返回 200那恭喜最麻烦的一步已经过了。3.5 更新 IP 的小脚本hosts 里的 IP 会过期我不建议你手动查 6 个域名再一个个改太容易漏。写个简单的脚本帮你批量查#!/bin/bash DNS223.5.5.5 DOMAINSgithub.com api.github.com raw.githubusercontent.com gist.github.com codeload.github.com objects.githubusercontent.com avatars.githubusercontent.com for d in $DOMAINS; do ip$(dig short $d $DNS | head -1) [ -n $ip ] echo $ip $d done把脚本执行结果和 /etc/hosts 里的旧记录对一下有变化的就更新。这个操作我会每隔几个月做一次因为 GitHub 的 CDN 节点调整不算罕见等失效了再救火不如定期维护一遍。4. 第三板斧git clone 失败的专项处理4.1 HTTPS clone 超时的三种应对如果你已经改了 DNS 和 hosts浏览器能打开网页但git clone还是卡住那问题往往出在协议层和仓库大小。先试浅克隆它只拉取最新一次提交网络流量会小很多git clone --depth 1 https://github.com/user/repo.git仓库特别大、历史特别深的时候再加一个 filter 参数把 blob 对象也懒加载git clone --depth 1 --filterblob:none https://github.com/user/repo.git浅克隆的代价是拿不到完整历史后续如果需要全部提交记录在仓库里执行git fetch --unshallow即可。这个方法特别适合那种“我只想看看代码、编译一下”的场景。4.2 SSH 端口被网络策略挡掉很多网络环境下 22 端口不通但 443 是开放的。GitHub 官方提供了一个替代入口ssh.github.com让 SSH 流量走 443。配置方法是在~/.ssh/config里加内容mkdir -p ~/.ssh cat ~/.ssh/config EOF Host github.com Hostname ssh.github.com Port 443 User git EOF ssh -T gitgithub.com首次连接会询问是否信任主机指纹输 yes 回车。如果看到Hi 你的用户名! Youve successfully authenticated...说明 SSH 通道已经通了。这个改法只对 github.com 这一个 Host 生效不影响你连其它 git 服务器非常安全。4.3 用 Gitee 导入当跳板如果上面的方法在某个网络里都不好用或者你要拉的仓库特别大、历史特别深最稳妥的土办法是借道国内的代码托管平台。个人建议用 Gitee网页上新建仓库时选择“导入仓库”把 GitHub 仓库地址填进去等它同步完成再git clone https://gitee.com/你的用户名/仓库名.git。导入完成后你可以把本地远程地址保留为 Gitee也可以把 GitHub 原地址加为第二个 remote之后在 Gitee 上同步代码再手动 push 回 GitHub。这个方案的限制是只能处理公开仓库私有仓库或者涉及账号授权的场景不适合硬来。另外导入是大仓库的“救星”GitHub 上动辄几个 GB 的仓库在本地直接 clone 经常半路断掉Gitee 导入后基本是内网速度体验完全不一样。4.4 下载单个 Release 压缩包的细节浏览器里点 Download 老失败时不要反复点直接用命令行续传更稳wget -c -O app.tar.gz https://github.com/user/repo/releases/download/v1.0.0/app.tar.gz-c是断点续传-O指定保存文件名。如果这个地址超时先确认 hosts 里的codeload.github.com那条是否生效Release 的下载链路经常要经过 codeload不是主页一个域名那么简单。很多项目发布的是源码包传到 Release 页面的 zip 文件实际上由 codeload 提供所以它挂了你下载就会一直卡在 0%。5. 第四板斧网页能开但样式全丢5.1 GitHub 页面依赖的子域名浏览器打开 github.com 只是第一步页面里的 CSS、JS、头像、代码预览、文件下载分别由不同的子域提供。常见的是你点开某个代码文件时raw.githubusercontent.com一直在转圈或者头像位置裂开、下载按钮点了没反应。把前面 hosts 模板里的几条都加上能解决大部分“半残”状态。子域名用途hosts 建议github.com主站140.82.x.xapi.github.comAPI 接口140.82.x.xraw.githubusercontent.com原始文件预览185.199.108.133gist.githubusercontent.comGist 内容185.199.109.133codeload.github.comzip/tar 下载185.199.110.133objects.githubusercontent.com大对象下载185.199.108.133avatars.githubusercontent.com用户头像185.199.108.133如果你只改了主站的 hosts 而漏了 raw 和 codeload就会出现“网页打开了但代码预览和下载一碰就死”的奇怪现象。GitHub 页面加载是一个复合过程你把它想成一个店铺主站只是门脸里面每个货架都有自己的仓库入口。5.2 IPv6 导致的假死Ubuntu 24.04 默认开启了 IPv6如果你的宽带 IPv6 路由不通就会出现“能解析、连不上、一直转圈”的假死状态。判断方法是用 curl 强制指定协议curl -4 -I -m 10 https://github.com # 畅通 curl -6 -I -m 10 https://github.com # 卡住或失败如果-4通、-6不通就是 IPv6 链路的问题。两种修法第一种是让系统优先使用 IPv4编辑/etc/gai.conf去掉这行的注释precedence ::ffff:0:0/96 100这行规则的意思是IPv4 映射地址的优先级高于 IPv6。第二种更直接关闭系统的 IPv6 支持sudo sysctl -w net.ipv6.conf.all.disable_ipv61想持久化就把它写入/etc/sysctl.conf。不过我个人建议优先改 gai.conf因为全线关闭 IPv6 会影响系统里其它正常的 IPv6 服务代价比优先级调整要大。5.3 证书校验失败先查时间如果你遇到报错SSL certificate problem: certificate is not yet valid或者浏览器提示“连接不是私密连接”八成是系统时间不对。先看timedatectl然后执行sudo timedatectl set-ntp true。如果 NTP 同步不上可能是 ca-certificates 包有问题sudo apt update sudo apt install --reinstall ca-certificates这一步做完再 curl大部分证书错误都能消失。注意 apt 本身也需要网络如果连 Ubuntu 软件源都慢那是另一个独立问题和 GitHub 无关。先把 apt 源切到国内镜像再回来处理 GitHub这个顺序不要搞反。6. 常见问题速查表与个人避坑心得6.1 症状、原因、解法速查表症状直接原因解法ping github.com超时ICMP 被网络策略过滤忽略改用 curlCould not resolve hostDNS 解析异常换 223.5.5.5 或加 hostsconnect to port 443 timed out出口链路不通hosts 校验 多次重试git clone卡在 Enumerating仓库过大、长连接被掐浅克隆 filterSSH 连接超时22 端口不通ssh.github.com 走 443地址解析正确但样式全丢子域 hosts 缺失批量加静态资源域名能解析但一直转圈IPv6 优先但链路不通改 gai.conf 规则证书报错系统时间偏差set-ntp / 重装 ca-certificates这张表基本覆盖了我日常处理的问题。如果你的症状不在表里就回到第 1 节按 curl 的报错信息对号入座别乱试。6.2 几个我踩过的坑第一个坑是太相信 ping。有一阵子我排查一台 Ubuntu 服务器连不上 GitHub看到 ping 超时直接往网络策略方向找折腾半天才发现 curl 其实能通浪费了很多时间。现在我的习惯永远是 curl 先行。第二个坑是 hosts 里的 IP 会过期。我抄了一份网上的 hosts 模板用了一个多月没出问题某天突然 clone 一直超时重新 dig 才发现 github.com 的 IP 早就换了。从那以后我每写一条 hosts 记录都会在旁边注释日期每隔几个月批量更新一次。第三个坑是在 Ubuntu 24.04 上只改/etc/resolv.conf。系统里 systemd-resolved 会把它覆盖回符号链接状态看起来改了重启就没。改 DNS 要么走 netplan要么用 resolvectl硬写文件只是应急。第四个坑是公司或校园网里的网络策略。本地改 hosts 和 DNS 在这种环境经常无效因为流量出口是网关控制的。别硬拗改走 Gitee 导入或者找网络管理员更实际。第五个坑要特别提醒别盲目执行网上下载的 hosts 更新脚本。有些脚本会往你系统里写入一串来路不明的地址映射你根本不知道它指向哪台服务器安全风险很高。自己用 dig 查、自己改虽然麻烦一点但你能完全掌控系统里发生了什么。6.3 我现在的默认操作顺序现在我遇到 Ubuntu 访问 GitHub 异常固定按这个顺序走先curl -I看报错再getent hosts看解析结果然后按需改 DNS 或更新 hostsgit 层问题优先检查 SSH 443 和浅克隆条件允许就借道 Gitee 导入。这套流程从 18.04 用到 24.04基本没有失手。最后分享一个个人习惯hosts 文件我并不是写完就永久启用而是把它当作排查期的手动开关。问题确认解决后我会在 hosts 里给每条记录加注释写上日期和当时 dig 出来的 IP下次再遇到时先更新这些记录再谈别的。这样一轮下来你对整台 Ubuntu 的网络栈理解会比之前清晰不少再遇到类似问题一眼就能定位到根因。
阅读完成 · 觉得有帮助？
