PHPWAF规则优先级设置方法解析

PHPWAF的规则匹配并非权重评分，而是严格遵循配置文件中从上到下的短路执行逻辑——一旦命中即刻动作、终止后续检查，因此规则顺序直接决定防御有效性与系统性能；必须将白名单IP、静态资源豁免和良性爬虫UA过滤这三类高优规则置于最前端，SQL注入规则须优先于XSS等次级威胁部署，并避免宽泛正则引发误杀，同时善用priority字段（或手动调整数组索引）精准控制执行时序，否则再严密的规则也可能因顺序错位而形同虚设，甚至导致管理员被拦截、CDN缓存失效或CPU过载崩溃。

规则匹配顺序决定拦截效果

PHPWAF 是按配置文件中规则出现的**从上到下顺序**逐条匹配的，一旦某条规则命中（match为 true），就会立即执行对应动作（如 deny、log 或跳过后续检查），后面的规则不再触发。这不是“权重打分”，而是典型的“短路匹配”。所以把高频误触或低风险规则放前面，等于主动给攻击者让路。

必须前置的三类高优规则

以下规则建议硬性放在 config.php 的 $rules 数组最顶部（或规则文件最开头）：

• 白名单 IP 检查：用 $config['allow_ips'] = ['192.168.1.0/24', '203.0.113.5']; 直接 skip，避免管理员被自己 WAF 拦在门外
• 静态资源豁免：对 .js、.css、.png 等后缀加 skip 规则，否则每张图片请求都要跑一遍 SQL/XSS 正则，白白拖慢 TTFB
• 已知良性爬虫 UA 过滤：匹配 Googlebot|Bingbot|yandex 并 skip，否则搜索引擎抓取时可能触发误限速或质询

SQL 注入规则别堆在底部

很多人把 enable_sql_injection = true 当开关用，其实它背后是若干正则规则（如 union\s+select、sleep\(\d+\)）。如果这些规则排在 XSS 或文件上传规则之后，而攻击者先发一个带 的 payload 被 XSS 规则拦住，SQL 注入特征反而没机会被检测——但真实攻击常混用多种手法。正确做法是：

• 把 SQL 注入相关正则单独提成一组，放在 XSS 规则之前（因为 SQL 注入更致命、特征更稳定）
• 避免写过于宽泛的规则，例如 select.*from 会误杀 SELECT * FROM users WHERE name LIKE '%select%'，改用 \b(select|union|insert)\s+(all\s+)?(into\s+)?from\b 更稳妥
• 对 POST /wp-admin/admin-ajax.php 这类高危接口，可额外加一条「强匹配 + deny」规则，不依赖通用 SQL 规则库

自定义规则要设 priority 字段（若支持）

部分 PHPWAF 分支（如 GitHub 上 phpwaf/rules v2.3+）支持在自定义规则里显式声明 priority，数值越小越靠前。例如：

$config['custom_rules'][] = [
  'pattern' => '/wp-login\.php$/i',
  'source' => 'REQUEST_URI',
  'action' => 'challenge',
  'priority' => 10
];
$config['custom_rules'][] = [
  'pattern' => '/union\s+select/i',
  'source' => 'REQUEST_BODY',
  'action' => 'deny',
  'priority' => 5  // 这条会比上面那条先执行
];

没这个字段的版本，就老老实实按数组索引顺序排——别指望靠注释或空行控制优先级。上线前务必用 curl -X POST "http://yoursite.com/?id=1%20union%20select%201,2,3" 验证是否真被拦在登录页之前。

规则排序不是调参游戏，是防御逻辑的拓扑结构。漏掉白名单或把静态资源检查放太后面，再强的 SQL 规则也救不了 CPU 100% 的夜。

好了，本文到此结束，带大家了解了《PHPWAF规则优先级设置方法解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！