简介面向需要自行搭建抓包工具的 .NET 开发者压缩包以 FiddlerCore 为核心提供一套可直接运行的示例工程重点解决 HTTPS 解密、证书安装以及系统代理与自定义代理两种抓取方式的选择问题适合刚接触抓包原理的读者快速上手。压缩包共 33 个文件包含 11 个 C# 源码文件覆盖代理、证书、事件处理等模块、4 个 DLL 依赖、4 个可执行文件以及配置、XML、工程文件等整体仅 717KB目录结构精简便于直接打开工程逐段核对逻辑。实现上提供两种抓取 Session 的方式通过系统代理或通过自定义代理 WebProxy.Start(8877)代码对应位置已标明系统代理设置入口证书处理与事件回调也一并封装。作者结合 Fiddler Core 官方 Demo 与 C# 社区示例改写整理出可复用的抓包基础框架从源码、配置文件到编译产物都包含在内既能看到完整实现也能按需修改扩展对于刚接触 FiddlerCore 的开发者来说是理解证书信任链和代理拦截机制的实用起点。目前已有 1577 人浏览学习。1. FiddlerCore抓包把抓包引擎装进自己的程序里做客户端开发或接口调试的人大概率都经历过这样的场景小程序里有个请求Fiddler 能抓到但你想在自动化脚本里实时拿到同样的流量或者 App 做了证书校验Fiddler 装好证书后还是只能看到 CONNECT 隧道再或者你想在测试环境里自动校验每个请求的响应码但手工开 Fiddler 抓包再导出效率太低。FiddlerCore 就是干这个的——它是 Fiddler 的抓包引擎库把 Fiddler 的代理能力以 DLL 形式暴露出来让你在自己的程序里直接启动一个抓包代理注册回调处理每一个经过的请求和响应。你不再需要开着图形界面点来点去而是把抓包变成代码里的一段逻辑。这篇文章我会从最小启动代码开始讲到 HTTPS 解密、证书信任、常见坑和性能参数让新手能照着一路跑通老手也能看到几个平时容易忽略的边界。2. FiddlerCore抓包环境搭建引用方式、初始化与最小代理2.1 FiddlerCore的三种宿主方式与选型FiddlerCore 不是一个独立运行的 exe它是一个托管 DLL需要宿主进程把它加载起来。常见做法有三种第一种是写一个独立的控制台程序或 Windows 服务专门做代理中转适合后台持续抓包第二种是嵌入到已有的测试框架里比如 pytest 的 fixture 里启动和销毁适合接口自动化时顺带抓流量第三种是嵌入到一个带界面的工具里比如 WPF 或 WinForms 程序适合做内部调试工具。我一般会建议先按第二种方式起步因为测试框架的生命周期管理和 FiddlerCore 的 Start 和 Shutdown 天然对应写起来最顺手。选型上需要注意一个关键点FiddlerCore 官方提供的是商业授权个人学习或内部评估可以直接用但如果是商业项目集成要确认授权范围。另外 NuGet 上有 FiddlerCore 包版本比较老也有第三方封装的开源版本但行为不完全一致。如果你要跟线上 Fiddler 的抓包行为保持完全一致直接用官方包最稳妥。2.2 最小可用的代理启动代码先把最简单的跑起来。下面这段代码启动一个监听在 127.0.0.1:8877 的代理并把每个请求的 URL 打到控制台using System; using Fiddler; class Program { static void Main(string[] args) { // 绑定回调每个请求经过都会触发 FiddlerApplication.BeforeRequest session { Console.WriteLine($[{DateTime.Now:HH:mm:ss}] {session.fullUrl}); }; // 启动监听代理 FiddlerApplication.StartProxy(8877, true, true, true); Console.WriteLine(代理已启动127.0.0.1:8877按回车退出...); Console.ReadLine(); FiddlerApplication.Shutdown(); } }逻辑很简单但有几个参数需要解释清楚。StartProxy 的第一个参数是监听端口第二个参数表示是否在系统 IE 代理里自动写入当前地址第三个参数是是否允许远程客户端连接第四个参数是是否作为系统代理的监视器。开发本机调试时第三个参数建议设成 false只监听回环地址避免局域网内其他机器连上来。第二个参数如果你不想影响系统全局代理可以先设 false然后在目标程序里单独指定代理地址。跑起来后你需要在客户端浏览器、App、小程序开发者工具里把 HTTP 代理指向 127.0.0.1:8877。注意这里只代理了 HTTP 明文流量。如果你用浏览器访问的是 HTTPS 网站控制台里会看到大量CONNECT开头的请求这就是代理隧道的建立。此时 FiddlerCore 还看不到真正的 HTTPS 请求内容需要先解决证书问题。2.3 会话回调里拿到第一个请求启动回调后还有一个常见问题在 BeforeRequest 里修改请求比如加一个 Header怎么做其实就是在回调里直接操作 session 对象FiddlerApplication.BeforeRequest session { // 给所有请求加一个标记头 session.RequestHeaders.Add(X-Captured-By, FiddlerCore); // 只处理目标域名的请求 if (session.Hostname.Contains(api.example.com)) { Console.WriteLine($捕获API请求: {session.fullUrl}); } };这段代码中有两个常用操作RequestHeaders.Add 是在不影响原有请求体的前提下追加自定义头适合在抓包的同时给流量做标记Hostname 是 session 解析出来的主机名比直接用 fullUrl 判断更快。有一点要提醒——回调里做的修改会直接影响发往服务器的请求也就是说 FiddlerCore 不只是在“看”流量它本身就是一个代理有能力篡改请求。这在做测试时非常方便但也意味着处理不当会引发线上事故后面避坑章节会具体展开。3. FiddlerCore抓包HTTPS流量证书安装、解密配置与回调过滤3.1 HTTPS解密为什么默认抓不到Fiddler 能抓 HTTPS是因为它在客户端和服务器之间充当了中间人客户端信任的是 Fiddler 的根证书Fiddler 再用自己的客户端证书去连接服务器。这种手法叫 MITM也是几乎所有抓包工具的通用做法。FiddlerCore 作为引擎默认行为也一样——如果你没有安装并信任根证书HTTPS 请求只会以 CONNECT 隧道的形式出现过完全看不到里面的内容。这里就回到了搜索热词里常见的“app抓包失败”和“fiddler 手机抓包”问题手机或小程序环境往往没有把根证书加入系统信任列表或者 App 做了 SSL Pinning证书即使装了也不信任。FiddlerCore 解决不了 Pinning 问题只能做到“信任链通畅时能解密”。3.2 证书的生成、安装与信任要把 HTTPS 抓明白第一步是让 FiddlerCore 自己生成并安装根证书。它的接口封装得很直接但坑也不少// 检查根证书是否存在不存在就创建 if (!FiddlerApplication.CertMaker.RootCertExists()) { FiddlerApplication.CertMaker.CreateRootCertificate(); } // 把根证书安装到当前用户信任区 FiddlerApplication.CertMaker.TrustRootCertificate(); // 确保每次连接都动态签发证书 FiddlerApplication.CertMaker.EnsureReady();逻辑上CertMaker 模块负责根证书的管理。CreateRootCertificate 会生成一个自签名的根证书TrustRootCertificate 把它导入 Windows 当前用户的证书存储区。这里有个重要的边界TrustRootCertificate 只影响当前 Windows 用户如果你用管理员权限跑程序但调试用的是另一个用户证书就不生效。另外如果你抓的是 Android 7.0 以上的 App光装用户证书还不够很多 App 默认只信任系统证书这属于平台限制需要在模拟器或 root 过的设备里把证书挪到系统证书目录这不是 FiddlerCore 的问题但排查时要能想到这一层。如果你是给小程序抓包用的是微信开发者工具情况不太一样。开发者工具有一个“设置-代理设置”可以手动指定代理地址和端口。它本身信任本机证书但你也必须在 Windows 的“受信任的根证书颁发机构”里能看到 FiddlerCore 生成的证书否则开发者工具会报证书错误。实际操作时我一般会先手动打开 certmgr.msc 确认证书在不在再启动代理。3.3 用回调过滤掉噪音流量一旦 HTTPS 解密生效你就会发现流量多到爆炸。微信小程序有各种上报、日志、统计请求App 有推送心跳这些都会涌入回调。如果不做过滤控制台刷屏是小事处理不过来导致代理变慢才是大问题。我习惯在 BeforeRequest 里做三层过滤域名白名单、URL 关键词排除、Content-Type 筛选。FiddlerApplication.BeforeRequest session { // 第一层只关心业务 API 域名 if (!session.Hostname.EndsWith(api.example.com) !session.Hostname.EndsWith(log.example.com)) return; // 第二层排除埋点上报类路径 string path session.Path; if (path.Contains(/collect) || path.Contains(/metrics)) return; // 第三层只抓 JSON 接口 string contentType session.RequestHeaders[Content-Type] ?? ; if (!contentType.Contains(application/json) session.HTTPMethod ! GET) return; // 命中条件的请求记录方法、路径、请求体摘要 Console.WriteLine(${session.HTTPMethod} {session.Path} 参数长度{session.RequestBody.Length}); };三层过滤的价值在于把回调里的逻辑从“所有流量”收窄到“目标流量”避免无关数据干扰。注意第三层用了session.RequestBody.Length这个属性会触发请求体的完整读取如果请求体很大频繁访问会影响性能。如果你只需要 URL不要读 Body如果必须读 Body做好长度截断。还有一处值得说明FiddlerCore 的回调里访问session.RequestBody或者session.GetResponseBody()都会改变 session 的状态可能导致后续事件里数据不可用。最稳妥的做法是只在需要的回调里读取一次并且尽快把数据复制到自己的结构里。4. FiddlerCore抓包避坑5个必踩的坑与排查4.1 证书装上后仍然显示CONNECT隧道现象根证书已经创建并信任启动代理后 HTTPS 请求仍然只看到CONNECT api.xxx.com:443看不到真正的请求头。原因最常见的是“代理端口被系统代理设置污染了”也就是 StartProxy 的第二个参数 setAsSystemProxy 设为 true 后系统代理指向了之前的残留配置。另一种可能目标程序浏览器/App根本不信任当前根证书连接在 TLS 握手阶段失败FiddlerCore 只能显示隧道建立动作。解决方式先关掉系统代理手动在目标程序里设置代理为 127.0.0.1:8877然后打开浏览器访问 https://www.baidu.com如果能看到解密后的请求说明正向代理正常。如果仍然只有 CONNECT在程序启动前先调用CertMaker.RemoveFiddlerGeneratedCerts()清掉旧证书再重新生成旧证书可能已过期或被部分程序缓存了不可信状态。4.2 回调里修改请求导致程序崩溃现象在 BeforeRequest 里给 session 写入了自定义 Header目标服务返回 400 或连接被重置更严重的某些情况下回调抛异常直接让宿主程序崩溃。原因FiddlerCore 的回调是同步执行的异常会直接向上抛而且并非所有 Header 都允许修改比如Content-Length如果你手动改了和实际请求体长度不一致服务器会直接断开。解决方式所有回调体用 try-catch 包一层异常至少打到日志里不要让引擎进程退出。修改 Header 时遵循“只加自定义字段不动协议字段”的原则。万一必须改 Content-Length一定要先改 Body 再重算长度。4.3 端口被占用或代理设置不生效现象启动时报Failed to listen on port 8877或者程序没报错但客户端连不上。原因8877 端口可能被别的代理工具占着。另一个很隐蔽的情况是代理设成了 localhost但 FiddlerCore 监听的是 IPv6 回环地址 ::1而客户端用的是 IPv4 127.0.0.1导致连接失败。解决方式监听端口用IPAddress.Loopback时FiddlerCore 默认监听0.0.0.0:8877而不是127.0.0.1:8877你可以用netstat -ano | findstr 8877确认监听地址。如果发现有别的进程占用换端口即可。客户端设置代理时尽量用 127.0.0.1 而不是 localhost避免解析到 ::1。4.4 抓包导致目标App掉线或卡顿现象手机 App 配置代理后部分页面加载很慢甚至直接提示网络异常。原因FiddlerCore 默认在处理每个请求时都会调用回调如果回调里做了耗时操作比如访问数据库、写日志文件代理吞吐量会急剧下降。另外App 可能做了并发长连接FiddlerCore 处理长连接的能力和线程池配置直接相关。解决方式回调里不要做任何同步 IO。写文件先用内存队列缓冲再另开线程落盘需要转发到别的地方时用异步任务。同时在 StartProxy 时设置连接池参数具体参数在下一章讲。4.5 内存只涨不降最终OOM现象程序跑一晚上内存占用从几百 MB 涨到几个 GB。原因FiddlerCore 的 session 对象在回调结束后不会自动释放如果你把 session 引用保存到了全局列表里它携带的请求和响应体就会一直驻留内存。很多人很容易犯这个错想在最后统一分析结果吃光了内存。解决方式回调里只抽取需要的字段URL、状态码、耗时、指定 Header存成自己的轻量结构不要让 session 本身离开回调作用域。如果确实需要保存完整响应体写到文件而不是内存。还可以定期调用FiddlerApplication.oSessionHandler相关清理方法释放内部缓冲。5. FiddlerCore抓包进阶并发场景、性能参数与业务集成5.1 吞吐量上不去的三个关键参数FiddlerCore 底层是 Socket 轮询模型默认配置偏向兼容性而不是性能。当你同时有几十个连接或者单个连接频繁发送请求时会出现延迟忽高忽低的情况。我一般会调整三个地方// 连接复用默认 false改成 true 能显著减少 TCP 握手开销 FiddlerApplication.Prefs.SetBoolPref(fiddler.network.http.ConnectionReuse, true); // IO 超时默认 30 秒偏长内网调试设 10 秒 FiddlerApplication.Prefs.SetIntPref(fiddler.network.timeouts.Read, 10); // 缓冲大小默认 8192 字节大响应体场景调到 65536 FiddlerApplication.Prefs.SetIntPref(fiddler.network.buffer.Size, 65536);这三个参数中ConnectionReuse 影响最大。如果你的目标程序启用了 Keep-Alive复用连接可以把吞吐量提升一倍以上。缓冲区大小调整也要谨慎调得过大对内存占用有直接影响。FiddlerCore 的参数命名空间沿用了 Fiddler 的配置体系调整后立即生效不需要重启代理。这里尤其适合“fiddler抓包详细教程”里提到的性能调优部分——很多人只知道回调怎么写不知道还有 Prefs 层可以调。5.2 把抓包结果按需落盘抓包这件事最终价值是数据能留下来分析。把 session 信息直接写到一个轮转文件里比塞进数据库更省心。做法是在 BeforeRequest 和 AfterResponse 里分别记录请求摘要和响应状态private static StringBuilder _buffer new StringBuilder(); static void AppendRequestLog(Session session, string direction) { _buffer.AppendLine(string.Join(\t, DateTime.Now.ToString(yyyy-MM-dd HH:mm:ss.fff), direction, session.HTTPMethod, session.fullUrl, session.responseCode.ToString(), session.ResponseHeaders[Content-Type] ?? )); } // 在回调中调用 FiddlerApplication.BeforeRequest session { AppendRequestLog(session, REQ); }; FiddlerApplication.AfterResponse session { AppendRequestLog(session, RESP); };这里面有个细节方向把_buffer的内容定时刷到文件而不是每条立即写。最常见的做法是启动一个 Timer每两秒把新行追加写入日志文件然后清空 StringBuilder。这个方案的优点是不会阻塞代理回调而且日志格式是制表符分隔可以直接拖进 Excel 处理。实际我在给“小程序抓包”做数据统计时就是靠这个方式把请求明细沉淀下来再用脚本统计各接口的响应时长分布。5.3 与自动化测试框架的集成方式FiddlerCore 抓包接口自动化最常见的用法是“动态断言”测试请求发出后在代理回调里确认确实有某个外部调用发生或者拦截测试桩数据返回。public static void InstallMockRule(string urlPart, string responseBody) { FiddlerApplication.BeforeRequest session { if (session.fullUrl.Contains(urlPart)) { session.utilCreateResponseAndBypassServer(); session.responseCode 200; session.responseBody responseBody; } }; }在没有 FiddlerCore 的情况下测试桩通常要依赖后端测试环境的一套 mock 服务有了这条规则你可以完全在本机制造指定响应。这里的关键是为utilCreateResponseAndBypassServer——调用后 FiddlerCore 直接生成响应返回给客户端不再与服务器通信。这在做故障注入比如模拟 500 响应、模拟超时时非常有用。需要警惕的是这个操作会影响所有匹配到的请求规则一定要带环境判断否则容易误伤正常流量。5.4 线程模型与回调顺序FiddlerCore 的回调在不同连接上是并行触发的意味着两个请求的回调可能同时执行。如果你的回调里引用了一个共享的 Dictionary 或 List就会遇到线程安全问题。我在做集成时一般会给回调外层的容器加锁或者用 ConcurrentDictionary。还有一件事很多人踩坑BeforeRequest 和 AfterResponse 不保证成对出现——一个请求如果在传输中连接断开只有 BeforeRequest 被触发。所以你的统计逻辑不能默认每个 BeforeRequest 都有一个对应的 AfterResponse。6. FiddlerCore抓包的自检清单从“能跑通”到“可信赖”当你把代理跑起来也能看到请求了先别急着认为自己已经“会抓包了”。我经历过太多次“明明抓到了却分析错”的情况所以后来养成一个习惯先验证抓包结果的完整性再开始信任数据。验证方法分三步第一步用浏览器无痕模式访问一个固定 URL确认代理日志里有且仅有预期的那一个请求没有多余域名第二步对比目标 App 的请求在 FiddlerCore 日志里统计同一接口的出现频率看是否和 App 表现一致第三步做一次抓包结果的重放把 session 的请求体完整打印出来和服务器端日志核对是否有字段丢失。三步全过我才敢把数据用于后续分析。还有一个容易忽略的问题不同机器、不同用户环境下FiddlerCore 的证书状态完全隔离。你在一台机器上信任了根证书换一台机器就要重新执行一遍生成和信任流程。所以我建议把证书操作封装成一个独立的环境初始化方法在程序每次启动时调用而不是只在安装时调用一次。如果一个环境抓不到 HTTPS先跑这个初始化方法通常能解决过半的问题。最后说一个个人的习惯线上环境绝不开 FiddlerCore 的“自动作为系统代理”选项只允许显式指定代理的测试任务连接。因为一旦系统代理被自动设置其他无关进程的流量都会涌进来轻则日志爆炸重则把生产环境的敏感请求打到了你的本地代理里这是安全红线。FiddlerCore 的能力边界很清楚它是一个引擎不是魔法。你能用它做到 Fiddler 界面版 90% 的事情甚至做到界面版做不到的自动化但证书信任和 App 自身的校验仍然要回到操作系统和客户端机制里去解决。把这些边界摸清楚这个方向就值得投入。希望这篇笔记能帮你少走一些我走过的弯路。本文还有配套的精品资源点击获取