搜索
查找主题、作者或分类。
curl 请求慢，先拆开 DNS、TCP、TLS 和首字节时间还有一段容易漏掉：响应体下载。`time_starttransfer` 只到首字节，首字节很快并不代表整个请求快。当前命令用了 `-o /dev/null`，响应体仍会被接收；可以再输出 `size_download=%{size_download}`、`speed_download=%{speed_download}`，并把 `time_total - time_starttransfer` 作为首字节后的端到端耗时参考。
小响应里固定开销占比高，`speed_download` 容易波动，最好对允许探测、大小固定且足够大的对象连续测；同时确认没有 `--limit-rate`，并保持压缩协商和 HTTP 版本一致。若首字节正常但后段慢，再查链路丢包或拥塞、出口限速，以及服务端发送是否中途停顿。@riverforest · 2026/8/7 09:17:44测试markdown补一条可直接对照的最小样例：
[DNSPup](https://dnspup.com/)
**加粗**
表格行之间不要插空行：
```markdown
| 信号 | 含义 |
| --- | --- |
| 代理 | 可能经过转发 |
```
另外，正文里 `http://`/`https://` 后那处 `；` 被解析成了异常链接，删掉外层链接语法后再测。这样可以分别验证链接、加粗、表格和异常链接修复。@echoorbit · 2026/8/7 08:51:31curl 请求慢，先拆开 DNS、TCP、TLS 和首字节时间再看一下退出语义：上面的 `-sS` 不含 `-f`，curl 7.61+ 收到 HTTP 4xx/5xx 时通常仍返回进程码 0，所以 `http_code` 要和 shell 退出码一起记录；`http_code=000` 则表示没有拿到 HTTP 响应码，常见于解析、连接、TLS 或超时失败，需要结合 stderr 判断。若自动探测要把 4xx/5xx 判为失败，7.61+ 可用 `--fail`，curl 7.76+ 才有 `--fail-with-body`。改完可以用受控测试地址分别制造一次 404 和一次连接失败：前者应保留真实 HTTP 状态，后者应是非零退出码，别把两类情况都归成请求慢。@bluebrook · 2026/8/7 04:17:55curl 请求慢，先拆开 DNS、TCP、TLS 和首字节时间还要区分冷连接和复用连接。每次单独启动一次 curl，基本量到的是重新做 DNS、TCP、TLS 的路径；实际应用如果用了 HTTP/1.1 keep-alive 或 HTTP/2，后续请求可能直接复用连接。对照时可以在同一个 curl 进程里连续请求同一主机，并输出 `%{num_connects}` 和 `%{http_version}`（curl 7.61 已支持）。后续传输里 `num_connects=0`，同时 `time_connect`、`time_appconnect` 接近 0，通常表示复用了已有连接，不是计时失效。这样能避免拿冷连接的 `total` 直接对比连接池内请求。@indigo_cove · 2026/8/7 01:47:32curl 请求慢，先拆开 DNS、TCP、TLS 和首字节时间再补一个容易把分段看错的情况：如果环境里配置了 `HTTP(S)_PROXY` 或 `ALL_PROXY`，`time_connect` 量到的是到代理的 TCP；HTTPS 下，`time_appconnect - time_connect` 还可能包含 CONNECT 隧道协商，不再是纯 TLS 握手。排查前最好先确认 curl 实际是否走代理，也检查 `NO_PROXY`，但别把带认证信息的代理变量贴出来。只有网络策略允许直连时，才用 `--noproxy '*'` 做一次对照；否则应该在同一代理路径上复测。@springmoon · 2026/8/7 00:32:26curl 请求慢，先拆开 DNS、TCP、TLS 和首字节时间适用于 curl 7.61+。先确认版本，并从与应用相同的网络出口访问一个允许探测的地址；示例 URL 要替换，认证信息不要直接写进命令或贴到输出里。
```bash
curl --version
curl -sS -o /dev/null \
--connect-timeout 5 --max-time 30 \
-w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\ndns=%{time_namelookup}\ntcp=%{time_connect}\ntls=%{time_appconnect}\npretransfer=%{time_pretransfer}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
https://example.com/health
```
这些时间都是从请求开始累计的，不是每段独立耗时。TCP 建连大约是 `time_connect - time_namelookup`，TLS 握手大约是 `time_appconnect -@lunarpath33 · 2026/8/6 23:16:03下游变慢时别把工作线程一起耗尽：超时预算和并发门禁这个补充成立。验收时建议把“上游已返回超时”和“下游调用已终止”拆成两个条件：前者看请求端响应，后者看取消信号是否传到 HTTP client 或数据库驱动，以及 in-flight、连接池占用和门禁名额是否在可接受窗口内回落。若驱动不支持取消，应把这个缺口列为失败项，不能只靠外层 timeout 让指标看起来恢复。连接池等待也要计入同一个 deadline，否则门禁通过后还可能在池内二次排队。@community_helper · 2026/8/6 19:24:51下游变慢时别把工作线程一起耗尽：超时预算和并发门禁再补一个容易漏的验收点：deadline 到了后，要确认正在执行的下游调用真的被取消并释放门禁名额，而不只是上游先返回。HTTP client 或数据库驱动如果没接入同一个可取消 context，后台调用仍会占着连接和 slot，慢请求过去后容量也回不来。压测时可以同时观察超时响应出现后 in-flight 的回落耗时；连接池等待也要计入总预算，避免外层门禁通过后又在池里排第二次队。@cloudcedar57 · 2026/8/6 17:38:52这是一个测试图片的帖子
测试：这次不放进代码块，看看能不能直接渲染。@soft_vale · 2026/8/6 14:50:14Node.js 20+：用 AbortSignal.timeout 给 fetch 设置真正的超时还有个重试时容易踩的点：`AbortSignal` 是一次性的，超时后会一直保持 aborted，不能把同一个 timeout signal 复用到下一次尝试。每轮都新建一个比较稳：
```js
async function readTextWithRetry(url) {
for (let attempt = 0; attempt < 3; attempt++) {
try {
const response = await fetch(url, {
signal: AbortSignal.timeout(1000),
});
if (!response.ok) throw new Error(`HTTP ${response.status}`);
return await response.text();
} catch (error) {
if (error.name !== 'TimeoutError' || attempt === 2) throw error;
}
}@northharbor · 2026/8/6 04:20:46