CLI 工具突然变慢了？别急着怀疑网络，按这四步排查

工具变慢了，本能反应是"网络问题"------重启代理、换节点、关 VPN。但当我真的按层排查下去之后，发现答案和最初的猜测完全不同。

把这次排查整理出来，给同样困惑的同行参考。方法论适用于任何"调用远程服务的 CLI / SDK 工具"------AI 编码助手、API 客户端、上传下载工具都通用。

第 0 步：先知道日志在哪里

很多人卡在"工具变慢"这一步，不是因为不会排查，而是根本不知道这些工具有日志。整理几个常见场景：

VSCode / Cursor 扩展 ：Cmd+Shift+P → 输入 Output → 在 Output 面板右上角的下拉里选具体扩展（比如对应的 AI 编码扩展、GitHub Copilot、ESLint）
JetBrains 系列 ：Help → Show Log in Finder/Explorer，里面有 idea.log
独立 CLI 工具 ：试 --verbose / -v / --debug，或环境变量 DEBUG=1 / <TOOL>_LOG=debug
浏览器扩展 ：chrome://extensions → 找到目标扩展 → 详情 → 「检查视图：背景页」/「Service Worker」

判断日志够不够用的标准：有没有精确到毫秒的时间戳 + 关键事件名。如果只是一行行文本输出没有时间，没法做时序分析，需要换更详细的日志级别。

这一步看似废话，但实际上是后面所有诊断的基石------没有时间戳，"慢"就是个模糊感受，没法量化。

第一步：读日志，看时间戳

打开日志之后，找几个关键事件的时间戳，拆出区间。比如：

makefile 复制代码

23:02:13.987  API REQUEST started
23:02:14.788  Auth check complete
23:02:28.552  Stream started - received first chunk

从这三行能立刻拆出两个区间：

13.987 → 14.788 = 0.8s --- 认证 / 握手开销
14.788 → 28.552 = 13.8s --- 等待服务端首字节（TTFB）

这一步是分流的关键：13.8s 这个数字本身不会告诉你瓶颈在哪，但它把"慢"这个模糊感受变成了具体的可分析数字。下一步要做的是搞清楚------这 13.8s 是网络传输慢，还是服务端处理慢。

第二步：用 curl 隔离网络层

光看 SDK 日志没法判断瓶颈，因为里面混着网络 + 服务端处理两层。要分开，最简单的办法是绕过 SDK，直接用 curl 打同一个 endpoint：

bash 复制代码

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://api.example.com

time_starttransfer 就是从连接发起到收到第一个字节的时间------纯网络 + 服务端最简响应。如果这个值是 0.5s 左右，而你的 SDK 报 13.8s，那 13s 一定不是网络层的事。

更进一步，如果你正在使用本地代理（HTTP 代理或 SOCKS 代理），可以对比两次：

bash 复制代码

# 走代理
curl -x http://127.0.0.1:7890 -o /dev/null -s \
  -w "TTFB: %{time_starttransfer}s\n" https://api.example.com

# 直连
curl --noproxy '*' -o /dev/null -s \
  -w "TTFB: %{time_starttransfer}s\n" https://api.example.com

两个数字差不多 → 代理没拖慢。差异很大 → 代理是一部分原因。

我自己的案例里：两次都是 ~0.5s。也就是说，代理完全不是瓶颈，13.8s 是服务端处理 + 流式生成的时间。

第三步：理解本地代理工具的工作模式

如果第二步发现代理确实拖慢了，那就要进一步分清楚------是代理本身的链路慢，还是代理工具的"工作模式"引入了额外开销。

macOS / Linux 上的本地代理工具通常有两种工作模式：

系统代理（HTTP Proxy） ：通过修改系统的 HTTP/HTTPS 代理配置（macOS 上是 networksetup 命令），让进程在发请求时主动走代理端口。优点是开销小、可被进程感知；缺点是某些不读系统代理配置的进程会绕过它。
TUN 模式（虚拟网卡）：建一块虚拟网卡，把所有流量在 IP 层劫持过去再判断是否转发。优点是真"全局"，连不读代理配置的程序也能接管；缺点是多一层封包/解包，对长连接、流式响应（SSE、WebSocket）可能引入额外延迟。

如果你在 TUN 模式下感觉特定流式工具慢，可以切回系统代理对比一下。

macOS 上的一个坑 ：切换系统代理需要管理员权限（networksetup 命令要 sudo）。如果你的代理工具的 helper 没正确安装或没获得授权，UI 上点开关会失败但不报错，肉眼看不出来。验证方法：

bash 复制代码

networksetup -getwebproxy "Wi-Fi"

如果 UI 显示开了、命令显示 Enabled: No，那就是 helper 提权机制坏了，不是网络问题。

第四步：排除网络之后，看应用层

走完前三步如果发现网络层没问题，那慢就来自应用层本身。对于调用远程 AI 类服务的工具，应用层的主要时间消耗是：

模型推理首 token 时间 --- 上下文越长、模型越大、生成越精细，首 token 越慢。一个塞满了上下文的对话，10-20s 首 token 完全正常。
工具调用 / RAG 检索 --- 在生成前先做一轮检索或工具调用，会叠加延迟。
服务端排队 --- 高负载时段或限流策略下，请求可能在队列里等待。

这一层基本是用户侧无法优化的------你能做的是：

控制上下文长度（开新会话、清缓存）
选择更轻量的模型（如果工具允许切换）
错峰使用（避开高峰）

一个反直觉的总结

工具变慢的时候，本能反应是"网络问题"。但真按层排查下来，很多时候慢不在网络，而在应用层本身。

找到日志面板 → 拿到原始数据
看日志时间戳 → 量化问题
curl 隔离 → 分清网络 vs 应用层
切换代理模式 → 分清代理工具 vs 代理链路
排除以上之后 → 才该怀疑模型 / 服务端

排查顺序错了，会浪费几小时调代理配置，最后发现问题压根不在代理上。

速查表

现象	第一反应	真正该做的
工具响应变慢	重启代理	先找到日志面板
看不到日志	当成黑盒放弃	试 Output / `--verbose` / `DEBUG=1`
TTFB 高	怀疑网络	curl 打同一 endpoint 做基线
curl 也慢	换代理节点	对比走代理 vs 直连
都没差	没招了	应用层因素：模型、上下文、负载

这套思路对任何"调用远程服务的 CLI"都通用。下次某个工具变慢，先冷静量化，再决定动哪里。