网站页面打开慢，先不要直接重启服务或升级配置。排查的起点是确认“慢”发生在哪里：是所有页面都慢，还是只有登录、搜索等动态页面慢；是各地访问都慢，还是只有部分访问者慢；是连接建立慢，还是连接完成后等待响应慢。不同现象对应的检查方向不同，单看一次 CPU 使用率无法判断整台香港服务器是否存在性能瓶颈。

建议在故障发生时，选定一个已确认可安全重复访问的页面，记录访问时间、响应状态、耗时及测试位置，再与服务器同一时段的指标对照。排查前需具备网站测试权限，以及服务器指标和应用日志的只读权限。下文命令以可登录的 Linux 服务器为例，均用于观察，不要求修改配置；如果网站运行在容器中，还要确认看到的是宿主机指标、容器指标，还是应用实际受限的资源配额。

先确认慢的是哪一段

先把问题收窄到可复现的请求。用同一个网址，分别观察静态资源和实际变慢的动态页面；不要用提交订单、发送消息等会产生副作用的接口做重复测试。记录测试时是否已登录、是否经过缓存或代理，以及异常是否只出现在某些时间段。否则，两次访问看似相同，实际可能由不同缓存状态或后端处理，耗时不能直接比较。

在测试者自己的电脑上运行以下命令。先把示例地址换成目标网站上允许重复 GET 访问的页面；在服务器上运行同一命令，可作为另一访问位置的对照。

URL='https://example.com/path'
curl -sS --max-time 20 -o /dev/null \
  -w 'http=%{http_code} ip=%{remote_ip} dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} bytes=%{size_download}\n' \
  "$URL"

--max-time 20 只是防止测试长时间挂起，不是判断网站性能的合格线。命令默认不跟随跳转：如果状态码是 3xx，应先确认跳转目标，再分别测试；如果请求报错或超时，应记录报错内容，不能把输出中的不完整时间当作一次成功请求。

这些时间从请求开始累计：dns 到域名解析完成，tcp 到连接建立，tls 到 HTTPS 握手完成，ttfb 到收到首字节，total 到传输结束。要判断某一阶段耗时，应比较相邻时间的差值，而不是把各项相加。ttfb 较长既可能是应用或数据库处理慢，也可能包含网络传输等待；total 明显长于 ttfb，则还要检查响应体大小和传输过程。

此时先作初步分流，不急于定因：

正常与异常的分界，应以同一页面、同类访问条件下的历史表现，以及故障时用户实际感受到的变化为依据。不同页面的大小、缓存状态和处理流程不同，不适合套用一个统一耗时值。

由外到内检查网络

当连接阶段异常，或仅部分访问者反馈慢时，先分别从受影响位置和另一个可用位置测试同一域名、同一页面，保留测试时间、状态码和阶段耗时。如果只有某个位置异常，而服务器上的应用处理时间、资源指标均未同步恶化，应优先继续核查该位置的访问路径；如果不同位置同时异常，再把注意力转向服务器及其上游服务。

在 Linux 服务器上，可用以下只读命令查看网卡收发统计和连接概况：

ip -s link
ss -s

ip -s link 中的丢包、错误计数通常是累计值。应在故障期间对实际承载业务的接口间隔取样，比较计数是否继续增长，并结合访问测试判断；单次看到非零值，不能证明错误正在发生。虚拟网卡的统计也不一定覆盖服务器之外的整条访问路径。ss -s 可辅助观察连接数量和状态变化，但连接数上升可能只是访问量增加，需要与正常时段比较。

如果网络侧没有对应异常，而动态请求的首字节持续变慢，就继续检查主机资源。反过来，即使服务器 CPU、内存看起来空闲，也不能据此排除访问路径问题。

对照同一时段的 CPU、内存与磁盘

以下检查应尽量在用户反馈变慢的时段进行，并记录命令输出的时间。故障已经结束后才取得的一张资源截图，只能说明截图当时的状态，不能证明故障发生时没有资源瓶颈。只读观察不需要回滚；不要为了排查而先清缓存、停进程或重启服务，以免抹掉线索并影响在线请求。

CPU：看持续占用和等待，而非只看负载数字

date -Is
uptime
top -b -n 1 | head -n 25
ps -eo pid,comm,%cpu,%mem,stat --sort=-%cpu | head -n 15

uptime 的负载值反映一段时间内等待运行或不可中断等待的任务情况，不等于 CPU 使用率。应结合 top 中 CPU 忙闲情况、进程占用、核心数量和同时间的请求变慢情况判断：

• 某个进程持续占用 CPU，且对应应用请求同步变慢，优先检查该进程处理的任务；总 CPU 未满时，单个执行路径也可能成为瓶颈。
• 负载升高，但 CPU 并未持续繁忙，不宜直接归为“CPU 不够”；还要看是否存在磁盘等待或其他阻塞。
• 只出现一次短暂峰值，随后请求与指标恢复，尚不足以判断为持续瓶颈，应继续按相同间隔观察。

