AeroBox for Android连接问题排查指南

排查前先确认设备环境符合运行要求。最低系统为 Android 12，应用的目标 SDK 下限是 31，低于该版本可能出现无法安装或部分行为异常。阅读安装条件不仅是为了确认能否启动，更因为某些故障的根因就藏在系统限制里。如果设备版本较旧，很多后续测试都失去意义。不要跳过这一步，尤其当问题表现为闪退、无法创建连接或界面元素缺失时。先排除系统不兼容，再谈网络和节点。

获取应用时应留意来源。搜索过程中可能遇到名称相似的程序，或自称官网的页面。安装前查看开发者信息和包名签名，避免把不同实现的问题混在一起。官方入口只有一个，即 GitHub 上 imengying 的 AeroBoxForAndroid 项目 Release 页。从其他位置取得的安装包行为无法预判，排查时也不会作为有效依据。如果当前安装来源不明，建议先替换为 Release 页提供的版本，再开始记录现象。

这一层不涉及网络协议配置，但能排除最基本的版本与安装包问题。系统版本不足时，后续所有测试都可能被设备兼容性干扰。

订阅导入后，应用能显示节点不代表节点本身可用。AeroBox for Android 支持多种协议，包括 Shadowsocks、Shadowsocks 2022、VMess、VLESS、Trojan、AnyTLS、Hysteria 2、TUIC、SOCKS5、HTTP Proxy 和 Naive。排查时可以先确认当前节点对应的协议，服务端是否仍开启该协议，以及订阅提供方是否变更了端口或密码。

应用提供节点延迟测试。测试结果只是到达延迟的参考，不一定等于实际可用性。可以分别测试不同节点：若多个节点延迟都异常，可能不是单个节点问题；若只有某一种协议失败，建议更换其他协议节点对比。

导入节点和导入规则是两个独立动作。看到节点列表出现，不代表远端规则会自动进入配置并生效。排错时如果分流表现不符合预期，不应假设订阅内容已经完整应用，更不应把节点连通性和规则匹配混为一谈。节点只负责提供连接目标，规则决定流量走向，二者来源和更新时机都可能不同。出现部分应用不通或走错出口时，先确认规则是否实际存在，而不是反复更换节点。

AeroBox for Android 的路由模式可切换全局代理、规则分流与直连。连接失败时，先记录当前处于哪一个模式。

如果切到直连，目标流量不会走代理，这本身不是故障。若想让代理接管流量，应选择全局代理或规则分流。全局代理会尽量把所有流量导入代理出口；规则分流则按 Geo 规则集判断。应用使用官方 Geo 规则集，命中结果取决于规则集本身和应用当前选择的出口。

规则分流下，某些域名可能被判定为直连，某些域名才走代理。你打开的是 A 网站，但失败的是 B 服务，可能两者走了不同路径。排查时不要只凭“浏览器打不开”判断整体故障，可以先切换路由模式对比结果。若全局代理下恢复正常，而规则分流下失败，问题更可能出在规则命中或分流条件，而不是节点本身。

应用支持分应用代理，但具体以哪种模式实现不应臆测。不要声称存在允许、排除、白名单或黑名单等选项，除非界面明确显示相应入口。排查某个应用异常时，把它和另一个已知正常的目标应用放在相同节点下对比。若一个通一个不通，差异可能来自规则匹配，而非节点质量。记录具体是哪个应用、什么行为，比笼统说“分应用失效”更有价值。

如果某个应用一直连不上，而浏览器或其他应用正常，优先检查分应用代理中这个应用的代理状态。分应用代理与系统 VPN 模式相关，应用是否被纳入代理范围，会直接改变它的出口路径。

如果当前没有改动分应用设置，可以观察同类网络请求在不同应用中的表现。比如浏览器能打开目标站点，而某个客户端失败，可能是客户端自身要求不同，也可能它没有走代理。这种情况下不要急改节点，先确认该客户端的流量是否真的经过代理出口。

可以在 DNS 层单独观察变化。应用支持自定义 DNS，也提供 DoT 与 DoH 两种加密方式。进行测试时，应把连接层和解析层分开记录，不要因为改了 DNS 就期待速度或连通性一定改善。某些问题只在解析阶段出现，另一些则与隧道本身有关。分别更换节点和 DNS 设置各测一次，有助于判断卡顿或失败发生在哪一层。任何 DNS 调整都不保证改善连接结果。

