装了客户端、连上了节点，打开某个应用却发现加载不出来——这种情况十有八九不是"不支持"，而是分流规则没有覆盖到它。应用支持这件事，本质上是两件事的组合：客户端能否正确识别这个应用的流量，以及识别之后是否按预期把它导向优化通道。下面把支持范围、适配清单、识别原理、自查方法和排查步骤一次讲清楚，对照操作即可。
1000+ 应用支持具体覆盖哪些类型？
快连的覆盖范围按使用场景划分，共八个大类。这个分类方式也基本对应了分流规则中预设的规则组：
- 流媒体类 —— 视频、音乐、直播平台，对带宽和稳定性要求较高，是适配优先级最高的一类。
- 社交类 —— 即时通讯、社区论坛、图片分享平台，特点是连接频繁、单次数据量小。
- 游戏类 —— 端游、手游与游戏平台，对延迟最敏感，通常需要单独优选低延迟节点。
- 办公协作类 —— 在线文档、视频会议、云盘同步，对稳定性和上传带宽有明确要求。
- 开发工具类 —— 代码托管、包管理源、容器镜像仓库，是开发者使用频率最高的一类。
- 电商与支付类 —— 购物平台与数字内容商店，对连接安全性要求较高。
- 资讯与学习类 —— 新闻站点、在线课程、学术数据库。
- 云服务类 —— 对象存储、CDN 资源、各类 API 服务。
各类主流应用的适配情况如何？
下表按类别汇总了典型应用的适配状态。需要说明的是，适配状态指的是"客户端能否正确识别并处理其流量"，不代表应用本身的全部功能都可用——这与应用自身的访问策略有关。
| 应用类型 | 典型场景 | 适配状态 | 使用要点 |
|---|---|---|---|
| 流媒体 | 视频播放、音乐收听、直播 | 已完成适配 | 建议选带宽充足节点，避免高峰时段共用 |
| 社交 | 即时通讯、社区、图片分享 | 已完成适配 | 保持长连接，切换网络后需短暂等待重连 |
| 游戏 | 端游、手游、游戏平台 | 已完成适配 | 优先选低延迟节点，延迟超过 200ms 会明显影响操作 |
| 办公协作 | 在线文档、视频会议、云盘 | 已完成适配 | 视频会议对上行带宽敏感，建议单独测速 |
| 开发工具 | 代码托管、包管理、镜像仓库 | 已完成适配 | 终端类工具需确认其解析路径已走优化通道 |
| 电商支付 | 购物平台、数字内容商店 | 已完成适配 | 支付环节建议保持连接稳定，避免中途切换节点 |
| 资讯学习 | 新闻站点、在线课程、数据库 | 已完成适配 | 大文件下载建议避开网络高峰时段 |
| 云服务 | 对象存储、CDN、API 调用 | 已完成适配 | API 类调用对稳定性要求高，建议固定节点 |
表格里没有逐一列出具体应用名称，原因有两层：一是数量确实多，列全反而影响阅读；二是应用的访问策略会随时间调整，静态清单容易过时。更可靠的做法是掌握自查方法，随时判断某个应用当前是否可用。
应用支持的底层识别原理是什么？
"支持某个应用"这件事，技术上要经过三个环节，缺一不可：
流量捕获
通过网络扩展或虚拟网卡接管设备的网络流量
规则匹配
按进程名、域名、IP 段匹配分流规则，判断归属
路径分发
命中规则的流量走优化通道，其余保持本地直连
三个环节中最容易出问题的是规则匹配。流量捕获是系统级的，只要权限到位就能覆盖；路径分发是确定性的，命中就走、没命中就不走。但"是否命中"取决于规则库——规则库对某个应用的进程名或域名有收录，它就能被正确识别；没有收录，流量就会被当作"未知应用"，按默认策略处理。
这也解释了为什么同一款应用在不同设备上的表现可能不一样。桌面端能读到进程名，识别相对准确；移动端受沙盒限制，多数情况下只能按域名匹配，同一个应用的不同功能模块如果使用不同域名，就可能出现"部分功能可用、部分不可用"的情况。想了解分流规则的完整配置方式，可以在客户端的分流模式设置中查看详细说明，或参考 帮助中心 的规则配置章节。
如何判断某个应用是否在支持范围内？
不需要查清单，用下面三步实测就能得出结论，比查表更准确：
步骤 1 · 确认连接状态。 先确认客户端显示已连接，且状态图标为绿色。在未连接状态下测试应用是没有意义的。
步骤 2 · 观察应用的实际表现。 打开目标应用，执行一个典型操作——播放一段视频、加载一次页面、发起一次请求。观察是否能在合理时间内正常完成。
步骤 3 · 用分流日志确认归属。 在客户端的分流日志或连接记录中查找该应用对应的条目。能看到进程名或域名，说明已被识别；显示为"其他"或"未知"，说明规则库未收录，需要手动添加规则。
不同平台上的应用支持有什么差异？
五个平台的识别能力与配置入口存在差异，主要受各系统的权限模型影响：
| 能力维度 | 桌面端（Windows / macOS / Linux） | 移动端（Android / iOS） |
|---|---|---|
| 进程名识别 | 支持，可精确到单个可执行程序 | 不支持，受系统沙盒限制 |
| 域名识别 | 支持 | 支持，是移动端的主要识别方式 |
| 自定义分流规则 | 支持按应用、域名、IP 段配置 | 提供预设规则组，精细度略低 |
| 规则导入导出 | 支持，便于批量部署 | 不支持，配置需逐台设置 |
| 识别准确度 | 较高，多维度匹配 | 中等，依赖域名匹配 |
按平台逐一来看：Windows 端可读取进程名，识别最精确，支持完整的分流规则配置，适合需要精细控制的场景；macOS 端同样支持进程名识别，菜单栏入口可快速切换规则组，系统权限模型与 Windows 相近；Linux 端支持进程与域名双维度识别，需要确认系统代理设置未被其他工具覆盖，否则可能影响识别结果；Android 端仅支持域名识别，建议将常用应用的域名手动加入规则组，同时注意省电策略对后台识别的影响；iOS 端同样以域名识别为主，需保持网络扩展权限开启以确保识别生效，系统沙盒对配置的约束比 Android 更严格。
这个差异是系统层面的限制，不是实现上的取舍。移动端无法读取其他应用的进程信息，因此只能通过域名来判断流量归属。实际影响是：在移动端，一个应用如果使用了多个域名，可能出现部分流量被识别、部分未被识别的情况。解决办法是在分流规则中把该应用的域名手动加入规则组，或者在设置中切换为全局代理模式——后者会让所有流量统一走优化通道，不再依赖识别。
应用无法正常使用怎么办？
按下面的顺序排查，多数问题能在前三步内解决：
先分清故障类型
应用完全打不开，还是能打开但部分功能异常？前者更可能是识别或连接问题，后者通常是应用自身的访问策略问题。
切换分流模式测试
从智能分流切换到全局代理后再试一次。如果全局模式下正常，说明问题出在规则识别，需要手动补充规则。
检查应用是否走了本地网络
部分应用自带网络配置，会绕过系统代理。需要在应用自身的设置中确认其网络行为是否为"跟随系统"。
更换节点验证
切换一个不同地区的节点。如果换节点后恢复正常，说明是原节点线路问题，与识别无关。
清除应用缓存重试
应用可能缓存了旧的连接信息。清除应用缓存后重新打开，让它重新建立连接。
确认客户端版本
规则库随版本更新。旧版本可能缺少对新应用的识别规则，更新到最新版本后再试一次。
如果按上述步骤排查后仍无法解决，可以在 常见问题 页面按应用类型检索，或联系 7×24 小时在线客服 提供应用名称、平台与具体表现，通常能更快定位。
如何为特定应用手动配置分流规则？
当某个应用没有被自动识别时，手动补充规则是最直接的解决办法。桌面端的操作路径如下：
- 打开客户端设置，进入"分流模式"或"规则管理"页面。
- 选择"自定义规则"，新建一条规则。
- 选择匹配方式：按进程名（仅桌面端可用）、按域名、或按 IP 段。
- 填入要匹配的目标。进程名需填可执行文件的完整名称，域名支持通配符。
- 选择动作：走优化通道、直连、或拒绝。多数场景选"走优化通道"。
- 保存并应用，客户端会立即按新规则处理流量，无需重启。
移动端的配置路径略有不同，因为没有进程名这个概念，只能按域名添加。如果不知道某个应用使用了哪些域名，可以在分流日志中观察该应用产生的连接记录，把其中的域名逐个加入规则组。这个过程稍显繁琐，但配置一次长期有效。更详细的规则语法与示例，可以查看 帮助中心 的规则配置文档。
应用适配清单会持续更新吗？
会。规则库随客户端版本迭代更新，更新内容主要包括三类：新增应用的识别规则、已有应用域名变化后的修正、以及失效规则的清理。更新节奏与新应用的出现频率相关，没有固定周期。
对使用者来说，有两点值得注意：
- 保持客户端为最新版本。 规则库随版本分发，停留在旧版本意味着缺少最新的识别规则。建议开启自动更新，或在发现新应用无法识别时主动检查更新。
- 遇到未识别应用可以反馈。 把应用名称、平台、具体表现反馈给客服，有助于该应用在后续版本中被收录。反馈时附上分流日志中的相关记录，定位会更快。
另外需要明确，应用支持与账号权益无关。单账号支持 5 台设备同时在线，覆盖 Windows、macOS、Android、iOS、Linux 五大平台，各设备上的规则配置相互独立。需要在新设备上使用，前往 下载页面 获取对应版本即可；订阅方案与权益细节，可以查看套餐页面说明。
应用支持这件事，与其背清单，不如掌握判断方法：连上后打开应用实测、看分流日志确认是否被识别、未被识别就手动补一条规则。三步走下来，绝大多数"不支持"的疑问都能自己得出结论。如果遇到确实无法识别的新应用，反馈给客服是最有效的推动方式。需要在新设备上配置时，前往下载页面获取对应平台版本即可；订阅方案与多设备权益的完整说明，也可以在套餐页面找到，或直接咨询 7×24 小时在线客服。