fiddler-traffic-debugging

Fiddler 功能验证

分析功能运行期间产生的流量，判断观察到的 HTTP 行为是否正常，并按端点分组汇总可能的问题。

操作规则

1. 此技能以 MCP 为优先。只要当前会话中有可用的 Fiddler Everywhere MCP 工具，就使用它们分析流量。
2. 如果 Fiddler MCP 工具可用，请勿使用 Shell 工具、rg、grep、工作区文件扫描或导出的会话转储来检查流量。
3. 如果已知要关注的进程，优先将 CaptureApplication 用作预捕获步骤——它会在操作系统层面限定捕获范围，从一开始就保持会话列表整洁。必要时使用 ApplyFilters，将大量或嘈杂的捕获内容缩小到与功能验证相关的流量。
4. 分析应注重实用性。目标是验证功能是否正常运行，而非进行详尽的数据包级审计。
5. 如果当前会话中没有 Fiddler MCP 工具，请停止操作，并告知用户先运行 fiddler-mcp-setup，然后重试。
6. 如果运行时已提供 Fiddler MCP 工具，切勿手动探测 /mcp 或使用 curl 发送原始 MCP 协议请求。
7. 只能使用主机在 tools/list 中公布的工具名称。切勿编造或假定会话中没有提供的工具名称。
8. 所有会话工具（GetSessionsCount、GetSessions、GetSessionDetails、ClearSessions、ApplyFilters）都需要 sessionsSource 参数——对于捕获的 HTTP/HTTPS 流量，始终传入 LiveTraffic；对于 LLM/AI Agent API 调用，始终传入 AgentCalls。切勿省略此参数。

会话来源

Fiddler 提供两种会话来源；调用每个会话工具时，始终传入正确的来源：

sessionsSource	使用场景
LiveTraffic	从浏览器、终端或经过检测的进程实时捕获的 HTTP/HTTPS 流量。功能验证的默认来源。
AgentCalls	LLM/AI Agent API 调用（例如 OpenAI、Anthropic、Azure OpenAI）。此处的会话还包含 isCached、LLM 模型名称以及最近一条用户提示词的预览。验证 AI Agent 行为或调查 LLM 调用模式时使用。

Agent API 调用也属于 HTTP 流量，会同时出现在两个来源中；AgentCalls 提供了包含丰富元数据的视图。

前提条件检查

1. 确认已安装 Fiddler Everywhere。
2. 确认 Fiddler Everywhere MCP 工具可用。

常用工具及其用法

GetStatus

首先使用此工具，确认 Fiddler 可连接且处于可用状态。

可用于确认：

• 用户是否已登录
• Fiddler 是否正在捕获流量
• 是否有浏览器或终端实例已连接
• HTTPS 检查的前提条件是否正常

CaptureApplication

只要知道哪个进程会产生你想要验证的流量，就应将此工具作为第一步。

这是目前最强大的降噪工具。它会将操作系统级别的捕获范围限定为一个或多个特定进程，因此 Live Traffic 检查器中只会显示这些进程的流量，消除同时运行的浏览器、IDE、系统服务和其他应用产生的背景噪声。

使用方法：

• 根据当前 IDE 或命令行上下文推断进程名称或 PID（例如，运行待测功能的进程）。
• 多个目标之间用空格分隔；包含多个单词的名称必须加引号（例如，"Google Chrome"）。
• 提供的列表会替换当前捕获筛选器。如果支持信息征询，Fiddler 也可能会询问是否与现有筛选器合并。
• 调用 CaptureApplication 后，在用户运行该功能之前，使用 ClearSessions 清除过期会话（传入 sessionsSource: LiveTraffic），确保捕获结果只包含相关运行产生的流量。

以下情况不适合使用 CaptureApplication：

• 进程名称或 PID 未知，且无法推断。
• 功能涉及多个进程，且无法确定这些进程的名称。
• 用户明确希望分析未经筛选的流量。

在这些情况下，请在调用 GetSessions 后改用 ApplyFilters。

GetSessionsCount

在深入分析之前，可用此工具快速进行合理性检查。

它有助于确认：

• 是否捕获到了任何流量
• 用户最近是否运行过该功能，足以进行分析

GetSessions

这是用于验证的主要工具。使用它获取捕获的会话列表，然后在内存中进一步筛选流量。

可用于：

• 找出最可能与该功能运行相关的请求
• 确定请求顺序
• 发现失败、重试、重定向、预检请求和耗时较长的调用
• 为最终摘要整理端点分组

缩小列表范围时，优先参考用户请求中的线索，例如：

• 主机名
• URL 路径或路径片段
• HTTP 方法
• 功能名称或关键词
• 大致时间范围，例如“刚才”或“点击 Save 之后”

如果会话列表规模适中，通常只需在内存中进一步筛选。如果捕获结果很大或噪声较多，请使用 ApplyFilters，按主机、端点类别、方法或相关失败模式缩小 Fiddler 的范围。

GetSessionDetails

使用 GetSessions 找到相关会话后，再调用此工具。

适合检查详情的会话：

• statusCode >= 400 的会话
• statusCode 为空或缺失的会话
• 某个端点耗时最长的会话
• 重要端点中具有代表性的成功请求
• 可能涉及 CORS 时的 OPTIONS 预检请求及其后的请求

利用详情检查：

• 请求标头和响应标头
• 请求正文和响应正文
• 重定向目标
• 内容长度和内容类型
• 身份验证标头、Cookie、验证消息和错误负载

