Fiddler如何只捕获特定Android/iOS App的HTTP/HTTPS流量？

Question

**常见技术问题：** 在使用Fiddler抓取移动App流量时，常遇到“所有设备流量混杂、难以区分目标App请求”的问题——Fiddler默认捕获本机代理转发的所有HTTP/HTTPS请求，而Android/iOS系统级代理会将整个设备的网络流量（包括系统服务、其他App、后台更新等）一并转发至Fiddler，导致日志爆炸式增长、关键接口难以定位。尤其当App采用OkHttp（Android）、NSURLSession（iOS）或自签名证书校验、非标准端口、Websocket/QUIC等协议时，还可能因证书信任失败或协议不兼容导致流量缺失。开发者亟需一种轻量、可靠、无需Root/Jailbreak的方式，精准过滤出**仅属于某一个指定包名（如com.example.myapp）或Bundle ID（如com.example.MyApp）的HTTP/HTTPS请求**，同时兼顾HTTPS解密有效性与抓包稳定性。如何在Fiddler中实现基于进程/应用标识的流量筛选，而非依赖URL关键词或IP粗粒度过滤？

Answer 1

```html

一、问题本质剖析：为什么Fiddler无法原生识别App进程标识？

Fiddler作为基于HTTP(S)代理的调试工具，工作在OSI模型第7层（应用层），其核心机制是拦截TCP连接并解析HTTP协议头。它不感知操作系统进程上下文——既无权限读取Android的UID/PID映射、也无法访问iOS的sandboxed process info。系统级代理（如Android WiFi代理设置或iOS手动代理）将所有出站流量统一转发至Fiddler监听端口（默认8888），导致Fiddler收到的请求仅含标准HTTP字段（Host、User-Agent、Referer等），缺失包名（Android）、Bundle ID（iOS）、进程名、UID等关键OS级元数据。这是根本性架构限制，非配置缺陷。

二、技术瓶颈分层诊断

• 协议层阻断：OkHttp默认启用证书固定（Certificate Pinning），NSURLSession支持ATS（App Transport Security），绕过Fiddler根证书；QUIC/WebSocket over TLS 1.3因加密握手不可见，Fiddler无法解密
• 系统层隔离：Android 7+强制应用级网络安全性配置（android:networkSecurityConfig），禁止明文HTTP；iOS 15+限制后台App代理行为
• 工具链盲区：Fiddler Classic（v5.x）无进程注入能力；Fiddler Everywhere不支持自定义TLS解密钩子；两者均无SDK集成接口供App主动上报标识

三、可行方案对比矩阵

方案	是否需Root/Jailbreak	是否支持HTTPS解密	能否精准过滤包名/Bundle ID	稳定性	适用场景
① Fiddler + Android App主动埋点（OkHttp Interceptor）	否	是（需禁用Pinning）	✅ 完全可控	★★★★☆	开发/测试环境，可修改源码
② Fiddler + iOS URL Scheme + 自定义HTTP Header透传	否	是（需ATS豁免）	✅ Bundle ID可编码进Header	★★★☆☆	iOS企业签名App
③ Fiddler + 系统级流量标记（Android TrafficStats + ProxyChains）	是（需adb root）	部分（需配合mitmproxy）	⚠️ UID级近似，非精确包名	★★☆☆☆	高级调试，Root设备

四、推荐实践：Fiddler与App协同过滤（零Root方案）

以Android OkHttp为例，通过Interceptor注入唯一标识头，再在Fiddler中编写Custom Rule实现动态过滤：

// Android端：OkHttpClient构建时添加标识Interceptor
val client = OkHttpClient.Builder()
    .addInterceptor { chain ->
        val request = chain.request().newBuilder()
            .header("X-App-Identifier", "com.example.myapp") // 关键！透传包名
            .header("X-App-Version", BuildConfig.VERSION_NAME)
            .build()
        chain.proceed(request)
    }
    .build()

五、Fiddler规则定制：基于Header的精准过滤

在Fiddler中启用Rules → Customize Rules...，修改OnBeforeRequest函数：

static function OnBeforeRequest(oSession: Session) {
    // 只保留指定包名的请求，忽略其他所有流量
    if (oSession.oRequest.headers.Exists("X-App-Identifier")) {
        var appId = oSession.oRequest.headers["X-App-Identifier"];
        if (appId != "com.example.myapp") {
            oSession["ui-hide"] = "true"; // 隐藏非目标请求
        }
    } else {
        // 无标识头的请求（如系统服务、WebView预加载）一律隐藏
        oSession["ui-hide"] = "true";
    }
}

六、HTTPS解密增强保障措施

1. 在Android res/xml/network_security_config.xml 中显式信任Fiddler证书：
   <domain-config><domain includeSubdomains="true">example.com</domain><trust-anchors><certificates src="@raw/fiddler_root"/></trust-anchors></domain-config>
2. iOS中，在Info.plist添加：
   <key>NSAppTransportSecurity</key><dict><key>NSAllowsArbitraryLoads</key><true/></dict>（仅限测试）
3. Fiddler中启用：Tools → Options → HTTPS → Decrypt HTTPS traffic + Ignore server certificate errors

七、自动化流程图（Mermaid）

graph LR
A[Android App启动] --> B[OkHttp注入X-App-Identifier Header]
B --> C[请求经WiFi代理发往Fiddler]
C --> D{Fiddler OnBeforeRequest}
D -->|Header存在且匹配| E[显示请求日志]
D -->|Header不匹配或不存在| F[ui-hide=true]
E --> G[开发者聚焦分析]
F --> H[日志界面自动过滤]

八、进阶技巧：Bundle ID动态提取（iOS）

iOS可通过[[NSBundle mainBundle] bundleIdentifier]获取Bundle ID，并在所有NSURLSessionTask创建前，向request header注入：
[mutableRequest setValue:[[NSBundle mainBundle] bundleIdentifier] forKey:@"X-Bundle-ID"];。Fiddler规则同步改为检查X-Bundle-ID字段，实现跨平台统一过滤逻辑。

九、避坑指南：高频失效场景及修复

• WebView内嵌H5流量丢失：需在WebSettings.setDomStorageEnabled(true)后，额外调用setDatabaseEnabled(true)确保Cookie同步
• OkHttp 4.x+ CertificatePinner绕过失败：必须使用CertificatePinner.Builder().add("*", "sha256/...")白名单方式，而非全局disable
• Fiddler内存溢出：启用File → Capture Options → Limit to 10MB of captured data，避免日志堆积

十、演进方向：从Fiddler到可观测性平台

随着微服务与混合架构普及，单一抓包工具已难满足需求。建议将此方案作为可观测性链路起点：
→ 将X-App-Identifier作为OpenTelemetry trace context传播字段
→ Fiddler导出的Saz文件经脚本解析为JSON，接入ELK或Grafana Loki
→ 构建“App维度HTTP SLA看板”，实现QPS、P95延迟、错误率按包名聚合分析

```