Android网络安全配置实战：2024年如何安全允许明文HTTP通信

1. 项目背景与核心诉求：为什么我们还在讨论明文HTTP？

在2024年的今天，当HTTPS已经成为移动应用开发的默认标准，甚至各大应用商店和操作系统都将其作为强制要求时，我们却要专门来讨论“允许明文HTTP通信”这个话题，这听起来似乎有些不合时宜，甚至像是在开倒车。但作为一名在Android开发一线摸爬滚打了十多年的老兵，我必须告诉你，现实情况远比想象中复杂。这个需求并非源于对安全性的漠视，而是源于大量存量系统、特殊开发场景以及特定行业环境的真实困境。

想象一下这样的场景：你接手维护一个为工厂车间开发的内部设备管理App，它需要与一台十几年前部署的、固件早已停止更新的老式PLC（可编程逻辑控制器）通信，这台设备只支持HTTP协议。或者，你正在开发一个用于本地网络调试的工具，需要快速嗅探和分析局域网内其他设备发出的HTTP流量。又或者，你的应用需要接入一个由第三方提供的、暂时还未升级HTTPS的测试环境API。在这些情况下，生硬地要求“必须使用HTTPS”只会让项目停滞不前。

Android系统为了推动全网HTTPS化，从Android 9（API级别28）开始，就默认禁止了应用使用明文HTTP流量。这意味着，如果你的targetSdkVersion设置为28或更高，应用将无法向非HTTPS的端点发起网络请求，除非你显式地进行配置。这就是android:usesCleartextTraffic属性和网络安全配置（Network Security Configuration）文件登场的原因。它们不是用来鼓励使用HTTP，而是为那些不得不使用HTTP的“例外情况”提供一条合规、可控的通道。本次讨论的核心，就是如何在2024年的开发环境下，安全、正确地为你的Android应用配置这条通道，而不是简单粗暴地“一开了之”。

2. 网络安全配置基础：从android:usesCleartextTraffic到NSC

在早期，允许HTTP通信非常简单，只需要在AndroidManifest.xml文件的<application>标签中添加一行配置即可：

<application ... android:usesCleartextTraffic="true"> ... </application>

这行代码的作用是全局性的：它告诉Android系统，“我这个应用需要访问明文HTTP流量，请放行”。在Android 6.0到8.1的时代，这几乎是处理内部HTTP请求的标准做法。然而，这种粗放式的配置带来了显著的安全风险。一旦开启，应用内所有组件（WebView、HttpURLConnection、OkHttp等）对所有域名的HTTP请求都将被允许，这无疑大大增加了应用遭受中间人攻击（Man-in-the-Middle Attack）的风险。

因此，从Android 9开始，Google引入了更精细化的管理工具——网络安全配置（Network Security Configuration， 简称NSC）。NSC允许开发者通过一个XML配置文件，以声明式的方法定义应用的网络安全策略。它的核心思想是“最小权限原则”和“域隔离”：

1. 最小权限：只允许必要的域名或IP地址使用明文HTTP，而不是全局放开。
2. 域隔离：可以为不同的域名设置不同的安全策略。例如，允许http://internal.company.com使用HTTP，但强制https://api.public.com必须使用HTTPS并校验证书。

当targetSdkVersion>= 28时，即使你在AndroidManifest.xml中设置了android:usesCleartextTraffic="true”，系统也会忽略此属性，转而强制要求使用NSC文件来定义明文流量规则。如果你没有配置NSC，那么所有的HTTP请求都将失败，并可能抛出Cleartext traffic not permitted异常。这是很多开发者在升级Target SDK后遇到的第一个坑。

所以，在2024年，正确的姿势是：彻底放弃android:usesCleartextTraffic="true”，全面拥抱网络安全配置（NSC）文件。即使你的应用暂时不需要HTTPS，也应该通过NSC来明确声明你的HTTP访问范围，这既是遵循最佳实践，也是为应用未来的安全升级打下基础。

3. 实战配置：创建与应用网络安全配置文件

接下来，我们一步步地实现一个典型场景的配置：允许应用访问特定的内部HTTP服务，同时保持对其他所有流量的HTTPS要求。

3.1 创建网络安全配置文件

