Claude Code Router 请求超时怎么排查定位耗时发生在哪一段【免费下载链接】claude-code-routerOne local control plane for every AI agent: route across models, fuse new capabilities, orchestrate tools, and stay fully in control.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-router用 Claude Code RouterCCR代理模型请求时任务变慢或直接超时第一个要回答的问题是耗时花在了哪一段。CCR 文档的排查入口是先看请求日志里的耗时和错误信息判断超时发生在哪一段。超时的主因有三类——上游服务延迟、Fusion 工具执行耗时、timeout 设置过短三者的处理方式不同。下面按“开启日志 → 复现超时 → 在日志里定位段 → 调整对应 timeout”的顺序给出文档中的做法。先开启请求日志与观测排查超时依赖两个开关到设置 → 日志与观测打开请求日志记录当天经过 CCR 的模型请求明细。打开Agent 观测让观测面板展示 Agent 的执行链路。两个面板都只记录开关打开之后的新数据所以开启后要重新触发一次超时的任务否则这次失败在日志里看不到。各开关和面板能力的完整说明见 日志与可观测性配置参考。在请求日志里找到这条请求看耗时字段请求日志每条记录包含请求时间、请求 ID、客户端、路径、请求模型、最终命中的供应商和模型resolved provider、resolved model、凭据、状态码、是否成功、耗时、token、成本估算、请求体、响应体和错误信息。日志页支持按状态、供应商、模型、凭据、请求 ID、模型名、请求体或响应体筛选。超时通常表现为失败状态可以先按状态或模型名缩小范围再打开单条记录重点看三处耗时这条请求实际花了多久状态码与错误信息失败在什么环节、是什么错误resolved provider/resolved model请求最终被路由到了哪个供应商服务。默认情况下请求体和响应体是全部记录的requestLogBodyCapture默认all一般不需要为此调整采样或捕获设置。两个边界需要注意如果请求日志里根本查不到这条请求先确认请求确实走了 CCR。常见问题要求的检查顺序是CCR 服务是否正在运行、Agent 是否从 CCR 启动而不是直接打开、配置是否已应用且作用范围覆盖当前项目。普通请求日志只保留本地当天的数据进入第二天后下一次读取或写入时会自动清理前一天的日志。超时排查要趁当天做它不适合作为长期审计归档。判断耗时集中在哪一段文档把超时原因归纳为三类对照日志中的现象归类日志中的现象对应原因下一步单条模型请求耗时长或出现失败状态上游服务延迟结合resolved provider与错误信息确认卡在哪个供应商服务耗时集中在工具调用步骤Fusion / ToolHub 工具执行耗时检查并调大对应的 timeout同样的请求稳定超时上游响应正常timeout 设置过短调整对应超时项Agent 观测面板为“工具调用耗时”这类情况提供另一个视角它展示每个步骤何时发生、调用了哪个工具、工具获得了什么结果、耗时多久、是否出错以及后续步骤如何继续适合定位某一步耗时过长或工具结果异常的问题。请求日志提供单条模型请求的请求体、响应体和错误信息两者配合使用。耗时集中在工具调用时调整 timeout文档给出的结论是如果耗时集中在工具调用调大对应的 timeout。按工具所在链路调整位置不同。ToolHub 链路在设置 → ToolHub中超时毫秒是 ToolHub 解析和调用的基础超时范围8000到300000默认60000。如果后端 MCP server 需要更长的 request timeoutCCR 会按后端超时自动抬高实际调用超时远程服务启动慢或请求耗时长时单独调高该 server 的Startup timeout或Request timeout。ToolHub 文档的排查条目与之一致遇到调用超时分别检查 ToolHub 的超时毫秒和单个 MCP server 的 request/startup timeout。Fusion 链路Fusion 工具循环不设置轮次上限或工具调用次数上限但请求超时和客户端取消仍然生效。常见问题在 Fusion 相关检查项中也把“timeout 是否设置得太短”列为其中一项。注意媒体工具图片生成、视频生成的保留期、并发和超时属于 CCR 的内部安全策略不在 Fusion UI 中要求用户配置这些值无法在界面上手动调大。验证调整结果调大 timeout 后重新触发同一个任务在请求日志中再找这条记录对比调整前后的记录看该条请求的状态是否从超时失败变为正常返回并查看耗时字段是否随之变化。如果状态恢复说明原超时设置过短的问题已解除如果耗时仍集中在同一步骤或错误信息依旧说明瓶颈在对应段的服务侧上游供应商或 MCP server 本身回到上一节的归类继续检查该段的服务状态与自身超时配置。相关文档常见问题日志与可观测性配置参考开启日志与观测ToolHub 配置【免费下载链接】claude-code-routerOne local control plane for every AI agent: route across models, fuse new capabilities, orchestrate tools, and stay fully in control.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-router创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Claude Code Router 请求超时怎么排查：定位耗时发生在哪一段
Claude Code Router 请求超时怎么排查定位耗时发生在哪一段【免费下载链接】claude-code-routerOne local control plane for every AI agent: route across models, fuse new capabilities, orchestrate tools, and stay fully in control.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-router用 Claude Code RouterCCR代理模型请求时任务变慢或直接超时第一个要回答的问题是耗时花在了哪一段。CCR 文档的排查入口是先看请求日志里的耗时和错误信息判断超时发生在哪一段。超时的主因有三类——上游服务延迟、Fusion 工具执行耗时、timeout 设置过短三者的处理方式不同。下面按“开启日志 → 复现超时 → 在日志里定位段 → 调整对应 timeout”的顺序给出文档中的做法。先开启请求日志与观测排查超时依赖两个开关到设置 → 日志与观测打开请求日志记录当天经过 CCR 的模型请求明细。打开Agent 观测让观测面板展示 Agent 的执行链路。两个面板都只记录开关打开之后的新数据所以开启后要重新触发一次超时的任务否则这次失败在日志里看不到。各开关和面板能力的完整说明见 日志与可观测性配置参考。在请求日志里找到这条请求看耗时字段请求日志每条记录包含请求时间、请求 ID、客户端、路径、请求模型、最终命中的供应商和模型resolved provider、resolved model、凭据、状态码、是否成功、耗时、token、成本估算、请求体、响应体和错误信息。日志页支持按状态、供应商、模型、凭据、请求 ID、模型名、请求体或响应体筛选。超时通常表现为失败状态可以先按状态或模型名缩小范围再打开单条记录重点看三处耗时这条请求实际花了多久状态码与错误信息失败在什么环节、是什么错误resolved provider/resolved model请求最终被路由到了哪个供应商服务。默认情况下请求体和响应体是全部记录的requestLogBodyCapture默认all一般不需要为此调整采样或捕获设置。两个边界需要注意如果请求日志里根本查不到这条请求先确认请求确实走了 CCR。常见问题要求的检查顺序是CCR 服务是否正在运行、Agent 是否从 CCR 启动而不是直接打开、配置是否已应用且作用范围覆盖当前项目。普通请求日志只保留本地当天的数据进入第二天后下一次读取或写入时会自动清理前一天的日志。超时排查要趁当天做它不适合作为长期审计归档。判断耗时集中在哪一段文档把超时原因归纳为三类对照日志中的现象归类日志中的现象对应原因下一步单条模型请求耗时长或出现失败状态上游服务延迟结合resolved provider与错误信息确认卡在哪个供应商服务耗时集中在工具调用步骤Fusion / ToolHub 工具执行耗时检查并调大对应的 timeout同样的请求稳定超时上游响应正常timeout 设置过短调整对应超时项Agent 观测面板为“工具调用耗时”这类情况提供另一个视角它展示每个步骤何时发生、调用了哪个工具、工具获得了什么结果、耗时多久、是否出错以及后续步骤如何继续适合定位某一步耗时过长或工具结果异常的问题。请求日志提供单条模型请求的请求体、响应体和错误信息两者配合使用。耗时集中在工具调用时调整 timeout文档给出的结论是如果耗时集中在工具调用调大对应的 timeout。按工具所在链路调整位置不同。ToolHub 链路在设置 → ToolHub中超时毫秒是 ToolHub 解析和调用的基础超时范围8000到300000默认60000。如果后端 MCP server 需要更长的 request timeoutCCR 会按后端超时自动抬高实际调用超时远程服务启动慢或请求耗时长时单独调高该 server 的Startup timeout或Request timeout。ToolHub 文档的排查条目与之一致遇到调用超时分别检查 ToolHub 的超时毫秒和单个 MCP server 的 request/startup timeout。Fusion 链路Fusion 工具循环不设置轮次上限或工具调用次数上限但请求超时和客户端取消仍然生效。常见问题在 Fusion 相关检查项中也把“timeout 是否设置得太短”列为其中一项。注意媒体工具图片生成、视频生成的保留期、并发和超时属于 CCR 的内部安全策略不在 Fusion UI 中要求用户配置这些值无法在界面上手动调大。验证调整结果调大 timeout 后重新触发同一个任务在请求日志中再找这条记录对比调整前后的记录看该条请求的状态是否从超时失败变为正常返回并查看耗时字段是否随之变化。如果状态恢复说明原超时设置过短的问题已解除如果耗时仍集中在同一步骤或错误信息依旧说明瓶颈在对应段的服务侧上游供应商或 MCP server 本身回到上一节的归类继续检查该段的服务状态与自身超时配置。相关文档常见问题日志与可观测性配置参考开启日志与观测ToolHub 配置【免费下载链接】claude-code-routerOne local control plane for every AI agent: route across models, fuse new capabilities, orchestrate tools, and stay fully in control.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-router创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考