教程 VPS选购指南

网站白天快、晚上慢怎么办？按步骤排查线路、带宽和服务器

网站白天正常、晚上变慢，CPU低也不能证明线路拥堵。用浏览器分清连接、首字节和下载阶段，结合服务端日志与分时测试，判断该优化网站、升级带宽还是调整线路。

更新于 2026年10月22日文档维护：MatrixIDC 0 人阅读

本页目录

白天点开网站正常，晚上客户发来一句“怎么一直转圈”。你登录服务器，CPU 占用不高，重启后又试了几次，速度还是不稳定。这时最容易做的决定，就是加带宽，或者直接换一台带“优化线路”的服务器。

先把这笔钱留住。网站晚间变慢、CPU 不高，还不能证明线路拥堵。 要把访问过程分成连接、等待响应和下载资源几个阶段，再对照服务器记录。本文是一份排查教程，示例用于说明方法，不代表 MatrixIDC 或其他厂商的实测结果。

第一步：确认谁在什么时候访问慢

保留具体页面和发生时间

记下完整网址、出问题的动作、发生时间和时区。是首页显示慢，还是点登录、查订单、上传文件时慢？不同请求经过的程序和外部接口不同，不能只测首页就代表整个网站。

如果用户说“昨天晚上”，继续把时间缩小到能查日志的范围。保留一次现场后再改配置，避免重启、切换 CDN、更新插件全挤在一起，最后不知道哪一步产生了效果。

区分单个用户和一类网络

用原来的网络复测，再换手机流量或另一个运营商作对照。同时记录地区、运营商、是否使用代理、访问设备及浏览器。

只有一条家庭网络慢时，应先检查本地 Wi-Fi、路由器和同网下载占用。多个地区的同一运营商都出现相似问题，才有理由继续深入该访问路径。多个运营商都慢，也不自动等于服务器故障，还要看请求具体卡在哪里。

白天和晚上使用相同条件

保留相同页面、测试设备、访问网络和缓存设置，在正常时段与故障时段分别测几次，记录全部结果。不要只挑白天最好的一次和晚上最差的一次比较。

记录项目	需要写什么
时间	日期、时刻、时区
访问来源	地区、运营商、网络类型
目标	完整页面或具体接口、是否经过CDN
现象	首屏空白、图片慢、按钮无响应或下载慢
条件	是否登录、缓存设置、是否改过配置
结果	状态码、请求耗时、同期服务器记录

测试时访问了不同 CDN 节点或不同 IP，也要留下记录。这些变化会影响对比，不能默认两次请求完全走同一路径。

第二步：用浏览器看网页到底卡在哪一段

打开Network面板，找到真正慢的请求

在 Chrome 中按 F12，打开 Network，确认网络限速选择为正常的不限速状态。清空请求列表，再访问问题页面。若比较首次访问，可以勾选 Disable cache，并在两次测试中保持设置相同。

先找主文档请求，再找耗时较长的接口、图片或脚本。点开请求的 Timing，查看各阶段耗时。浏览器缓存、连接复用和请求协议会影响显示，有些阶段没有单独耗时并不等于测量失败。Chrome Network 官方说明

不要只盯着页面底部的总完成时间。统计脚本、广告资源或长连接也会留在请求列表中；用户看到主要内容的时间，与所有请求结束的时间并不相同。

连接阶段慢，继续检查网络和接入层

DNS、建立连接或 TLS 阶段明显变长时，检查解析结果、访问路径、CDN 节点及服务器接入情况。用另一网络访问相同页面作对照，观察慢的阶段是否也发生变化。

这一步提供排查方向，还没有直接定位到哪一家网络有问题。若连接被复用，本次请求不会完整经历新连接过程，不能把它与另一次全新连接的数字直接作等价比较。

等待首字节慢，不能直接说是CPU不够

浏览器等待响应的时间包含网络往返及服务端准备响应的影响。它不是纯粹的程序计算时间。数据库等待、请求队列、外部接口和缓存未命中，都需要结合服务端记录核对。

例如，商品页很快，但支付前的运费查询很慢，就要重点检查那次接口请求，而不是先把整个网站迁走。浏览器里找到慢请求的时间，正好可以拿来查对应的应用日志。

首字节正常、文件下载慢，检查资源大小和传输

页面框架很快出现，图片迟迟加载不完时，查看图片实际传输大小、缓存状态，以及是否集中从同一个地址下载。原始大图、重复资源和第三方素材，都值得逐项检查。