首先，在你的Android项目res目录下，新建一个xml文件夹（如果不存在的话），然后在该文件夹内创建一个名为network_security_config.xml的文件。这个文件名是自定义的，但这是通用的命名约定。

文件内容如下：

<?xml version="1.0" encoding="utf-8"?> <network-security-config> <!-- 基础配置：默认情况下，信任系统预装的CA证书，并强制使用HTTPS --> <base-config cleartextTrafficPermitted="false"> <trust-anchors> <certificates src="system" /> </trust-anchors> </base-config> <!-- 针对特定域名的配置：这里我们定义了一个“调试域” --> <domain-config cleartextTrafficPermitted="true"> <!-- 允许使用明文HTTP的域名，支持通配符* --> <domain includeSubdomains="true">192.168.1.100</domain> <domain includeSubdomains="true">internal.test.com</domain> <!-- 注意：localhost和127.0.0.1在Android模拟器或设备本地有特殊处理，通常不需要在此配置也能访问 --> </domain-config> <!-- 另一个例子：为某个需要自定义证书的HTTPS域名配置 --> <domain-config> <domain includeSubdomains="true">secure.corp.com</domain> <trust-anchors> <certificates src="@raw/custom_ca_certificate" /> </trust-anchors> </domain-config> </network-security-config>

让我们拆解一下这个配置的关键部分：

• <base-config>：这是应用的默认网络安全配置。cleartextTrafficPermitted="false"表示默认禁止所有明文HTTP流量。<certificates src="system" />表示默认信任Android系统内置的证书颁发机构（CA），这是验证HTTPS证书有效性的基础。
• <domain-config cleartextTrafficPermitted="true">：这是一个域级别的覆盖配置。它为内部指定的一个或多个域名设置了不同的规则。cleartextTrafficPermitted="true"是关键，它明确允许列在此标签内的域名使用HTTP协议。includeSubdomains="true"表示此规则也适用于该域名的所有子域名（例如，配置了test.com，则api.test.com和www.test.com也适用）。
• 域名指定：我们允许了两个地址使用HTTP。一个是IP地址192.168.1.100，这在访问本地局域网设备时非常常见；另一个是域名internal.test.com。重要提示：配置IP地址时，直接写IP即可，不要加http://前缀。
• 关于本地地址：对于localhost、127.0.0.1或10.0.2.2（模拟器访问主机）这类环回地址，Android系统通常有豁免，即使在默认禁止明文的情况下，应用也可以访问。但为了策略清晰和兼容性，如果你遇到问题，也可以将它们显式添加到<domain-config>中。

3.2 在AndroidManifest中引用配置文件

创建好配置文件后，需要在AndroidManifest.xml中告诉应用使用它。在<application>标签内添加android:networkSecurityConfig属性进行关联：

<manifest ...> <application android:networkSecurityConfig="@xml/network_security_config" ...> ... </application> </manifest>

至此，配置工作就完成了。你的应用现在拥有了一个清晰的网络安全策略：默认情况下，所有对外请求必须使用HTTPS；但针对192.168.1.100和internal.test.com这两个特定的地址，允许使用HTTP进行通信。

3.3 验证配置是否生效

配置完成后，如何验证呢？最直接的方法是发起一个HTTP请求到你所配置的域名。你可以使用OkHttp或HttpURLConnection写一个简单的测试代码。如果配置正确，请求会成功；如果失败，通常会抛出异常，并在Logcat中看到相关的网络错误信息。

一个更系统的方法是检查应用在运行时加载的网络安全配置。你可以通过以下ADB命令来验证：

adb shell dumpsys package your.package.name | grep -A 50 “Network Security Config”

这个命令会输出你的应用当前生效的网络安全配置详情，你可以检查其中是否包含了你的<domain-config>规则。

4. 高级场景与深度避坑指南

基础的配置只能解决80%的问题，剩下的20%往往隐藏在各种边界情况和细节之中。下面分享几个我踩过坑的高级场景和对应的解决方案。

4.1 WebView中的明文HTTP访问

如果你的应用使用WebView来加载本地HTML或访问内部HTTP服务器，NSC配置同样适用，但需要注意一个关键点：WebView的兼容性行为。

在Android 9及以上版本，WebView默认遵守应用的全局网络安全配置。也就是说，如果你按照上述方法配置了NSC，WebView加载你允许的HTTP网址应该是没有问题的。

