PanVell 规则路由设置指南

先理解 PanVell 规则路由在做什么

规则路由可以理解为一张按顺序匹配的判断表。每一条连接产生时，客户端读取规则列表，逐条比对，命中哪条就按哪条指定的策略处理，常见结果是走代理、直连或按策略组选择。它的价值在于把不同用途的流量区分开：需要经代理访问的连接交给代理，本地或已可直连的请求保持原样，从而减少不必要的转发。

这也解释了为什么规则路由设置不只是“选一个节点”。节点决定出口，规则决定哪些流量需要出口。PanVell 支持多种代理协议，配合基于规则的路由，用户可以在同一份配置里管理不同协议对应的策略组，再让规则去引用这些策略组。由于代理配置在设备本地处理，规则和策略的解析都发生在本地，理解这一点有助于后续排查：出现异常时，优先怀疑本地配置内容，而不是远端服务。

PanVell 订阅导入步骤

规则路由的前提是有一份可用的配置，而配置通常通过订阅获得。PanVell 支持订阅 URL 或服务商账号连接，两种方式都指向同一件事：把服务商提供的配置引入客户端。

第一步，准备服务商给出的订阅信息。第二步，在客户端内选择订阅 URL 或账号连接的方式完成导入。第三步，等待配置解析完成，确认策略组与规则已经载入。第四步，选择节点。第五步，点击连接。

导入完成后不要急着判断效果，先确认配置本身是否完整：策略组是否存在、规则条目是否为空。若导入后看不到预期的策略结构，问题多半出在订阅内容或导入环节，而不是路由逻辑本身。需要再次提醒，PanVell 不提供代理服务器，订阅必须来自用户自行准备的有效代理服务，客户端只负责按配置执行。

PanVell 分流规则怎么配：从目标反推规则

PanVell 分流规则怎么配，建议从使用目标反推，而不是先堆规则。可按以下顺序推进：

1. 明确要区分的流量类型。把日常访问分成“必须经代理”“可以直连”“需要单独走某个出口”三类，先想清楚分类，再动手。
2. 建立策略组。为不同出口建立策略组，让规则引用策略组而不是直接绑定单个节点，这样更换节点时不必改动规则。
3. 安排规则顺序。规则按顺序匹配，范围窄、指向明确的规则放在前面，范围宽的兜底规则放在后面，避免前面的宽规则把后面的精细规则挡住。
4. 设置兜底策略。明确未命中任何规则时的默认处理方式，保证行为可预期。
5. 小步调整。每次只改一类规则，改完立即连接观察，避免一次改动过多导致无法定位问题。

这套流程的关键是“先分类、再分组、后排序”。PanVell 提供基于规则的路由，但规则内容由用户的配置决定，因此配置质量取决于分类是否清晰。

PanVell 规则模式和全局模式区别

PanVell 规则模式和全局模式区别，本质是判断环节是否生效。规则模式下，每条连接都要经过规则匹配，再按命中结果决定去向；全局模式下，规则判断被绕过，流量统一按指定出口处理。

理解这个区别能解决很多困惑。如果你发现所有流量都走了同一个出口，先确认当前是否处于全局模式，而不是怀疑规则写错。反过来，如果只有部分流量经代理，说明规则正在起作用，此时应检查未命中的流量是否符合预期。规则模式适合需要区分流量的日常使用，全局模式更适合临时统一出口的场景。切换模式后，建议重新连接并观察连接状态信息，确认行为变化与切换一致。

用实时流量监控和连接状态观察结果

规则是否按预期生效，不靠猜，靠观察。PanVell 提供实时流量监控和连接状态信息，这两项是验证规则路由的主要依据。

观察时可按以下排查流程进行：

1. 连接后查看连接状态，确认客户端处于已连接状态。
2. 打开实时流量监控，观察是否有流量产生以及流量的走向是否符合预期。
3. 针对某类访问做单点测试：先访问一个应直连的目标，再访问一个应经代理的目标，对比两者在连接状态中的表现。
4. 若结果与预期不符，回到规则顺序检查，确认是否有更靠前的规则提前命中。
5. 若某类流量完全无记录，检查该规则引用的策略组是否存在、是否可用。

这个过程不需要任何测速或排名数据，只看行为是否与配置意图一致。规则路由的验证标准是“分类正确”，不是“速度更快”。

常见异常与处理思路

规则路由的异常大多集中在三类。第一类是导入后策略组缺失，处理方向是重新确认订阅内容与导入方式。第二类是规则不生效，优先检查规则顺序与兜底策略，再看是否处于全局模式。第三类是连接状态正常但流量走向异常，回到实时流量监控逐条比对，定位是哪条规则命中。

另外几项事实也值得纳入排查视野：PanVell 支持深色模式，支持英语、中文、日语和俄语，界面语言不影响规则逻辑，但可能影响你对策略组名称的识别；App Store 标记为 iOS Universal，适用于 iPhone、iPad，最低系统要求 iOS 15.0；开发者 RFHKS，销售方 REIFENG SHARE LIMITED，分类为 Utilities 和 Productivity。版本说明只涉及崩溃修复、界面交互优化和已知问题处理，说明规则逻辑本身没有额外需要关注的变化点。说明称不会记录、检查或出售浏览历史与网络流量，代理配置在设备本地处理，这也是把排查重点放在本地配置上的原因。

把规则路由设置变成可复用的习惯

