fiddler-traffic-debugging

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fiddler Feature Verification

Fiddler功能验证

Analyze the traffic generated by a feature run, decide whether the observed HTTP behavior looks correct, and produce a grouped-by-endpoint summary with likely issues.

分析功能运行时生成的流量，判断观察到的HTTP行为是否正常，并生成按端点分组的汇总报告，标注可能存在的问题。

Operating rules

操作规则

This skill is MCP-first. Use Fiddler Everywhere MCP tools for traffic analysis whenever they are available in the current session.
Do not use shell tools,
```
rg
```
,
```
grep
```
, workspace file scans, or exported session dumps to inspect traffic if the Fiddler MCP tools are available.
Use
```
ApplyFilters
```
whenever it helps narrow a large or noisy capture to the traffic that matters for the feature verification.
Keep the analysis practical. The goal is to verify whether the feature appears to work, not to produce an exhaustive packet-level audit.
If the Fiddler MCP tools are not available in the current session, stop and tell the user to run
```
fiddler-mcp-setup
```
first, then retry.
Never manually probe
```
/mcp
```
or send raw MCP protocol requests with
```
curl
```
when the runtime already exposes Fiddler MCP tools.
Use only tool names that the host advertises in
```
tools/list
```
. Never invent or assume tool names beyond the ones available in the session.

优先使用MCP工具。只要当前会话中提供了Fiddler Everywhere MCP工具，就使用它们进行流量分析。
如果Fiddler MCP工具可用，请勿使用shell工具、
```
rg
```
、
```
grep
```
、工作区文件扫描或导出的会话转储来检查流量。
若需要将庞大或嘈杂的捕获结果缩小到与功能验证相关的流量范围，可使用
```
ApplyFilters
```
。
保持分析务实。目标是验证功能是否正常工作，而非进行详尽的数据包级审计。
如果当前会话中没有Fiddler MCP工具，请停止操作并告知用户先运行
```
fiddler-mcp-setup
```
，然后重试。
当运行时已暴露Fiddler MCP工具时，切勿手动探测
```
/mcp
```
或使用
```
curl
```
发送原始MCP协议请求。
仅使用主机在
```
tools/list
```
中公布的工具名称。切勿编造或假设会话中未提供的工具名称。

Prerequisites check

前置检查

Verify that Fiddler Everywhere is installed.
Verify that the Fiddler Everywhere MCP tools are available.

验证Fiddler Everywhere已安装。
验证Fiddler Everywhere MCP工具可用。

Useful tools and how to use them

实用工具及使用方法

GetStatus

GetStatus

Use this first to confirm that Fiddler is reachable and in a usable state.

What it helps verify:

Whether the user is logged in
Whether Fiddler appears to be capturing traffic
Whether there are browser or terminal instances attached
Whether HTTPS inspection prerequisites look healthy

首先使用此工具确认Fiddler是否可访问且处于可用状态。

它有助于验证：

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

GetSessionsCount

GetSessionsCount

Use this as a fast sanity check before deeper analysis.

What it helps verify:

Whether anything has been captured at all
Whether the user likely ran the feature recently enough to analyze it

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

它有助于验证：

是否捕获到任何流量
用户是否在足够近的时间内运行了功能以便进行分析

GetSessions

GetSessions

This is the main tool for verification. Use it to pull the captured session list, then narrow the traffic locally in memory.

Use it to:

Find the requests most likely related to the feature run
Identify the order of requests
Spot failures, retries, redirects, preflights, and slow calls
Build endpoint groups for the final summary

When narrowing the list, prefer clues from the user's request such as:

Hostname
URL path or path fragment
HTTP method
Feature name or keyword
A rough time window such as "just now" or "after clicking Save"

If the session list is already manageable, narrowing locally in memory is usually enough. If the capture is large or noisy, use

ApplyFilters

to focus Fiddler on the host, endpoint family, method, or failure pattern that matters.

这是验证的核心工具。使用它获取捕获的会话列表，然后在本地内存中缩小流量范围。

用于：

找到最可能与功能运行相关的请求
确定请求的顺序
发现失败、重试、重定向、预检请求和慢速调用
为最终汇总报告构建端点分组

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

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

如果会话列表已经易于管理，通常在本地内存中缩小范围即可。如果捕获结果庞大或嘈杂，使用

ApplyFilters

让Fiddler聚焦于相关的主机、端点组、方法或失败模式。

GetSessionDetails(id)

GetSessionDetails(id)

Use this after

GetSessions

identifies the interesting sessions.

Good candidates for detail inspection:

Any session with
```
statusCode
```
>= 400
Any session with an empty or missing
```
statusCode
```
The slowest session for an endpoint
A representative successful request for an important endpoint
OPTIONS preflight requests and the request immediately after them when CORS might be involved

Use the details to inspect:

