同一个网址，换一种请求方法，测出来的数字可能差一倍。不是测速不准，是测的东西不一样。

默认的 HEAD 是「最轻的一问」

HEAD 和服务端说：我只要头，别给我正文。响应里的状态码、Content-Length、缓存头一个不少，就是没有内容本身。

好处是快，而且不受页面体积影响。判断「这个站通不通、快不快」，HEAD 最干净。

坏处也明显：下载阶段几乎是空的。你看到的那一段耗时接近 0，不代表用户下载也接近 0。

GET 才是用户真实走的那条路

换成 GET，服务端把 HTML 完整吐出来，下载阶段才开始有意义。页面 200KB 和 2MB，在这一段上差得很清楚。

所以当用户说「打开慢」而你的 HEAD 测速一切正常时，先换 GET 再测一次。很多时候慢就慢在体积和压缩上，HEAD 根本看不见。

POST 在这里的作用是「探路」

高级选项里的 POST 只切换请求方法，不会带请求体。它验证的是：这个地址接不接受 POST。

结果通常是三种。返回 200 或者 405，说明服务端对方法的处理是明确的；返回 403，多半是 WAF 直接拦了；连接被重置，可能是协议层就被挡了。碰到后两种，先用 IP 查询 看一眼解析落在哪台机器上，再判断是策略问题还是节点问题。

要注意它的边界：不带参数的 POST 测不到业务逻辑。想测登录接口、下单接口的真实耗时，得上压测工具，拨测做不了这件事。

怎么选，看你要回答什么问题

问「通不通、快不快」，用默认 HEAD，干扰最小。

问「用户下载花了多久」，用 GET，这才是完整链路。

问「接口允许什么方法、有没有被拦」，用 POST，配合 Cookie 还能测鉴权接口。

三个方式都能在 网站测速 的高级选项里切换，建议同一条 URL 三种各跑一次，把三个结果摆在一起看，比单看任何一个都有用。