网站测试状态码

网站测试状态码，很多人只记两个数：200 算好，5xx 算坏。

实际跑一遍会发现，同一个站，一小时里能出三种码。码本身不说明问题，码在什么时候出现才说明。

下面按时间走一遍。

第一次测：先拿到一个码

先拿到一个码，别的先不管。

用命令行最快：curl -o /dev/null -s -w '%{http_code}\n' https://你的域名。

拿到 200，先别收工。拿到 502，先别急着改。

这一步只做一件事：定一个起点。

同一分钟再测：码会不会变

隔三十秒再跑一次同一条命令。

两次一样：这个码暂时稳定。

两次不一样：说明有东西在轮换，可能是多台后端，也可能是缓存。

不一样的码，比稳定的 5xx 更值得看。

改完配置之后：缓存还在

改完配置，第一件事不是测，是等。

前面有 cdn 或者反向代理时，改完立刻测，拿到的往往是旧的。

要么清缓存，要么等一个缓存周期。

没清就测，很容易得出「改了没用」这个错结论。

半小时后再测：有的节点先变

半小时后，从多个地区各测一次。

用宝塔拨测的网站测速跑一轮，按地区看每个节点拿到什么码。

一部分变新、一部分还是旧：说明各地缓存进度不一。

全部都还是旧：说明缓存没刷掉，或者改的地方不是生效点。

第二天早上：看是不是稳定

第二天同一小时再测一次。

昨天怎么测今天还怎么测，码一致，才算改对了。

今天变成了另一种码：看是不是夜里跑过任务，或者防护策略调过。

一天里的码不一样，不要急着下结论。

用户报错那天：对时间轴

用户说「昨天打不开」，就按昨天那个时间点对。

先问清是几点、哪个地区、哪个页面。

再翻那段时间各个节点拿到什么码。

对得上，才叫复现。对不上，先补信息。

一周后归档：留一份码的历史

把这一周每次测的时间、地区、码记在一张表里。

下次再出问题，先比这份历史。

码的历史比单次结果有用。

反过来，有人看到 4xx 就去加白名单，加完还是 4xx，一天就过去了。码没变，说明动手的地方不对。