打开呀 .co

海外网站与 AI 访问解决方案
网站打不开 • • 更新：2026-09-25 • DeepSeek 深度技术推导

网络错误 ERR_CONNECTION 怎么解决？常见代码与根因图谱

遇到 ERR_CONNECTION_CLOSED、RESET、TIMED_OUT、REFUSED、ABORTED？打开呀为您系统梳理 Chromium 常见 ERR_CONNECTION 错误代码的 TCP 状态机对照表与针对性修复方案。

网络错误 ERR_CONNECTION 系列怎么解决？全代码根因图谱与修复

网络错误 ERR_CONNECTION 怎么解决？常见代码与根因图谱

Answer Block

ERR_CONNECTION_* 是 Chromium 网络栈（net:: 命名空间）在 TCP/TLS 建连阶段抛出的错误族，不是单一错误。核心成员与 TCP 状态机的对应关系是：ERR_CONNECTION_TIMED_OUT 对应客户端发出 SYN 后重传耗尽仍无应答（对端静默丢包或路由黑洞）；ERR_CONNECTION_RESET 对应收到对端 RST 强制复位（中间设备注入或服务端主动拒绝）；ERR_CONNECTION_REFUSED 对应收到 SYN 的 ACK+RST（目标 IP 可达但端口无监听）；ERR_CONNECTION_CLOSED 对应连接建立后（含 TLS 握手阶段）被 FIN/RST 意外关闭；ERR_CONNECTION_ABORTED 对应客户端本地主动取消或本地安全软件/代理截断。排查路径是：先用 chrome://net-export 抓 NetLog 定位失败发生在 DNS、TCP 连接、TLS 握手还是 HTTP 阶段，再用系统命令（Windows netsh/Test-NetConnection、macOS nc/pfctl、Linux ss/tcpdump）验证对应层，最后按层修复。绝大多数 ERR_CONNECTION 不是浏览器问题，而是 DNS 污染、路由不可达、端口未监听、TLS 证书链断裂或本地防火墙/WFP 拦截。

一、Chromium 网络栈与 ERR_CONNECTION 家族

Chromium 的网络请求不走操作系统的 socket API 直连，而是经过自己的网络服务进程（Network Service，network::mojom 接口）。一次 HTTPS 请求的完整链路是：

Renderer → Network Service → HostResolver → TCPClientSocket → SSLClientSocket → HttpStream
                ↓                ↓                ↓                ↓
            DNS 解析        TCP 三次握手      TLS 握手        HTTP 事务

ERR_CONNECTION_* 全部产生于 TCPClientSocket 和 SSLClientSocket 两层。理解这一点很关键：浏览器报的错是它自己观察到的 socket 层结果，而不是操作系统直接告诉用户的。所以同一个 ERR_CONNECTION_RESET，可能来自真实对端 RST，也可能来自本地 WFP 驱动注入的 RST。

1.1 错误码与 TCP 状态机对照表

Chromium 错误码底层事件TCP 状态机位置典型触发
ERR_CONNECTION_TIMED_OUTSYN 重传耗尽（Linux 默认 6 次，约 127s；Chromium 内部超时更短）SYN_SENT 停留至超时路由黑洞、对端静默丢包、GFW 式丢包、防火墙 DROP
ERR_CONNECTION_RESET收到 RST 段SYN_SENT / ESTABLISHED / CLOSE_WAIT 任意阶段中间设备注入 RST、服务端 SO_LINGER 0 关闭、连接跟踪表满
ERR_CONNECTION_REFUSED收到 SYN 的响应为 RST+ACKSYN_SENT → 立即 CLOSED目标 IP 可达但端口无进程监听、iptables -j REJECT
ERR_CONNECTION_CLOSED连接被 FIN 或 RST 关闭且无有效响应ESTABLISHED → CLOSEDTLS 握手未完成即断、HTTP/2 GOAWAY、服务端 keepalive 超时
ERR_CONNECTION_ABORTED本地主动取消（CancelableRequest）任意阶段用户点停止、页面导航离开、本地代理/杀软截断、ERR_ABORTED 同源
ERR_CONNECTION_FAILED泛指连接建立失败SYN_SENT综合错误，需 NetLog 细分
ERR_NAME_NOT_RESOLVEDDNS 解析失败连接前严格说属 DNS 族，但常与 CONNECTION 混报

