git提交、拉取、推送代码时弹出一句“网络连接失败”“连接超时”这种报错有多让人血压升高经历过的人都懂。明明代码没写错仓库地址也对着偏偏每次git push都像开盲盒运气好一次过运气差反复重试半小时。我最近就结结实实踩了一次报错从“Failed to connect”到“Could not resolve host”换着花样来最后定位下来是两个问题叠在一起DNS解析异常加历史配置残留。整套排查过程不超过十分钟但真正值钱的不是那几条命令而是“按什么顺序查”的思路。这篇文章就对着这个标题把 git 网络连接失败的判断方法、修复命令和避坑经验一次性捋清楚。1. 先说现象git报“网络连接失败”到底长什么样1.1 最常撞见的几种报错文案git 本身不是网络工具它只是个调用底层协议干活的客户端所以一旦网络出问题报错信息会有很多变体但核心就几类。第一种连接不上fatal: unable to access https://gitee.com/xxx/xxx.git/: Failed to connect to gitee.com port 443: Connection refused。这句话的意思是握手阶段就被拒绝了连TCP连接都没建立起来。第二种域名解析不了fatal: unable to access https://github.com/xxx/xxx.git/: Could not resolve host: github.com。DNS解析这一步就失败了git 拿着域名不知道往哪台服务器发请求。第三种连接断了error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104或者fatal: The remote end hung up unexpectedly。这类多半出现在推送大文件、网络不稳定、传输被中间拦截的场景看起来像“连上了但中途被掐断”。第四种证书报错SSL certificate problem: unable to get local issuer certificate。这属于HTTPS证书校验失败常见于系统时间不对、CA证书过期、或者你访问的仓库平台证书链不完整。标题里说的“网络连接失败”是个笼统描述实际上这四种背后的原因和解决方法完全不一样。所以拿到报错第一件事不是急着找命令而是把完整报错文案复制下来看清楚是哪种。1.2 先给报错归类再动手我的习惯是先把问题分成四类来看DNS解析层、TCP连接层、传输中断层、证书校验层。DNS解析层报错里带Could not resolve host说明域名解析失败优先查DNS服务器配置和本机缓存。TCP连接层报错里带Failed to connect、Connection refused、Connection timed out说明域名能解析但连不上端口优先查防火墙、安全软件、端口是否被限制。传输中断层报错里带RPC failed、hung up、SSL_ERROR_SYSCALL说明建立连接后传输被掐断优先查大文件、传输缓冲区、网络稳定性。证书校验层报错里带SSL certificate problem优先查系统时间和证书链。这么一分你后面所有的排查动作都有了方向不会像个没头苍蝇一样乱试。我自己见过太多人一看到网络报错就反复git push重试或者干脆删了仓库重新 clone结果问题原封不动地还在那里。2. 排查路线图从DNS到端口到配置残留2.1 第一步确认域名能不能解析不管报错长什么样我建议第一步都先做域名解析检查。因为DNS是这一切的起点git 要发起请求第一步就是把仓库域名解析成IP地址这一步挂了后面全完。Windows 下打开 PowerShell 或 CMDLinux/macOS 打开终端执行nslookup gitee.com以 Windows 为例正常输出会有一个Address字段显示出解析出来的IP。如果提示Non-existent domain或者server cant find说明DNS解析确实有问题。再换个公共DNS试试nslookup gitee.com 223.5.5.5后面的223.5.5.5是公共DNS服务器这样能区分是“本机配置的DNS有问题”还是“所有DNS都解析不了”。实测下来很多所谓网络连接失败其实就是本机DNS缓存里存了一条过期记录或者当前网络的DNS服务器本身不稳定。顺便看下系统DNS缓存Windows执行ipconfig /displaydns如果里面出现一堆无效记录清理掉会清清爽爽命令是ipconfig /flushdns这一步做完再去nslookup一次能正常解析出IP说明DNS这层已经通关。2.2 第二步确认到服务器端口通不通域名能解析不代表你就万事大吉。HTTP/HTTPS 仓库走的是80/443端口SSH 仓库走的是22端口。你所在的网络环境办公室、学校、云服务器安全组很可能禁掉或限制某些端口。这一步我用curl来测顺手还能看到更多细节。比如你的仓库是 HTTPS 地址curl -v https://gitee.com/ --connect-timeout 10看输出里的关键行如果出现Connected to gitee.com (IP) port 443说明443端口是通的问题不在端口层。如果卡在Trying IP...很久然后报Connection timed out那就是端口不通或者被防火墙拦截。如果仓库是 SSH 地址可以测一下22端口telnet gitee.com 22或者直接尝试 SSH 握手ssh -T gitgitee.com这一步输出会非常直观通不通、有没有权限提示一眼就能看出来。实测下来很多内网环境对22端口管控很严但对443端口宽容得多后面我会讲到怎么利用这一点。2.3 第三步检查git自身配置重点看http/https段这一步是被很多人忽略的。git 是有本地配置的而且配置文件分三层系统级system、全局级global、仓库级local。这三层里任何一层如果残留了旧环境设置的“请求转发地址”都会导致你日常提交拉取推送时被指向错误的地方。先看全局配置git config --global --list再看仓库级配置进到项目目录里执行git config --local --list系统级也顺手看一眼git config --system --list重点检查有没有形如http.或https.开头的配置项值是一个IP加端口或者一个奇怪的URL。这种东西多见于以前为了走内网网关配过一次、后来项目换了环境忘了删、或者是团队某个人往公共机器上写了一条共享配置。如果确认是残留配置不用背命令直接打开配置文件手动清理更快git config --global --edit这会打开全局配置文件找到[http]和[https]小节把里面指向奇怪地址的行删掉保存退出再执行一次git config --global --list确认。仓库级的残留同样处理用git config --local --edit。坦白讲我这次推送超时最后定位到的根因之一就是一条存了很久的转发配置。它平时不吭声但一遇到仓库地址变化就直接把你的流量带到错误的地方去。2.4 第四步区分HTTPS链路和SSH链路有些坑只属于HTTPS有些坑只属于SSH。所以排查时要明确你当前仓库用的是哪种协议。用下面的命令看git remote -v输出如果是https://开头就是HTTPS链路如果是git开头就是SSH链路。HTTPS链路的问题集中在证书校验、用户名密码/凭证管理、DNS解析、端口限制。SSH链路的问题集中在密钥认证失败、22端口被限制、known_hosts 冲突。一个很实用的技巧如果 HTTPS 链路怎么调都不顺直接把 remote 地址切成 SSH 协议再试一次很多时候问题直接消失。反过来也一样。切换命令git remote set-url origin gitgitee.com:你的用户名/你的仓库名.git别怕切来切去git 仓库和你的本地代码不会因此丢任何东西这只是改了“去哪个门、走哪条路”的问题。3. 对症下药五套亲测有效的修复方案3.1 解析异常切换DNS并清理缓存DNS 不靠谱是“Could not resolve host”的头号原因。遇到这种情况我建议把本机DNS切到稳定的公共DNS服务器常用的有这几组DNS服务器IP说明阿里公共DNS223.5.5.5 / 223.6.6.6国内访问响应快腾讯公共DNS119.29.29.29国内备用选择114 DNS114.114.114.114老牌公共DNS稳定性好Windows 设置路径是控制面板 → 网络和共享中心 → 更改适配器设置 → 右键当前网络 → 属性 → 双击“Internet 协议版本4 (TCP/IPv4)” → 选择“使用下面的DNS服务器地址” → 填入首选和备用DNS → 确定。Linux 下如果用的 systemd-resolved可以临时测试sudo systemd-resolve --flush-caches改完DNS后强烈建议清一遍本机DNS缓存再重新nslookup验证。需要说明的是公共DNS只是帮你把域名解析更快更准确地完成它不涉及任何特殊网络功能你该通的地方通不该通的地方照样不通。3.2 端口受限用443端口走SSH链接如果你的网络环境只开放443端口很多办公网络和云服务器安全组是这种策略那么默认的SSH 22端口大概率是废物状态。这时候不用去求管理员git 官方给了现成的方案把 SSH 连接改走 443 端口。以 GitHub 为例先测试443端口能不能完成SSH握手ssh -T -p 443 gitssh.github.com能通的话就在~/.ssh/config文件里加一段Host ssh.github.com HostName ssh.github.com Port 443 User git然后把你仓库的 remote 地址改成 SSH 格式再推拉一次。这个方案我实际用在好几个项目上效果很稳定不需要额外装任何软件属于纯配置层面的调整。Gitee 虽然不提供官方443 SSH端口但它对HTTPS的支持比较完善如果你在 Gitee 遇到22端口不通直接切回HTTPS地址推拉就行。3.3 传输中断调大postBuffer再用Git LFS兜底推送大文件时报RPC failed、The remote end hung up unexpectedly核心原因是HTTP传输缓冲区默认值太小推送超过几十MB的文件时连接容易被掐断。临时调大当前仓库的缓冲区git config http.postBuffer 524288000524288000 字节就是 500MB这个值够大多数场景用了。实测下来调完再推大包成功率明显上升。但我要提醒一句postBuffer不是万能的。如果单个文件本身就超过了平台限制GitHub 单文件建议别超过100MBGitee 也有类似限制再怎么调缓冲区都是白搭。这种情况正确的做法是用 Git LFS 管理大文件。Git LFS 的原理是仓库里只放一个文本指针真正的大文件存到LFS存储服务里。安装后执行git lfs install git lfs track *.zip然后正常git add、git commit、git pushgit 会自动把匹配*.zip的文件走 LFS 通道上传。3.4 配置残留清理git config里的多余条目前面提过git 配置分三层任何一层有残留转发配置都可能让你推拉失败。判断方法已经给了再补充一个快速清理的实践经验。不确定改哪条配置时最稳妥的办法不是敲git config --unset而是打开配置文件亲眼看一下。全局配置用git config --global --edit系统级配置用git config --system --edit仓库级配置直接在项目.git/config文件里改。看到[http]、[https]小节下面的地址指向一个你根本不认识的IP或端口就把它删掉。保存退出后执行git config --list确认没有可疑条目再去推拉一次。我处理过好几个“怎么都找不到原因”的网络问题最后都是这么拎出来的。3.5 本地拦截防火墙和安全软件逐个排查有时候问题根本不在远端而在你本机。Windows 防火墙、第三方杀毒软件、企业终端管控软件都可能悄悄把 git 的网络请求掐了。Windows 防火墙排查方法是控制面板 → Windows Defender 防火墙 → 允许应用或功能通过防火墙 → 找到 Git 相关条目确认“专用”和“公用”都有勾选。如果没找到 Git 条目选择“允许其他应用”把 Git 安装目录下的cmd/git.exe和usr/bin/ssh.exe都加进去。还有一类容易被忽略的杀毒软件行为拦截。某些安全软件会对“程序发起网络请求”弹出拦截提示如果你当时点了拒绝后续所有 git 请求都会被静默拦截。遇到诡异的“时好时坏”先去安全软件的拦截日志里看有没有 git.exe 的记录。企业网络环境下如果所有排查都做了还是不联那就别硬抗了直接找网络管理员确认出站端口策略。4. 一次完整排障实录从报错到恢复4.1 现场推送提交时443端口超时我把这次真实经历完整还原一遍。当时项目是从 Gitee 拉下来的改完代码正常提交然后git push报错如下git push origin main fatal: unable to access https://gitee.com/xxx/xxx.git/: Failed to connect to gitee.com port 443 after 30023 ms: 连接超时注意关键词Failed to connect、连接超时。这个报错说明域名解析大概率是过的问题出在TCP连接层要么端口不通要么流量被中途挡住。4.2 定位三层检查逐层缩小范围我没有直接改任何东西先跑了一套检查。第一步确认DNSnslookup gitee.com正常解析出IPDNS这层过。第二步测443端口curl -v https://gitee.com/ --connect-timeout 10结果卡在Trying IP...很长一段时间后超时这说明443端口到该IP的TCP连接被堵了。第三步检查git配置git config --global --list这一看就发现问题了里面有一条历史遗留的转发配置指向一个内网IP。这条配置是以前在某个旧开发环境调试时配的项目搬迁后完全没用但它一直赖在全局配置里。每次 git 发起 HTTPS 请求时都会优先读它导致流量被送到错误的地方。第四步顺手验证一下切到 SSH 链路能不能绕开git ls-remote gitgitee.com:xxx/xxx.gitSSH 反而能通。但是项目离线的同事习惯用 HTTPS所以最终选择直接把残留配置清掉而不是让所有人切协议。4.3 恢复两处修改解决清理配置git config --global --edit手动删掉 [http] 小节下的可疑配置行保存退出。再验证 HTTPS 链路git ls-remote https://gitee.com/xxx/xxx.git这次能正常列出远端分支了。然后实际推送git push origin main推送成功。整个过程中我没有改任何代码也没有重装 git问题出在“本机 DNS 正常 端口可通 配置残留”这几个因素叠加后的一个隐蔽场景。这也是为什么我一直强调遇到网络报错先把报错读透、再逐层确认比直接删了重新clone强一百倍。5. 常见问题速查与避坑心得5.1 报错、原因、操作速查表报错关键词大概率原因优先操作Could not resolve hostDNS解析失败切换公共DNS清空DNS缓存Failed to connect / Connection refusedTCP连接层被拒查防火墙、查端口用curl测连通性Connection timed out数据包被丢弃链路不通检查网络隔离策略测试其他端口The remote end hung up unexpectedly大文件或传输不稳调大postBuffer或用Git LFSRPC failed; curl 56SSL连接被重置检查安全软件拦截尝试切SSHSSL certificate problem证书校验失败校准系统时间更新CA证书Unable to access / Could not read from remote综合类连通问题按第2节四层检查逐步排除这张表是我自己排查时用的速查索引你可以保存下来。每一条都对应一个明确的操作动作不用盲目试。5.2 几个容易反复踩的坑第一个坑动不动就改全局配置。git config --global的改动会影响这台机器上所有仓库有些人为了赶工图快把转发配置、缓冲区配置全部写进全局后面换项目就一直带着这些配置跑迟早出事。如果是项目特有的问题尽量用git config --local在当前仓库里配置别污染全局环境。第二个坑postBuffer往大了调当作万能药。这个变量本质是申请一块内存做缓冲区不是越大越好。我见过有人调到1GB内存占用暴涨电脑直接卡死。合理做法是先调大到500MB试一次不行就上Git LFS别死磕这个参数。第三个坑清配置时手滑删了不该删的项。git config --unset或git config --edit操作之前先用git config --list把当前配置完整看一遍确认哪条是真正的问题所在。改错了也没关系但别慌着重装git。第四个坑在公司或者受控网络环境里反复重试。某些封闭开发环境对外只开放白名单域名和端口你在里边怎么调都不可能推到外部仓库。这种情况下优先用git ls-remote确认链路通不通不通就果断找网络管理员别自己折腾半小时。第五个坑报错只复制后半句丢了前半句。排查网络问题重点要看完整报错开头的动作描述和失败节点。我的建议是报错信息直接右键复制全粘贴到备忘录里再逐行看不要只看红体字。写在最后的实操习惯折腾 git 网络问题这么多次我的真实体会是先读报错再分级排查最后才动手改配置。这三步的顺序反了大概率会越修越乱。现在我遇到任何 git 网络类问题第一反应永远是先跑三个命令git config --list看配置、nslookup 域名看解析、curl -v 目标地址看端口连通性。这三个命令跑完问题定位基本就完成七八成了。最后再分享一个小技巧调试之前给 remote 地址加一个临时--receive-pack或者先用git ls-remote探路比直接push大包试探要温和得多也不会在远端留下半截分支记录。