宝塔waf拦截正常请求应通过白名单、url忽略或调整阈值解决：①ip白名单绕过全部检测；②对特定url忽略触发规则；③调高精准防护参数上限。
这不是浏览器缓存或 MySQL 严格模式的问题，而是宝塔 WAF 防火墙在拦截请求。看到“您的请求带有不合法参数”就去清浏览器缓存、关 MySQL 严格模式，基本是白忙活——两者完全不相关。
为什么清浏览器缓存没用
这个提示由宝塔 WAF（Web Application Firewall）模块在 Nginx/Apache 请求处理链路的早期阶段直接返回，压根没走到 PHP 或前端资源加载环节。浏览器缓存只影响 app.css、app.js 这类静态文件的加载，和 WAF 拦截无关。
- 清缓存后仍报错 → 说明问题在服务端规则匹配，不是本地副本旧了
- 隐身窗口访问同样报错 → 进一步排除浏览器侧干扰
- 错误响应状态码通常是
403，Response Headers 里带X-Request-ID和X-WAF-Status: blocked
关闭 MySQL 严格模式根本不对路
sql_mode=NO_ENGINE_SUBSTITUTION 只影响 MySQL 解析 SQL 时的行为（比如是否允许插入空字符串到 NOT NULL 字段），和 HTTP 请求参数校验毫无关系。WAF 拦截发生在数据库连接建立之前，连 mysql_connect() 都没调用，MySQL 配置动了也毫无作用。
- 改完
my.cnf并重启 MySQL 后依然报错 → 正常现象，因为根本没走那儿 - 面板日志
/www/server/panel/logs/error.log里搜不到任何 MySQL 相关报错，但能看到waf_block记录 - 如果你同时遇到“插入失败”+“不合法参数”，那是两个独立问题，别混为一谈
真正该查的是 WAF 规则匹配行为
宝塔 WAF 默认启用基于关键词和结构的正则匹配，比如把 desc 当成 SQL 注入词、把 base64_ 前缀当成恶意编码、把未编码的 " 或 // 当成路径遍历信号。它不看上下文，只做字符串扫描。
- 常见触发点：
sort=desc、filter={"status":"active"}（JSON 未encodeURIComponent）、path=/api/v1/users//123、data=select%20*%20from（即使只是日志字段值） - 快速验证：登录宝塔 → 网站 → 对应站点 → 防火墙 → 把安全级别临时调为「低」→ 保存 → 重启 Nginx → 再试请求；若不报错了，就是 WAF 误拦
- 生产环境不能长期开低级别，必须加白名单：放行类型选
POST，放行 URL 填/api/v1/submit，放行值留空（全放行该接口所有参数） - 更稳妥的做法是代码侧规避：前端对敏感字段值做
encodeURIComponent()，后端接收时再解码；或把desc改成descending，select改成choose，避开规则库关键词
容易被忽略的关键细节
WAF 白名单规则里填的正则必须以 ^ 开头、$ 结尾，中间不能换行；写错一个字符，整条规则就静默失效。另外，修改 WAF 配置后必须点右上角「保存」，且部分宝塔版本要求手动重启 Nginx 才生效——光点「保存」不重启，等于没改。
