re.search 更安全，因其扫描整个字符串匹配恶意模式，而 re.match 仅从开头匹配易漏掉中间或末尾的攻击载荷，且需配合 re.DOTALL 和 re.IGNORECASE 等标志确保跨行、大小写不敏感匹配。
Python WAF 规则里写正则，为什么 re.search 比 re.match 更安全？
WAF 规则常要检测请求体或 header 里是否含恶意模式，比如 SQL 注入特征 ' OR 1=1。用 re.match 容易漏掉——它只从字符串开头匹配，而攻击载荷可能藏在中间或末尾。
-
re.search扫描整个字符串，适合检测任意位置的关键词、编码绕过（如%20OR%201%3D1） - 注意默认不支持多行匹配，如果规则要跨
\n检查（比如 POST body），得加re.DOTALL标志 - 避免用
^和$锚定，除非你明确只关心整行内容；WAF 输入不是“一行一请求” - 正则本身要加
re.IGNORECASE，否则union select和UNION SELECT就漏一个
if re.search(r"(?i)union\s+select", payload, re.DOTALL):
block_request()
Lua 脚本在 OpenResty WAF 中怎么访问原始请求体？
OpenResty 的 ngx.req.read_body() 不是自动触发的，很多规则写了 ngx.var.request_body 却返回空——因为 body 没被读取，或者被其他模块提前消费了（比如 lua_need_request_body on 没配，或用了 proxy_pass 后 body 被清空）。
- 必须在
access_by_lua_block阶段调用ngx.req.read_body()，不能只依赖配置项 - 读取后用
ngx.var.request_body取值；若为空，检查是否被client_max_body_size截断，或是否超过client_body_buffer_size导致写入临时文件（此时要用ngx.req.get_body_data()或读文件） - 请求体可能被编码（
application/x-www-form-urlencoded或multipart/form-data），直接正则容易失效；简单场景可先用ngx.unescape_uri解码 URL 编码部分，复杂结构建议交给专用解析器
Python 和 Lua 规则共存时，URL 解码顺序不一致导致绕过
Python 规则通常在 WAF 入口层处理已解码的字符串（比如 Flask/Werkzeug 自动解码），而 Lua 在 Nginx 层看到的是原始字节流。同一段 payload %2527（即 %27 的二次编码），Python 可能解成 '，Lua 还是原样——规则如果只在 Lua 里写 %'%，就匹配不到。
- 统一在最外层做一次标准解码：Lua 用
ngx.unescape_uri(ngx.var.args)或对 body 做类似处理；Python 侧确认框架没多解一次（比如 Werkzeug 默认解一次，但某些中间件会再解） - 不要依赖“自动解码”，显式控制解码轮数；二次编码绕过很常见，规则应覆盖
%2527、%u0027等变体 - 如果用正则匹配，把常见编码形式全列进 pattern，比如
r"(%27|%2527|%u0027|\x27)"，别只写'
性能敏感场景下，Lua 正则比 Python 快，但别滥用 ngx.re.match
OpenResty 的 ngx.re.match 是 PCRE 编译后复用的，确实比 Python 的 re 模块快；但它默认开启 JIT，遇到回溯型正则（比如 (a+)+b）可能卡住 worker 进程，引发超时或拒绝服务。
立即学习“Python免费学习笔记（深入）”；
- 写正则时禁用贪婪量词嵌套，用原子组或占有性量词（
(?>...)）；实在不行，用字符串查找（string.find）代替复杂正则 - Python 规则若跑在独立进程（如用
subprocess调外部脚本），IPC 开销远大于正则本身，不如把逻辑移到 Lua 层 - Lua 里不要在循环中反复编译正则，用
local re = require "resty.core.regex"+regex.new(..., "j")预编译并缓存
规则越靠近网络边缘越高效，但越靠近业务逻辑越准确——平衡点往往不在语言本身，而在你愿不愿意为一次误报多写两行解码逻辑。
