Fiddler自动着色规则实战：状态码、域名、耗时多维度标红

盯着一屏Fiddler会话列表翻了三分钟，只为了找那条502的请求，这种体验做过接口联调的人都不陌生。几十上百行记录里每条长得都差不多，接口一多眼睛直接看花，全靠滚动条一点点扫，效率极低。

我的做法是给Fiddler定制一套自动着色规则：让它在会话出现的第一时间，就根据字段和状态给请求上色，该红的红、该绿的绿，该加粗的加粗。一眼扫过去就知道哪些请求需要点开看，哪些可以直接忽略。这篇文章以Fiddler Classic经典版为例，讲清楚规则脚本的修改入口、核心API，以及按状态码、域名、URL关键字、响应内容、耗时等维度实现标红的完整写法，每个场景都给出可以直接套用的代码块，最后整理几个规则不生效和颜色串台的坑。适合正在折腾抓包调试、前后端联调、接口排障的开发者。

1. 先搞明白Fiddler的会话着色机制

1.1 需求拆解：“字段”和“状态”到底指什么

标题里的“字段”和“状态”，对应的是Fiddler会话列表里两个维度的信息。

字段类条件，通常是会话列表第一列到第五列展示的内容：Host（请求域名）、Method（请求方法）、URL关键字、Content-Type（响应类型）、自定义请求头/响应头等。状态类条件则是另一层信息：HTTP状态码（200、302、404、500、502）、请求耗时、响应体内容里是否出现业务错误码等。

把这两个维度拆开之后，标红规则就变成了一段逻辑判断代码。本质上就是遍历每个会话，检查它是否命中我们设置的条件，命中就给这行的背景色或前景色赋值。想按哪个字段标红，就把哪个条件写进判断里，判断条件之间还可以自由组合。

有一点需要提前讲清楚：Fiddler会话列表的颜色信息，最终是通过SessionFlag（会话标志）实现的。修改会话的ui-backcolor、ui-forecolor这类标志，列表就会即时刷新成对应颜色。我们写的所有规则，最后都是落在这些flag上。

1.2 为什么用脚本自动着色，而不是手工Highlight

很多人一开始用的是Fiddler自带的右键Highlight功能，选中一条会话，挑个颜色，完事。我刚开始也是这么干的，但用了几次就放弃了。原因很简单：

• 手工Highlight只能一条条操作，请求量大时完全不现实；
• 刷新列表或者工具重启之后，颜色信息直接丢失；
• 团队里换个环境联调，又得重新标一遍，纯重复劳动。

脚本规则的好处是“一劳永逸”。CustomRules.js保存后立即生效，之后每个新产生的会话都会自动按规则着色。条件随便写，颜色随便挑，规则可以跟着项目走，一套脚本吃遍所有环境。更重要的是，规则是明文代码，团队之间直接共享一个文件，视觉标准就统一了。

Fiddler本身也有内置的自动高亮规则，但内置规则能匹配的条件非常有限，而且对“根据字段或状态定制”这种需求支持得很弱。要真正解放双手，还是得打开脚本自己写。

2. Fiddler规则脚本入口：CustomRules.js从哪里改

2.1 打开脚本的正确姿势

Fiddler的规则脚本入口只有一个核心文件：CustomRules.js。

打开方式很简单，菜单栏点击 Rules -> Customize Rules，有些汉化版本叫“自定义规则”，默认用记事本或系统关联编辑器打开。这个动作等效于直接打开文件，它的物理位置一般在：

%USERPROFILE%\Documents\Fiddler2\Scripts\CustomRules.js

如果你的系统文档目录被迁移到了其他盘，以资源管理器打开后的实际路径为准。点击菜单后脚本会自动打开，不必手动去翻文件夹。

首次打开这个文件的人可能会被吓一跳，里面已经有一大段默认代码，定义了OnBeforeRequest、OnBeforeResponse两个静态函数，还有一些辅助类。我们不需要理解全部内容，只往这两个函数里添加判断逻辑就行。