规则路由设置不是一次性的动作。建议保留一份清晰的分类清单，每次调整只动一类规则；更换节点时只改策略组，不动规则；切换模式后重新观察连接状态。长期来看，这种习惯比反复重写规则更有效。

若想继续深入，可阅读 tutorial.html 了解基础操作，遇到具体疑问查阅 faq.html，需要获取客户端前往 download.html。规则路由的稳定性，最终来自清晰的分类与耐心的观察，而不是复杂的规则数量。

规则调整时的阅读顺序

阅读 PanVell 规则路由时，可以先问三个问题：这条规则要描述哪一类流量，命中后应交给哪个策略，前面是否已经有更宽的规则。先回答对象，再回答去向，最后检查顺序。这样做的好处是每一条修改都有明确目的，出现变化时也知道应该回到哪个环节。

策略组与节点不是一回事。节点是具体的服务出口，策略组是规则可以引用的选择集合。更换节点时，如果规则只引用策略组，就不必逐条重写；如果把某个节点直接写进很多规则，更换服务后就需要重新整理。PanVell 支持多种代理协议，但协议本身不会替你决定规则顺序，顺序仍由导入的配置内容决定。

每次调整后只观察一个目标。先访问应当直连的内容，再访问应当经过代理的内容，结合连接状态和实时流量监控看结果。若结果相反，优先检查是否处于全局处理方式；若只有一个目标异常，优先检查它命中的规则。保持小步修改，才能让本地配置逐渐变得可读。

把规则路由画成决策树

理解规则路由时，可以把每条请求想成沿着决策树向下移动。第一层负责识别范围，第二层负责选择策略，最后一层提供兜底路径。范围越具体的条件越适合靠前放置，范围很大的条件应留在后面。这样做不是为了增加规则数量，而是为了让每一次命中都能解释。PanVell 的本地规则处理让这种解释可以直接结合当前设备的连接状态与流量反馈。

调整前先写下目标，例如让某类请求直连、让另一类请求通过策略组、让未知对象遵循默认处理。完成一次修改后，只观察目标对应的行为。若目标没有变化，检查它是否在更早的条件中已经被截走；若所有目标都走向同一出口，检查是否误用了统一处理方式。这样的决策树思路比凭感觉来回切换更容易定位。

对于多协议配置，可以把协议视为连接描述，把策略视为流量选择。二者属于不同层面，不能互相替代。订阅导入成功后先确认策略组，再确认节点，再看连接。只有每一层都存在，规则路由才有足够的信息完成判断。

把规则阅读变成一次次小实验

理解规则路由时，可以把一个访问目标当成观察对象，先写下它预计经过的处理方式，再在 PanVell 中查看连接状态与实时流量变化。结果不符合预期时，只回到一条规则或一个节点，避免同时更改多处设置。由于应用在设备本地处理代理配置，这种小范围调整能让每次结果都与当前设备直接对应。

订阅里可能包含多种代理协议，但协议描述、节点选择和策略判断属于不同层次。先确认配置已经出现，再看节点列表，之后才判断某一类流量的路径。把三个层次分开，阅读导入内容时会更容易找到具体问题。

让规则说明对应到可观察的动作

阅读一份规则配置时，可以把抽象条件换成设备上看得见的动作。先挑一个明确的访问目标，记录连接前后的状态，再改变一个规则条件。若流量方向随之变化，说明这条规则确实影响了当前目标；若完全没有变化，应该回到匹配范围和配置来源，而不是立刻增加更多条件。

节点列表、规则列表和连接状态提供的是三种不同线索。节点列表回答“有哪些选择”，规则列表回答“流量怎样分配”，连接状态回答“当前动作有没有完成”。把它们按这个顺序阅读，能避免看到一个空列表就推断全部配置失效，也不会把一次连接波动归因于某个不相关的策略。

PanVell 在 iOS 与 iPad 上运行时，界面空间会有所不同，但判断路径相同。先找到当前配置，再查看节点和规则，之后观察连接反馈。为了保持记录连续，可以在每台设备上使用相同的描述方式，把“配置出现”“选项改变”“状态变化”分别写下。

当规则内容来自订阅，更新后应重新阅读它的结构。不要假设上一次看到的顺序仍然存在，也不要把服务方新增的条目当成客户端自动生成的能力。PanVell 负责处理收到的配置，具体内容仍随来源资料变化。

从配置结构理解路由反馈

规则路由的阅读可以从三个可见层次开始。第一层是来源：这份内容来自订阅 URL 还是账号取得的配置。第二层是选择：列表中有哪些节点或策略。第三层是反馈：连接状态与实时流量是否随访问动作变化。每一层只回答一个问题，排查时不必把所有现象混成一句“不能用”。

当来源内容更新后，先查看配置名称有没有变化，再看列表结构是否仍然可读。若名称变化而节点消失，应该回到服务资料的返回内容；若节点仍在但某个目标行为改变，则更适合观察规则路径。PanVell 能处理多种代理协议，但客户端不会替服务方补齐缺少的配置字段。

在 iOS 设备上，系统网络变化也可能影响观察结果。切换 Wi-Fi、移动网络或暂时离线后，连接状态与流量读数都会有不同表现。记录发生变化时的设备网络条件，再重现同一个访问动作，比直接下结论更稳妥。保持一次只改变一个条件，才能知道反馈属于哪一层。