对于 AgentCalls 会话，还应检查大模型、isCached 标记和最近一条用户提示词的预览，这些信息通常能揭示模型路由配置错误或意外的缓存命中。

速率限制：避免在短时间内连续调用 GetSessionDetails 超过 5 次。

ApplyFilters

需要让分析更快或更可靠时，请使用此工具进行筛选。

适用场景：

• 仅显示某个主机的流量
• 仅显示失败的请求
• 将界面聚焦于特定端点类别
• 隔离重试、身份验证失败或某种请求方法（例如 POST）

如需重置筛选器，请使用空筛选器集合调用 ApplyFilters。

ClearSessions

在进行有针对性的捕获之前，使用此工具移除过期会话。始终传入 sessionsSource。通常在调用 CaptureApplication 后、用户运行该功能前调用，以确保检查器中只包含相关会话集。

StartCaptureWithBrowser / StartCaptureWithTerminal

当被测功能需要全新且已配置代理的环境时，请使用这些工具：

• StartCaptureWithBrowser — 打开一个已预先配置 Fiddler 代理的 Chrome 实例。
• StartCaptureWithTerminal — 打开一个已设置 Fiddler 代理环境变量的终端。

当无法通过 CaptureApplication 为目标进程添加监控，或需要干净的浏览器会话以避免缓存的身份验证状态时，这些工具会很有用。

建议的工作流

此工作流有意保持灵活。请根据功能和捕获的流量量进行调整。

1. 了解功能范围。

   • 从用户的请求中提取任何有用线索：执行的操作、主机、路径片段、方法、目标进程或预期的端点。
   • 确定合适的 sessionsSource：对于标准 HTTP 功能，使用 LiveTraffic；验证 LLM 或 AI Agent 行为时，使用 AgentCalls。
   • 如果请求不够明确，请分析最近的流量，并说明结果是基于最近一次捕获得出的。

2. 限定捕获范围（强烈建议）。

   • 如果已知目标进程，或可以根据 IDE/CLI 上下文推断目标进程，请使用进程名称或 PID 调用 CaptureApplication。
   • 然后调用 ClearSessions（并设置 sessionsSource: LiveTraffic）以丢弃先前的噪声，让接下来的运行产生干净的捕获结果。
   • 如果用户尚未运行该功能，请让用户运行；如果已经运行，则继续分析。

3. 使用 GetSessions 获取会话列表。

   • 筛选出与功能范围匹配的会话。
   • 如果没有明确线索，请关注最近一批相关会话，而不是整个捕获历史。
   • 如果捕获结果仍然太嘈杂，请使用 ApplyFilters 进一步缩小范围。

4. 按端点对流量分组。

   • 按主机 + 规范化路径分组。
   • 分组时去除查询字符串。
   • 将数字 ID 和类似 UUID 的路径段视为路径变量，因此 /users/123 和 /users/456 应被视为同一端点类别。

5. 检查调用顺序。

   • 检查请求流是否符合该功能的预期。
   • 留意预期的后续调用，例如先创建再获取、先预检再发起实际请求、先上传再轮询状态，或先保存再刷新。
   • 如果缺少必要的后续调用，请将其指出为可能的问题；除非证据充分，否则不要断定问题已确定。

6. 检查有代表性的详情。

   • 获取失败调用、耗时较长的调用、状态混杂的端点，以及一两个关键成功端点的详情。
   • 对于 AgentCalls，还要检查模型名称、缓存命中情况和提示词预览。
   • 在说明功能是否正常时，使用响应正文和标头作为证据。

7. 判断功能是否正常运行。

   • 正常的功能运行通常会显示预期端点、大多数成功的状态码、合理的延迟，并且没有重复失败。
   • 如果流量不完整或含义不明确，请直接说明。

输出格式

不要输出原始 JSON。请使用通俗易懂的语言，按以下部分撰写验证报告。

Feature Verification

Overall verdict: [Feature appears healthy / Feature appears partially successful / Feature likely failed / Inconclusive]

Traffic window: [what part of the capture you analyzed]
Sessions source: [LiveTraffic / AgentCalls]
Capture scope: [CaptureApplication used: <process name/PID> / Unscoped — all traffic analyzed]

Endpoint summary:
- METHOD HOST /normalized/path
  Calls: [N]
  Statuses: [e.g. 200 x3, 401 x1]
  Timing: [avg X ms, max Y ms]
  What happened: [plain-language summary of what this endpoint appears to do]
  Evidence: [optional header/body/status detail when useful]

- METHOD HOST /another/path
  Calls: [N]
  Statuses: [...]
  Timing: [...]
  What happened: [...]

Possible issues:
- ⚠️ [Endpoint] [Issue name] — [what looks wrong and why it matters]
- ⚠️ [Endpoint] [Issue name] — [supporting evidence]

Conclusion:
- [Short answer on whether the feature appears to work properly]

输出要求

1. 按端点分组汇总，而不是按原始会话 ID 分组。
2. 列出每个端点组的状态码分布和耗时。
3. 始终说明使用了哪个 sessionsSource，以及是否使用 CaptureApplication 限定了捕获范围。
4. 如果没有明显问题，请明确写出：No obvious issues detected in the analyzed traffic.
5. 如果存在问题，请在每项问题前加上 ⚠️，明确指出问题，并说明其可能的表现。
6. 如果捕获结果含义不明确或不完整，请说明结论仅为暂定。