PAYATHON 2026

React Native Android 发布包登录报 Network Error 如何排查？

数据小陈

结论

优先检查发布包实际使用的 android:networkSecurityConfig 和设备端的网络异常。现有材料提示自定义网络安全配置可能与故障有关，但还无法确定是哪条配置导致失败，也不能据此认定 Firebase 分发本身有问题。

err.response === undefined 表示 axios 没有取得可用的 HTTP 响应对象。仅凭这一点，不能断定故障发生在服务器收到请求之前，也无法区分 DNS、TCP、TLS、超时或其他底层异常。

如果请求来自 React Native Android 原生网络栈，通常无需按浏览器 CORS 机制排查；如果请求来自 WebView 中的网页，则需要另行判断。

为什么电脑能访问，Android 仍然失败？

浏览器、Postman、curl 或 Invoke-WebRequest 在电脑上访问成功，只能说明目标地址在该电脑环境下可用。Android 设备使用的 DNS、网络路径、代理和证书信任配置可能不同，发布包还受自身 manifest 和网络安全配置的约束。

排查时应确认两端请求是否一致，包括最终 URL、端口、请求方法和重定向后的目标。电脑打开地址成功，并不能证明设备上的登录请求经过了相同路径。

先获取设备端的底层错误

保留 axios 错误中的诊断字段，避免只记录 Network Error：

import axios from 'axios';

function logRequestError(error) {
  if (axios.isAxiosError(error)) {
    console.warn('Request failed', {
      message: error.message,
      code: error.code,
      status: error.response?.status,
      hasResponse: error.response !== undefined,
    });
    return;
  }

  console.warn('Unexpected request error');
}

在现有请求的 catch 中调用该函数。不要记录登录密码、Token、完整请求头或请求体。

连接设备并打开日志，然后复现发布包中的登录失败：

adb logcat

结合复现时间和应用进程查找相关异常。常见线索包括：

日志线索优先检查
UnknownHostExceptionAPI 域名、设备 DNS 和网络可达性
ConnectException主机、端口、服务监听和网络连接
SSLHandshakeException 或证书相关异常证书链、主机名、设备时间和信任配置
CLEARTEXT communication ... not permitted请求或重定向是否使用 HTTP
超时相关异常网络路径、代理、服务处理时间和超时设置

具体异常文本可能随运行环境变化。没有这些日志时，不宜直接断定是证书故障。

验证自定义网络安全配置是否相关

检查 release 构建合并后的 manifest，确认 android:networkSecurityConfig 最终引用了哪个 XML，以及 release 专用资源或构建变体是否覆盖了配置。只查看开发目录中的某一个文件，可能遗漏实际打包结果。

重点检查以下内容：

  • domain-config 中的域名是否覆盖 API 主机及实际重定向目标。
  • trust-anchors 是否改变了预期的证书信任来源。
  • 如果存在证书固定配置，其证书或公钥是否仍与服务端匹配。
  • 开发主机使用的配置是否进入了 release 构建。

base-config、domain-config 和 cleartextTrafficPermitted 同时存在，并不代表 XML 配置有误。需要结合具体取值、继承关系和设备日志判断。

如果 API 使用平台默认信任的 HTTPS 证书，且应用没有必须保留的自定义信任要求，可以在测试构建中暂时移除 android:networkSecurityConfig 引用，重新构建并安装，再使用同一设备、同一网络和同一请求复测。

如果请求恢复，说明自定义配置与故障有关，但仍需逐项恢复配置，定位具体原因。如果没有恢复，则继续根据底层异常检查 DNS、连接和 TLS。原始材料没有提供完整 XML 或设备日志，无法指出应删除的具体规则。

HTTPS 故障不要直接用开放明文流量解决

cleartextTrafficPermitted 和 android:usesCleartextTraffic 涉及明文 HTTP 策略，不能修复 HTTPS 证书不受信任、主机名不匹配或证书链缺失。

只有日志表明请求使用了 HTTP，或 HTTPS 请求被重定向到 HTTP 时，明文策略才是直接相关的检查项。还应先确认发布环境是否本就应该使用 HTTPS。

Metro 开发连接与生产 API 的访问需求不同。debug 构建中为 Metro 设置的明文访问规则，不能作为 release API 配置正确的依据。也不要通过信任所有证书或关闭主机名校验来绕过 TLS 错误。

如何确认修复完成？

使用最终通过 Firebase 分发的 release 安装包复测 /auth/login，确认请求取得预期的 HTTP 响应，并检查设备日志中原有的异常是否消失。如果返回业务层 4xx/5xx，再按响应内容排查认证或接口问题。

发布前应保留应用确实需要的安全配置，并确认临时排查改动没有引入宽泛的明文访问或证书校验绕过。

备注：内容仅供参考。