本页目录
只想让某个 App 走指定线路，小火箭里却找不到按应用名添加的入口？这篇从流量日志入手：找应用实际访问的域名、添加规则、复测出口，再讲第三方配置、规则集和模块，以及测试结果对不上的排查方法。
先说边界：这次做的是域名分流，不是按进程精确隔离 App。一个域名可能被多个应用共用，目标应用也可能访问多个域名。
1. 应用分流：打开日志，找到请求
在 数据 → 日志 → 代理中启用日志记录，暂时只操作待排查应用，做一个能重复的动作，再返回日志看新请求。我用 Gemini 对话举例，根据时间和域名特征找到了 Google API 请求。
给观察到的域名添加规则：配置 → 当前配置 → 编辑配置 → 规则 → 添加。选择合适类型，填域名，指定已有策略组，再保存。域名后缀字段只填域名，不带协议、路径或 :443 端口。
我演示使用 googleapis.com 后缀与美国策略组，重新对话后记录显示走了所选线路。它只是当时的排查例子，不是当前 Gemini 必须走美国或所有请求都属于该域名的保证；服务资格按当前官方条件核对。
但这只是我用时间和请求特征做的关联判断；看到 googleapis，不等于它天然属于 Gemini。Google 其他应用可能也调同一个域名，登录与媒体还可能走别的地址。我后来试过更宽的 DOMAIN-KEYWORD 匹配 google，连 Gmail 和浏览器里的 Google 服务也跟着受影响。想只动一个 App 时，这种大网兜刚好与目标相反。
较稳妥的顺序是：
- 记录修改前的请求与出口，尽量隔离无关应用活动，避免把同时发生的请求误认成目标 App 的。
- 优先从明确的完整域名或有限的域名后缀入手；观察其他功能是否还需要独立规则，不轻易扩大到关键词。
- 保存一条规则后，在同一网络环境下复测目标功能和其他常用应用，查看命中结果。
- 记录结束及时关闭详细日志，并按需要清理其中可能含有域名、时间、设备和账号活动的敏感记录。日志是排错工具，不是应公开的素材。
规则类型与策略组可先看分流基础，配置结构另见配置文件拆解。这里专注于从真实请求反推哪条规则值得加。
2. 第三方配置：先看它改了哪些区块
第三方配置可能改通用设置、DNS、策略组和全部规则。先用当前示例配置对照结构，备份现有文件，再检查订阅、地址和权限。不需要的区块先停用，不把整份陌生配置直接覆盖自己的环境。
3. 规则集：选来源，也要选策略
规则集提供一组域名或 IP 匹配项，使用时添加 RULE-SET 类型、填写对应资源 URL，再选择适合的策略组。先读列表内容和格式，确认当前客户端支持，不把网页地址当规则文件地址。
广告
规则集不自带合法服务资格。例如某服务有地区或金融监管限制，换出口不能改变用户身份和许可；不要把线路配置当开户或交易建议。外部列表更新后，范围可能变化，要复测目标和其他常用服务。
4. 模块：来源、脚本和证书分别检查
模块可能包含重写、脚本或 HTTPS 解密，先看源码、维护日期和目标域名，再按当前项目说明安装。安装入口与实际用法可参考Sub-Store 模块教程，不代表其他模块有完全相同的权限需求。
老模块可能失效，看不懂作用就先不装；别为了凑“豪华套装”把每个开关都打开。
5. “测试规则”与真实请求对不上怎么办
我还遇到过一次古怪现象：订阅刚更新，界面的“测试规则”显示一个地区，浏览器实际访问和策略组当前选择却是另一处。手动让该组重新测速之后，结果才跟后续请求一致。这是那台设备、那个版本下的现象；我不会据此宣布所有小火箭都有同一个 Bug。
遇到不一致，按下面顺序看：
- 确认当前配置和命中的具体规则，找出它引用的策略组。
- 查看组当前选中节点；引用了子组就继续向下看。
- 若刚更新订阅，检查候选列表，再对实际使用的组手动测速。
- 重新测试规则，并发起真实请求查看日志与响应。
这次界面在组重新测速后与后续结果一致。它是该版本下的观察，不应断言所有版本都有同一 Bug。页面地区还可能受 Cookie、账号和缓存影响，最终综合请求日志、节点和响应判断。
把分流问题留在能观察的地方
先看真实请求，再改规则，再核对组与出口。配置、规则集和模块分别处理，出现问题才能知道是哪一层影响了访问。DNS 路径还可能独立于网页出口，继续看DNS 原理。
欢迎分享遇到的规则冲突与排查过程，附客户端版本和脱敏后的相关记录即可。感谢阅读，也欢迎关注后续网络工具分享；日志与订阅中的私有内容就留在自己的设备里。
广告