但是，存在一个历史遗留的“坑”：在Android 9（API 28）且WebView版本低于某个特定版本时，WebView可能会忽略NSC中针对localhost的配置。这通常发生在使用系统WebView且系统未更新的老旧设备上。虽然这种情况现在已不多见，但为了绝对可靠，特别是对于加载本地file://或http://localhost内容的Hybrid应用，我建议采取双重保障：

1. 在NSC中显式声明本地域（尽管可能不是必须的）：

   <domain-config cleartextTrafficPermitted="true"> <domain includeSubdomains="true">localhost</domain> </domain-config>

2. 在代码中为WebView设置WebViewClient并覆盖shouldOverrideUrlLoading，虽然这主要用于控制导航，但在某些极端情况下也能起到作用。更直接的是，确保你使用的第三方库或自定义的WebView都运行在主应用的进程上下文中，以继承NSC配置。

4.2 使用IP地址与域名混用的陷阱

在配置<domain>时，直接使用IP地址（如192.168.1.100）是允许的。但这里有一个非常重要的细节：DNS解析的结果与配置的匹配是字面匹配。

假设你的内部服务IP是192.168.1.100，但你的代码中请求的URL是http://api.internal/，并且api.internal通过本地DNS或/etc/hosts文件解析到了192.168.1.100。在这种情况下，网络请求会失败！因为NSC检查的是URL中的主机名（host），即api.internal，而不是最终解析的IP地址。你的配置允许的是主机名为192.168.1.100的请求，而不是解析到该IP的所有主机名。

解决方案：

• 方案A（推荐）：在代码中直接使用IP地址构造URL。这是最直接、最可靠的方式，http://192.168.1.100/api/data。
• 方案B：在NSC配置文件中，将所有可能用到的主机名（域名）都列出来。例如，同时添加<domain includeSubdomains="true">api.internal</domain>。
• 方案C：对于复杂的内部网络环境，可以考虑在应用启动时，通过代码动态修改网络安全配置，但这涉及反射和更复杂的逻辑，非必要不推荐。

4.3 第三方库与底层网络组件的兼容性

现代Android应用网络层大多使用OkHttp或Retrofit，它们都很好地遵循系统的网络安全策略。但如果你集成了某些使用原生代码（C/C++）或使用低级别Socket进行网络通信的第三方库（例如某些游戏引擎、音视频SDK或物联网SDK），情况可能会变得复杂。

这些库可能绕过Java层的网络栈，直接调用操作系统底层的BSD Socket接口。在这种情况下，标准的NSC配置可能无法生效，因为NSC的拦截点主要在Java网络库这一层。

排查与解决思路：

1. 查阅SDK文档：首先确认该SDK是否对Android 9+的明文HTTP限制有特殊说明。正规的SDK会提供配置指南。
2. 全局放行（最后的手段）：如果确认是底层库的问题，且该库只用于访问特定的安全内网环境，你可以考虑在NSC中配置一个非常宽松的<base-config>。这是一个安全风险很高的操作，务必谨慎评估！

   <network-security-config> <!-- 警告：此配置允许所有明文流量，仅用于测试或绝对可信的内部网络环境 --> <base-config cleartextTrafficPermitted="true"> <trust-anchors> <certificates src="system" /> </trust-anchors> </base-config> </network-security-config>

3. 隔离网络操作：如果可能，将必须使用HTTP的、与这类SDK交互的功能，封装到一个独立的进程或使用android:process属性隔离的应用组件中。然后只为这个进程配置较宽松的NSC，从而限制安全风险的影响范围。

4.4 调试构建与发布构建的差异化配置

在开发阶段，我们可能需要访问本地的HTTP调试服务器；而上线版本则必须严格禁止所有明文流量。手动修改配置文件很容易出错。最佳实践是利用Android构建系统（Gradle）的资源合并和变体（Build Variants）功能，为debug和release构建不同的NSC文件。

操作步骤：

1. 保持src/main/res/xml/network_security_config.xml作为release版本的配置，里面只包含必须的、安全的HTTP域名（如果有的话），或者完全禁止明文。
2. 在src/debug/res/xml/目录下创建同名的network_security_config.xml文件。Gradle在构建debug版本时，会优先使用debug目录下的这个文件，覆盖main中的配置。
3. 在debug版本的配置文件中，你可以放心地添加你的本地开发服务器地址（如<domain includeSubdomains="true">10.0.2.2</domain>用于模拟器访问主机）或其他测试环境域名。