判断时可以先看现象：如果域名解析不出来，通常表现为连接迟迟没有响应，或者提示找不到服务器；如果域名解析正常但传输失败，则可能已经开始连接但中途中断。普通用户不一定能直接看到底层错误，可以借助日志观察。

若你在应用中设置了自定义 DNS，清理后改回简单配置再观察。DNS over TLS 与 DNS over HTTPS 依赖服务可用性，如果上游 DNS 不稳定，可能影响解析。换用其他 DNS 或暂时不自定义，能帮助判断问题是否来自 DNS。

此外，系统是否支持 IPv6，也会影响部分网络路径。应用支持 IPv6，但如果本地网络环境没有稳定的 IPv6 连接，相关请求仍可能失败。排查时无需深入协议细节，只需知道 DNS 与 IP 版本也可能造成“节点正常但连不上”的错觉。

AeroBox for Android 支持开机自连与断线自动重连。连接断掉后是否恢复，取决于当前是否启用了相关能力，以及网络环境是否真的恢复。

如果发现应用周期性断开，可以先记录断线时设备网络处于什么状态：Wi-Fi 与移动网络切换、休眠后唤醒、信号变化，都是常见观察条件。断线自动重连不代表零中断，也不代表所有应用都能立刻恢复会话。部分应用在代理切换后需要重新建立连接。

应用提供运行日志与通知栏快捷切换。运行日志是排查的重要依据，但不应把日志中的每一项都理解为确定错误。可以先看最近一次失败出现的时间点，再看当时是否有路由切换、节点切换或网络变化。不要在没有依据的情况下把日志内容解释为某种固定报错。

通知栏快捷切换适合用于快速停止或开启代理，方便在排查时做对比。一次测试保持一个变量变化，结果更容易判断。

节点延迟测试不是点一下就能下结论。它的价值在于做差异对比：同一时间测多个节点，看是否有明显分层；同一节点在不同网络下分别测试，看延迟是否随网络环境变化。

如果所有节点都显示较高延迟，可能不是节点集体失效，而是当前网络到测试目标的路径不好。此时换一个网络环境再测，比逐个删除节点更有意义。相反，如果只有个别节点异常，其他节点正常，可以暂时禁用异常节点，观察连接是否改善。

延迟数据也可能随时间波动。一次测试只能作为参考，不适合作为“节点好坏”的绝对标准。若延迟测试结果显示可用，但实际连接仍失败，说明还要看路由、DNS、分应用等其他层。

建议按以下顺序观察，而不是随机切换设置：先确认系统与安装来源，再换节点，再看路由模式，再查分应用，再调整 DNS，最后看日志。每一步记录变化，避免一次修改多个地方。

应用具备开机自动连接、掉线后自动重连以及 IPv6 相关能力。这些属于已实现的功能，不意味着在每种网络环境下都能得到预期结果。自动重连可能被省电策略打断，开机启动可能受系统限制，IPv6 连通性取决于运营商和路由环境。排查时不要因为功能存在就认定当前网络一定支持。观察实际表现，把网络环境作为变量之一，而不是把问题简单归为功能失效。

同时，本应用基于 sing-box / libbox 提供 Android VPN 模式代理。系统 VPN 模式会改变设备的网络转发路径，某些系统级功能、热点共享或特殊网络环境可能影响代理表现。若问题只在特定环境出现，可以切换到其他网络观察。

最后需要明确：本文只提供通用观察思路，不保证一定能解决特定连接问题。应用界面基于 Material 3 与 Jetpack Compose，不同版本在视觉布局上可能变化，具体菜单名称、字段位置和报错文本均以你安装的版本为准。排查时若无法定位原因，建议回到官方发布页查看最新说明，并提交详细的日志与复现条件给维护者。

更多与导入和配置相关的步骤，可继续阅读 AeroBox for Android 订阅导入步骤详解、AeroBox for Android 使用教程与基础配置，也可以从 AeroBox for Android 常见问题与故障处理 查找其他故障场景。