Qwen Code 添加 Qwen3.7-Max 后为什么模型测试通过但连接总是超时？

Qwen Code 中“模型测试通过，但正式对话一直超时”通常说明测试按钮只验证了密钥、地址或短响应，并没有覆盖正式会话使用的协议路径、流式传输和长上下文。尤其是把 Qwen3.7-Max 配成 Anthropic 协议时，服务端必须真正兼容 Anthropic Messages API；仅能返回一个测试请求，不代表它能正确处理 Qwen Code 的流式工具调用。

为什么测试成功不等于正式连接成功

连接测试常见做法是发送一条很短的消息，或只请求模型列表、鉴权接口。这样的请求耗时短、请求体简单，也可能没有启用流式输出、工具定义、系统提示和历史消息。正式对话则会携带完整上下文，并由客户端按照选定的协议解析持续返回的数据。

因此，两者至少可能在请求路径、HTTP 方法、消息结构、请求头、模型名称、流式开关、工具字段和超时策略上不同。只要其中一项不一致，就会出现测试显示可用，而聊天窗口一直等待的情况。

先确认协议与基础地址匹配

Qwen Code 官方配置说明将 OpenAI 兼容、OpenAI Responses、Anthropic、Gemini 等作为不同的 provider 协议。OpenAI 类型由官方 OpenAI Node.js SDK 发送，Anthropic 类型由 Anthropic SDK 发送，所以配置的 baseUrl 必须与相应协议的请求格式兼容。

如果第三方服务只提供 OpenAI 兼容的 Chat Completions，就应选择 OpenAI provider，不能因为模型名称是 Qwen 就随意选择 Anthropic。反过来，只有服务明确提供 Anthropic Messages 兼容接口时，才能使用 Anthropic provider。

基础地址通常是 SDK 用来继续拼接资源路径的根地址。是否应包含 /v1，以及能否直接填到 /messages，取决于服务端文档和 SDK 的拼接行为。不要通过反复猜测路径解决问题：记录客户端实际发出的最终 URL，再与服务商给出的协议示例逐字比较。

检查有效配置，而不是只看编辑表单

模型管理界面保存成功后，还要确认当前会话实际选中了该 provider 条目。Qwen Code 的模型配置可能来自命令行、环境变量、用户设置和项目设置，不同层有覆盖优先级。相同模型 ID 也可能绑定不同基础地址。

核对时至少记录以下有效值：

• 当前认证类型和 provider 协议；
• 实际模型 ID，而不是界面显示名称；
• 最终基础地址和环境变量对应的密钥来源；
• 请求超时、流式空闲超时与最大重试次数；
• 是否启用代理，以及项目级设置是否覆盖用户设置。

不要在日志中打印完整 API Key。只保留密钥来源名称和末尾少量脱敏字符，足以判断是否选错凭据。

分别测试非流式和流式请求

最有效的对照是使用完全相同的模型、消息和协议，先发送非流式请求，再发送流式请求。非流式成功而流式超时，问题通常落在 SSE 响应、代理缓冲、心跳、空闲超时或客户端事件解析；两者都失败，则优先检查地址、鉴权、模型权限和请求格式。

流式输出（Server-Sent Events，SSE）要求连接在多个数据块之间保持打开。某些兼容服务会先长时间思考，再返回第一个文本块；某些反向代理会缓存数据，直到缓冲区填满才向客户端转发。这两种情况都可能触发客户端的流式空闲保护，即使服务端最终能够生成答案。

区分请求超时和流式空闲超时

Qwen Code 官方文档区分每次请求的总超时与流式数据块之间的空闲超时。请求超时限制整个调用持续时间；流式空闲超时只关心相邻数据块之间允许沉默多久。单纯把界面中的 30 秒改成 60 秒，若改的是错误配置层或只影响连接测试，正式会话仍会按旧值中止。

配置调整后必须重启相应进程或重新创建客户端，并通过调试日志确认生效值。临时增大超时可以帮助定位，但不应直接当成修复。若服务在合理时间内完全没有首包，应继续检查请求是否抵达服务端、代理是否缓冲以及模型是否支持当前协议。

用最小请求定位差异

1. 只发送一条短文本，不带历史消息、图片、工具和复杂系统提示。
2. 用服务商官方示例直接请求同一模型和地址，确认协议端点可用。
3. 让 Qwen Code 使用相同协议发送非流式请求，并保存状态码和响应体。
4. 开启流式输出，记录首包时间、每个事件的时间和连接关闭方。
5. 再逐项恢复系统提示、历史消息、工具定义和多模态输入。

每一步只增加一个变量。最先导致超时的变量，才是下一步应该调查的对象。若一次同时更换地址、协议、超时和模型，即使恢复成功，也无法知道真正原因。

需要记录哪些网络证据

客户端日志应包含脱敏后的最终请求 URL、协议类型、模型 ID、状态码、首字节耗时、最后一个数据块时间、异常类型和请求 ID。服务端返回 401 或 403 是鉴权问题，404 多半是路径不匹配，429 是配额或限流，5xx 指向服务端或上游异常；只有连接建立后长期无数据，才主要考虑流式空闲超时。

如果测试按钮吞掉了错误正文，只显示“连接成功”或一直等待，应让测试逻辑使用与正式会话相同的 transport，并设置明确的成功条件：收到有效状态码、解析出协议规定的响应结构，并在流式模式下至少完整读到一个结束事件。DNS 或 TCP 建连成功不能算模型可用。

一个可靠的配置思路

{
  "modelProviders": {
    "anthropic": [
      {
        "id": "实际服务支持的模型ID",
        "envKey": "ANTHROPIC_API_KEY",
        "baseUrl": "服务商声明的Anthropic兼容根地址",
        "generationConfig": {
          "timeout": 120000,
          "streamIdleTimeoutMs": 120000,
          "maxRetries": 1
        }
      }
    ]
  }
}

这只是字段结构示意，不能替代服务商的真实地址和模型标识。若目标服务提供的是 OpenAI 兼容协议，应把 provider 改成对应类型，并使用该服务声明的 OpenAI 兼容根地址与凭据变量。

生产环境还要避免重复副作用

连接超时后自动重试可能重复执行工具调用。写文件、发送消息、创建订单或修改数据库等操作必须带幂等键，并区分“客户端没有收到结果”和“服务端没有执行”。在无法确认上一请求状态时，不应无条件重放整段 Agent 会话。

最终判断标准是：测试请求和正式请求使用同一协议栈；实际 URL、模型与凭据均符合服务商说明；流式首包和结束事件能被完整解析；超时配置在当前 provider 上确实生效。做到这些后，若最小请求仍能稳定复现超时，才有足够证据把请求 ID、版本和脱敏日志提交给 Qwen Code 或模型服务方排查。