连接超时是网络排查中最常见的故障类型之一，浏览器显示ERR_CONNECTION_TIMED_OUT，curl命令卡住几十秒后返回超时错误，这些现象背后往往混合了多种原因。很多人遇到这种情况第一反应是重启路由器，但真正高效的做法是按照DNS、代理、防火墙、CDN这条链路逐层排查，因为请求从发出到成功返回，中间每一个环节都可能成为卡点。本文把这条链路拆成四个环节，每个环节给出具体的判断方法和操作命令，照着做基本能覆盖九成以上的连接超时场景。
第一步：刷新DNS缓存，排除域名解析故障
DNS负责把域名翻译成IP地址，如果本地缓存的解析结果已经失效或者被污染，浏览器就会拿着一个错误或不可达的IP去连接，最终表现为超时。判断是不是DNS的问题很简单，直接用IP访问服务，如果能通而域名访问不通，基本可以锁定解析环节。
先手动查询域名的解析结果，和预期IP对比。Windows系统在命令提示符中执行nslookup ippipp.com，Linux和macOS可以使用dig ippipp.com或host ippipp.com。如果返回的IP明显不对，或者解析直接失败，就需要刷新本地DNS缓存了。不同系统的命令如下：
# Windows（需要打开命令提示符） ipconfig /flushdns # macOS（版本不同参数略有差异） sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder # Linux（以systemd-resolved为例） sudo systemd-resolve --flush-caches # 或者重启解析服务 sudo systemctl restart systemd-resolved
刷新之后如果问题依旧，可以尝试临时更换公共DNS服务器，比如把本机DNS改成223.5.5.5或8.8.8.8再测试。更换方法在Windows上位于网络适配器的IPv4属性中，Linux下修改/etc/resolv.conf即可。换了DNS立即就能访问，说明之前的DNS服务商返回了异常结果，这种情况下保持使用更可靠的DNS即可解决。
第二步：检查代理设置，排除本地转发异常
代理是连接超时的另一个高发原因，尤其对装了各类网络工具的开发者来说。代理客户端崩溃、节点失效、或者系统代理指向了一个早已关闭的本地端口，都会让请求被转发到一个黑洞里，等到超时才报错。这种情况的特点是：部分网站能访问、部分不能，或者换一台没有代理的设备就能正常访问。
排查顺序建议从系统代理开始。Windows在设置的网络和Internet选项中查看代理页签，确认手动代理是否指向了仍然存活的端口。macOS在系统设置的网络高级选项里查看。命令行工具也要单独确认，因为终端不一定走系统代理，可以通过环境变量检查：
# 查看当前终端是否设置了代理环境变量 env | grep -i proxy # 临时清空代理环境变量 unset http_proxy unset https_proxy unset all_proxy # 测试直连是否正常（绕过所有代理） curl --noproxy '*' -I https://ipipp.com
浏览器插件代理和系统代理叠加使用时容易出问题，比如插件代理指向本地7890端口，而系统代理又指向1080端口，两层转发一旦有一层断了就整体超时。建议统一只保留一层代理，排查期间先全部关闭，直连测试通过后再逐层打开，确定是哪一层导致的。curl加上--noproxy '*'参数可以直接绕过代理测试，如果绕过后正常而走代理超时，问题就在代理客户端本身，更换节点或重启客户端即可。
第三步：检查防火墙与安全软件，排除端口拦截
如果DNS和代理都正常，请求依然超时，就要考虑是不是被防火墙或安全软件拦截了。防火墙可能拦截的方向有两个：出站方向的本地防火墙，以及目标服务器侧的防火墙。本地防火墙拦截常见于安装了企业安全软件或某些杀毒软件之后，它们会静默拦截非常用端口的出站连接。
本地排查可以先测试不同端口，比如对比80、443和8080端口的连通性：
# 测试目标端口是否可达 curl -v --connect-timeout 5 telnet://ipipp.com:443 # Windows下用PowerShell测试 Test-NetConnection ipipp.com -Port 443 # Linux下用nc测试 nc -zv ipipp.com 443 -w 5
如果443通而8080不通，大概率是本地防火墙只放行了常用端口。Windows可以在防火墙高级设置中查看出站规则，临时关闭防火墙验证一下也能快速定位（验证完记得开回来）。Linux服务器上检查iptables或firewalld规则，云服务器还要额外检查安全组配置，这是最容易遗漏的一层，很多开发者在自己机器上排查半天，最后发现是云平台安全组没放行端口。
还有一个细节值得注意：某些安全软件会拦截特定的进程访问网络，表现为浏览器正常但某个客户端程序超时。可以把该程序加入白名单试试，或者查看安全软件的拦截日志，通常能直接找到记录。
第四步：确认CDN与服务端状态，排除远端故障
当本地所有环节都排查正常后，问题可能出在远端。现在大量网站都接入了CDN，某个CDN节点故障或者调度异常，就会导致部分地区用户超时而另一些地区正常。判断方法是用多个地点的拨测工具检测目标域名，如果只有部分区域失败，基本可以确认是CDN节点问题，这种情况只能等待服务商恢复，或者联系服务商切换节点。
命令行上可以用tracert或mtr看路由路径，观察丢包发生在哪一跳。如果丢包集中在某一跳之后并且该跳属于CDN网段，责任就在远端。同时检查目标服务的官方状态页，主流云服务商都有状态页可以查到故障公告。也可以直接联系服务提供方，让他们确认源站是否正常：
# Windows追踪路由 tracert ipipp.com # Linux/macOS使用mtr（需要安装），持续观察丢包 mtr -rw ipipp.com # 直接向源站IP发起请求（绕过CDN验证源站存活） curl -I -H "Host: ipipp.com" http://源站IP/
绕过CDN直连源站测试是区分责任的关键一步：如果直连源站正常，说明源站活着，问题出在CDN调度；如果直连源站也超时，那就是服务端本身故障，和本地环境无关。搞清楚这一步，至少能避免在自己机器上浪费时间。
总结排查顺序
连接超时的排查核心是按链路从近到远：先刷新DNS确认解析正确，再关闭所有代理测试直连，然后检查防火墙和安全软件的端口拦截，最后通过拨测和路由追踪确认CDN与服务端状态。每一步都只做一个变量修改，改完立即测试，这样能准确锁定问题层。多数情况下问题出在前两步，尤其是代理相关的配置冲突，占据了日常超时案例的大半。养成用curl的--connect-timeout参数快速测试的习惯，配合-v查看详细过程，排查效率会明显高于反复开关网页。