1.2 为什么必须区分这五种

因为修复动作完全不同：

  • TIMED_OUT → 查路由、查丢包、查是否被静默阻断，改 DNS 或换网络通常无效，要查路径。
  • RESET → 查中间设备、查服务端行为、查连接跟踪表，本地清缓存无用。
  • REFUSED → 目标端口没开，查服务端进程、查端口映射，客户端怎么修都没用。
  • CLOSED → 连接建立后被断，重点在 TLS 层和服务端 keepalive 配置。
  • ABORTED → 本地问题，查代理、查杀软、查扩展、查 WFP 过滤驱动。

把 RESET 当 TIMED_OUT 修，或把 REFUSED 当本地网络问题修，是最常见的时间浪费。

二、逐错误码拆解：触发原因、场景、排查手段

2.1 ERR_CONNECTION_TIMED_OUT

底层机制：客户端发出 SYN，进入 SYN_SENT，启动重传定时器。Linux 默认 tcp_syn_retries=6，重传间隔指数退避（1s、2s、4s、8s、16s、32s），总时长约 127 秒。Chromium 有自己的连接超时（通常远短于此），超时后抛 ERR_CONNECTION_TIMED_OUT。关键特征：没有任何回包，连 RST 都没有。

触发原因：

  1. 路由黑洞：目标网段路由存在但下一跳丢弃。
  2. 静默丢包型阻断：中间设备对特定 IP/端口直接 DROP 而非 REJECT。
  3. 对端主机宕机但 ARP/路由仍指向它。
  4. 本地出口防火墙 DROP 出站 SYN。
  5. NAT 设备连接跟踪表满，新连接被丢弃。

排查手段：

  • ping 目标 IP：能通说明三层可达，问题在四层或中间设备。
  • tracert/traceroute：看在哪一跳开始丢。
  • tcpdump/Wireshark 抓包：确认 SYN 是否发出、是否有 SYN-ACK 回来。
  • 换端口测试：如果 443 超时而 80 正常，多半是端口级阻断。

修复方向：换网络路径、检查本地防火墙出站规则、确认目标服务是否真的在监听。

2.2 ERR_CONNECTION_RESET

底层机制：收到 TCP RST 段。RST 是 TCP 的强制复位，收到即连接立即销毁，不经过四次挥手。RST 可能来自真实对端，也可能来自路径上的中间设备（这是中国大陆网络环境的高频现象）。

触发原因：

  1. 中间设备注入 RST：连接跟踪设备检测到特定特征后，伪造源和目的向双方各发一个 RST。
  2. 服务端主动 RST：进程崩溃、SO_LINGER 设为 0 后 close、accept 队列满时某些内核行为。
  3. 连接跟踪表项过期：NAT 设备表项超时后收到后续包，回 RST。
  4. TLS 握手特征触发：某些设备在 ClientHello 阶段就注入 RST。

排查手段：

  • 抓包看 RST 的 TTL：如果 RST 的 TTL 与 SYN-ACK 的 TTL 明显不同，说明 RST 来自中间设备而非真实对端。
  • 看 RST 到达时机：SYN 发出后极短时间（<10ms）就收到 RST，且地理位置远，物理上不可能，必是中间设备。
  • 对比不同网络：同一目标在 A 网络 RST、B 网络正常，指向路径设备。

修复方向：RESET 通常不是客户端能修的，需要换路径或确认服务端行为。本地清 DNS 缓存、重装浏览器基本无效。

2.3 ERR_CONNECTION_REFUSED

底层机制：客户端发 SYN，对端回 SYN + ACK + RST 或直接 RST + ACK。这表示 IP 层完全可达，但对端内核明确告知”这个端口没人监听”。这是最”诚实”的错误，因为对端主动回应了。

触发原因：

  1. 目标端口确实无进程监听（服务没启动、监听在别的端口）。
  2. 服务监听在 127.0.0.1 而非 0.0.0.0，外部访问被拒。
  3. 防火墙用 REJECT 而非 DROP（iptables -j REJECT --reject-with tcp-reset）。
  4. 端口映射/反向代理配置错误，后端端口写错。
  5. IPv6 优先但服务只监听 IPv4。

