网站还没输入就超时；问题多半出在这两处

输入框还没加载出来，光标都没地儿落，屏幕上那个圈就在那儿转，转到最后甩一句连接超时，或者干脆 504。这种「网站还没输入就超时」的情况，十个人有八个先去测网速，测完发现下载挺快，就更懵了。网速只是嫌疑名单里的一个，真正爱出问题的是另外两个位置：请求还没顺利走到服务器，以及请求到了服务器却被攥着不撒手。

我干这行久了养出一个习惯：凡是框还没出来就转圈的，先别动服务器，也先别换网络，把这条请求从头到尾的时间线拉出来看一眼。这条线一分段，答案基本自己就跳出来了。

网站还没输入就超时，先分清是链路还是后端

请求从浏览器发出去，到服务器吐出第一个字节，中间要过好几道关口：本机 DNS 解析、TCP 建连、TLS 握手，可能还夹着代理和 CDN 回源。这些都算「请求还没到」的阶段。等字节真的进了应用层，才开始算另一头的账——查库、调外部接口、抢锁、排队。两边表现一模一样，都是转圈到超时，位置却差着十万八千里。

一个土办法先分大类：换一台不同的网络去开同一个页面，比如从家里宽带切到手机热点。换网络立刻好了，基本可以盯链路那一头；换了网还是老样子，或者在别人的机器上也能复现，那就往服务端查。

一条请求的时间线，拆开看就明白

浏览器按 F12 开 Network 面板，点开那条卡住的请求，Timing 一栏会把时间切成几段：DNS 查询、Initial connection、SSL 握手、Waiting(TTFB)、Content Download。Waiting 那一段特别长，说明请求已经到了服务端却没人应答，属于第二处；前面几段加起来占了大头，那还在路上兜圈子，属于第一处。

命令行更干净，一条 curl 就能看到分段：curl -o /dev/null -s -w “dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n” https://example.com/ 。想多抓几次看稳定性，外面套个循环就行，别折腾太复杂。

提醒一句，这套模板只对 https 有意义，http 的站点没有 TLS 那一项，跑出来是 0，别以为命令写错了。另外 curl 走的是系统 DNS 和系统代理，浏览器可能用的是自己那一套，两边结果对不上很正常——这种对不上本身就是线索。

第一处：请求还没出门，卡在建连

DNS 这一层最常见的不是解析错，而是慢。解析记录改过之后，浏览器有自己的缓存，操作系统有一层，中间还可能有递归服务商的一层，谁先更新谁后更新全看运气。用 nslookup 或 dig 在命令行查一次，再跟浏览器里的结果比一比，差得多就有问题。

更隐蔽的是 IPv6。域名同时挂着 A 记录和 AAAA 记录时，很多浏览器优先走 IPv6，那条路径不通就一直在等，等到超时阈值才退回来重试 IPv4。用户看到的就是什么都没干就超时了。临时把 AAAA 记录停掉，或者在本机把 IPv6 关掉试一次，能很快验证是不是这条原因。

TLS 握手也爱卡。系统时间偏差太大、证书链缺中间证书、公司网络里那台设备做了证书替换，握手都可能反复重试甚至失败。代理同理，装过的加速器、VPN 客户端卸不干净，系统代理设置还留着，请求先绕一圈才出门。这类毛病最气人的地方在于换台机器就好了，于是被当成偶发，一直查不出根。

第二处：请求到了，服务端攥着不放

TTFB 飙高，先看应用在等什么。常见三种：一是查询慢，某个列表页翻到后几页扫了整张大表；二是外部调用没设超时，页面加载时去拉第三方接口、发短信、请求支付网关，对面不回，本地进程就一直举着；三是并发顶住了，数据库连接池打满，或者队列里堆着任务没人消费。

还有一种专挑页面干的：会话锁。像 PHP 默认把 session 存在文件里，同一个 session 的请求要串行处理，页面上一口气发好几个 ajax，就互相干等，表现是打开页面卡死，其实服务器负载看着并不高。把 session 挪到 Redis，或者在请求里早点关掉写锁，都能缓解。

范围也能帮判断：所有页面都卡，锅更可能在链路或整站公共设施；只有某个页面卡，就往这个页面的逻辑上找；只有登录之后的页面卡，先怀疑会话和权限校验那一段。

浏览器和本地环境也别放过

装了一堆扩展的、被公司策略推了代理的、开着下载工具的，都可能拦请求。最快的排除法是开个无痕窗口，或者换一个从没装过插件的浏览器开一次。另外页面一打开就要拉一堆外部资源——字体、统计脚本、图片、客服悬浮窗，来自好几个不同域名，其中哪个卡住，整页就跟着一起等，看着像主站超时，多半是被它拖的。

先做这几步，别急着重启

顺序建议这么走：换网络开一次；无痕浏览器开一次；curl 拉一遍分段；翻服务端错误日志和慢查询日志；临时停掉 AAAA 记录再试；把应用里所有对外请求过一遍，看有没有超时设置。六步下来范围基本压得很窄，比重启服务、重装系统、换服务器省事得多。

改的时候一次只动一个变量

定位到之后，改动一次只做一处。改了记录就别同时动超时参数，不然下回复发你不知道是哪一步起的效。相对划算的改动是给所有对外调用补上超时和重试上限，把无限等改成等不到就报错放行——报一个错总比整页吊死强。链路那边，把不通的 AAAA 记录清掉、代理设置收拾干净，通常能解决大半。

页面超时这毛病最怕三方互相甩锅：用户觉得网站烂，运维觉得网络差，开发觉得服务器不行。真到现场，能拿得出时间线分段的那个人说话最算数。下次再碰上输入框都没出来就转圈，先看 TTFB 那一段占了多久，比换个新服务器有用。