Feature Request: 增强模式增加手动选择代理协议(HTTPS / SOCKS5)
虽然分析是AI分析的.但是功能是需要的.
虽然分析是AI分析的.但是功能是需要的.
虽然分析是AI分析的.但是功能是需要的.
背景
当前 Reqable 增强模式中,代理协议(SOCKS5 / HTTPS CONNECT)由系统自动选择,用户无法干预。经在多台设备上系统测试,发现不同设备/ROM 对同一协议表现差异巨大,自动选择策略无法覆盖所有场景。
测试环境
|
设备 A |
设备 B |
| 机型 |
vivo V2245A(模拟器) |
小米 8 真机 |
| 系统 |
AOSP Android 12 |
MIUI 12.5.2(Android 10) |
| Root |
是 |
是 |
| Reqable |
最新版 |
最新版 |
| 连接方式 |
WiFi 局域网 |
WiFi 局域网 |
测试结论
增强模式表现差异
| 测试项 |
模拟器(AOSP) |
小米 8(MIUI 12.5.2) |
| 增强模式 |
✅ 正常 |
❌ 失败 |
| 透明 VPN 解密(h2 GET/POST) |
✅ 正常 |
❌ 不可达 |
| 显式 CONNECT 代理 |
— |
❌ 有请求无响应 |
| HTTPS 代理模式(关增强) |
✅ 正常 |
✅ 正常 |
| SSL 证书 Pinning |
❌ 无(可正常解密) |
❌ 无 |
根因定位
经过逐层排查(禁用 MIUI 安全组件、SELinux Permissive、抓包对比),最终确认问题在 MIUI 12.5.2 内核 TUN 驱动的 TCP 回程路径丢包:
模拟器:App → VPN TUN → Reqable → 目标服务器 → TUN 回程 → App ✅
小米 8:App → VPN TUN → Reqable → 目标服务器 → TUN 回程 → ❌ 丢弃
证据:
- 同一 Reqable 实例,两种设备表现截然不同 → 排除 Reqable 问题
- 禁用了
com.miui.vpnsdkmanager、com.miui.securitycore、com.miui.powerkeeper、com.miui.guardprovider,SELinux 设为 Permissive → 无效 → 排除 MIUI 用户层组件
- 唯一变量是内核 → 问题在 MIUI 定制内核的 TUN 驱动
为什么需要手动选择代理协议
虽然本次 MIUI TUN 的问题是内核层面的(切换代理协议也无法解决),但在以下场景中手动选择协议是必要的:
- 部分 ROM 对 SOCKS5 有兼容性问题(如 MIUI 12.5 内核),但 HTTPS CONNECT 在增强模式 VPN 路径上可能表现不同
- 部分企业网络/防火墙拦截 SOCKS5 流量,只放行标准 HTTPS
- 调试场景:排查问题时需要逐一排除变量,目前无法控制这一变量
- 性能调优:SOCKS5 二进制协议比 HTTP CONNECT 文本协议效率更高,但某些网络环境下 HTTPS 更稳定
建议方案
核心诉求:解耦「流量拦截方式」与「代理协议」
当前:
增强模式 ON → VPN TUN + 自动选择协议
增强模式 OFF → WiFi 系统代理 + HTTPS
建议:
增强模式 ON/OFF(控制流量拦截方式)
└── 代理协议:● HTTPS CONNECT ● SOCKS5 ● 自动(默认)
设置项建议
在 Reqable 设置中增加:
代理协议:
● 自动(默认,根据设备和网络环境自动选择)
● HTTPS CONNECT(基于 HTTP CONNECT 隧道,兼容性最好)
● SOCKS5(更高效,但对设备和网络要求更高)
⚠️ 仅在增强模式下生效。遇到连接问题时优先尝试切换到 HTTPS CONNECT。
可能的架构方案(可选,供参考)
如果后续考虑从根本解决类似 MIUI TUN 兼容性问题,可考虑将「应用识别」和「流量转发」拆分为独立层:
方案:VPN UID 标记 + iptables 转发
VPN TUN → 仅用于获取数据包所属 UID(解析来源 App)
iptables NAT → 将流量重定向到 Reqable 本地代理端口
代理端口 → HTTPS CONNECT / SOCKS5 转发到远端
优点:
- 应用识别与流量转发解耦
- 即使 TUN 回程异常,仍可通过 iptables 路径获取应用信息
- 兼容更多定制 ROM
当前临时方案
在功能实现前,小米 8 MIUI 12.5.2 用户可通过以下方式正常抓包:
- 关闭增强模式 → 使用 HTTPS 代理模式
- 代价:不显示 App 名称/包名(可从 User-Agent 头辅助判断)
- 如需应用信息 → 使用模拟器
相关信息
- 创建时间:2026-08-05
- 相关抓包 ID(增强模式失败):867、869、872、1049、1125、1158、1239、3590、3592
- 相关抓包 ID(HTTPS 代理模式成功):303-307
- 相关抓包 ID(模拟器增强模式成功):3182、3329
Feature Request: 增强模式增加手动选择代理协议(HTTPS / SOCKS5)
虽然分析是AI分析的.但是功能是需要的.
虽然分析是AI分析的.但是功能是需要的.
虽然分析是AI分析的.但是功能是需要的.
背景
当前 Reqable 增强模式中,代理协议(SOCKS5 / HTTPS CONNECT)由系统自动选择,用户无法干预。经在多台设备上系统测试,发现不同设备/ROM 对同一协议表现差异巨大,自动选择策略无法覆盖所有场景。
测试环境
测试结论
增强模式表现差异
根因定位
经过逐层排查(禁用 MIUI 安全组件、SELinux Permissive、抓包对比),最终确认问题在 MIUI 12.5.2 内核 TUN 驱动的 TCP 回程路径丢包:
证据:
com.miui.vpnsdkmanager、com.miui.securitycore、com.miui.powerkeeper、com.miui.guardprovider,SELinux 设为 Permissive → 无效 → 排除 MIUI 用户层组件为什么需要手动选择代理协议
虽然本次 MIUI TUN 的问题是内核层面的(切换代理协议也无法解决),但在以下场景中手动选择协议是必要的:
建议方案
核心诉求:解耦「流量拦截方式」与「代理协议」
设置项建议
在 Reqable 设置中增加:
可能的架构方案(可选,供参考)
如果后续考虑从根本解决类似 MIUI TUN 兼容性问题,可考虑将「应用识别」和「流量转发」拆分为独立层:
当前临时方案
在功能实现前,小米 8 MIUI 12.5.2 用户可通过以下方式正常抓包:
相关信息