排查手段：

  • telnet host port 或 nc -vz host port：直接看是否 refused。
  • 服务端 ss -tlnp / netstat -ano：确认监听地址和端口。
  • 检查是否 localhost 能通而外网 IP 不通 → 监听地址问题。

修复方向：这是服务端问题为主。客户端能做的是确认自己连的端口对不对、是否被本地 hosts 或代理改写。

2.4 ERR_CONNECTION_CLOSED

底层机制：TCP 连接已经建立（三次握手完成），但在 TLS 握手或 HTTP 事务完成前，连接被 FIN 或 RST 关闭，且 Chromium 没有拿到有效响应。与 RESET 的区别在于：RESET 是明确的 RST，CLOSED 是”连接没了但原因不明确”。

触发原因：

  1. TLS 握手失败：ClientHello 发出后服务端直接关闭（SNI 不匹配、协议版本不支持、证书问题导致服务端主动断）。
  2. 服务端 keepalive 超时：连接空闲过久被服务端关闭，客户端复用时才发现。
  3. HTTP/2 GOAWAY 后连接关闭。
  4. 中间设备在 TLS 阶段切断。
  5. 服务端负载均衡后端全部不可用，前端直接关连接。

排查手段：

  • openssl s_client -connect host:443 -servername host：手动完成 TLS 握手，看在哪一步断。
  • NetLog 看 SSL_HANDSHAKE 事件：确认是握手前断还是握手后断。
  • 检查证书链：openssl s_client 输出里的 Verify return code。

修复方向：TLS 配置问题为主。客户端可尝试关闭 QUIC（chrome://flags 里禁用 Experimental QUIC protocol）排除 QUIC 干扰。

2.5 ERR_CONNECTION_ABORTED

底层机制：Chromium 内部 CancelableRequest 被取消。这不是网络层错误，而是客户端主动中止。触发源可能是用户操作、页面导航、扩展、代理软件，或本地安全软件的 WFP 过滤驱动。

触发原因：

  1. 用户点击停止加载或快速导航离开。
  2. 浏览器扩展拦截请求（广告拦截、隐私扩展）。
  3. 本地代理软件（系统代理、PAC、透明代理）截断。
  4. 杀毒软件的 HTTPS 扫描功能注入过滤驱动。
  5. Windows WFP（Windows Filtering Platform）上的第三方过滤驱动。

排查手段：

  • 无痕模式测试：如果无痕正常，是扩展问题。
  • 禁用系统代理测试：如果正常，是代理软件。
  • 临时关闭杀软 HTTPS 扫描测试。
  • chrome://net-export 看请求是否在 URL_REQUEST 层就被 cancel。

修复方向：定位本地拦截源。Windows 上用 netsh wfp show state 可查看 WFP 过滤器；macOS 上查 pfctl -s rules 和系统扩展。

三、用 chrome://net-export 与 NetLog 定位卡点

chrome://net-export 是 Chromium 官方的事件日志工具，记录网络栈每一层的详细事件。这是排查 ERR_CONNECTION 最有力的工具，因为它能告诉你请求卡在哪一层。

3.1 抓取流程

  1. 打开 chrome://net-export/。
  2. 选择 Include raw bytes（含原始字节，能看到 TLS 握手细节，但文件大）。
  3. 点击 Start Logging to Disk，选保存路径。
  4. 复现问题。
  5. 点击 Stop Logging。
  6. 用 https://netlog-viewer.appspot.com/ 打开日志文件分析。

3.2 关键事件与卡点判断

在 NetLog Viewer 的 Events 面板，按 type 过滤，关注以下事件：

事件类型含义卡在这里说明
HOST_RESOLVER_IMPL_REQUESTDNS 解析DNS 问题，非 CONNECTION 族
TCP_CONNECTTCP 连接尝试看 net_error 字段
SOCKET_CONNECTsocket 层连接底层 errno
SSL_CONNECTTLS 握手开始TLS 层问题
SSL_HANDSHAKE_MESSAGE_RECEIVED收到握手消息卡在握手某步
HTTP_TRANSACTION_READ_HEADERS读响应头连接已建立，HTTP 层问题
URL_REQUEST请求生命周期看 net_error 和 CANCELLED

