在Shadowrocket中，分应用代理模式和规则模式不仅可以同时启用，而且在实际使用中遵循“分应用优先、规则兜底”的协同逻辑，两者在功能定位上互补而非冲突。分应用代理在系统进程层面依据应用包名进行路由决策，其执行顺序在规则引擎之前，具有绝对优先级，当按需求连接中为某应用配置了策略时，该应用的流量直接按该策略处理，完全跳过规则引擎的域名和IP匹配，即使配置文件中包含冲突规则也不生效。同时启用两种模式时，用户需在“设置→按需求连接”中为特定应用配置策略，并保持主界面的全局路由为“配置”模式以激活规则引擎，此时按需求连接覆盖的应用执行分应用策略，未覆盖的所有应用流量进入规则引擎按域名和IP规则进行智能分流，两者在流量处理管道中无缝衔接。日常使用建议以规则模式为核心分流框架，仅在银行App、特定游戏或内网工具等极少数应用需要强制直连或强制代理时才在按需求连接中添加对应的分应用策略，以此实现“通用分流精准化、特殊应用可控化”的最佳平衡。如需验证两者的实际生效情况，开启连接日志查看每个请求标注的策略来源，即可明确区分是该请求走了分应用代理还是规则模式。场景配置中可将两种模式的不同组合保存为独立场景，以便在不同网络环境下快速切换整体的管控策略组合。
两种模式在功能定位上的本质区别
分应用代理基于应用包名进行进程级决策
Shadowrocket的分应用代理功能（通常体现为“按需求连接”中的应用规则）是在系统进程层面进行流量捕获和路由判断，它依据的是每个网络请求所属的应用包名或应用名称，而非请求的目标域名或IP地址。当用户为微信App设置为“直连”策略时，所有由微信进程发出的网络请求，无论目标是国内还是境外服务器，均被直接标记为直连通道。这一决策发生在流量进入规则引擎之前，完全绕过了后续的所有域名和IP匹配逻辑，是基于“谁发起的请求”而非“请求去往哪里”的粗粒度管控。
规则模式基于域名和IP进行网络特征匹配
规则模式（全局路由设为“配置”）则是依托配置文件中的规则列表进行逐条匹配，匹配的依据是每个请求的目标域名、目标IP地址所属的地理位置或IP段范围。例如DOMAIN-SUFFIX,google.com,PROXY规则匹配的是目标域名的后缀，GEOIP,CN,DIRECT匹配的是目标IP归属地。这种决策完全独立于发起请求的应用是哪个，仅关注“请求要去哪里”，是一种基于网络层特征的细粒度分流机制。两种模式的工作维度完全不同，一个关注“谁在发”，一个关注“发给谁”。
两种机制在网络协议栈中处于不同层级
分应用代理的拦截点位于iOS系统的网络扩展框架层，在应用进程发出请求后、数据包进入Shadowrocket的处理管道之前即被执行。规则模式的匹配则发生在数据包已经进入Shadowrocket的内部管道后，此时应用层信息已被剥离或标记，规则引擎仅看到目标地址和协议类型。由于分应用代理在更早的阶段介入，其决策结果在逻辑上位于规则引擎的上游，这种层级差异决定了两者在同时启用时的优先级顺序。
两者同时启用时的执行顺序与优先级规则
分应用代理的决策优先于规则模式的域名匹配
当用户同时开启了分应用代理（即在“按需求连接”中为特定应用配置了策略）并保持全局路由为“配置”模式时，Shadowrocket的实际执行顺序是：首先检查当前请求所属的应用是否在按需求连接列表中配置了策略。如果配置了，则直接应用该策略，并且完全跳过后续的规则引擎评估，不再执行任何域名或IP规则的匹配。这意味着即使配置文件中包含了对该应用目标域名的代理规则，只要按需求连接中将其设为直连，该应用的请求仍会直连，规则模式中的对应规则不会生效。
冲突场景下分应用代理的设置覆盖规则模式
当两者的策略方向发生冲突时，分应用代理拥有绝对优先级。例如用户在按需求连接中将YouTube App设为“直连”，同时在配置文件中添加了DOMAIN-SUFFIX,youtube.com,PROXY的代理规则，此时打开YouTube App产生的所有网络请求都会直连，配置规则完全不生效。这种覆盖机制确保了用户对特定应用的管控意图不受全局分流规则的干扰，但也要求用户在同时使用两种模式时必须清楚分应用代理的“一票否决权”，避免配置规则时产生预期之外的覆盖。
规则模式处理分应用代理未拦截的剩余流量
分应用代理仅对在“按需求连接”列表中明确配置了策略的应用生效，对于所有未在该列表中配置策略的应用，其流量不受分应用代理的干预，完整进入规则引擎的匹配流程。这意味着用户可以将分应用代理作为一种“特例处理”工具，强制某些关键应用（如网银App、内网办公应用）直连或走特定代理，而其余所有应用的流量完全交给规则模式按域名和IP进行精细化分流。两种模式在这种场景下形成了“特例覆盖+通用分流”的互补关系，而非互斥关系。
实际使用场景中的协同工作方式
精细化管控策略搭配全局分流框架
用户可以利用分应用代理为少数特殊应用设定强制路由策略，同时保持规则模式处理其余所有流量的通用分流。例如将银行类App设置为强制直连，避免金融交易数据经过不可控的代理节点；将游戏App设置为强制代理以优化游戏延迟；而微信、浏览器等通用应用则交由规则模式根据目标域名自动判断是直连还是走代理。这种组合方案既满足了个别应用的严格路由要求，又保留了规则模式对绝大多数流量的智能分流能力，是两者协同的最佳实践。
规则模式作为兜底处理分应用代理未覆盖的所有请求
当用户仅对少量应用配置了按需求连接策略，而全局路由保持在“配置”模式时，所有未被按需求连接匹配的应用流量会正常进入规则引擎。此时规则模式中的FINAL兜底规则（通常设为PROXY）确保未被任何规则显式匹配的境外请求走代理，而GEOIP,CN,DIRECT规则保障国内网站直连。分应用代理没有配置的应用数量越多，规则模式承担的分流任务就越重，两者在逻辑上无缝衔接，不会出现流量因未匹配任何策略而丢失的情况。
场景化配置中两者的动态组合
用户可以在不同的场景中分别决定是否启用分应用代理以及如何与规则模式组合。例如在“家庭”场景中同时开启分应用代理（仅让Netflix App强制走代理）和规则模式（其余流量按规则分流）；在“办公”场景中关闭分应用代理，完全依赖规则模式处理所有流量；在“公共Wi-Fi”场景中启用分应用代理将浏览器以外的所有应用强制直连，仅浏览器流量进入规则模式。通过场景功能结合两种模式的开关状态，用户可为不同网络环境定制差异化的组合策略。
同时启用时的典型配置方法与注意事项
在“按需求连接”中为应用指定策略并保持全局路由为配置模式
实现两者同时启用的前提是：进入Shadowrocket的“设置→按需求连接”页面，开启该功能并添加需要特殊管控的应用，分别为其选择“代理”、“直连”或“拒绝”策略。同时确保主界面的全局路由下拉菜单保持在“配置”模式（即规则模式），不可切换至“代理”或“直连”，否则规则引擎不会被激活，分应用代理将独自决定所有流量的路由，规则模式无法发挥任何作用。
避免为系统关键应用设置冲突的代理策略
分应用代理的优先级高于规则模式，如果用户误将系统关键应用（如“设置”、“App Store”）设置为“代理”而当前节点不可用，可能会导致系统更新、应用下载等关键服务失效。同时，若将某些依赖本地网络的服务（如“文件”App访问局域网NAS）设置为“代理”，可能导致内网资源无法访问。建议只在按需求连接中配置非系统级的常规应用，且尽量以“直连”策略为主，代理策略仅针对明确需要翻墙的应用，避免影响系统基础功能。
分应用代理的策略不会因配置文件切换而失效
按需求连接中配置的应用策略是独立于配置文件的全局设置，不会因为用户切换了不同的配置文件或场景而改变。这意味着用户即使更换了规则集或配置，之前设定的银行App直连策略依然有效，无需重复配置。这种持久性确保了应用级别的管控意图始终得到执行，不会因分流规则的调整而意外失效，但也要求用户在修改配置文件规则时记住分应用代理的存在，避免在规则中做出与分应用策略冲突的修改而无法生效。
两者冲突时的判定逻辑与验证方法
通过连接日志查看实际生效的决策依据
当用户不确定某个应用的流量是走了分应用代理的策略还是规则模式的规则时，可开启Shadowrocket的连接日志功能并打开该应用触发网络请求。日志中每个连接记录会明确标注该请求的来源应用、目标域名以及最终执行的策略名称。如果日志显示策略来源为“按需求连接”或直接标注了“应用规则”，则说明该请求被分应用代理拦截并决策；如果显示匹配了某条DOMAIN-SUFFIX规则，则说明该请求进入了规则引擎处理。日志是区分两者实际生效情况的最直接工具。
IP出口验证确认应用是否真正走了预期通道
除了日志查看外，用户还可通过访问IP检测网站来验证应用的出口IP。在被测试应用内打开浏览器访问http://ipinfo.io，查看显示的IP地址是代理节点IP还是本地网络IP，结合该应用在按需求连接中的策略和规则模式中的规则进行判断。如果策略设为直连但出口IP为代理IP，说明规则模式可能覆盖了分应用代理（但实际不会发生）；如果策略设为代理但出口IP为本地IP，则需检查按需求连接是否生效或节点是否连通。
按需求连接的“直连”设置会无视配置规则
当按需求连接中某应用被设为“直连”时，该应用的所有请求在日志中会显示直接匹配了“按需求连接-直连”策略，且完全不会在规则引擎中留下匹配记录，即使配置文件中包含该域名的PROXY规则，日志中也不会有该规则的命中记录。这种现象确认了分应用代理的绝对优先级，用户在排障时应优先检查按需求连接中的策略设定，而非在规则模式中反复寻找原因。
综合建议与最佳实践
日常使用以规则模式为主，分应用代理为辅
对于绝大多数用户而言，规则模式已经能够满足国内直连、国际代理的分流需求，无需额外配置分应用代理。仅在个别应用需要强制直连（如银行App）或强制代理（如特定游戏）时，才在按需求连接中为该应用单独配置策略。这种“默认规则分流、特例应用管制”的组合既保持了配置的简洁性，又实现了特殊需求的精准满足。
分应用代理的优先级决定其应谨慎配置
由于分应用代理的策略会完全覆盖规则模式中对应的域名规则，用户在配置按需求连接时应充分理解这一优先级关系，避免因为随意设置代理或直连策略而导致意料之外的路由行为。建议在添加按需求连接规则时先通过日志确认该应用的流量当前在规则模式下是如何处理的，再决定是否需要通过分应用代理进行强制覆盖，而非盲目添加规则。
多场景下的灵活组合提升使用效率
用户可以在不同场景中启用或禁用按需求连接功能，或保留相同的按需求连接配置但切换不同的配置文件，实现分应用策略与规则策略的多样化组合。例如在家庭场景中保留银行App直连的按需求规则并加载通用配置，在办公场景中同样保留该规则但加载专门优化内网访问的配置，使相同的分应用策略在不同规则框架下发挥差异化的整体效果。
常见问题FAQ
按需求连接中设置了应用走代理，但规则模式中该应用的域名有直连规则，哪个生效？
按需求连接的设置优先，该应用的流量会走代理，规则模式中的直连规则被完全忽略。用户如需让规则模式生效，必须先在按需求连接中删除该应用的策略条目，否则规则模式对该应用的所有域名规则均不会被执行。
分应用代理和规则模式同时启用会增加设备耗电吗？
两者同时启用会增加规则引擎的匹配工作量以及系统级的进程拦截开销，但增加幅度极为有限。分应用代理仅在应用进程发出请求时进行一次应用包名匹配，规则引擎的域名规则匹配在毫秒级内完成，两者叠加对电池续航的影响几乎无法感知，远小于代理节点本身加密传输带来的CPU消耗。
关闭分应用代理后，规则模式能接管之前被分应用策略覆盖的流量吗？
可以。当用户在“按需求连接”中删除某应用的策略条目或整个关闭该功能后，该应用之前被分应用策略覆盖的流量会立即重新进入规则引擎的匹配流程，按照配置文件中的域名和IP规则进行路由。无需重启应用或代理开关，切换后新发起的请求即按新规则处理，已建立的连接可能会维持旧策略直到断开。
规则模式中配置了域名规则，分应用代理中该应用设为“直连”，但访问时IP显示代理，为什么？
这种情况理论上不会发生，因为分应用代理的直连策略具有绝对优先级。如果出现IP显示代理，可能是因为用户开启了代理开关且当前访问的IP检测页面实际并未被该应用的按需求连接规则捕获（如浏览器访问的页面不属于该应用进程），或该应用实际并未匹配到按需求连接中的策略条目。用户应检查按需求连接中是否真正包含了该应用，并确认策略确实设为“直连”而非“代理”。