Android App 网络栈测试怎么做？接入代理后异常定位

先记录异常和请求标识，再确认应用使用的网络栈及系统网络配置，最后逐阶段做直连与测试网络对照。异常类型提供排查线索，不能单独证明根因；本文只讨论自有或明确授权的 App。

先从异常信息判断请求卡在哪一步

App 无法连接时，可先按 DNS 解析、传输连接、TLS 握手和 HTTP 响应梳理证据。异常名称和状态码有助于缩小范围，但还需核对请求是否发出、响应来自哪一端，以及应用是否使用自建网络栈。

示例：App 抛出 SSLHandshakeException，而浏览器访问同一地址正常。此时可继续比较两者的信任配置、证书链和网络栈；单凭这一现象还不能确定是代理还是服务器证书问题。需要进一步理解握手或超时错误时，可参考连接超时与 TLS 错误排查。

先确认 407 或 403 是哪一端返回的

407 通常表示代理认证要求，但仍应结合响应头和请求路径确认响应来源；403 可能来自源站、中间层或代理策略。响应头可提供线索，最好同时关联请求标识和服务端日志。

确认 App 是否读取了系统代理设置

Android 系统代理是否被应用使用，取决于应用采用的网络栈及其配置。使用自建网络库的 App 可能不读取系统代理，因此测试时应在授权构建中确认实际请求路径，并记录网络库、系统版本和配置。

用应用、代理和服务端记录确认请求路径

抓包可帮助确认请求路径，但可见性受抓包位置、传输协议和设备权限影响。没有抓到流量不能单独证明请求未经过代理；应结合应用日志、代理侧记录和服务端请求标识交叉确认。

证据链可结合 App 请求标识与发起时间、代理侧连接记录（如源地址和目标域名）及服务端 Trace ID 与结果。记录采集点、时间窗、目标和每类记录的可见范围。HTTPS 隧道中的代理侧未必能读取 HTTP 请求 ID，不要求三端共享同一 Trace ID；可用受控时间、连接元数据、测试标识及相关 ID 映射关联。证据不足时标为“未确认”。抓包位置决定能看到哪一层——设备侧看应用出口，代理侧看转发，服务端看入口；TLS 之下看不到路径与参数属正常，不能据此判定请求未发出。

测试范围限定在自有或授权 App

本文限定在自有或明确授权的 Android App 测试构建。重点是核对应用网络栈、系统网络配置、证书校验和请求阶段，不涉及第三方 App 接入教程。需要确认设备侧代理设置时，可参考Android 手机代理设置说明；该说明只覆盖系统设置，App 是否读取系统代理仍要在测试构建中验证。

按请求路径逐层定位

1. 抄下完整异常类名与消息。产出：一行异常。
2. 用系统浏览器打开同一地址做对比。产出：浏览器是否正常。
3. 直连与经代理各跑一次，比对结果。产出：两条结果。
4. 记录抓包采集点、时间窗、目标和可见性限制；将抓包作为路径可见性证据，再结合 App 与服务端记录判断。无流量只表示该采集点未观察到数据，不等于请求未发出。产出：注明限制的采集记录。
5. 按层级一次只改一个变量（同时改系统代理和网络库配置就失去了归因），重跑第 3 步。产出：改动前后的参照。

FAQ

只有 App 报错、浏览器正常，下一步该查什么？

先比较错误阶段、目标域名与协议、App 和浏览器的实际请求路径、系统与网络库版本及服务端记录。只有证据指向 TLS 握手时，再核对 CA、主机名、证书固定和信任差异。普通 HTTPS 隧道不会自动替换源站 CA 或 TLS 身份材料；不要先改信任配置或关闭校验来换取成功。确需实验时，只在授权调试构建中使用明确的测试信任配置，并一次只改一个变量。

抓包看不到请求，能说明请求没发出吗？

不能。抓包位置、传输协议或设备权限都可能影响可见性，需再查应用日志或服务端请求记录。

407 和 403 应分别核对什么？

确认响应来源后再处理：407 通常检查代理认证，可参考407 认证失败排查；403 则根据源站或中间层记录判断拒绝原因。

能用在第三方 App 上复现吗？

不建议。本文方法只适用于自有或明确授权的测试构建，第三方 App 的网络栈和代理行为无法由测试方控制。