Request headers and response headers
Request and response bodies
Redirect targets
Content length and content type
Auth headers, cookies, validation messages, and error payloads

Rate limit: avoid firing more than 5

GetSessionDetails

calls in rapid succession.

在

GetSessions

识别出感兴趣的会话后使用此工具。

适合进行详细检查的会话：

任何
```
statusCode
```
>= 400的会话
任何
```
statusCode
```
为空或缺失的会话
某个端点中最慢的会话
重要端点的代表性成功请求
OPTIONS预检请求及其紧随的请求（当可能涉及CORS时）

使用详细信息检查：

请求头和响应头
请求体和响应体
重定向目标
内容长度和内容类型
认证头、Cookie、验证消息和错误负载

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

GetSessionDetails

。

ApplyFilters

ApplyFilters

Use this when filtering will make the analysis faster or more reliable.

Possible use cases:

Show only traffic for one host
Show only failing requests
Focus the UI on a particular endpoint family
Reduce a very large capture to the recent feature run you actually need to inspect
Isolate retries, auth failures, or one request method such as
```
POST
```

It is often useful when

GetSessions

returns too much unrelated traffic.

当过滤能让分析更快或更可靠时使用此工具。

可能的使用场景：

仅显示某一主机的流量
仅显示失败的请求
将UI聚焦于特定的端点组
将庞大的捕获结果缩小到实际需要检查的近期功能运行流量
隔离重试、认证失败或某一种请求方法（如
```
POST
```
）

当

GetSessions

返回过多无关流量时，此工具通常很有用。

Suggested workflow

建议工作流

This workflow is intentionally flexible. Adapt it to the feature and the amount of captured traffic.

Understand the feature scope.
- Extract any useful clue from the user's request: action performed, host, path fragment, method, or expected endpoint.
- If the request is vague, analyze the most recent traffic and say that the result is based on the recent capture.
Pull the session list with
```
GetSessions
```
.
- Shortlist sessions that match the feature scope.
- If no clear clue is available, focus on the most recent burst of related sessions rather than the entire capture history.
- If the capture is too noisy to reason about comfortably, use
```
ApplyFilters
```
  to narrow the visible traffic before continuing.
Group traffic by endpoint.
- Group by host + normalized path.
- Strip query strings for grouping.
- Treat numeric IDs and UUID-like segments as path variables when useful, so
```
/users/123
```
  and
```
/users/456
```
  are understood as the same endpoint family.
Review the sequence.
- Check whether the request flow looks plausible for the feature.
- Look for expected follow-up calls such as create then fetch, preflight then actual request, upload then status poll, or save then refresh.
- If a needed follow-up call is absent, call that out as a possible issue rather than a certainty unless the evidence is strong.
Inspect representative details.
- Fetch details for failures, slow calls, mixed-status endpoints, and one or two key successful endpoints.
- Use response bodies and headers as evidence when explaining whether the feature appears healthy.
Decide whether the feature appears to work properly.
- A healthy feature run usually shows the expected endpoints, mostly successful status codes, reasonable latency, and no repeated failures.
- If the traffic is incomplete or ambiguous, say so directly.

此工作流具有灵活性，可根据功能和捕获的流量量进行调整。

明确功能范围。
- 从用户的请求中提取有用线索：执行的操作、主机、路径片段、方法或预期端点。
- 如果请求模糊，分析最新的流量并说明结果基于近期的捕获。
使用
```
GetSessions
```
获取会话列表。
- 筛选出符合功能范围的会话。
- 如果没有明确线索，聚焦于最新的相关会话 burst，而非整个捕获历史。
- 如果捕获结果过于嘈杂难以分析，先使用
```
ApplyFilters
```
  缩小可见流量范围，再继续操作。
按端点分组流量。
- 按主机+标准化路径分组。
- 分组时去除查询字符串。
- 必要时将数字ID和类UUID片段视为路径变量，这样
```
/users/123
```
  和
```
/users/456
```
  会被视为同一端点组。
检查请求序列。
- 检查请求流程对于该功能是否合理。
- 查找预期的后续调用，例如创建后获取、预检后实际请求、上传后状态轮询或保存后刷新。
- 如果缺少必要的后续调用，除非证据确凿，否则将其标注为可能存在的问题而非确定问题。
检查代表性详细信息。
- 获取失败请求、慢速调用、状态混合的端点以及一两个关键成功端点的详细信息。
- 解释功能是否正常时，使用响应体和头信息作为证据。
判断功能是否正常工作。
- 正常运行的功能通常会显示预期的端点、大多为成功状态码、合理的延迟，且无重复失败。
- 如果流量不完整或模糊，直接说明这一点。

Output format

输出格式

Do not dump raw JSON. Write a plain-language verification report with these sections.

text

Feature Verification

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

Traffic window: [what part of the capture you 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]

请勿输出原始JSON。撰写通俗易懂的验证报告，包含以下部分：