今早同事拉代码，卡了两分钟弹出一行 fatal: unable to access，后面跟着 operation timed out。他第一反应是网断了，浏览器打开网页却是好的，这就是超时问题的迷惑之处，能上网不等于能连上那个地址。

这个报错本身不挑技术栈，git 拉代码、ssh 连服务器、pip 装包、curl 请求接口，都可能看到它。含义很统一，就是客户端把请求发出去了，等对方回应等超了，始终没等到一条完整回包。常见默认超时是几十秒到两分钟不等，各工具不一样。

先分清是被墙还是服务真挂了

打开终端敲 ping 目标域名，能通说明网络到得了那台机器，问题在端口或者服务。再敲 telnet 域名 端口号，端口连不上就卡在那，连得上会显示已连接。这一套下来基本能定位是链路问题还是服务问题。连接超时和读取超时是两码事，连接超时是握手就没成，读取超时是连上了但对方半天不回数据。

最常见的三个原因和对策

一是走海外地址被中间链路卡住，公司网络尤其明显，这时候挂上代理再重试，git 的话可以去配置里设 http.proxy。二是目标服务过载，并发高的接口偶尔抽一下，重试几次就好，别死磕一次结果。三是防火墙或者安全组把端口挡了，换台机器试试就知道，本地能连服务器不能连就是安全组的事。

  • git 拉代码超时：先换 ssh 协议，再考虑代理
  • 接口偶发超时：加超时参数和重试，比如 curl 的 max-time
  • 数据库连接超时：查连接池配置，别让等待队列排太长

还有个容易忽略的点，DNS 解析慢也会伪装成超时。换成公共 DNS 再试，很多时候一下就通了。

再补两类容易误判的情况。一种是 HTTPS 证书握手阶段超时，telnet 测端口是通的，结果请求还是超时，这时候要用 curl 加详细参数看卡在哪一步。另一种是连接池满了，看着像超时，其实请求根本没发出去，在排队，这类得去看连接池监控，压根不是网络的锅。

说白了，超时不是一句话能定死的错，按链路、端口、服务、DNS 四层逐个排除，比反复重试有效得多。