插件
若需深入了解插件的定义，插件的类型和使用方法，请继续阅读本指南。
什么是插件（Plugin）
AxisNow 通过插件来不断扩展功能，可以灵活组合以适应各种场景。插件有 3 种不同的运行时：请求生命周期、AxisNow Cloud 和混合型。
Edge 请求生命周期
此类插件直接工作在您的 Edge 代理层，作为规则集合介入请求与响应的处理流程，我们基于请求生命周期预设了插件的阶段（宏观角度可分为请求阶段和响应阶段）。
插件预设了执行顺序，即您在面板中看到的插件列表顺序。
TCP 协议和 HTTP/S 协议的插件执行顺序互相独立。
AxisNow Cloud 独立运行
此类插件不依赖和介入 Edge 中的请求流量，工作在 AxisNow Cloud。基于定时任务或系统状态主动执行。例如 边缘拨测、DNS 路由、缓存清理、缓存预热。此类插件无执行顺序。
混合型
此类插件的功能包含了上述两种类型，例如 SSL / TLS。
默认订阅插件
我们已为新创建的租户默认订阅了常用或必需的插件。此外，您可随时根据业务需求，在插件市场中探索并订阅更多高级插件，以进一步增强安全、性能和精细控制。
插件的协作
插件之间可以协同工作，几种典型的场景：
条件跳过与标签驱动：规则可基于“标签/请求属性/上游元数据”进行匹配或跳过。如通用访问控制插件中配置“跳过速率控制”。
共享上下文：插件共享请求上下文与中间结果（如命中标识、请求认证元数据），后续插件可直接消费。
边缘拨测与 DNS 路由：边缘拨测监控目标服务的可用性，并联动 DNS 路由实现解析启停。
如果某个插件命中了阻断、直接返回本地响应、发起重定向等终止型动作，那么请求会在此处被“短路”，后续的请求阶段插件将不再继续执行。
插件引擎（Plugin Engine）
边缘内置了一个 插件引擎（Plugin Engine），统一管理插件的加载与执行，确保各功能有序协同。通过这一机制，插件能够独立启用、灵活组合。我们先来看总体架构，再详细展开各模块的作用。
规则集（RuleSet）
大部分插件都会执行一个规则集（RuleSet），这些规则集可以包含多条规则。在这些插件内部，内置有一个规则引擎（Rule Engine），用于支撑插件规则集的执行。规则集有两种类型，有序规则集合和无序规则集。
有序规则集：规则会自上而下顺序执行，一旦命中某条规则，对应的动作立即生效，后续规则将不再继续匹配。绝大部分插件的规则集都是有序规则集合。
无序规则集：规则无顺序，少数插件如 DNS 路由规则集是无序的。
一些独立运行的插件以“一次性/批处理任务”的方式运行，因此不包含规则集。他们通过参数指定目标与范围，然后执行相应的逻辑，如缓存清理、预热插件。
规则（Rule）
每一条规则均由优先级（Priority）、条件（Condition）与动作（Action）三部分组成。
优先级（Priority）
定义规则的执行顺序，序号小的先执行。
条件（Condition）
用于定义规则的触发逻辑，当条件判定为真时，执行相应的动作。条件可以由多个匹配（Match）灵活组合而成，并支持 AND / OR 运算，实现任意复杂场景下的匹配。
匹配（Match）= 匹配字段（Field）+ 匹配操作（Operator） + 匹配值（Value）。
匹配字段：可从请求、连接、资源等上下文中选择，如域名（Domain）、URI 路径（URI Path）、客户端 IP 地址（Remote Address）、客户端区域（Region）、资源标签（Resource Label/Tag）等，每一个插件的实际可用字段由具体插件暴露的能力决定（以插件文档为准）。
匹配操作：支持等于、不等于、包含、前缀/后缀匹配、正则表达式等多种方式，便于适配不同业务规则。
匹配值：用于与字段比较的具体取值，如字符串、数值、CIDR、正则表达式等，当匹配字段在所选操作符下满足该取值时，即视为匹配成功。
DSL 引擎
为了实现任意请求条件的灵活匹配，我们在条件匹配里使用了 DSL 引擎。DSL 引擎只负责条件的判定，与动作（Action）解耦，从而保证了匹配逻辑的独立性和可复用性。
它为策略定义提供了极高的灵活性与表达力。能够以简洁的语法和布尔逻辑（AND/OR）组合复杂条件，实现从简单规则到企业级精细化策略的全覆盖。
下面是一个典型的条件组合和对应的 DSL 表达式，请求是否匹配这些条件由 DSL 引擎来判定。
动作（Action）
当请求满足条件时，系统立即执行指定动作，根据不同的产品功能每个插件执行对应的动作，如允许（Allow）、阻断（Deny）、封禁（Block），重定向（Redirect）。大多数情况下有两种类型的动作，终止型和非终止型。
终止型：明确改变请求生命周期，立即结束或跳转（Deny/Block、Redirect、Return Response）。
非终止型：对请求做修改、标记或记录，但不影响继续执行后续插件（Allow、Rewrite、Log、Tag、SetConfig）。
请求例子
通过上述介绍，您已了解了插件的实现机制，现在我们来看一个具体的例子。图例有两个插件，第一个插件里配置有包含四条规则（R1、R2、R3 和 R4）的有序规则集。
请求 A：命中 R1（Allow）
引擎依次检查 R1 → R2 → …，在 R1 处首次命中并执行 Allow。由于 Allow 为非终止型，停止在本插件继续匹配 R2 → R4，但请求继续流向下一个插件。
请求 B：未命中 R1，命中 R2（Block）
引擎在 R2 处首次命中并执行 Block。由于 Block 为终止型，立即短路，后续插件不再执行，请求在此结束。
请求 C ：命中 R3（Allow & Skip）
引擎在 R3 处首次命中并执行 Allow。由于这里也配置了跳过（Skip）插件 B ，因此插件 B 将跳过执行。
请求 D：不命中 R1 → R4 任意一条
本插件无规则生效，不执行任何动作，请求继续流向下一个插件。
最后更新于
这有帮助吗？