CC Switch 模型检查功能3 个参数调好30 秒确认供应商可用【免费下载链接】cc-switchA cross-platform desktop All-in-One assistant for Claude Code, Codex, OpenCode, OpenClaw, Grok Build Hermes Agent. Only official website: ccswitch.io项目地址: https://gitcode.com/GitHub_Trending/cc/cc-switchCC Switch 的模型检查Stream Check功能通过发送一次真实的轻量 API 请求验证你配置的供应商是否真的能用——模型是否存在、API Key 是否有效、端点响应多快。改完配置点一下「测试」就能在 30 秒内分清是我配错了还是供应商挂了不用等到写代码时被报错打脸。跑通基础流程在主界面找到目标供应商卡片点击卡片上的「测试」按钮。等待几秒弹窗显示结果 健康 / 降级 / 不可用附带响应延迟和 TTFBTime To First Byte流式响应中首个字节返回的耗时。如果显示 看错误信息里是 DNS/连接/TLS 问题指向 base_url 或网络还是鉴权问题指向 API Key。想改测试参数时进入 设置 → 高级 → 模型测试调整超时、重试、阈值后保存。保存后对同一个供应商再点一次「测试」状态变成 就算配通了。图 1主界面的供应商列表每张卡片上的「测试」按钮就是模型检查的入口逐项拆解四个关键参数超时时间秒它控制什么单次测试请求最多等多久才判超时。就像给快递设最晚签收时间设太短正常件也判丢。默认值8 秒可设 2–60 秒。什么时候该改供应商正常但偶发被判 而手动 curl 能通时多半是超时下限卡得太紧反过来如果你只想快速摸底、不愿等也可以调短。改成多少合适默认 8 秒覆盖了绝大多数端点的首字节响应跨洋专线或高负载端点可放到 15–30 秒没必要往 60 秒顶——等半分钟才得知故障巡检效率太低。最大重试次数它控制什么请求失败后自动重发几次用来区分网络抖了一下和服务真挂了。默认值1 次可设 0–5 次。什么时候该改公司网络、代理链路不稳定测试经常随机失败。改成多少合适3 次是上限内的甜点——偶发抖动能被重试吸收又不会让一次真正的故障拖成1 次 3 次重试 × 8 秒超时的漫长等待。0 次适合你只想快速探活、不在乎误报的场景。较慢阈值毫秒它控制什么响应正常但超过这个耗时供应商被标为 降级而非 健康。默认值6000ms可设 1000–30000ms。什么时候该改你发现某个正常供应商总是 但实际使用没感觉慢或者故障转移自动切换供应商太敏感把还能用的供应商切掉了。改成多少合适日常巡检场景保持 6000ms对延迟敏感的交互场景收紧到 3000ms端点物理距离远、天然慢的放到 10000ms 以上避免天天看到假降级。测试模型它控制什么测试请求实际发往哪个模型直接决定每次检查的 token 花费和响应速度。默认值各应用默认使用其系统默认模型设置 → 高级 → 模型测试中按应用单独配置。什么时候该改默认模型较贵或供应商根本不支持该模型会直接报模型不存在误判为不可用。改成多少合适优先选各家最便宜快速的系列——Claude 用 Haiku、Codex 用 mini、Gemini 用 Flash。测试模型不需要和生产模型一致但建议同系列否则延迟数据没有参考意义。场景推荐组合理由日常健康检查8s 超时 / 1 次重试 / 6000ms 阈值 / Haiku 类模型快速、省钱能区分好坏即可网络环境不稳15–30s 超时 / 3 次重试 / 6000ms 阈值吸收抖动减少假 故障转移敏感8s 超时 / 1 次重试 / 10000ms 阈值避免把慢但能用的供应商切走图 2高级设置区域检查参数超时、重试、较慢阈值都在这里调整场景配置速查场景一新供应商接入验证推荐组合默认 8s 超时 1 次重试 6000ms 阈值 供应商最便宜的模型。 理由新供应商的重点是通不通默认参数 30 秒内给出结论失败后先按报错信息判断是 base_url 写错还是 Key 无效再谈调参。场景二日常巡检配合故障转移推荐组合8s 超时 1 次重试 6000ms 阈值保持默认不动。 理由开启代理后系统会定期对故障转移队列里的供应商做健康检查不健康的会被暂时跳过——巡检参数追求的就是快、准、便宜默认值就是为这个目的调的。场景三线上故障定位推荐组合临时把超时调到 30s、重试调到 3对怀疑的供应商逐个测试拿到 TTFB 和具体错误码后再提交给供应商。 理由故障时你需要的是排除法证据——同一时间我这边 30 秒都等不到首字节比我这边连不上更有说服力。定位完记得改回默认不然平时巡检会被拖慢。排障四象限1. 测试显示 不可用但实际使用正常现象点测试报错手动 curl 或直接调用却没事。可能原因配置的测试模型供应商不支持返回模型不存在base_url 格式有误如多写了/v1或漏写超时设置过短慢端点被误判排查动作看错误弹窗里是鉴权错误还是模型错误把测试模型换成供应商文档里明确列出的模型用 curl 请求同一端点对比返回解决 / 规避测试模型改成供应商支持的最低配模型base_url 与官方文档逐字核对。2. 状态在 和 之间反复横跳现象同一供应商多次测试结果不稳定。可能原因网络链路本身抖动供应商服务器负载波动阈值恰好卡在响应耗时的平均值附近排查动作连续测 3–5 次记录每次的延迟数值对比测试时段的网络状况开不开代理、是否高峰期把较慢阈值从 6000ms 上调到 10000ms 再测一轮解决 / 规避阈值放宽到实测延迟的 2 倍以上 就只会出现在真正异常的时候。3. 所有供应商同时测试失败现象批量点测试无一幸免全是 。可能原因本地网络或代理断了大概率不是供应商集体阵亡系统代理配置错误CC Switch 进程异常排查动作浏览器随便打开一个网页确认网络检查系统代理是否指向了已停用的端口重启 CC Switch 后再测解决 / 规避全挂先查本地网络与代理单挂才去查供应商。4. 连通正常但怀疑鉴权其实不对现象状态显示可达/正常你却不放心 API Key 是否真有效。可能原因部分探测只验证地址可达不验证鉴权收到任意响应即视为可达测试模型配置与真实请求用的模型不一致排查动作确认走的是模型检查发送真实模型请求而非纯连通探测看结果里是否有真实的首字节时间和 token 输出必要时直接 curl 带上 Key 请求一次解决 / 规避把测试模型固定为常用模型 且带延迟数值才说明 Key、模型、端点三者都通了。图 3路由接管配置界面模型检查结果会直接服务于这里的故障转移决策进阶小贴士省 token测试请求虽然已限制最大输出通常 10–50 个 token但次数多了仍会累计。巡检场景用 Haiku/mini/Flash 级别的模型单次成本基本可以忽略避免用 Opus 这类高价模型做日常检查。省时间把「测试」按钮的使用时机固定在两个节点——改完任何供应商配置之后、怀疑故障转移切错供应商的时候。日常不需要主动刷测试代理开启后的定期健康检查会自动覆盖巡检需求。模型检查的价值在于把供应商到底能不能用从玄学问题变成 30 秒内的三选一答案配合故障转移它就是你多供应商架构里最便宜的那道保险。完整参数说明与边界情况含 Codex 第三方供应商的端点探测细节见项目文档 docs/user-manual/zh/4-proxy/4.5-model-test.md。【免费下载链接】cc-switchA cross-platform desktop All-in-One assistant for Claude Code, Codex, OpenCode, OpenClaw, Grok Build Hermes Agent. Only official website: ccswitch.io项目地址: https://gitcode.com/GitHub_Trending/cc/cc-switch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CC Switch 模型检查功能：3 个参数调好，30 秒确认供应商可用
CC Switch 模型检查功能3 个参数调好30 秒确认供应商可用【免费下载链接】cc-switchA cross-platform desktop All-in-One assistant for Claude Code, Codex, OpenCode, OpenClaw, Grok Build Hermes Agent. Only official website: ccswitch.io项目地址: https://gitcode.com/GitHub_Trending/cc/cc-switchCC Switch 的模型检查Stream Check功能通过发送一次真实的轻量 API 请求验证你配置的供应商是否真的能用——模型是否存在、API Key 是否有效、端点响应多快。改完配置点一下「测试」就能在 30 秒内分清是我配错了还是供应商挂了不用等到写代码时被报错打脸。跑通基础流程在主界面找到目标供应商卡片点击卡片上的「测试」按钮。等待几秒弹窗显示结果 健康 / 降级 / 不可用附带响应延迟和 TTFBTime To First Byte流式响应中首个字节返回的耗时。如果显示 看错误信息里是 DNS/连接/TLS 问题指向 base_url 或网络还是鉴权问题指向 API Key。想改测试参数时进入 设置 → 高级 → 模型测试调整超时、重试、阈值后保存。保存后对同一个供应商再点一次「测试」状态变成 就算配通了。图 1主界面的供应商列表每张卡片上的「测试」按钮就是模型检查的入口逐项拆解四个关键参数超时时间秒它控制什么单次测试请求最多等多久才判超时。就像给快递设最晚签收时间设太短正常件也判丢。默认值8 秒可设 2–60 秒。什么时候该改供应商正常但偶发被判 而手动 curl 能通时多半是超时下限卡得太紧反过来如果你只想快速摸底、不愿等也可以调短。改成多少合适默认 8 秒覆盖了绝大多数端点的首字节响应跨洋专线或高负载端点可放到 15–30 秒没必要往 60 秒顶——等半分钟才得知故障巡检效率太低。最大重试次数它控制什么请求失败后自动重发几次用来区分网络抖了一下和服务真挂了。默认值1 次可设 0–5 次。什么时候该改公司网络、代理链路不稳定测试经常随机失败。改成多少合适3 次是上限内的甜点——偶发抖动能被重试吸收又不会让一次真正的故障拖成1 次 3 次重试 × 8 秒超时的漫长等待。0 次适合你只想快速探活、不在乎误报的场景。较慢阈值毫秒它控制什么响应正常但超过这个耗时供应商被标为 降级而非 健康。默认值6000ms可设 1000–30000ms。什么时候该改你发现某个正常供应商总是 但实际使用没感觉慢或者故障转移自动切换供应商太敏感把还能用的供应商切掉了。改成多少合适日常巡检场景保持 6000ms对延迟敏感的交互场景收紧到 3000ms端点物理距离远、天然慢的放到 10000ms 以上避免天天看到假降级。测试模型它控制什么测试请求实际发往哪个模型直接决定每次检查的 token 花费和响应速度。默认值各应用默认使用其系统默认模型设置 → 高级 → 模型测试中按应用单独配置。什么时候该改默认模型较贵或供应商根本不支持该模型会直接报模型不存在误判为不可用。改成多少合适优先选各家最便宜快速的系列——Claude 用 Haiku、Codex 用 mini、Gemini 用 Flash。测试模型不需要和生产模型一致但建议同系列否则延迟数据没有参考意义。场景推荐组合理由日常健康检查8s 超时 / 1 次重试 / 6000ms 阈值 / Haiku 类模型快速、省钱能区分好坏即可网络环境不稳15–30s 超时 / 3 次重试 / 6000ms 阈值吸收抖动减少假 故障转移敏感8s 超时 / 1 次重试 / 10000ms 阈值避免把慢但能用的供应商切走图 2高级设置区域检查参数超时、重试、较慢阈值都在这里调整场景配置速查场景一新供应商接入验证推荐组合默认 8s 超时 1 次重试 6000ms 阈值 供应商最便宜的模型。 理由新供应商的重点是通不通默认参数 30 秒内给出结论失败后先按报错信息判断是 base_url 写错还是 Key 无效再谈调参。场景二日常巡检配合故障转移推荐组合8s 超时 1 次重试 6000ms 阈值保持默认不动。 理由开启代理后系统会定期对故障转移队列里的供应商做健康检查不健康的会被暂时跳过——巡检参数追求的就是快、准、便宜默认值就是为这个目的调的。场景三线上故障定位推荐组合临时把超时调到 30s、重试调到 3对怀疑的供应商逐个测试拿到 TTFB 和具体错误码后再提交给供应商。 理由故障时你需要的是排除法证据——同一时间我这边 30 秒都等不到首字节比我这边连不上更有说服力。定位完记得改回默认不然平时巡检会被拖慢。排障四象限1. 测试显示 不可用但实际使用正常现象点测试报错手动 curl 或直接调用却没事。可能原因配置的测试模型供应商不支持返回模型不存在base_url 格式有误如多写了/v1或漏写超时设置过短慢端点被误判排查动作看错误弹窗里是鉴权错误还是模型错误把测试模型换成供应商文档里明确列出的模型用 curl 请求同一端点对比返回解决 / 规避测试模型改成供应商支持的最低配模型base_url 与官方文档逐字核对。2. 状态在 和 之间反复横跳现象同一供应商多次测试结果不稳定。可能原因网络链路本身抖动供应商服务器负载波动阈值恰好卡在响应耗时的平均值附近排查动作连续测 3–5 次记录每次的延迟数值对比测试时段的网络状况开不开代理、是否高峰期把较慢阈值从 6000ms 上调到 10000ms 再测一轮解决 / 规避阈值放宽到实测延迟的 2 倍以上 就只会出现在真正异常的时候。3. 所有供应商同时测试失败现象批量点测试无一幸免全是 。可能原因本地网络或代理断了大概率不是供应商集体阵亡系统代理配置错误CC Switch 进程异常排查动作浏览器随便打开一个网页确认网络检查系统代理是否指向了已停用的端口重启 CC Switch 后再测解决 / 规避全挂先查本地网络与代理单挂才去查供应商。4. 连通正常但怀疑鉴权其实不对现象状态显示可达/正常你却不放心 API Key 是否真有效。可能原因部分探测只验证地址可达不验证鉴权收到任意响应即视为可达测试模型配置与真实请求用的模型不一致排查动作确认走的是模型检查发送真实模型请求而非纯连通探测看结果里是否有真实的首字节时间和 token 输出必要时直接 curl 带上 Key 请求一次解决 / 规避把测试模型固定为常用模型 且带延迟数值才说明 Key、模型、端点三者都通了。图 3路由接管配置界面模型检查结果会直接服务于这里的故障转移决策进阶小贴士省 token测试请求虽然已限制最大输出通常 10–50 个 token但次数多了仍会累计。巡检场景用 Haiku/mini/Flash 级别的模型单次成本基本可以忽略避免用 Opus 这类高价模型做日常检查。省时间把「测试」按钮的使用时机固定在两个节点——改完任何供应商配置之后、怀疑故障转移切错供应商的时候。日常不需要主动刷测试代理开启后的定期健康检查会自动覆盖巡检需求。模型检查的价值在于把供应商到底能不能用从玄学问题变成 30 秒内的三选一答案配合故障转移它就是你多供应商架构里最便宜的那道保险。完整参数说明与边界情况含 Codex 第三方供应商的端点探测细节见项目文档 docs/user-manual/zh/4-proxy/4.5-model-test.md。【免费下载链接】cc-switchA cross-platform desktop All-in-One assistant for Claude Code, Codex, OpenCode, OpenClaw, Grok Build Hermes Agent. Only official website: ccswitch.io项目地址: https://gitcode.com/GitHub_Trending/cc/cc-switch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考