如何修复 Chrome 中的 ERR_CONNECTION_TIMED_OUT

当 Chrome 显示 ERR_CONNECTION_TIMED_OUT 时，表示它向服务器发出了连接请求，但在内置的等待时间结束前没有收到任何响应。与重置（有东西主动掐断连接）不同，超时是一种沉默：你的数据包已经离开电脑，却没有在规定时间内得到答复。浏览器只能放弃，并告诉你服务器"响应时间过长"。

区分这三种连接错误很有帮助。ERR_CONNECTION_REFUSED 是即时的、明确的"拒绝"——有机器应答，但端口上没有服务。ERR_CONNECTION_RESET 是传输中途被突然中断。ERR_CONNECTION_TIMED_OUT 则是缓慢的"无回应"：请求消失在网络中，再未返回。这种沉默把排查方向引向外部——你与服务器之间的路径、为其命名的 DNS，或服务器本身。

六个根本原因几乎涵盖了所有现实中的超时：网站确实宕机了、你的本地网络或运营商是瓶颈、过时的 DNS 把你引向了错误 IP、失效的代理吞掉了请求、Chrome 在本可接受的慢链路上过早放弃，或服务器本身过载。下面的步骤按从最快见效到更深层服务器检查的顺序逐一讲解。

常见原因一览

可能的触发因素	根本原因	首选操作
仅一个网站失败，其他正常	网站宕机或屏蔽了你	用宕机检测工具查询；稍后再试
所有网站都慢或超时	本地网络或运营商问题	测试其他网络；重启路由器
DNS 或 IP 变更后开始	DNS 记录过期	刷新 DNS；续约 IP
启用了 VPN 或代理	失效/过载的代理	禁用代理/VPN 后重试
服务器慢但可达	Chrome 过早放弃	禁用 QUIC；提高客户端超时
服务器是你自己的	服务器过载或配置不当	检查负载、数据库、防火墙、限制

步骤 1：检查网站是否宕机

在认定问题出在你这边之前，先确认该网站是否对所有人都不可用。服务器崩溃或在全球范围内不可达时，超时是最自然的症状。把网址粘贴到宕机检测服务中，例如 downforeveryoneorjustme.com 或 istheservicedown.com。你也可以让另一个网络上的朋友帮忙试试。

如果网站对所有人都宕机了，你这边无需修复任何东西——只能等运营方恢复。如果别人能访问而你不行为，就继续后续步骤。先做这一步，能避免你为了一个源自服务器的问题而花一小时去排查自己的网络。

步骤 2：测试不同的网络

如果别人能访问而你不行，下一个问题是你的本地网络是否是瓶颈。最干净的测试方法是彻底切换网络：在手机上开启热点，让电脑连接它，然后重新加载页面。如果热点能打开而常用 Wi-Fi 不行，问题就出在你的路由器、运营商，或它们与服务器之间的路由路径上。

先重启路由器和光猫——大量超时在重启清除陈旧的 NAT 状态后就消失了。如果使用 Wi-Fi，改用网线以排除无线干扰。如果无论换到哪个网络（包括手机流量）问题都跟随你，那么原因更可能是 DNS、代理或地区屏蔽——这些在后续步骤中处理。

步骤 3：刷新 DNS 并续约 IP

过期或损坏的 DNS 记录是超时的经典原因。如果你的电脑缓存了某域名的旧 IP——一个已不再提供服务的地址，或被防火墙拦截的地址——请求就会发往死地址并超时。刷新 DNS 缓存并续约 IP 会强制系统获取最新记录。

# Windows（在命令提示符中运行）
ipconfig /flushdns
ipconfig /release
ipconfig /renew

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

顺带考虑改用更快、更可靠的公共解析器。Cloudflare（1.1.1.1）和 Google（8.8.8.8）都是不错的选择；在 Chrome 中启用 DNS-over-HTTPS（设置 > 隐私和安全 > 安全）可以彻底绕过运营商的 DNS 干扰。

步骤 4：检查代理设置

指向失效或过载服务器的代理会默默吞掉你的请求直到超时——你既不会收到拒绝，只会得到沉默。这常发生在 VPN 客户端崩溃后未清理其代理条目，或系统代理仍为某个你已不在的网络而配置时。

在 Windows 上进入设置 > 网络和 Internet > 代理，关闭"使用代理服务器"。在 macOS 上检查系统设置 > 网络 > 详细信息 > 代理。在 Linux 和 macOS 上检查环境变量：

# 显示当前生效的代理变量
echo "http_proxy=$http_proxy"
echo "https_proxy=$https_proxy"

# 为当前 shell 清除它们
unset http_proxy https_proxy all_proxy no_proxy

禁用 VPN 客户端以及任何代理流量的 Chrome 扩展。如果禁用代理后超时消失，再逐个启用以找出元凶，然后修复或移除它。

步骤 5：提高浏览器中的连接超时

Chrome 并没有提供一个简单的"连接超时"滑块，但有若干设置会影响它放弃的速度。例如，实验性的 QUIC 协议在屏蔽 UDP 的网络上会导致超时。禁用它可强制 Chrome 回退到 TCP，在限制性网络上更宽容：

# 在 Chrome 地址栏打开：
chrome://flags/#enable-quic
# 将 "Experimental QUIC protocol" 设为 Disabled，然后重新启动。

也可以在设置 > 安全中切换安全 DNS（DNS-over-HTTPS）的服务商，并清除 Chrome 的主机缓存（chrome://net-internals/#dns）。对于调用确实较慢 API 的开发者，应在自己的代码中设置更长的超时，而非依赖浏览器默认值：

