在版本v2.2.4中WAF打开人机滑动后出现请求携带恶意参数已被拦截，关闭人机滑动恢复正常，地址是ip+端口
截图你的配置
v2.2.4 开启 WAF 自定义人机滑动规则后，正常请求被错误拦截
一、环境信息
- 1Panel 版本：v2.2.4
- OpenResty 镜像版本：1.31.1.1-2-1-noble
- WAF 运行版本：2.0
- 访问方式：HTTPS + IP 地址 + 自定义端口
- 示例地址：
https://<服务器IP>:<HTTPS端口>/ - 浏览器：Google Chrome
二、问题描述
升级至 1Panel v2.2.4 及对应的 OpenResty/WAF 组件后，在网站的自定义 WAF 规则中开启“人机滑动”验证，访问网站根路径 / 时，没有正常显示滑动验证页面，而是直接返回 403 页面，提示：
请求携带恶意参数，已被系统拦截
关闭该人机滑动规则后，网站立即恢复正常访问。
经检查，请求中没有携带 SQL 注入、XSS 或其他恶意参数，WAF 攻击记录中也没有对应的恶意请求记录。
三、复现步骤
- 在 1Panel 中创建或选择一个通过“IP + HTTPS 自定义端口”访问的网站。
- 进入该网站的 WAF 自定义规则。
- 新建或启用以下规则：
- 匹配对象：URL
- 匹配方式：等于
- 匹配内容：
/ - 执行动作：人机滑动验证
- 使用无验证缓存、无有效访问令牌的浏览器访问：
https://<服务器IP>:<HTTPS端口>/ - 问题稳定复现：未进入滑动验证流程，直接返回 403 恶意参数拦截页面。
- 关闭该规则后，再次访问即恢复 HTTP 200。
四、实际结果
- 根路径请求被返回 HTTP 403。
- 页面显示通用的“请求携带恶意参数”提示。
- 浏览器没有加载人机滑动验证页面。
- 请求过程中没有出现滑动验证接口或访问令牌设置接口。
- WAF 攻击日志中没有发现对应的 SQL 注入、XSS 等攻击记录。
五、预期结果
匹配到“人机滑动”规则后，应返回 HTTP 200 的滑动验证页面；验证通过后设置访问令牌，再放行原始请求，而不是进入通用 403 拦截流程。
六、排查结果
- 同一个网站在关闭人机滑动规则时可以正常返回 HTTP 200。
- 开启规则后，普通的
GET /请求直接变为 HTTP 403。 - 返回内容与 WAF 通用禁止访问页面相符，不是滑动验证页面。
- 失败请求发生时，没有调用滑动验证相关接口，说明异常发生在人机验证流程启动之前。
- 同一服务器、同一“IP + 端口”访问方式，在升级前曾能够正常加载滑动验证并设置访问令牌，因此初步排除“IP + 端口不支持人机验证”的问题。
- 网站监听端口和 WAF 站点映射均正常，目标端口已经正确归属到对应网站。
- 当前没有命中临时封禁、访问频率限制或已知攻击规则的证据。
- 问题出现在升级 1Panel v2.2.4 及新版 OpenResty/WAF 组件之后。
七、初步判断
初步怀疑这是 v2.2.4 配套 OpenResty/WAF 2.0 组件在人机验证动作处理流程中的回归问题。
自定义规则匹配成功后，原本应进入人机滑动验证分支，但实际未生成验证页面，也未进入验证接口流程，而是错误进入或表现为通用拒绝访问流程。
页面中的“请求携带恶意参数”应当只是通用 403 模板提示，并不能证明请求实际携带了恶意参数。
由于专业版 WAF 的核心 Lua 文件为编译后的字节码，目前无法进一步定位到具体源码行。
八、希望官方协助确认
- v2.2.4 是否修改了自定义规则中
captcha/人机滑动动作的处理流程？ - 新版 WAF 的检测、观察及最终动作处理是否可能将人机验证动作错误转换为拒绝访问？
- 使用“IP + HTTPS 自定义端口”访问时，新版组件是否存在未覆盖的兼容性问题？
我测试了一下 没有被拦截
截图你的配置页面
和 拦截日志的详情
没有拦截日志， v2.2.4 配套的 1panel/openresty:1.31.1.1-2-1-noble 存在回归。自定义 ACL 的 captcha 动作命中后，没有生成滑动验证页面，而是错误按照规则的code/res结束请求。完全相同的配置使用旧镜像 1.31.1.1-0-noble 可以正常返回 HTTP 200 滑动验证页面。
为排除网站配置、IP+端口和浏览器缓存影响，我使用完全相同的网站配置及规则副本进行了隔离镜像对比：
旧镜像 1.31.1.1-0-noble：返回 HTTP 200，页面标题为“滑动验证”，滑动页面内容完整。
新镜像 1.31.1.1-2-1-noble：返回 HTTP 403，页面标题为“请求拦截”。
因此，相同配置只有更换 OpenResty/WAF 镜像后才出现问题，可以排除网站本身及 IP+端口配置问题。
新版增加了 detection.lua 异常评分汇总流程，相关执行过程为：
自定义 ACL 命中 action=captcha。
新版 action.exec_action() 没有像旧版一样立即执行滑动验证，而是先调用 detection.add_match() 将规则加入异常评分队列。
detection.add_match() 中仍然保留了命中规则的 action=captcha、code=403 和 res。
但 detection.finalize() 构造最终动作时，没有使用主命中规则的 action=captcha，而是使用了事务级的全局处置动作。
在保护模式下，最终动作被转换为 deny，同时继续沿用原规则的 code=403 和空 res。
最终实际执行的是 deny + 403 + 空响应内容，所以显示了通用 forbidden 页面，而不是滑动验证页面。
我还做了一个状态码对照：仅把同一条规则的 code 从 403 改成 200，新镜像会返回 HTTP 200，但响应体为空，仍然不会生成滑动验证页面。这进一步证明新版执行了最终 code/res，但丢失了 captcha 动作。
我不知道这个是不是官方人员，他说他测试没问题，OpenResty回退上个版本就好了。然后等下个版本吧
找了下拦截日志，没有记录 
好的 我看一下这个
确实有问题 我测试的时候用了旧的镜像
POST /system/cmd.php?act=search HTTP/2.0
SEC-FETCH-DEST: document
CACHE-CONTROL: max-age=0
UPGRADE-INSECURE-REQUESTS: 1
SEC-FETCH-USER: ?1
HOST: www.123.com
CONTENT-LENGTH: 5
CONTENT-TYPE: application/x-www-form-urlencoded
COOKIE: timezone=8
SEC-CH-UA: “Not;A=Brand”;v=“8”, “Chromium”;v=“150”, “Microsoft Edge”;v=“150”
ORIGIN: https://www.123.com
SEC-CH-UA-MOBILE: ?0
SEC-CH-UA-PLATFORM: “Windows”
DNT: 1
PRIORITY: u=0, i
ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
ACCEPT-LANGUAGE: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6
SEC-FETCH-SITE: same-origin
ACCEPT-ENCODING: gzip, deflate, br, zstd
SEC-FETCH-MODE: navigate
REFERER: https://www.123.com/
USER-AGENT: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36 Edg/150.0.0.0
已复现 马上修复
已修复
在本地环境中测试通过
是否能提供在线环境测试？
或者可以直接 拉取镜像 1panel/openresty:1.31.1.1-2-2-noble
修改 compose 文件 在你本地测试