判断逻辑：

  • 如果 TCP_CONNECT 事件带 net_error: -118（ERR_CONNECTION_TIMED_OUT），且没有后续 SSL_CONNECT，说明卡在 TCP 建连。
  • 如果 TCP_CONNECT 成功但 SSL_CONNECT 带 net_error: -101（ERR_CONNECTION_RESET），说明 TLS 握手被 RST。
  • 如果 URL_REQUEST 显示 CANCELLED 且无网络层错误，是 ABORTED 类。
  • 如果 TCP_CONNECT 带 net_error: -102（ERR_CONNECTION_REFUSED），直接指向端口未监听。

3.3 命令行替代方案

不想开浏览器时，可用 curl 的 verbose 模式做类似分层观察：

curl -v --connect-timeout 10 https://example.com 2>&1 | head -50

输出会明确显示 Trying x.x.x.x...、Connected to、TLS handshake 各阶段，卡在哪一步一目了然。curl 的错误码与 Chromium 不完全对应，但阶段划分一致。

四、跨平台综合修复命令

以下命令按”先诊断、后修复”排列。所有命令均为系统自带或开源工具，不涉及任何商业软件推荐。

4.1 Windows（CMD / PowerShell）

诊断：

:: 测试 TCP 连通性（PowerShell）
Test-NetConnection example.com -Port 443

:: 查看 DNS 解析
nslookup example.com

:: 查看路由
tracert example.com

:: 查看当前 TCP 连接状态
netstat -ano | findstr :443

:: 查看 Winsock 目录状态
netsh winsock show catalog

:: 查看 WFP 过滤器（需管理员）
netsh wfp show state

修复：

:: 重置 Winsock（会重启，影响 VPN/代理软件）
netsh winsock reset

:: 重置 TCP/IP 栈
netsh int ip reset

:: 刷新 DNS 缓存
ipconfig /flushdns

:: 释放并续租 IP
ipconfig /release
ipconfig /renew

:: 查看并临时禁用代理
netsh winhttp show proxy
netsh winhttp reset proxy

注意：netsh winsock reset 会清除 LSP（分层服务提供者）注册，某些安全软件和代理软件依赖它，重置后需重装这些软件。

4.2 macOS（Terminal）

诊断：

# 测试端口连通
nc -vz example.com 443

# 手动 TLS 握手
openssl s_client -connect example.com:443 -servername example.com

# 查看路由
traceroute example.com

# 查看 DNS 解析
dig example.com
scutil --dns

# 查看 pf 防火墙规则
sudo pfctl -s rules
sudo pfctl -s state

# 查看系统扩展（可能拦截网络）
systemextensionsctl list

修复：

# 刷新 DNS 缓存
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# 查看并清除代理设置
networksetup -getwebproxy "Wi-Fi"
networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off

# 查看钥匙串中的证书信任问题
security find-certificate -a -p /Library/Keychains/System.keychain | openssl x509 -noout -subject

macOS 的 BSD 网络栈与 Linux 有差异：pf 是默认防火墙，networkd 管理网络配置，TLS 信任走 Keychain。如果 openssl s_client 能握手但浏览器不能，重点查 Keychain 里的证书信任设置和系统扩展。

4.3 Linux（Bash）

诊断：

# 查看监听端口
ss -tlnp

# 查看连接状态
ss -tan state syn-sent
ss -tan state established

# 测试端口
nc -vz example.com 443
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/example.com/443' && echo OK

# 抓包看 TCP 握手
sudo tcpdump -i any -nn 'host example.com and tcp port 443' -c 20

# 查看连接跟踪表
sudo conntrack -L | grep 443

# 查看 iptables/nftables 规则
sudo iptables -L -n -v
sudo nft list ruleset

修复：

# 查看并调整 SYN 重传
sysctl net.ipv4.tcp_syn_retries
sudo sysctl -w net.ipv4.tcp_syn_retries=3

# 查看并调整连接跟踪表大小
sysctl net.netfilter.nf_conntrack_max
sudo sysctl -w net.netfilter.nf_conntrack_max=262144

# 刷新 DNS
sudo systemd-resolve --flush-caches   # systemd-resolved
sudo resolvectl flush-caches

# 查看 MTU 和分片问题
ip link show
ping -M do -s 1472 example.com