这样，你就能在开发时畅通无阻，发布时自动收紧安全策略，避免因疏忽将调试配置带到生产环境的安全事故。

5. 安全红线：何时绝对不应该允许明文HTTP

尽管我们讨论了各种允许HTTP的“姿势”，但必须划清一条绝对的安全红线。作为一名负责任的开发者，你必须清楚，在以下场景中，允许明文HTTP是绝对不可接受的：

1. 传输用户个人敏感信息：包括但不限于密码、身份证号、银行卡号、生物特征信息、家庭住址、精确地理位置轨迹等。这些信息一旦在传输中被截获，将直接导致用户隐私泄露和财产损失。
2. 涉及身份认证的请求：例如登录、令牌（Token）刷新、会话保持等API。攻击者通过中间人攻击不仅可以窃取认证凭证，还可能直接冒充用户进行操作。
3. 面向公网的生产环境服务：任何部署在互联网上、可供公众访问的服务端接口，都必须使用HTTPS。这是现代互联网应用不可妥协的底线。Let‘s Encrypt等机构提供免费的SSL/TLS证书，成本已不再是借口。
4. 金融、支付、政务、医疗等强监管领域：这些行业有明确的法律法规和行业标准（如PCI DSS、HIPAA等）强制要求使用加密通信，违反规定不仅是不专业，更可能涉及法律风险。

允许HTTP通信，本质上是在网络传输层放弃了机密性和完整性保护。你应当始终将其视为一个临时的、局部的、风险可控的例外，而不是常态。在配置时，要反复问自己：这个HTTP端点是否在绝对可信的局域网内？传输的数据是否非敏感？是否有迫不得已的理由不能升级到HTTPS？并且，在项目文档和代码注释中明确记录这些例外配置的原因和范围，以便未来的维护者知晓其中的安全权衡。

6. 从明文HTTP到HTTPS的平滑迁移路线图

讨论“允许明文HTTP”的终极目的，是为了最终“消灭”它。对于任何长期项目，都应该制定一个向HTTPS全面迁移的路线图。以下是一个可行的迁移计划：

1. 评估与清单：梳理应用所有网络请求端点，区分出哪些是内部的、哪些是外部的，哪些已支持HTTPS，哪些仍在使用HTTP。使用NSC配置文件本身就是一个很好的清单工具。
2. 服务端升级：这是迁移的基础。推动后端团队或服务提供商为所有公网和内部重要服务部署SSL/TLS证书。内部服务可以使用私有CA签发的证书。
3. 客户端适配：
   • 证书信任：如果使用私有CA证书，需要在Android应用的NSC中配置<trust-anchors>来信任你的私有CA（将证书放在res/raw/目录下引用）。
   • 代码更新：将代码中的HTTP URL统一替换为HTTPS URL。建议使用配置中心或依赖注入来管理Base URL，避免硬编码。
4. 双轨运行与测试：在服务端支持双协议（HTTP/HTTPS）运行一段时间。在客户端，可以通过特性开关（Feature Flag）或构建变体，让部分用户或测试版本先切换到HTTPS，进行充分的功能和性能测试。
5. 收紧NSC策略：当所有重要端点都确认HTTPS工作正常后，开始逐步收紧客户端的NSC配置。首先，将<base-config>中的cleartextTrafficPermitted设为false。然后，逐个移除<domain-config>中允许HTTP的条目，每移除一个，都进行全面的回归测试。
6. 最终清理：当确认所有流量都通过HTTPS后，可以从代码库中删除所有用于允许HTTP的NSC配置条目，并移除相关的特性开关和兼容代码。在AndroidManifest.xml中，android:networkSecurityConfig属性可以指向一个只包含严格HTTPS策略的配置文件，或者对于纯HTTPS应用，甚至可以不指定该属性，直接使用系统默认的严格策略。

迁移过程中，完善的监控和日志至关重要。你需要监控网络请求失败率、错误类型，确保在切换过程中能快速发现问题并回滚。这个过程可能漫长，但每一步都让应用变得更加安全、健壮。