★ FEATURED ARTICLE 白底黑字的终端里光标停在一行Cloning into /home/user/.nvm...上一动不动我等了十分钟它还是不动。这个画面我太熟悉了每次教新手安装 node.js十个人里至少有五个会卡在这一步。有人会顺手再敲一遍命令有人直接怀疑是电脑坏了还有人换了一台机器重来。其实这一行字背后藏着一个非常明确的网络下载过程搞清楚它在干什么排查起来一点都不玄。这篇文章就是一份实打实的排错记录讲清楚这个“卡住”到底卡在哪个环节、怎么定位原因、以及如何用几种不同思路把 nvm 装好。如果你正准备通过 nvm 安装 node.js或者已经在Cloning into这行字上浪费过半小时这篇文章可以直接帮你把问题“拆开看”而不是凭感觉反复重试。1. 卡在 “Cloning into ‘/home/user/.nvm‘” 时系统到底在干哪一步先说一个很多人不知道的事实卡在这一行时你真正等待的并不是“安装”而是“下载”。网上流传最广的 nvm 安装方式核心就是一条管道命令左边用 curl 把安装脚本下载下来右边用 bash 执行这个脚本。脚本体积很小下载基本瞬间完成。所以大多数人的终端里根本看不到 curl 那一步有什么动静第一眼进入视线的就是Cloning into /home/user/.nvm。看到这行提示意味着安装脚本已经成功运行正在执行它内部的一个重要动作调用git clone把 nvm 的源码仓库克隆到本地/home/user/.nvm目录。这个动作不是从某个 CDN 下载一个压缩包那么轻量它需要和仓库服务器建立网络连接、完成协议握手、再逐步拉取文件。只要网络链路中任何一个环节不稳定这行提示就会一直挂在终端里直到超时或者你手动打断。1.1 安装脚本的前三步卡住的是哪一棒用一句话概括nvm 的自动安装过程分三步下载安装脚本curl 完成检测系统里有没有 git、curl 等基础工具把 nvm 源码仓库 clone 到$HOME/.nvm顺序上第一步虽然在最前面但它花的时间最短第二步只是几个命令判断也很快第三步才是真正耗时且不可控的一步。Cloning into这行提示就是第三步开始的标志问题的根源也几乎都在第三步的网络请求上。我习惯用一个生活化的类比你点了一份外卖看起来等了很久但问题不在饭店做菜快不快而是骑手在路上堵住了。终端里卡住的Cloning into就是外卖 App 上那句“骑手正在赶路”提示订单在进行但外卖没到。1.2 为什么简单的“重跑一遍”多半没用新手的第一反应一定是按CtrlC中断然后把刚才那条命令再执行一遍。如果网络只是抖动了一下重跑可能确实就成功了。这也是网上很多人分享“多跑几次就好”的原因其实不是重跑的命令有多神奇而是你第二次执行时网络刚好恢复了。但如果问题出在 DNS 解析、网络策略或者证书校验上重跑一百遍都是同一个结果依然卡在Cloning into /home/user/.nvm。因为每次执行脚本它都会走到同一个 git clone 动作然后撞上同一堵墙。所以与其重复一个“大概率不动”的命令不如停下来先把现场信息收集清楚这也是下面要讲的重点。2. 别急着重跑先判断自己是“卡死”还是“龟速”遇到卡住第一步不是修而是判断“卡”到什么程度。这决定了后续是走网络排查路线还是走配置检查路线。我一般提醒别人做三个观察看光标终端里光标还在闪烁说明终端本身没死某个进程还在后台等待只是没有输出。看时间3 到 5 分钟没有新输出属于正常波动范围超过 10 分钟毫无动静基本可以判定异常不是正常下载。看报错如果出现了错误提示反而是好事。报错能直接给出排查方向比干等强得多。最怕的是“什么都没有”一切安静得让人心慌。把常见现象和可能原因整理成一张表方便对照判断现象最可能的原因下一步动作长时间无输出光标闪烁网络连接建立被卡住测试到仓库服务器的连通性偶尔有输出但进度极慢带宽受限或者传输延迟高尝试换镜像源或浅克隆突然跳出证书相关提示SSL 证书校验失败更新系统 CA 证书提示无法解析主机或域名DNS 解析异常检查 DNS 或换源跳出一堆 HTTP 错误码服务器拒绝或连接被重置按具体错误码继续排查2.1 用另一个终端探测网络量化“慢”而不是靠感觉很多人判断“卡住”全凭感觉等了几分钟没动就慌了。我更建议的做法是不要中断当前终端另外开一个终端窗口主动探测一下网络通道。这样既不会破坏现场又能拿到可比对的数据。先做一次简单的连通性测试拿 nvm 安装时需要访问的仓库域名来试ping -c 4 你的目标仓库域名注意ping 基于 ICMP 协议能通不代表 HTTPS 一定能通ping 不通也不代表 HTTPS 一定不行。所以更准确的探测方式是用 curl 模拟一次真实的 HTTPS 请求并把关键耗时打印出来curl -o /dev/null -s -w 连接耗时: %{time_connect}s\n总耗时: %{time_total}s\n下载速度: %{speed_download}B/s\n https://example.com/如果 curl 也卡住不动问题大概率出在本地网络到目标服务器这一段如果 curl 秒回但 git 卡住那就不是单纯的网络连不通而是 git 的配置、证书或请求细节出了问题。这个区分很关键能直接决定你后面往哪个方向查。2.2 往上游看报错可能早就出现了有一个非常常见的误区只盯着终端里最后一行。实际上Cloning into /home/user/.nvm前面可能已经出现过好几行警告只不过因为滚动太快或者注意力全在最后一行上被你忽略了。比如卡住之前如果有类似 “fatal: unable to access” 的提示说明仓库服务器已经明确拒绝了请求如果有 “certificate verify failed”说明证书校验环节失败如果是 “Could not resolve host”说明域名解析环节就断了。这些信息哪怕只出现一秒钟也会留在终端缓冲里往上翻一翻基本都能找到。如果终端滚动得太多看不到最干净的办法是重新执行一次安装过程但这次把所有日志完整记录下来。具体怎么做下一章直接给可复制的命令。3. 完整排查链路从被中断的进程到真正的报错信息既然已经确定卡住接下来的操作标准是把安装过程重新执行一遍借这个“重跑”的机会把隐藏的错误信息挖出来。这和盲目重试的区别在于我们这次不是碰运气而是开着“仪表盘”跑。3.1 终止卡住的进程让 Git 把所有挣扎过程打出来先按CtrlC终止卡住的安装然后设置两个环境变量让 git 自己汇报每一步动作export GIT_TRACE1 export GIT_CURL_VERBOSE1GIT_TRACE 会让 git 输出内部执行的每个命令GIT_CURL_VERBOSE 则会把底层 HTTP 请求的细节全部展开包括 DNS 解析结果、连接到哪个 IP、TLS 握手状态、发送了哪个请求、等待响应用了多久。这些信息对定位“卡在哪一步”至关重要。设置好之后重新运行安装脚本curl -o- 官方安装脚本地址 | bash如果不想动官方脚本也可以直接单独测试 git clone 那一步把仓库地址替换成 nvm 源码仓库地址git clone --verbose nvm仓库地址 /tmp/nvm_test这样等着看输出卡在哪个阶段如果卡在 DNS 解析问题在网络配置如果卡在 TLS 握手问题在证书链路如果卡在 “Receiving objects”问题大概率在传输速度。日志不会骗人它会把 git 的每一次犹豫都记录下来。3.2 把“git 卡住”拆成“网络卡住”和“配置卡住”拿到详细日志后下一步是做一次对照实验。用 curl 直接访问同一个仓库地址看结果如何。因为 curl 和 git 的 HTTPS 底层有很多相通之处curl 的行为能反映网络真实状况。curl -o /dev/null -s -w HTTP状态码: %{http_code}\n总耗时: %{time_total}s\n nvm仓库地址对比一下结果如果 curl 同样卡住不出结果说明网络通道本身有问题继续调网络配置换镜像源是更高效的方案。如果 curl 很快返回说明网络通道是通的问题聚焦在 git 的配置上比如 SSL 证书校验、代理设置、或者 git 的 http 参数。这一步做完你的排查范围就缩小了不会像无头苍蝇一样乱试。3.3 分三条路径修复连不通、证书错误、太慢明确了“卡在哪一层”接下来就是按路径处理。我根据实际踩坑经验把常见问题分成三类每类给一套可直接操作的修复思路。路径 A网络连不通或域名不可达这种情况下日志里大概率会出现Could not resolve host、Connection timed out或者Failed to connect一类的提示。处理思路排序是先检查当前网络环境确认是不是本地网络策略限制了对目标服务器的访问。如果你所在的网络环境要求通过指定的转发服务器访问外部资源需要按网络管理员给的参数配置环境变量如果平时直连就能上网就不要乱设。换一个国内可直接访问的镜像源。nvm 安装脚本本身是文本可以先把脚本下载到本地再用文本替换的方式把仓库地址改成镜像地址最后执行本地脚本。具体做法如下curl -o /tmp/install_nvm.sh 官方安装脚本地址 sed -i s#原仓库地址#你的镜像仓库地址#g /tmp/install_nvm.sh bash /tmp/install_nvm.sh这段命令的思路是脚本只下载一次改完地址后再执行。这样即使第一次下载成功了后面每次执行也不需要重新经过容易卡住的网络链路。换源虽然听起来像是“绕路”但在网络环境受限时这是最稳定有效的方案。路径 BSSL 证书校验失败日志中如果出现SSL certificate problem、certificate verify failed之类的字样说明 git 在验证服务器证书时找不到可信任的根证书。这类问题常见于精简版系统、长期没有更新 CA 证书的系统或者某些使用了自签名证书的网络环境。处理方式分两步更新系统 CA 证书。在 Debian/Ubuntu 系系统上运行sudo apt update sudo apt install -y ca-certificates重新执行安装脚本看问题是否消失。如果是测试阶段想快速验证“是不是证书问题导致的卡住”可以用git -c http.sslVerifyfalse clone nvm仓库地址 /tmp/nvm_test如果这条命令能正常 clone说明问题确实出在证书校验环节。但这只是排查手段不能长期关闭 SSL 校验因为这会让你下载的代码完全暴露在中间人攻击风险下。正确做法还是更新系统 CA 证书或者为 git 指定正确的 CA 文件路径。路径 C传输太慢但没有断如果你观察到的现象是git 有输出但进度条半天挪一格最后甚至“看起来像卡死了”其实是传输速度太慢慢到让人失去耐心。这类问题可以启用浅克隆只拉取最新一份文件不拉整个历史记录git clone --depth 1 nvm仓库地址 $HOME/.nvm浅克隆能把传输量降至最低对 nvm 这种体积不大但提交历史较多的仓库来说效果非常明显。安装完成后如果后续需要切换到具体版本再执行git fetch --unshallow补齐历史即可不影响使用。另外还可以给 git 设置一个低速阈值让它不再无限期等待而是快速报错退出export GIT_HTTP_LOW_SPEED_LIMIT1000 export GIT_HTTP_LOW_SPEED_TIME30这两行的意思是如果持续 30 秒平均传输速度低于每秒 1000 字节git 立即判超时报错。这样就不至于在终端前干等半小时还不知道发生了什么。4. 手动安装 nvm 的兜底方案不依赖官方安装脚本自动安装脚本的好处是封装了一步到位的操作但坏处是出了问题不好定位。如果你已经试了好几种方法还是卡在Cloning into我建议直接放弃自动脚本改用手动安装。手动安装的每一步都可以停下来检查整个过程完全可控反而更快。手动安装的思路是自己决定克隆哪个仓库、放到哪个目录、写哪些配置然后逐条执行并观察结果。全程不经过自动脚本那个“黑盒”也不会因为脚本内部某个隐藏动作而卡住。4.1 先清理半成品目录避免旧文件干扰这一点很多人会忽略。自动脚本跑到一半被你中断后~/.nvm目录下可能已经留下了一些不完整文件。拖着这些半成品去执行手动安装git 会直接报错说目标目录已存在且不为空。检查并清理的方法ls -la ~/.nvm rm -rf ~/.nvm执行rm -rf之前记得确认这个目录里没有你自己保存的其他内容。如果这是第一次安装目录里通常只有安装失败留下的残留文件清掉没有负担。4.2 从克隆到加载手把手走一遍清理干净后按顺序执行下面的命令export NVM_DIR$HOME/.nvm git clone --depth 1 nvm仓库地址 $NVM_DIR cd $NVM_DIR # 如果之后需要切换到某个带标签的发布版本先补齐历史 git fetch --unshallow git checkout $(git describe --tags $(git rev-list --tags --max-count1)) # 把初始化配置写入 shell 配置文件 echo export NVM_DIR$HOME/.nvm ~/.bashrc echo [ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh ~/.bashrc # 当前会话立即生效不用重开终端 export NVM_DIR$HOME/.nvm [ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh这里有一个非常容易踩的坑如果你用了--depth 1做浅克隆仓库里没有完整的 tag 列表直接执行git rev-list --tags --max-count1会拿不到结果。所以上面的命令里先执行了git fetch --unshallow补全历史再切换 tag。如果不需要指定版本只想尽快让 nvm 能用可以直接跳过补历史和切换 tag 这两步默认分支的 nvm.sh 功能上也是完整的。另一个坑是echo追加配置时没有检查~/.bashrc里是不是已经写过了。重复执行安装命令会导致配置出现多行相同内容每次打开终端都会加载一遍虽然不影响功能但会有一堆重复提示。养成好习惯先检查再追加grep -n NVM_DIR ~/.bashrc如果已经有内容没有必要再追加。4.3 验证安装是否成功的三个检查点安装完成不是“命令没报错”就行要有一个明确的验证清单nvm 命令能否被找到command -v nvm版本号是否正确输出nvm --version目录文件是否完整ls $NVM_DIR应该能看到nvm.sh文件如果command -v nvm没有输出任何路径多半是配置文件加载顺序问题检查~/.bashrc或~/.zshrc里的内容是否正确或者新开一个终端再试试。如果nvm --version能正常输出版本号说明手动安装已经成功这时候再通过 nvm 安装 node.js 就是水到渠成的事。5. 装好之后的收尾工作以及那些“卡住”教会我的事nvm 装好只是第一步接下来还有三件小事不做的话很容易在“新终端里找不到 node 命令”这类问题上栽跟头。第一件事查看远端有哪些版本可以安装nvm ls-remote如果这一步也是一直转圈说明当前网络环境对 npm 官方 registry 同样不友好后续安装 node 时还需要处理源的问题。如果列表能正常出来直接装 LTS 版本nvm install --lts第二件事设置默认版本。不设置的话每次新开终端都要手动nvm use非常麻烦nvm alias default lts/*第三件事验证 node 和 npm 是否真的可用。关掉当前终端新开一个窗口分别执行node -v npm -v如果都能正常输出版本号整条链路才算真正跑通。最后聊一点长期体会。和“卡在 Cloning into”斗争多了之后我养成了一个习惯遇到任何下载类的安装问题第一反应不再是重试而是先看日志、再测网络、然后考虑换源。这个顺序可以套用到很多工具安装场景中不只是 nvm。另外自动脚本失败并不代表环境出了问题很多时候只是它默认使用的网络通道在当前环境下不通。学会手动安装之后那些“一条命令搞定”的安装脚本在你眼里就变成了可读、可改、可控的文本出了问题也能从容应对。以后再看到Cloning into你就知道它只是告诉你“货还在路上”至于货什么时候到、走哪条路、为什么堵住你已经有能力自己去查了。
阅读完成 · 觉得有帮助？
