移动 App 网络兼容测试：五个失败阶段定位法
同一个 App 构建，直连正常、换到某地区出口就失败，问题可能落在域名解析、连接建立、证书校验、鉴权或超时任一环。按阶段记录域名、信号和错误码，才能分清兼容缺陷与出口质量。
同一个 App 构建，直连时正常，换到某个地区的出口就失败，这种问题最容易被一句"网络差"带过去。实际上失败点可能落在五处：域名没解析出来、TCP 连接没建立、TLS 握手被拒、鉴权请求被拦、或者响应超时。
对自有或明确授权的 App，先固定构建与设备，再列出实际请求域名。代理出口用于控制请求发起地区，不会替代真实用户网络或服务端数据。
先把 App 请求的域名列全
列出首屏接口、图片 CDN 和第三方 SDK 等实际请求域名，并标明哪些影响核心功能、哪些可以降级。这样可避免主接口正常、某个 SDK 不可达却被误判为整条链路正常。
以域名清单作为测试范围，逐项记录请求阶段和结果。
按请求阶段记录失败
请求阶段不同，检查方式也不同：
| 阶段 | 可观测信号 | 记录方式 |
|---|---|---|
| 域名解析 | NXDOMAIN、解析超时、返回地址与预期不符等 | 记录错误码、解析器、返回地址与耗时；内网地址也可能是合法配置 |
| TCP 连接 | SYN 无响应、建连超时 | 记录目标端口与建连耗时，区分本地到代理、代理到目标及服务端监听/路由 |
| TLS 握手 | 证书校验失败、握手重置或超时 | 记录证书链、服务身份、系统时间与握手日志；单一信号不定根因 |
| 鉴权/拒绝 | 返回 401 或 403 | 识别响应来自目标站、WAF 还是中间层，并记录错误码与响应特征 |
| 超时 | 解析、建连、TLS 或传输阶段超时 | 记录失败阶段与耗时分布；重复结果用于确认现象，不单独证明根因 |
单一信号可能对应多种原因。例如解析失败可能来自解析策略或目标站可达性；TLS 失败可能与客户端校验或链路有关。先记录信号，再结合对照组定位。
记录请求停在哪个阶段，以及错误码和耗时。再用相同构建与请求条件比较直连和地区出口；差异只说明相关性，仍需结合服务端或供应商证据。
对照直连与地区出口
对照时固定构建、设备、系统、语言、账号和请求参数，只改变出口。重复运行以观察结果是否稳定，并记录执行时段。
记录时间戳、出口地区和实际检测结果。先确认直连基线稳定；否则加入地区出口后难以区分问题来源。
判断出口相关性与待查项
多次结果可帮助判断现象是否稳定，但单一出口失败只能说明与该出口条件相关。要判断责任层，还需补同地区其他出口、不同时间和服务端证据。
TLS 失败可能涉及证书链、系统时间、目标站策略或中间链路；多个出口结果随机波动也不能单凭现象确定为网络质量问题。应保留证据继续核对。
工单写清已验证的条件、失败阶段和仍缺的证据；证据不足时标为“待确认”，再决定由客户端、服务端或网络人员继续排查。
记录时可用简表列出请求域名、失败阶段、直连与地区出口的实际结果、错误码/耗时及仍缺的证据。示例域名和结果不代表真实测试数据。
常见问题
Android 和 iOS 的网络栈差异会影响结论吗？
会。两端的解析、连接复用和证书校验实现可能不同，应分别执行相同用例。
DNS 解析失败和连接超时怎么区分？
DNS 失败要核对错误码、解析器和策略；TCP 超时还要区分本地到代理、代理到目标及服务端监听/路由。TLS 失败需核证书链、服务身份、系统时间与握手日志；401/403 要识别由目标、WAF 还是中间层返回。每种现象都记录阶段和证据，不仅凭单一信号归因。
启用了证书固定（pinning），还能测试吗？
能做，但要看固定的是哪一层。只固定叶子证书的实现，换出口后证书不变，通常仍能建立连接；固定中间证书或整条链的实现，遇到地区链路上的中间设备改写就容易失败，这本身也是要记录的现象。这里不提供绕过证书校验的方法，测试应在授权的调试构建上进行。
只在某个地区连不上，一定是代理 IP 的问题吗？
单一出口失败不能直接说明是代理问题或 App 缺陷。结合失败阶段，补同地区多出口、供应商、时段、直连与服务端证据；DNS、TLS、401/403 和超时都应先核实具体响应来源与路径，再决定是否换出口复测。