保存文件之后，Fiddler会在一两秒内自动检测到脚本变更并重新加载，不需要重启工具。如果保存后发现规则没有生效，可以在Fiddler底部QuickExec命令行输入!reload强制重载一次。编辑脚本前建议先把原文件复制一份备份，防止改坏了又没有留底。

2.2 关键事件选择：OnBeforeRequest和OnBeforeResponse

CustomRules.js里有两个最关键的事件函数，理解它们各自的触发时机，是规则能不能生效的前提。

第一个是OnBeforeRequest，它在请求发出之前触发。这个阶段能拿到的是请求行、请求头、URL、Host、Method这些请求侧数据。所以凡是依赖请求字段的判断，比如按域名标红、按URL关键字标红、按请求方法标红，都应该写在这里。

第二个是OnBeforeResponse，它在响应返回之后触发。这个阶段才能拿到状态码、响应时间、响应头和响应体。按状态码标红、按接口耗时标红、按响应内容包含特定字段标红，都只能放在这个事件里。如果你在OnBeforeRequest里判断状态码，拿到的会是初始值，判断永远不成立。

有个容易被坑的细节：如果在OnBeforeRequest里给某个会话设置了颜色，而后请求走到了OnBeforeResponse，另一个规则又给它设了别的颜色，后者会覆盖前者。所以当规则变多之后，最好把着色逻辑抽成公共函数，两个事件都去调用，让颜色由同一个逻辑决定，而不是各写各的互相覆盖。后面展开说。

2.3 设置颜色的核心API：SessionFlag

Fiddler为每个会话维护了一组键值对，叫做SessionFlag。其中这几个固定键和颜色、样式相关：

在脚本里赋值的方式是直接操作oSession对象：

oSession["ui-backcolor"] = "#FFCCCC"; oSession["ui-forecolor"] = "#CC0000"; oSession["ui-bold"] = "true";

颜色格式支持两种：命名颜色（red、blue、green等）和十六进制色值（#FF0000这类）。命名颜色简单但可选的少，要精细控制深浅，还是用十六进制方便。我习惯在规则文件顶部定义一套配色常量，不同场景用不同颜色，后面讲实战时会给出具体配色方案。

这里稍微说明一下为什么用字符串"true"而不是布尔值true。SessionFlag存储的类型本质上是字符串，虽然写true很多时候也能转成字符串，但为了减少类型判断的意外，我习惯显式写字符串形式。

3. 实战：按不同字段和状态写标红规则

3.1 按HTTP状态码标红：最基础的保命规则

状态码着色是所有规则里最实用的一条，它解决的是“满屏请求里快速锁定错误请求”的刚需。逻辑很简单：4xx说明是客户端问题，5xx说明是服务端故障，300系列则是重定向。