Linux 上 ss 比 netstat 快且信息全，conntrack 是排查 NAT 相关 RESET 的关键工具。

4.4 通用修复优先级

  1. 确认错误码：不同码不同修法，先看浏览器报的是哪个。
  2. 换网络验证：手机热点测试，排除本地网络。
  3. 换设备验证：同网络另一台设备，排除本机问题。
  4. 抓包定位：tcpdump/Wireshark 看实际报文。
  5. NetLog 分层：确认卡在 DNS/TCP/TLS/HTTP 哪层。
  6. 按层修复：DNS 问题改 DNS，TCP 问题查路由/防火墙，TLS 问题查证书，HTTP 问题查服务端。

五、高价值长尾 FAQ

H3：为什么同一个网站在手机热点下正常，在家庭宽带上报 ERR_CONNECTION_RESET，但 ping 和 tracert 都正常？

这是典型的路径中间设备注入 RST，而非路由或 DNS 问题。ping 走 ICMP，tracert 走 ICMP/UDP，两者都不触发基于 TCP 特征的检测设备；而浏览器走 TCP 443，中间设备在识别到特定 TCP 特征（如 SNI、TLS 指纹、目标 IP 组合）后，会伪造 RST 分别发给客户端和服务端。判断方法：用 tcpdump 抓包，观察 RST 的 TTL 值。真实对端的 RST 的 TTL 应该与 SYN-ACK 的 TTL 接近（同一主机发出），而注入的 RST 的 TTL 往往明显不同（来自路径上另一台设备，跳数不同）。另一个判据是时间：SYN 发出后几毫秒内就收到 RST，而目标服务器地理距离远、物理上不可能这么快响应，必是中间设备。这类问题客户端无法通过清缓存、改 DNS、重装浏览器解决，因为问题不在客户端也不在服务端，而在路径。可行的应对是更换网络路径（如切换运营商、使用不同出口），或确认该目标是否在特定网络环境下被策略性阻断。注意区分：如果 RST 只在 TLS ClientHello 之后出现，说明检测发生在 TLS 层；如果在 SYN 之后就 RST，说明是 IP/端口级策略。

H3：ERR_CONNECTION_TIMED_OUT 和 ERR_CONNECTION_REFUSED 在 TCP 层面到底差在哪，为什么一个能修一个不能修？

两者在 TCP 状态机上的差异是本质性的。REFUSED 表示客户端发出的 SYN 得到了明确回应——对端内核回了 RST+ACK，意思是”我收到了你的 SYN，但这个端口没有进程监听”。这说明 IP 层完全可达、路由正常、对端主机在线，唯一的问题是端口没开。这是服务端可控的问题：启动服务、改监听地址、修端口映射即可解决。TIMED_OUT 则表示 SYN 发出后什么回应都没有，客户端在 SYN_SENT 状态重传多次后放弃。没有任何回包意味着三种可能：路径上有设备静默 DROP、对端主机不可达（路由黑洞）、或对端防火墙 DROP 而非 REJECT。关键区别在于”有没有回包”：REFUSED 有回包（RST），TIMED_OUT 无回包。这决定了排查方向完全不同——REFUSED 查服务端端口，TIMED_OUT 查路径和防火墙。从修复角度说，REFUSED 是”能修的”因为问题定位明确且通常在服务端；TIMED_OUT 是”难修的”因为无回包意味着你无法从客户端判断是路径哪一段出的问题，只能靠 traceroute 和分段抓包逐步缩小范围。实践中，如果 ping 通但 TCP 443 超时，且 traceroute 在某一跳后全是 *，基本可判定该跳之后存在静默丢包。

H3：chrome://net-export 抓到的日志里，如何区分是 TLS 握手失败还是 TCP 连接失败导致的 ERR_CONNECTION_CLOSED？

