简介这是一份基于FiddlerCore开发的轻量级HTTPS抓包工具源码包面向C#开发者、网络调试初学者及逆向分析实践者解决商用抓包工具收费高、HTTPS解密配置复杂等痛点。资源共33个文件包含11个核心C#源码如Program.cs、FiddlerEventHandlerTingTing.cs、Certificate.cs、WebProxy.cs、4个可执行文件exe与配套DLL依赖、4个配置文件config用于代理与证书策略设定以及调试符号pdb、XML文档和项目定义csproj等完整覆盖从证书生成、系统代理切换到Session捕获的全流程实现压缩包仅717KB结构紧凑、即拿即用。已有1579人学习下载提供两种抓包模式一键启用系统代理或自定义端口启动独立代理服务默认8877并内置HTTPS证书自动安装与信任逻辑附带源代码说明文本与模块化分层设计事件处理、辅助方法、代理封装便于理解FiddlerCore底层机制并快速二次开发。1. FiddlerCore 抓包不是 GUI 工具的简化版而是嵌入式 HTTP(S) 流量控制黑匣子你可能用过 Fiddler Classic——那个带界面、能点点点看请求头、改响应体、断点调试的 Windows 抓包神器。但如果你正在写一个需要自动捕获、过滤、重写、甚至拦截 HTTPS 流量的后台服务、自动化测试框架或安全审计模块Fiddler Classic 就成了累赘它依赖 UI 线程、无法静默运行、证书管理不透明、进程隔离难、二次开发接口松散。这时候FiddlerCore 就不是“Fiddler 的精简版”而是一个可编程、无界面、可深度集成的 HTTP(S) 协议栈中间件。它本质是 Fiddler 引擎的 .NET Core/.NET 5 可重用类库封装暴露的是Session生命周期钩子、BeforeRequest/BeforeResponse事件、证书生成与信任链注入逻辑以及底层TcpClient和SslStream的可控接管能力。适合某公司做 API 自动化回归平台的后端流量录制模块也适合某高校实验室在 Windows 服务中实现无感知的 Web 客户端行为审计。它不解决“怎么学抓包”而是解决“怎么把抓包能力变成你代码里一个可控的using var core new FiddlerCore();”。2. FiddlerCore 集成原理为什么必须亲手处理证书信任链而不是靠系统自动信任FiddlerCore 的核心价值在于它把原本藏在 Fiddler Classic 图形界面背后的三件事彻底暴露出来代理监听、HTTPS 解密、证书信任。这三者环环相扣缺一不可。很多开发者第一次跑通FiddlerCore.Startup()后发现 HTTPS 请求全失败ERR_SSL_PROTOCOL_ERROR 或 NET::ERR_CERT_AUTHORITY_INVALID第一反应是“是不是没开 HTTPS 解密”——其实更大概率是证书根本没被目标进程信任。FiddlerCore 不会、也不能替你把它的根证书自动安装进系统或浏览器的受信任根证书存储区它只负责生成证书、签名、缓存并提供.cer文件路径和X509Certificate2实例。是否信任、如何分发、是否强制注入到特定进程的证书存储比如 Chrome 的--ignore-certificate-errors-spki-list不适用得走 Windows CryptoAPI 或 CertStore API全由你控制。这种“不越界”的设计恰恰是它能嵌入生产环境的关键你可以在服务启动时调用CertMaker.trustRootCert()尝试提升权限安装也可以选择仅对当前进程内发起的HttpClient注入自定义ServerCertificateCustomValidationCallback甚至为每个 Session 动态生成唯一域名证书并缓存到内存字典中——这些自由度GUI 工具给不了。2.1 代理监听机制从ListenOnPort到ProxyConfigurationFiddlerCore 启动代理服务本质是创建一个 TCP 监听器等待客户端连接再根据CONNECT方法建立隧道或直接解析 HTTP 请求。关键配置项不在StartupFlags字符串里硬编码而应通过ProxyConfiguration对象显式构造var config new ProxyConfiguration { ListenOnPort 8888, AllowRemoteClients true, // 允许局域网其他设备连接需防火墙放行 UseIPv6 false, MaxConcurrentConnections 1000, ConnectionTimeoutMs 30_000 }; FiddlerApplication.Startup(config);提示AllowRemoteClients true并不等于“开箱即用”。Windows 防火墙默认阻止非管理员程序监听非 1024 下端口且若监听0.0.0.0:8888需确保目标客户端明确设置代理地址为本机 IP如192.168.1.100:8888而非localhost:8888后者在某些网络栈下会被绕过。2.2 HTTPS 解密流程DecryptSSLTraffic只是开关真正干活的是CertMaker启用 HTTPS 解密只需一行FiddlerApplication.Prefs.SetBoolPref(fiddler.network.https.DecryptSSL, true);但这行代码背后触发的是整套证书生命周期管理首次调用时CertMaker自动生成一个名为DO_NOT_TRUST_FiddlerRoot的自签名根证书RSA 2048默认有效期 1 年每当遇到新域名如api.example.comCertMaker基于该根证书签发一张叶子证书Subject CN api.example.comSANs 包含所有匹配域名所有解密后的Session对象其oResponse.headers[X-Fiddler-Generated-Cert]会标记证书指纹便于日志追踪若未调用CertMaker.trustRootCert()或等效操作该根证书不会进入CurrentUser\Root或LocalMachine\Root存储浏览器/应用必然报证书错误。因此DecryptSSLTraffic true是必要不充分条件。它只是告诉 FiddlerCore“遇到 HTTPS 请求请尝试解密”但解密后能否被客户端接受完全取决于你是否让客户端信任那个根证书。2.3 证书信任链注入三种落地路径与适用边界FiddlerCore 提供了CertMaker类但信任注入必须由你决策并执行。常见路径有三路径适用场景关键代码/命令注意事项系统级安装推荐开发/测试本地调试、CI/CD 中的 Windows AgentCertMaker.trustRootCert();需管理员权限必须以Administrator权限运行进程否则抛UnauthorizedAccessException安装后影响整个系统需配套卸载逻辑进程级信任推荐服务/嵌入Windows 服务、后台守护进程、无 UI 应用ServicePointManager.ServerCertificateValidationCallback (sender, cert, chain, errors) true;仅对当前进程内HttpClient/WebRequest生效绕过验证不安全仅用于可控内网环境不适用于第三方 DLL 发起的请求手动导出 外部部署推荐交付/合规交付给客户部署、等保/密评要求明确证书来源File.WriteAllBytes(FiddlerRoot.cer, CertMaker.rootCert.Export(X509ContentType.Cert));需额外提供 PowerShell 脚本或 MSI 安装包将.cer导入目标机器TrustedRootCA避免权限问题但部署步骤变多注意CertMaker.rootCert是延迟初始化的。首次访问前必须确保FiddlerApplication.Prefs.SetBoolPref(fiddler.network.https.DecryptSSL, true);已设置否则rootCert为 null。3. FiddlerCore 初始化与事件绑定从空壳到可干预的流量管道FiddlerCore 的能力不是靠“启动”就自动生效的而是靠你主动注册事件处理器把原始Session对象变成可读、可写、可丢弃的数据包。它的事件模型是典型的观察者模式所有回调都在FiddlerApplication静态类上注册。最常用、也最容易误用的四个事件是BeforeRequest、BeforeResponse、AfterSessionComplete、OnNotification。它们的触发时机、线程上下文、可修改字段范围各不相同必须严格区分。3.1BeforeRequest唯一能修改请求头、URL、Method 的入口此事件在 FiddlerCore 接收到完整 HTTP 请求行和头部后、尚未转发给上游服务器前触发。此时oSession的oRequest.headers、fullUrl、hostname、method均可安全修改。典型用途包括统一添加鉴权 Header、重写 Host 头指向测试环境、屏蔽特定 User-Agent 请求。FiddlerApplication.BeforeRequest session { // 示例为所有请求添加 X-Trace-ID session.oRequest.headers[X-Trace-ID] Guid.NewGuid().ToString(N); // 示例将 prod.example.com 重写为 test.example.com if (session.hostname prod.example.com) { session.hostname test.example.com; session.fullUrl session.fullUrl.Replace(prod.example.com, test.example.com); } // 示例拦截并拒绝特定路径返回 403 if (session.PathAndQuery.StartsWith(/admin/)) { session.utilCreateResponseAndBypassServer(); session.responseCode 403; session.oResponse.headers.SetStatus(403, Forbidden); session.oResponse.headers[Content-Type] text/plain; charsetutf-8; session.oResponse.body System.Text.Encoding.UTF8.GetBytes(Access denied by policy.); } };逻辑说明utilCreateResponseAndBypassServer()是关键——它告诉 FiddlerCore “别转发了我来构造响应”。此后session.responseCode、oResponse.headers、oResponse.body就是你控制的全部输出。注意body必须是byte[]不能是字符串除非你手动编码。3.2BeforeResponse修改响应体前的最后机会但 Body 可能未加载此事件在 FiddlerCore 收到上游服务器完整响应头后、开始接收响应体前触发。此时oResponse.headers可读可写但oResponse.body通常为空除非你提前设置了bBufferResponse true。若需修改响应体如注入 JS、替换图片 Base64必须先启用缓冲FiddlerApplication.BeforeRequest session { // 启用响应体缓冲内存占用增加慎用大文件 session.bBufferResponse true; }; FiddlerApplication.BeforeResponse session { // 此时 oResponse.body 已加载到内存 if (session.oResponse.headers.Exists(Content-Type) session.oResponse.headers[Content-Type].Contains(text/html)) { var html System.Text.Encoding.UTF8.GetString(session.oResponse.body); // 注入脚本 html html.Replace(/head, script src/inject.js/script/head); session.oResponse.body System.Text.Encoding.UTF8.GetBytes(html); // 更新 Content-Length session.oResponse.headers[Content-Length] session.oResponse.body.Length.ToString(); } };参数说明bBufferResponse true会让 FiddlerCore 把整个响应体读入内存byte[]对视频、PDF 等大文件极易 OOM。生产环境建议结合Content-Length头和 MIME 类型白名单判断是否启用。3.3AfterSessionComplete日志、统计、清理的黄金位置此事件在 Session 完全结束无论成功、超时、取消后触发是唯一保证oRequest和oResponse全部字段都已填充完毕的回调。适合做耗时操作写入数据库、上传到 S3、计算耗时分布、释放资源。切忌在此处修改任何oRequest/oResponse字段——它们已发送完毕修改无效。FiddlerApplication.AfterSessionComplete session { // 记录关键指标 var logEntry new { Id session.id, Url session.fullUrl, Method session.method, StatusCode session.responseCode, DurationMs session.millisecondsElapsed, RequestSize session.oRequest.headers.ContentLength, ResponseSize session.oResponse.headers.ContentLength, ClientIP session.clientIP, ServerIP session.serverIP }; // 异步写入日志避免阻塞主线程 _logger.LogDebug(Session completed: {Log}, logEntry); // 清理大对象如果之前分配了 buffer session.oRequest?.body null; session.oResponse?.body null; };注意session对象在此事件后可能被池化复用不要长期持有引用。所有业务逻辑应尽快完成。4. 常见问题排查五个真实翻车现场与血泪修复方案FiddlerCore 的坑往往不在文档里而在 Windows 权限、.NET 运行时差异、证书存储隔离这些“看不见”的地方。以下是某开发者在某跨平台自动化测试平台中踩过的五个高频问题按现象→原因→解决结构整理每一条都经过真实环境复现。4.1 现象HTTPS 请求全部失败Chrome 显示NET::ERR_CERT_AUTHORITY_INVALID但 FiddlerClassic 能正常工作原因FiddlerCore 生成的根证书未被 Chrome 信任。Chrome 从 v86 开始不再读取 Windows 系统证书存储CurrentUser\Root而是使用自己的证书数据库位于%LOCALAPPDATA%\Google\Chrome\User Data\Default\Preferences关联的 SQLite且仅信任预装根证书或通过组策略导入的证书。FiddlerClassic 安装时会额外调用 Chrome 的证书导入逻辑FiddlerCore 不会。解决方案 A开发阶段启动 Chrome 时加参数--unsafely-treat-insecure-origin-as-securehttps://your-test-domain.com --user-data-dirC:\temp\chrome-profile并确保该 profile 下已手动导入FiddlerRoot.cer方案 B生产阶段用certutil -addstore ROOT FiddlerRoot.cer命令安装证书后再通过 Chrome 组策略模板UpdatePolicyForRootCerts强制同步方案 C通用改用 Edge 或 Firefox 测试它们仍尊重系统证书存储。4.2 现象BeforeRequest中修改session.hostname无效请求仍发往原域名原因hostname字段修改后FiddlerCore 并不会自动更新oRequest.headers[Host]。HTTP/1.1 协议要求Host头必须与实际连接的目标一致否则服务器可能返回 400 或路由错误。FiddlerCore 默认保留原始Host头即使你改了hostname。解决必须手动同步Host头session.hostname test.example.com; session.oRequest.headers[Host] test.example.com; // 关键 // 如果是 HTTPS CONNECT 请求还需修改 CONNECT 行 if (session.RequestMethod CONNECT) { session.oRequest.headers.UriScheme https; }4.3 现象FiddlerApplication.Startup()抛System.Net.Sockets.SocketException: Only one usage of each socket address is normally permitted原因端口8888或其他监听端口已被其他进程占用。常见于FiddlerClassic 未关闭、另一个 FiddlerCore 实例在运行、IIS Express 占用、甚至 Skype老版本默认用 80/443/8080。解决第一步netstat -ano | findstr :8888查 PID第二步tasklist | findstr PID确认进程名第三步若为svchost.exe用Get-Process -Id PID | Select-Object Name, Path在 PowerShell 中查具体服务第四步代码中改用动态端口var port GetAvailablePort(); // 自实现遍历 8000-8999 找可用端口 FiddlerApplication.Startup(new ProxyConfiguration { ListenOnPort port });4.4 现象BeforeResponse中修改oResponse.body后页面显示乱码或截断原因未同步更新Content-Length头且未处理Content-Encoding: gzip。FiddlerCore 默认透传压缩响应若你在BeforeResponse中解压并修改了 body却忘了重新压缩或清除Content-Encoding浏览器会尝试用 gzip 解码明文导致乱码。解决若需修改压缩内容先解压if (session.oResponse.headers[Content-Encoding]?.Contains(gzip) true) { using var gzip new GZipStream(new MemoryStream(session.oResponse.body), CompressionMode.Decompress); using var ms new MemoryStream(); gzip.CopyTo(ms); var plainBody ms.ToArray(); // 修改 plainBody... session.oResponse.body plainBody; session.oResponse.headers.Remove(Content-Encoding); session.oResponse.headers[Content-Length] session.oResponse.body.Length.ToString(); }若无需解压直接修改Content-Length即可。4.5 现象服务运行数小时后 CPU 持续 100%dotnet-dump显示大量Session对象堆积在FiddlerCore.SessionQueue原因AfterSessionComplete事件中执行了同步 IO如直接写 SQL Server、调用 HTTP API导致事件队列堵塞。FiddlerCore 内部使用单线程处理事件一个慢回调会拖垮全部 Session 处理。解决所有耗时操作必须异步化FiddlerApplication.AfterSessionComplete async session { await _logRepository.InsertAsync(new LogRecord(session)); // EF Core 5 支持 // 或投递到后台队列 _backgroundQueue.Enqueue(session); };启用 FiddlerCore 的会话池限制FiddlerApplication.Prefs.SetIntPref(fiddler.network.KeepAlive.MaxConcurrentSessions, 500);5. 进阶技巧用FiddlerCore实现零侵入的微服务链路追踪埋点在某公司微服务治理项目中我们面临一个典型难题不想改每个服务的 SDK又需要采集所有出站 HTTP 请求的完整链路信息trace_id、span_id、上游服务名、下游 URL、耗时、状态码。FiddlerCore 成了最轻量的“旁路探针”——它不修改业务代码只作为 Windows 服务运行劫持所有HttpClient发出的流量。关键在于利用BeforeRequest注入 trace header并在AfterSessionComplete中上报 span同时确保 trace 上下文在重定向、重试中不丢失。5.1 Trace Header 注入兼容 OpenTelemetry 规范我们选择注入traceparentW3C 标准和tracestate而非自定义 header确保与现有 APM 系统如 Jaeger、Zipkin兼容FiddlerApplication.BeforeRequest session { // 从当前线程获取 trace 上下文需业务层注入如 ASP.NET Core 的 Activity.Current var activity Activity.Current; if (activity ! null activity.Id ! null) { // 构造 traceparent: 00-{traceid}-{spanid}-{flags} var traceId activity.TraceId.ToHexString().PadLeft(32, 0); var spanId activity.SpanId.ToHexString().PadLeft(16, 0); var flags activity.Recorded ? 01 : 00; session.oRequest.headers[traceparent] $00-{traceId}-{spanId}-{flags}; // tracestate 可选传递 vendor-specific 信息 if (!string.IsNullOrEmpty(activity.GetTagItem(tracestate))) { session.oRequest.headers[tracestate] activity.GetTagItem(tracestate); } } else { // 无上下文时生成新 trace边缘服务入口 var newTraceId Guid.NewGuid().ToString(N).Substring(0, 32); var newSpanId Guid.NewGuid().ToString(N).Substring(0, 16); session.oRequest.headers[traceparent] $00-{newTraceId}-{newSpanId}-01; } };5.2 Span 上报异步批处理 本地缓存兜底AfterSessionComplete中不直接调用远程 API而是写入内存队列由后台任务批量上报private readonly ConcurrentQueueSpanData _spanQueue new(); private readonly Timer _flushTimer; public TracingProxy() { _flushTimer new Timer(_ FlushSpans(), null, TimeSpan.FromSeconds(5), TimeSpan.FromSeconds(5)); } private void FlushSpans() { var batch new ListSpanData(); while (_spanQueue.TryDequeue(out var span) batch.Count 100) { batch.Add(span); } if (batch.Count 0) { _ Task.Run(() UploadBatchAsync(batch)); // 真实上报逻辑 } } FiddlerApplication.AfterSessionComplete session { var span new SpanData { TraceId ExtractTraceId(session), SpanId Guid.NewGuid().ToString(N).Substring(0, 16), ParentSpanId ExtractParentSpanId(session), Name ${session.method} {session.hostname}{session.PathAndQuery}, StartTimestamp DateTimeOffset.FromUnixTimeMilliseconds(session.oRequest.startedDateTime.ToUniversalTime().Ticks / 10000), EndTimestamp DateTimeOffset.FromUnixTimeMilliseconds(session.oResponse?.endedDateTime.ToUniversalTime().Ticks / 10000 ?? 0), Status session.responseCode 400 ? ERROR : OK, Attributes new Dictionarystring, string { [http.method] session.method, [http.url] session.fullUrl, [http.status_code] session.responseCode.ToString(), [network.peer.address] session.serverIP } }; _spanQueue.Enqueue(span); };5.3 重定向链路保活从Location头还原原始 trace 上下文HTTP 重定向301/302会导致BeforeRequest为新 URL 触发但原始traceparent可能丢失。我们通过解析Location头将父 span ID 注入新请求FiddlerApplication.BeforeResponse session { if (session.responseCode is 301 or 302 or 307 or 308) { var location session.oResponse.headers[Location]; if (!string.IsNullOrEmpty(location) Uri.IsWellFormedUriString(location, UriKind.Absolute)) { // 缓存原始 traceparent供下次 BeforeRequest 使用 var originalTraceParent session.oRequest.headers[traceparent]; if (!string.IsNullOrEmpty(originalTraceParent)) { // 存入线程本地存储或 ConcurrentDictionarysessionId, traceparent _redirectTraceMap[session.id] originalTraceParent; } } } }; FiddlerApplication.BeforeRequest session { if (_redirectTraceMap.TryGetValue(session.id, out var traceParent)) { session.oRequest.headers[traceparent] traceParent; _redirectTraceMap.TryRemove(session.id, out _); } };从那以后我每次在 Windows 服务中集成 FiddlerCore都强制走一遍证书信任检查CertMaker.rootCert ! null CertMaker.isRootCertTrusted()、端口冲突扫描netstatGetAvailablePort、以及事件回调的异步化审查所有await和Task.Run标记。这三步做完90% 的线上故障都能在启动时暴露。希望帮到你。本文还有配套的精品资源点击获取