public static function OnBeforeResponse(oSession: Session) { // 服务端错误：深红底 + 白字，最醒目 if (oSession.responseCode >= 500) { oSession["ui-backcolor"] = "#FF0000"; oSession["ui-forecolor"] = "#FFFFFF"; oSession["ui-bold"] = "true"; } // 客户端错误：浅红，提示请求有问题但不至于崩 else if (oSession.responseCode >= 400) { oSession["ui-backcolor"] = "#FFCCCC"; } // 重定向：浅黄，方便观察跳转链路 else if (oSession.responseCode >= 300) { oSession["ui-backcolor"] = "#FFFFCC"; } }

这段代码必须放在OnBeforeResponse里，因为responseCode在请求发出前是拿不到的。实际体验下来，5xx（500、502、503、504）用深红底白字加粗，是整个列表里最有视觉冲击力的一个组合，扫一眼就能定位到故障请求。4xx用浅红不打扰，但又能明显区分正常请求。

另外一个小建议：如果页面上刷了一堆静态资源，在OnBeforeRequest阶段先对静态资源请求做个短路判断，比如.js、.css、.png结尾的请求，压根不用走后面的状态码判断，省得每次都得过一遍条件。

public static function OnBeforeRequest(oSession: Session) { var url = oSession.url.toLowerCase(); if (url.endsWith(".js") || url.endsWith(".css") || url.endsWith(".png")) { return; } }

3.2 按域名（Host）区分标红：联调环境一目了然

联调时最痛苦的事，就是浏览器一打开，页面请求里的测试环境域名、线上域名、第三方域名全混在一起，想找某个环境下的接口，全靠肉眼识别主机名。

按域名标红的逻辑写在OnBeforeRequest里最合适，因为请求还没出去，Host字段是现成的。

public static function OnBeforeRequest(oSession: Session) { // 测试环境域名：浅红背景提醒，别搞混了 if (oSession.HostnameIs("api-test.example.com")) { oSession["ui-backcolor"] = "#FFCCCC"; oSession["ui-bold"] = "true"; } // 线上环境域名：浅绿背景，代表正常环境 if (oSession.HostnameIs("api-prod.example.com")) { oSession["ui-backcolor"] = "#D5F5E3"; } }

这里的HostnameIs是精确匹配，不带端口号。如果你的请求里带了端口，比如api-test.example.com:8080，用HostnameIs匹配可能会落空。更稳妥的做法是用oSession.host这个属性做indexOf包含判断：

var host = oSession.host.toLowerCase(); if (host.indexOf("api-test") >= 0) { oSession["ui-backcolor"] = "#FFCCCC"; oSession["ui-bold"] = "true"; }

域名一多，靠散落的if语句维护起来会很费劲。我通常在脚本头部定义一个环境域名数组，用循环去匹配，规则文件看起来清爽很多。后面4.6小节会再展开。

3.3 按URL关键字和请求方法标红：精准锁定目标接口

上面两小节解决了“哪些请求出错了”和“哪些环境要关注”两个问题。但在业务联调里，经常要盯的是某一个特定业务接口，比如下单、支付、登录。这时按URL关键字标红是最精准的做法。

public static function OnBeforeRequest(oSession: Session) { // 包含order关键字的接口：橙色背景，重点关注 if (oSession.uriContains("order")) { oSession["ui-backcolor"] = "#FFCC66"; oSession["ui-bold"] = "true"; } // 登录接口：浅蓝背景 if (oSession.uriContains("login")) { oSession["ui-backcolor"] = "#CCE5FF"; } // POST写操作：字体标红加粗，区分读和写 if (oSession.HTTPMethodIs("POST")) { oSession["ui-forecolor"] = "#CC0000"; oSession["ui-bold"] = "true"; } }

这里补充一个易混点：oSession.fullUrl是完整地址，带协议和域名；oSession.url是路径加查询串部分；uriContains判断的是url内容。如果只想匹配某个具体路径片段，直接写关键字即可，比如uriContains("/api/v1/pay")和uriContains("pay")的命中范围完全不一样，写的时候心里要有数。

按方法标红有个用处：POST、PUT、DELETE这类写操作比GET更需要关注，字体标红能提个醒。但要注意，这里用的是ui-forecolor，只改字体颜色不改背景色，可以避免和背景色规则叠在一起的时候视觉冲突。

3.4 按响应内容包含关键字标红：业务错误码的兜底方案

状态码标红只能抓到HTTP层的错误，但更常见的情况是接口返回200，业务体里却写着"errorCode": "50001"。这种业务错误如果只靠状态码规则，永远不会被标出来。

解决办法是读取响应体，在里面查业务关键字。

public static function OnBeforeResponse(oSession: Session) { // 只对API接口做检查，静态资源跳过 if (oSession.uriContains("/api/")) { var body = oSession.GetResponseBodyAsString(); if (body && body.Contains("errorCode") && !body.Contains("\"errorCode\":\"0\"")) { oSession["ui-backcolor"] = "#FF9999"; oSession["ui-bold"] = "true"; } } }

这段代码的意图很直白：凡是API接口响应里出现了errorCode字段，而且值不是0（假设0代表成功），就标成粉红。用Contains做判断前一定先判空，因为GetResponseBodyAsString在某些情况下返回的是空值，直接调用会报错。

还有个细节：如果响应是Gzip压缩过的，Fiddler在脚本层默认会自动解压文本流，所以一般能直接读到可识别的字符串。遇到乱码或者读不到内容的情况，先检查一下该会话的响应头里Content-Encoding字段，确认是不是压缩格式没被解出来。

3.5 按响应耗时标红：提前暴露性能问题

定位接口慢这个问题，纯靠人工眼睛一遍遍刷新列表看Time列，逐个比较几百毫秒和几秒的差异，效率很低。更直接的做法是让超过阈值的慢请求自动变色。

因为Fiddler内置的计时属性在不同版本上有细微差别，我用一个通用的方案：在OnBeforeRequest里记录当前时间戳，存到会话的自定义flag里，然后在OnBeforeResponse里读出来算差值。

public static function OnBeforeRequest(oSession: Session) { // 记录发起时间 oSession["x-request-start"] = String(new Date().getTime()); } public static function OnBeforeResponse(oSession: Session) { var start = parseInt(oSession["x-request-start"]); if (!isNaN(start)) { var elapsed = new Date().getTime() - start; if (elapsed > 5000) { oSession["ui-backcolor"] = "#FFFFCC"; oSession["ui-bold"] = "true"; // 顺手把耗时写到备注列，鼠标悬停能看 oSession["ui-notes"] = "耗时: " + elapsed + "ms"; } } }

超过5秒的请求标成淡黄色背景，同时把具体耗时写进备注列，排查时不用再自己去算差值。这个场景特别适合和老接口做性能回归的时候用，阈值调到3000还是5000取决于具体项目，直接在文件头部用常量控制会更好。

这里注意一点：存时间戳的flag名字不能和Fiddler内置flag冲突，用x-前缀比较保险。同理写其他自定义flag也建议加前缀，避免误覆盖系统字段。

3.6 组合条件与优先级控制：多规则不会乱成花猫

如果上面的规则都往脚本里堆，不加任何管理，一个会话可能同时命中多个条件，背景色和字体色被后写的语句覆盖来覆盖去，最后呈现的颜色完全随机，反而失去意义。

我现在的做法是把着色逻辑统一收口到一个公共函数里，按优先级从高到低依次判断，一旦命中高优先级规则就直接return，不再继续往下执行低优先级规则。两个事件统一调用这个函数。

public static function ColorizeSession(oSession: Session) { // 重置颜色，防止旧状态残留 oSession["ui-backcolor"] = ""; // 优先级1：服务端错误，最高优先 if (oSession.responseCode >= 500) { oSession["ui-backcolor"] = "#FF0000"; oSession["ui-forecolor"] = "#FFFFFF"; oSession["ui-bold"] = "true"; return; } // 优先级2：客户端错误 if (oSession.responseCode >= 400) { oSession["ui-backcolor"] = "#FFCCCC"; return; } // 优先级3：慢请求 var start = parseInt(oSession["x-request-start"]); if (!isNaN(start)) { var elapsed = new Date().getTime() - start; if (elapsed > 5000) { oSession["ui-backcolor"] = "#FFFFCC"; return; } } // 优先级4：指定域名和业务接口 if (oSession.HostnameIs("api-test.example.com") || oSession.uriContains("order")) { oSession["ui-backcolor"] = "#FFCC66"; oSession["ui-bold"] = "true"; } } public static function OnBeforeRequest(oSession: Session) { oSession["x-request-start"] = String(new Date().getTime()); ColorizeSession(oSession); } public static function OnBeforeResponse(oSession: Session) { ColorizeSession(oSession); }

这样一套组合下来，任何会话最多只有一种颜色，而且颜色表达的含义是确定的：深红是服务端挂了，浅红是请求错了，淡黄是太慢了，橙色是命中了关注接口。整个列表看下来，视觉层级非常清楚。

4. 规则不生效、颜色串台：常见问题与调试技巧实录

4.1 保存后规则不生效

规则写好后保存，Fiddler却纹丝不动，这是最常见的翻车现场。按以下顺序排查：

• 确认保存的文件确实是当前生效的CustomRules.js。有些机器上存在多个副本，菜单打开的路径是最权威的参考，别用文件夹里翻到的另一个文件改了半天。
• 在QuickExec命令行输入!reload强制重载，并观察Fiddler Log（View -> Log）里有没有脚本报错信息。
• 检查函数签名是否正确。OnBeforeRequest、OnBeforeResponse必须写成public static function，少一个关键词，Fiddler都不会调用。
• 如果脚本里出现了语法错误，整个脚本都会加载失败，规则的失效范围是整个文件，不只是写错的那一段。

4.2 颜色一闪而过，或者被其他规则覆盖

场景是：OnBeforeRequest里明明标了红色，请求发完响应回来后，颜色没了或变成了别的颜色。

原因多半是你在两个事件里分别写了着色逻辑，后触发的OnBeforeResponse里的赋值把前面的颜色覆盖了。这是新手最容易踩的坑，也正好印证了前面3.6小节的方案：把着色逻辑抽成公共函数，两个事件统一调用，从根上避免各写各的互相打架。

还有一个小概率情况：Fiddler对某些会话在内部会重置样式，比如对某些自动请求或隧道请求。遇到这种，判断一下该会话的类型，在规则开头跳过非HTTP会话就行。

4.3 颜色太刺眼，或者满屏都是颜色

规则加多了之后，很容易出现下一页屏幕全是粉色橙色，看着很热闹，实际信息量没有提升。我的经验是控制颜色使用量：

• 深红背景只给5xx这种真正需要立刻处理的会话；
• 浅红给4xx，不刺眼又能区分；
• 淡黄给慢请求；
• 浅绿给线上环境请求；
• 业务重点接口用橙色，但数量必须少，最好一个项目只标两三个。

还有一种做法是“不加背景，只加粗”。对于需要提醒但不紧急的会话，设置ui-bold = "true"就够了，让背景颜色留给真正需要聚焦的错误和慢请求。

4.4 JScript.NET语法坑导致整个规则文件崩掉

Fiddler的脚本语言是JScript.NET，语法上接近JavaScript，但和浏览器里的JavaScript还是有一些差异。几个容易踩的坑：

• 字符串必须用双引号或单引号括完整，漏了一个引号，整个脚本直接编译失败；
• 方法名区分大小写，Contains、HostnameIs、GetResponseBodyAsString，大小写写错了不会报错，但函数不执行；
• 函数里声明变量尽量用var，避免隐式全局变量带来莫名其妙的变量污染；
• 公共函数必须写在两个事件函数之外，不能嵌在事件函数里面。

写完一段规则就保存一次，这是最土但最有效的自检方式。等你一次性写完几百行再保存，编译器报错之后定位错误位置是很痛苦的一件事。

4.5 快速验证规则是否生效

验证规则最快的方法，是制造一个已知会命中条件的环境。比如你刚写完状态码标红，就用浏览器去访问一个不存在的路径，让服务器返回404，看列表里那条记录有没有变成浅红；或者故意用来一个返回500的测试接口，看有没有变成深红。如果颜色没变，说明规则没写对，或脚本没重载，按4.1的顺序排查。

Fiddler自带的示例会话也适合用来验证脚本。菜单 File -> Load Sample Sessions，会生成一批带各种状态码的示例请求，保存规则之后加载一批，瞬间就能看出颜色逻辑是否正确。每次验证前，可以先按Ctrl+X清空会话列表，免得旧数据干扰观察。

4.6 多套环境的规则管理

最后聊点规则文件的工程化经验。如果你同时维护多个项目的调试环境，建议把环境差异都收敛到脚本头部，做成配置常量，规则逻辑只读取这些常量，不改中间判断。

var TIMEOUT_MS = 5000; var TEST_HOSTS = ["api-test.example.com", "admin-test.example.com"]; var BIZ_KEYWORDS = ["order", "pay", "refund"];

换项目时只改头部这一段，颜色体系和判断逻辑完全不用动。规则文件做好命名备份，比如CustomRules-order.js、CustomRules-pay.js，在项目切换时直接替换文件再!reload即可。这套做法看起来简单，但真正能省下不少切换环境时反复改脚本的功夫。

我自己用这套规则大概五六年了，最大的感受是它把“找问题”从主动扫描变成了被动接收：颜色一亮，目光就会自动聚焦过去，根本不用从上到下翻列表。规则别贪多，颜色别太满，挑几个真正影响判断的状态和字段去标，比什么都标红更实用。照着上面几个场景从状态码标红开始试，慢慢往上加，你会回来感谢这条规则的。