// 用 AbortController 为 fetch 设置 60 秒超时
const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), 60000);
try {
  const res = await fetch('https://api.example.com/data', { signal: controller.signal });
  const json = await res.json();
  console.log(json);
} catch (err) {
  console.error('请求失败或超时:', err);
} finally {
  clearTimeout(timeout);
}

// axios：以毫秒为单位设置自定义超时
axios.get('https://api.example.com/data', { timeout: 60000 });

这些改动为慢但可达的服务器提供了所需的额外响应时间。

步骤 6：检查服务器端问题

如果你拥有或运维该服务器，超时可能源自那里。一台过载、卡在慢数据库查询上，或触及资源上限的服务器，会接受 TCP 连接却无法在规定时间内完成 HTTP 响应。先检查系统负载和资源使用情况：

# Linux：整体负载和占用最高的进程
uptime
top -b -n 1 | head -20

# 内存和磁盘
free -h
df -h

# Web 服务器错误日志 (Nginx / Apache)
sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/apache2/error.log

留意常见元凶：耗时数秒的数据库查询、耗尽的 PHP/Node 工作进程池、上游超时短于后端所需时间的反向代理，或在负载下丢包的防火墙限速规则。只有在解决了底层慢速问题之后，才去调高相关超时（例如 Nginx 的 proxy_read_timeout）——否则你只是在掩盖更深层的性能问题。

诊断工具：ping、traceroute 和 curl

这三个工具能精确定位超时发生在路径的哪一段。请按顺序运行，并解读输出来缩小故障范围。

# 1. ping —— 基本可达性与延迟
ping -n 20 example.com        # Windows
ping -c 20 example.com        # macOS / Linux

# 2. traceroute —— 找出数据包在哪一跳中断
tracert example.com           # Windows
traceroute example.com        # macOS / Linux
# mtr 提供实时、循环刷新的视图（需单独安装）
mtr --report example.com

# 3. curl —— 精确测量每个阶段耗时
curl -o /dev/null -s -w "dns:%{time_namelookup}s connect:%{time_connect}s ttfb:%{time_starttime}s total:%{time_total}s\n" https://example.com

# 4. DNS 解析检查
nslookup example.com          # Windows
dig example.com               # macOS / Linux

如何解读结果：如果 ping 完全失败，说明主机不可达——检查 DNS 或全面宕机。如果 traceroute 在某一跳停止（通常是你的运营商或目标网络的边缘），阻断就在那里。curl 的耗时分解最为精确：较长的 connect 时间指向网络或防火墙问题，而 connect 很快却 ttfb（首字节时间）很长，则指向慢速服务器。

快速参考：原因与修复

症状	根本原因	修复方法
仅一个网站超时，其他正常，且对所有人宕机	服务器宕机	等待恢复；查看状态页
在某网络下所有网站都超时	本地网络或运营商	重启路由器；测试其他网络
DNS 或 IP 变更后超时	DNS 记录过期	刷新 DNS；续约 IP；更换解析器
开启 VPN/代理时超时	失效或过载的代理	禁用代理/VPN；清除代理环境变量
可达但 Chrome 过早放弃	QUIC 或浏览器超时过短	禁用 QUIC；提高客户端超时
自有服务器首字节响应慢	后端/数据库过载	检查日志、负载、查询、限制

常见问题

Chrome 的连接超时是多久？

Chrome 并没有公布单一的固定超时值，且该值随连接阶段和协议而变化。实际使用中，用户大约在连接尝试无响应 20 到 30 秒后会看到 ERR_CONNECTION_TIMED_OUT。目前没有受支持的方法直接修改它；切实的应对是修复底层慢速问题，或对于你自己的 API 调用在代码中设置明确的超时。

ERR_CONNECTION_TIMED_OUT 是我的问题还是服务器的问题？

两者皆有可能。如果只有一个网站受影响且对所有人都宕机，那是服务器的问题。如果所有网站都慢或超时，通常是你的网络、运营商或 DNS 的问题。测试另一个网络（步骤 2）并用宕机检测工具（步骤 1）能快速判断问题归谁。

为什么只有某一个网站超时，而其他网站秒开？

当只有一个网站超时时，原因通常是服务器端宕机、地区屏蔽，或 DNS 为该域名返回了错误 IP。请刷新 DNS、尝试公共解析器，并通过 VPN 或手机网络测试——如果用 VPN 能打开，多半是你的运营商或地区在屏蔽或错误路由到该主机的流量。

VPN 会导致 ERR_CONNECTION_TIMED_OUT 吗？

会。把你路由到过载或过远服务器的 VPN 会增加延迟，可能使请求超过超时窗口。更常见的是 VPN 已断开却留下陈旧的代理条目——你的流量无处可去并超时。禁用 VPN 并清除任何代理设置，即可测试它是否是元凶。

总结

ERR_CONNECTION_TIMED_OUT 本质上是一种沉默：你的请求已发出，却没有在规定时间内得到答复。这种沉默通常来自六个方面之一——宕机的网站、慢速的本地网络或运营商、过期的 DNS、失效的代理、Chrome 过早放弃，或过载的服务器。先从最快见效的入手：确认网站并非全球宕机（步骤 1），并测试另一个网络（步骤 2）。大多数超时在此即可解决。若仍未解决，诊断工具——尤其是 curl 的耗时分解——会准确告诉你沉默从何处开始，而其余步骤则针对该具体故障点给出修复方法。

相关指南

• 如何修复 Chrome 中的 ERR_CONNECTION_REFUSED
• 如何修复 Chrome 中的 ERR_CONNECTION_RESET
• 如何修复 Cloudflare 522 错误：连接超时
• Nginx 504 网关超时：完整修复指南