NetShare 如何绕过运营商的热点封锁
运营商限制的技术本质
大部分人对运营商热点限制的理解是"一个开关，交钱就开"。实际上背后的机制比这复杂得多，而且是多层叠加的：
第一层：SIM 卡配置（被动限制）
SIM 卡里携带了一个叫 Carrier Config 的数据文件，由运营商通过 OTA 更新推送到手机。这个文件里包含了上百个布尔开关，其中和热点相关的关键项：
tether_ap_required_authorization：是否需要授权才能开启系统热点tether_ap_disallowed：是否直接禁用热点功能require_entitlement_check：是否在开启热点时触发 entitlement 校验（向运营商后端确认套餐是否包含 tethering）
手机尝试开启系统热点时，WifiService 会先查这几个开关。如果是禁用状态，UI 层直接弹"不支持"提示，底层 API 调用被静默拒绝。
第二层：隐藏 API（主动阻断）
即使应用通过反射绕过了第一层检查，Android 12（API 31）引入的 AppOps 白名单机制也会把它挡在门外。原生热点相关的 API 被标记为 @hide，并且只有系统签名应用或在白名单内的应用才能调用。第三方应用反射调用时会收到 IllegalStateException。
第三层：流量检测（事后识别）
有些运营商还会在网络侧分析流量特征：
- Tethering 流量的包大小、TCP 窗口大小、TTL 值与手机正常流量有细微差异（PC 的 TCP 栈和手机的不同）
- 某些运营商会通过 DNS 查询特征、TLS 指纹识别等手段侧信道检测
这一层是最难绕过的，因为它不依赖手机侧的任何 API，而是在网络出口处直接识别流量模式。
NetShare 如何应对这三层封锁
| 封锁层 | NetShare 的应对 |
|---|---|
| SIM 卡 Carrier Config | 不触发。NetShare 不调用任何 tethering 相关 API，SIM 配置里的开关对它没有意义 |
| 隐藏 API / AppOps 白名单 | 不依赖。使用公开的 WifiP2pManager.createGroup()，从设计上就不需要绕过隐藏 API |
| 网络侧流量检测 | 有一定作用但不保证。NetShare 的 HTTP 代理会把连接设备的流量转发出去，运营商看到的流量特征和手机自身发出的流量类似（同样的 IP 出口、类似的 TCP 行为），但专业检测可能仍然能区分 |
为什么 NetShare "不被检测"
严格来说，NetShare 无法保证运营商永远检测不到。但它做到了以下几点：
- 不触碰系统热点通道：从根本上避开了 SIM 配置和 AppOps 的双重控制
- WiFi Direct 不属于 tethering API：Android 系统不会把它记为一次 tethering 会话
- 代理转发流量的源 IP 是手机：运营商看到的都是手机发出的请求，而不是来自外部设备的请求
Google Play 上有超过 1300 万次下载、5.1 万条评价的应用说明它在大部分运营商网络环境下是有效的。但网络侧检测是运营商单方面的行为，如果某个运营商非常激进，任何第三方热点方案（包括 NetShare）都无法保证 100% 不可检测。
合规提示
本站内容仅用于技术原理说明和个人学习。网络连接的使用应遵循你所在地区的法律法规和运营商的服务协议。使用第三方网络分享工具可能违反部分运营商的条款，请自行判断风险。