网站诊断别乱扫，先看这3项数据

网站一卡、一打不开，人的第一反应几乎都是打开检测工具来一遍：测速跑三家，在线扫描来两轮，顺手再点一次漏洞扫描。报告往回一拉几十页，红的黄的绿的一片，看完更不知道该动哪儿。我干活的方式一直是反过来——先拉三组数据，别的先放一边。网站诊断别乱扫，先看这3项数据，看的顺序也尽量别换，换一次至少多绕半天。

网站诊断别乱扫，这3项数据有先后

这3项不是什么高深指标，就是状态码分布、TTFB 拆解、后端耗时（里面通常藏着数据库）。为什么强调顺序？因为它们对应三类完全不同的病：报错、链路慢、服务端处理慢。三类病的药方不一样，混着看就永远对不上号。

测速分数为什么排在这3项后面

测速分数受节点、走没走缓存、CDN 在哪、并发多大一堆东西影响，同一个站在不同平台能差出一大截，首次访问和二次访问也不是一个数。它只能告诉你「慢」，不能告诉你是谁慢——是服务器处理慢，还是图片太大，还是那条线路正好抖了一下。服务器自己写下来的日志不会替谁说话，这是它比分数值钱的地方。分数拿来跟昨天的自己比还行，拿来当诊断依据就欠点意思。

第一项·日志里的状态码分布

把 access log 按状态码过一遍：5xx、4xx、2xx 各占多少，耗时最长的那几十条是什么、打的哪个地址。这一步最省事，也最能定方向。5xx 比例高，说明后端在报错，页面优化再狠也没用；4xx 一堆，多半是模板里的图片路径、内链，或者改版后老链接没做跳转；2xx 但耗时长的那些，才值得往性能上想。

这里有个坑必须躲：日志里一大半请求是爬虫和扫描器留下的，wp-login.php、/.env、/phpmyadmin 这类路径被刷出来的量，会把你对状态码的判断彻底带偏。统计之前先按 UA 和路径把这类剔掉，只看真实用户。剔完再看，比例往往完全不一样。

第二项·TTFB 拆成四段看

首字节时间是个笼统概念，得拆开：DNS 查询、TCP 连接、TLS 握手、等服务器吐第一个字节。浏览器开发者工具的网络面板里能看到 Timing 的细分，命令行也能，比如：

curl -o /dev/null -s -w “dns:%{time_namelookup} conn:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n” https://example.com/

怎么看这串数：time_namelookup 高，是解析或者 DNS 服务商这边的事，跟你服务器上那几行代码没半点关系；time_connect 高，多半是线路或者机房离用户太远；time_starttransfer 高，才是服务端处理慢，往下查后端。还有一种情况是首字节很快、下载拖很久，那就别再折腾服务器了，去看静态资源——图片没压、JS 一堆没合并、模板里引了外部字体，全是这条线上的事。

第三项·后端耗时，数据库慢查询躲不掉

TTFB 高的时候，下一步就是看服务端把时间花在哪。慢查询日志先打开，slow_query_log、long_query_time 这两个参数一改，重启或者热加载（具体以服务商或者官方页面说明为准）。跑一段时间，拉出耗时最长的几条 SQL，基本就是老面孔：where 的字段没索引、select * 把整张表拉出来、order by 走不了索引、join 了两张大表。这种慢，加机器加内存都压不住，得老老实实改语句或者加索引。

还有一种慢跟数据库没关系：代码里同步调了第三方接口，对方超时你跟着一起卡。这种时候日志干净、慢查询也干净，页面就是慢，得翻应用日志里那几行外部请求的耗时。找不到方向的人最容易在这里给服务器升配置，钱花了，问题原地不动。

顺序反了就是白忙

顺序其实就一句话——先看错，再看慢，最后看时间到底被谁占了。要是真有一半请求返回 5xx，你去压图片、上 CDN，除了报告好看，对用户没任何帮助。反过来也成立：三项都跑完发现数据都正常，那再回头查前端、查模板、查是不是网络抖动，也来得及，至少你知道不是服务器的问题。

还有个习惯得改：别三处一起调。一次只动一处，改完等一个完整的时间窗口，再拉一份同样的数据对比。三处一起改，速度回来了你也不知道是谁起的作用，下次碰上同类问题还得重新猜一遍。日志留存的窗口也尽量拉长些，短了看不出周期规律。

扫描器报告和诊断是两码事

端口扫描、漏洞扫描该做，但那是巡检的活儿，跟「网站为什么慢」是两条线。这类工具喜欢把版本号暴露、目录可列、Cookie 没加 HttpOnly 全标成风险项，一份报告里几十条提示很正常，可对性能问题几乎没有帮助。最常见的后果是，你花两天去修一堆低风险项，真正卡住用户的那个问题还在原地。安全和性能分开处理，别指望一个工具干两件事。

一个最小清单，照着走就行

拉日志、统计状态码、剔掉爬虫和扫描器请求；用 curl 或者网络面板把 TTFB 拆成四段，找出长在哪一段；打开慢查询日志，把最慢的几条 SQL 拎出来，顺手看一眼外部接口的耗时。三件事做完，方向基本就定了。CDN、模板、图片压缩、HTTP 版本这些，都是知道病根之后再动手的东西，早做一步都是浪费。

工具没错，错的是先掏工具、后看数据。乱扫一通最省事，也最容易把你带到跟问题无关的地方。先花点时间把这三组数据抄下来，比跑一天扫描器有用。各家面板的参数名和默认值不太一样，动手改之前，以服务商或者官方页面说明为准。