网站打开测试

上周三下午，网站我盯着浏览器里那个转了快十秒的打开加载圈，最后等来一句“ERR_CONNECTION_TIMED_OUT”。测试网站打不开。网站客户在微信上连发了三个问号，打开我回了个“正在查”，测试其实心里清楚——这活儿没那么快能搞定。网站

网站打开测试这件事，打开很多人以为就是测试“能不能访问”。真做过运维或者建站的网站人知道，这背后至少牵扯到四层：DNS解析、打开TCP连接、测试TLS握手（如果是网站HTTPS）、以及服务器返回首字节的打开时间。任何一层卡住，测试用户看到的都是同一个结果：白屏，或者一个冷冰冰的错误码。

我习惯用curl先跑一遍。命令不复杂：curl -o /dev/null -s -w "DNS: %{ time_namelookup}s | TCP: %{ time_connect}s | TLS: %{ time_appconnect}s | TTFB: %{ time_starttransfer}s | Total: %{ time_total}s\n" https://example.com。输出那串数字比任何监控图表都诚实。DNS超过200毫秒，说明解析环节有问题，可能是本地DNS服务器抽风，也可能是域名NS记录配错了。TCP连接时间飙到1秒以上，通常是服务器离你太远，或者中间路由跳数太多。TTFB超过800毫秒，那就得看看后端是不是在慢查询里挣扎。

上个月有个做外贸的客户找我，说他的独立站“偶尔打不开”，国内打开正常，国外客户投诉多。我让他把域名发过来，先查DNS。他用的是国内某家免费DNS服务，解析节点全在境内。欧洲用户请求解析时，要跨半个地球来回问，光DNS就耗掉1.5秒。后来换成Cloudflare的DNS，欧洲那边TTFB直接从2.3秒掉到400毫秒。问题不在服务器，在解析路径。

浏览器端也有不少门道。Chrome DevTools的Network面板里，看Waterfall那一列。如果一堆请求排着队等同一个域名，说明HTTP/1.1的队头阻塞在作怪。升级到HTTP/2或者HTTP/3，多路复用能把并发请求压到一条连接上。我见过一个页面，首屏加载了17个CSS和JS文件，全部串行下载，打开时间11秒。合并加压缩之后，2.8秒完事。用户不会管你技术栈多先进，他们只数秒。

移动端更麻烦。4G信号看着满格，实际带宽可能被基站限速。我用WebPageTest跑过同一个页面，在“4G”模拟环境下，LCP（最大内容绘制）是3.2秒；切换到“3G”预设，直接跳到9.7秒。运营商DNS劫持也常见，你明明配了A记录指向自己的服务器，用户却被解析到某个广告页。这时候得靠HTTPS证书校验和HSTS来兜底，浏览器一看证书不对，直接拦截。

还有个容易被忽略的：服务器防火墙。有些机房默认封禁ICMP，你用ping测域名，显示超时，以为网站挂了，其实HTTP端口活得好好的。反过来，有些服务器只开了80和443，你拿telnet去连22端口，连不上就慌，纯属自己吓自己。测之前先搞清楚要测什么协议、什么端口。

我自己养成了一个习惯：新站点上线前，至少跑三个工具。curl看时间分解，WebPageTest看真实浏览器渲染，再用dig查一遍全球DNS传播。三组数据对不上，就继续挖。网站打开测试不是点一下刷新就完事，它更像给一个系统做体检——你得知道每个器官的正常值是多少，才能判断哪里出了毛病。

昨天那个超时的站点，最后查出来是源站防火墙误封了CDN回源IP。解封之后，加载时间从超时变成1.4秒。客户又发来一个“OK”的表情。我关掉终端窗口，心想：下次能不能先看TTFB，再骂服务器。