本地AI助手原来直连接口时响应正常，改用代理（或第三方中转）后明显变慢，这不一定是模型变慢，更多时候是请求路径上多了 DNS 解析、TCP 握手、TLS 协商三个环节，以及代理服务本身的带宽和排队。可以先通过一次带耗时拆分的 HTTP 请求，确认时间是花在建立连接、等待响应，还是下载内容上，再决定调超时、缓存还是换回直连。
改用代理后响应变慢，建议先量化网络耗时再改配置：同一个接口分别用直连和代理做请求，对比 DNS、TCP 连接、TLS 握手和总耗时。超时设置要区分连接超时和读取超时，读取超时需要给模型生成留空间；不要仅靠提升超时掩盖网络问题。
先定位：慢在建立连接，还是慢在模型生成
本地AI助手调用接口时，请求通常经历“建立连接 → 发送请求 → 等待模型生成 → 接收内容”四个阶段。走代理后如果“打字机开始前要等很久”，通常出在前两段；如果“文字开始流式返回后中途停顿”，更可能是代理带宽、上游限流或网络丢包。先用 curl 把耗时拆开。
curl `--noproxy` "*" -o /dev/null -s -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n" https://api.example.com/v1/models
curl -x http://127.0.0.1:7890 -o /dev/null -s -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n" https://api.example.com/v1/models注意 time_namelookup 在走代理时只表示 curl 本机的解析耗时，不代表代理服务器上的解析情况；如果代理开了远程 DNS，还要结合代理日志判断。两组请求要连续多跑几次，如果某次总耗时突然很高，属于间歇性延迟，和固定超时设置关系不大。如果本机无法直连目标 API，省略直连命令，改为同一个代理在空闲和高峰时段的对比，也能看出是否与链路拥塞有关。
用同一请求对比直连与中转，别拿小请求猜全貌
/v1/models 这类接口只测网络路径，不测模型推理。要判断“响应变慢”是否与代理有关，需要让直连和中转走同一个聊天补全请求，并限定小输出长度，避免模型生成长文干扰网络对比。
curl `--noproxy` "*" -o /dev/null -s -w "首字节=%{time_starttransfer}s 总耗时=%{time_total}s\n" -H 'Content-Type: application/json' -H 'Authorization: Bearer '"$API_KEY" -d '{"model":"你的模型名","messages":[{"role":"user","content":"hi"}],"max_tokens":5,"stream":false}' https://api.example.com/v1/chat/completions
curl -x http://127.0.0.1:7890 -o /dev/null -s -w "首字节=%{time_starttransfer}s 总耗时=%{time_total}s\n" -H 'Content-Type: application/json' -H 'Authorization: Bearer '"$API_KEY" -d '{"model":"你的模型名","messages":[{"role":"user","content":"hi"}],"max_tokens":5,"stream":false}' https://api.example.com/v1/chat/completions对比时请保持模型名、请求体、上下文长度、max_tokens 一致，否则差异可能来自模型负载而不是代理。如果直连超时、走代理正常，要优先检查本地网络出口是否被干扰；如果直连正常、走代理变慢，重点看代理服务器的带宽和到目标 API 的路由。
超时设置：区分连接超时与读取超时
代理链路通常比直连多一跳 RTT，连接超时太短会让可用网络被误判为不可用。但读取超时不能照搬短连接标准：模型生成回答时，网络连接是空闲的，读取超时需要覆盖“模型生成时间 + 网络传输时间”，否则长回答会被客户端强制掐断。建议先给连接超时留出至少 10 秒，读取超时按你允许的最长回答时间放宽到 60-120 秒，再根据日志调整。这个范围需要结合你的实际网络环境确认，不要照搬。
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,10.0.0.0/8如果助手本身不读环境变量，而是在配置页填代理，去找对应的“连接超时”“读取超时”或“请求超时”字段。代码接 OpenAI SDK 时，可以这样理解结构：timeout 表示整体请求超时，max_retries 控制重试次数；具体参数名和默认值以你本机安装的 SDK 版本为准。
常见问题
为什么走代理后延迟高，但直连正常？
通常是链路多了中转节点，或代理软件开启了全局规则导致本不该走代理的请求也在排队。可以先检查 NO_PROXY，再用上文的 curl 对比 connect 和 total，确认慢在哪一段。若慢在 connect，是 TCP 握手路径问题；若慢在 total 且 connect 正常，可能是代理服务带宽不够或上游 API 对代理出口限速。
超时时间调大就能解决变慢吗？
只能减少“被客户端主动掐断”的假性失败，不能降低实际等待时间。如果网络链路本身丢包或代理排队，调大超时只是让用户转圈更久。正确顺序是先定位瓶颈，再调超时；超时是兜底，不是优化手段。