此时也要对照服务器出口带宽和相同资源在其他网络的下载表现。图片大与线路慢可以同时存在；先减少不必要的传输，再判断剩下的问题，才能知道扩带宽会改善哪一部分。

网页请求依次经历解析、连接、等待响应和下载资源，时间线仅表示阶段

网页请求依次经历解析、连接、等待响应和下载资源，时间线仅表示阶段。

第三步：把浏览器现象和服务器记录对上

看故障发生时的资源，别只看事后的面板

检查同一时段的 CPU、可用内存、磁盘活动、网络吞吐，以及应用和数据库的错误记录。面板几分钟一个平均值，会掩盖短时尖峰；事后登录看到资源空闲，也不能替代故障时间点的证据。

特别留意定时备份、批量任务、日志处理和爬虫请求。有明确的任务时间表，就把它与慢请求的时段并排对照，再用调整后的复测确认影响。

静态资源正常、动态页面慢，先查应用

找一个同站静态资源与问题页面对比，同时检查两者是否经过相同 CDN 缓存路径。若动态页面等待明显增加，而静态资源一直正常，可以继续检查数据库查询、插件、外部 API 和应用排队。

这不是“静态快就一定与线路无关”。缓存节点与源站的路径不同，会改变观察结果。需要先把访问层次讲清楚，再解释差异。

有反向代理时，分开看代理和上游

如果日志已经记录请求总耗时、上游响应时间或请求 ID，就用这些字段找到同一次请求。浏览器显示慢，代理与应用却很快结束，下一步应关注它们之外的传输和客户端环节。

没有这些记录时，先让维护人员确认日志配置，再在合适窗口增加观测。不要为查一个慢请求，直接在业务高峰反复重启网站或数据库。需要处理整机内存问题，可以参照服务器内存不足时的检查与升级判断。

第四步：用分时网络检查复核线路问题

可以用curl保留一次请求的时间记录

下面示例适用于 Linux 或 macOS 终端，需要已安装 curl。把地址替换为自己的问题页面，选择最终 HTTPS 地址，避免先被重定向到其他页面。

curl -sS -o /dev/null --connect-timeout 10 --max-time 30 \
  -w 'ip=%{remote_ip} code=%{http_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  'https://example.com/'

这些时间以秒为单位，多数字段是从开始到相应事件的累计时间，不能把它们相加当作总耗时。first_byte 也不能直接当作后端耗时。若请求超时或失败，要连错误信息一起保留，不要只复制一行数字。curl 参数说明

该命令只获取指定 URL，不会执行网页 JavaScript，也不会像浏览器一样继续加载所有图片。它适合对比同一个请求，不是完整网页体验测评。登录后页面还需要对应会话，不能拿未登录的跳转页替代实际故障页面。

路由检查要记录方向

从国内用户网络到服务器的检查，反映这个方向的路径；服务器到用户网络的路径需要单独检查。两边不必相同。若网站经过 CDN，测域名得到的通常是到 CDN 接入地址的路径，不能直接当作源站回程。

确有源站对比需要时，由维护人员使用正确域名和证书配置进行测试，不要公开源站信息，也不要为了测速关闭正式防护。线路选购的概念可参照三网优化VPS的回程与晚高峰验收方法。本篇重点是把它与真实慢请求关联起来。

中间一跳丢包，不等于网页流量在这里丢了

MTR 结合了路径发现和多次探测。中间设备可以限制对探测报文的回复；如果后续和目标响应正常，仅凭某一跳丢包率很高不能认定转发故障。目标探测本身也会受响应策略影响，要与实际访问和多次观测一起判断。MTR 官方项目说明

同样，网络测速跑出的高吞吐，不能证明网页响应快。测速连接数、目标位置、协议和服务器负载都可能不同。保存测试条件，比只保存一个最高速度数字更有用。

第五步：按证据选择处理办法

观察到的结果	下一步处理	怎样复查
自家Wi-Fi慢，其他网络访问正常	检查本地网络和占用	原网络处理前后访问同一页面
动态请求等待增加，应用日志也显示慢	检查查询、插件、队列或外部接口	对比同一接口耗时和失败情况
大图片下载久，出口带宽同期接近限额	压缩资源、检查缓存，再评估带宽	页面传输量与下载时间一起看
特定网络晚间连接或传输持续恶化	提交分时与多网络证据给服务商	在相同故障时段复测
第三方脚本慢，主站内容已返回	检查第三方依赖和加载方式	确认主要页面功能与显示改善