关键看事件序列中 TCP_CONNECT 和 SSL_CONNECT 的先后与结果。在 NetLog Viewer 里按时间顺序看：如果 TCP_CONNECT 事件的 net_error 是 0（成功），说明三次握手完成，连接已建立；随后出现的 SSL_CONNECT 事件如果带非零 net_error（如 -101 ERR_CONNECTION_RESET 或 -100 ERR_CONNECTION_CLOSED），则失败发生在 TLS 层。反之，如果 TCP_CONNECT 本身就带非零 net_error，则根本没到 TLS 层，是 TCP 建连失败。更细的区分看 SSL_HANDSHAKE_MESSAGE_RECEIVED 事件：如果这个事件完全没出现，说明 ClientHello 发出后服务端没有任何握手响应就断了，可能是 SNI 被中间设备识别后切断，或服务端不接受该 TLS 版本；如果出现了 SSL_HANDSHAKE_MESSAGE_RECEIVED 但后续 SSL_CONNECT 失败，说明握手进行到一半失败，重点查证书链、密码套件协商、协议版本。配合 Include raw bytes 选项，可以直接看到 ClientHello 的 SNI 字段和 ServerHello 的响应，精确定位。命令行下用 openssl s_client -connect host:443 -servername host -tlsextdebug 可以得到类似的分层信息，且输出更直观。

H3：Windows 上 netsh winsock reset 能修复 ERR_CONNECTION_ABORTED，但为什么有时重置后问题反而更多？

netsh winsock reset 的作用是清除 Winsock 目录中的 LSP（Layered Service Provider）注册，把 Winsock 栈恢复到出厂状态。ERR_CONNECTION_ABORTED 如果由第三方 LSP 或 WFP 过滤驱动引起，重置确实能修复。但问题在于：很多合法软件依赖 LSP/WFP 注册才能工作，包括 VPN 客户端、企业安全软件、部分代理工具、杀毒软件的网络防护模块。重置后这些注册被清除，软件的网络功能会失效，表现为”某些应用完全无法联网”或”VPN 连不上”。更麻烦的是，部分软件在检测到自己的 LSP 被清除后会自动重装，但重装过程可能不完整，导致 Winsock 目录处于半损坏状态，出现新的错误。正确的做法是：重置前记录当前 LSP 状态（netsh winsock show catalog > before.txt），重置后对比，确认哪些软件需要重装。如果重置后问题更多，用 netsh winsock reset catalog 再次重置并重启，然后逐个重装必要的网络软件。根本上说，winsock reset 是”核选项”，应该在其他排查手段（无痕模式、禁用扩展、关闭代理、临时关杀软）都无效后才用，而不是首选。Windows 10/11 上更精准的做法是用 Get-NetFirewallProfile 和 netsh wfp show state 定位具体的过滤规则，而不是整体重置。

H3：macOS 上浏览器报 ERR_CONNECTION_CLOSED 但 curl 和 openssl s_client 都正常，问题可能在哪？

这种”命令行正常、浏览器异常”的分裂现象，在 macOS 上通常指向三个方向。第一是 QUIC/HTTP3：Chromium 系浏览器默认尝试 QUIC（基于 UDP 443），而 curl 和 openssl s_client 默认走 TCP。如果网络环境对 UDP 443 有特殊处理（丢弃、限速、注入），浏览器会在 QUIC 失败后回退到 TCP，但回退过程中可能报 ERR_CONNECTION_CLOSED。验证方法是在 chrome://flags 里禁用 Experimental QUIC protocol，重启浏览器测试。第二是 Keychain 证书信任：macOS 的 TLS 信任链走 Keychain，浏览器用系统信任设置，而 openssl s_client 用自己的 CA bundle。如果目标站点的证书链中某个中间 CA 在 Keychain 里被标记为”永不信任”（可能被用户或某软件误操作），浏览器会拒绝而 openssl 不会。用 security verify-cert -c cert.pem 检查。第三是 系统扩展/网络扩展：macOS 的 Network Extension 框架允许内容过滤、DNS 代理、透明代理以系统扩展形式运行，这些扩展对浏览器流量生效，但 curl 从终端启动时可能不走同样的扩展路径（取决于扩展的配置范围）。用 systemextensionsctl list 查看已加载的网络扩展，逐个禁用测试。这三个方向的共同点是：问题不在网络协议本身，而在浏览器特有的行为路径或系统级的信任/过滤配置，所以命令行工具”看起来正常”。

总结：ERR_CONNECTION_* 不是一类错误，而是五个机制完全不同的错误。排查的第一步永远是确认具体错误码，第二步是用 chrome://net-export 或抓包确认卡在哪一层，第三步才是按层修复。跳过前两步直接清缓存、重装浏览器、改 DNS，是绝大多数人浪费时间的原因。