如果是在容器内执行命令，进程视图和 CPU 配额可能与宿主机不同。验收时必须注明观测范围，避免把宿主机空闲误认为应用没有受到配额限制。

内存：关注可用空间与换入换出

free -h
vmstat 1 5

free -h 中的 available 比单看 free 更适合判断 Linux 当前可供程序使用的内存；缓存占用本身不等于内存故障。vmstat 1 5 的第一行是历史汇总，应重点看后续采样中的 si、so 是否持续出现换入换出，并对照应用响应是否同时变慢。

如果可用内存持续紧张，且发生换页、进程被终止或应用日志出现内存相关错误，内存瓶颈的证据才更充分。仅看到交换空间已有使用量，不能证明此刻正在因内存不足而变慢。不要通过清理系统缓存来“验证”猜测，这会改变运行状态，也无法定位真正占用内存的环节。

磁盘：区分容量、等待和具体读写任务

df -h
df -i
vmstat 1 5

df -h 检查文件系统空间，df -i 检查 inode。任一资源接近耗尽，都可能使写入、日志或临时文件处理失败，但“空间不足”和“磁盘读写慢”是两个不同问题。vmstat 中持续的 wa 升高或阻塞任务增加，可作为继续检查 I/O 的线索，不能单独证明是哪块磁盘、哪个进程造成的。

如果系统已安装 iostat，可进一步查看设备级读写情况；未安装时无需为一次线上排查临时改动系统环境：

command -v iostat
iostat -xz 1 5

仅在第一条命令确认可用后执行第二条。iostat 第一组数据可能是启动以来的汇总，重点比较后续采样中的设备变化、读写量和等待时间，并与故障时段对齐。某个指标短时升高，并不自动等于用户请求被磁盘拖慢；需要结合应用日志、实际文件系统和请求耗时判断。

主机指标正常时，继续拆分应用与数据库

CPU、内存、磁盘和网卡没有发现同步异常，并不代表网站“没有瓶颈”。此时应把检查范围收缩到慢请求所经过的应用处理链路。

先选同一时段的几条慢请求，核对访问日志中的路径、状态码、请求耗时；如果应用有请求标识或分段计时，再对照应用日志，确认时间花在业务计算、外部依赖等待，还是数据库访问。只比较“静态快、动态慢”可以确定排查方向，但不能直接判定数据库有问题：动态页面也可能受模板渲染、锁等待、后台任务竞争等因素影响。

数据库方向的判断，需要有更直接的证据。例如，慢请求与数据库慢日志在时间和请求链路上能够对应，应用记录的数据库等待占主要耗时，或者连接等待、锁等待在故障时段同步增加。数据库 CPU 升高或出现一条慢查询记录，都不足以单独解释整个网站变慢；还要确认它是否属于受影响请求，以及是否持续出现。

现阶段以读取现有日志和监控为主，不在生产环境直接执行批量查询或修改数据库参数。如果后续确需调整索引、查询或配置，应先确认备份可用、评估影响范围，在约定窗口实施，并准备恢复原配置或回退变更的方法；变更后的判断仍以同一类请求复测为准。

将证据放在一起，通常能得到比“服务器配置不够”更明确的处理方向：

表中的判断都要求时间一致、对象一致。如果请求经过缓存、代理或多个后端节点，还要记录实际命中的路径；证据不能对应时，应保留“尚未定位”，而不是强行选一个资源归因。

用同一请求复测并留下验收记录

修复或调整之后，不只看监控曲线是否下降，还要从原先受影响的位置，用相同网址、相同登录状态和相近的访问条件复测。对照修复前后的状态码、DNS 与连接时间、首字节时间、完整传输时间，以及对应时段的主机和应用指标。若只是重启后暂时恢复，应继续观察原故障时段或相近负载下是否复发，不能把短时恢复当作瓶颈已消除。

一次可供复查的验收记录，至少保留：

• 故障与复测时间、测试位置、页面路径及是否命中缓存；分享记录前隐藏敏感路径、IP 和用户信息。
• 原始请求结果，包括状态码、各阶段耗时，以及失败时的错误信息。
• 同时段 CPU、内存、磁盘、网络的采样结果，并标明来自宿主机还是容器。
• 与慢请求对应的访问日志、应用日志或数据库等待证据，以及采取的变更和回退方式。

验收的正常状态，是原先可复现的慢请求恢复到该页面的正常表现，错误不再出现，相关异常指标也不再与请求变慢同步；若只有耗时改善而错误仍在，或资源指标恢复但用户访问仍慢，就应沿尚未排除的分支继续查。把同一组检查保留为持续观察项，下次出现波动时，才能更快区分是访问路径变化、主机资源压力，还是应用与数据库处理变慢。