JMeter压测Mendix应用axs请求返回560异常如何排查解决

问题现象 #

• 为Mendix Web应用编写JMeter负载测试脚本时，发起axs请求收到{"result":560,"type":"exception"}响应
• 初始登录阶段曾出现未授权响应，通过正则表达式提取器提取CSRF-TOKEN后登录流程已恢复正常
• 完成登录后执行应用提交操作时，再次触发上述560异常响应

核心诱因 #

• CSRF令牌作用域不匹配：Mendix的CSRF令牌并非登录后全会话通用，部分场景下令牌会和当前页面上下文、请求调用序列、会话临时标识绑定，仅提取登录阶段返回的令牌，无法通过提交操作的安全校验
• 必要自定义请求头缺失：Mendix前端原生发起axs请求时，会自动携带X-Mx-ReqToken、页面来源标识、会话上下文标记等非标准HTTP头，脚本漏传这类头时会直接触发服务端校验拦截
• 会话状态传递断裂：登录后生成的会话Cookie、临时状态Cookie未被JMeter正确存储和传递，提交操作时服务端无法识别有效会话上下文
• 动态参数未关联：Mendix业务提交请求会携带前端实时生成的临时校验参数、页面状态ID，脚本硬编码固定参数值时，服务端会判定请求为非法构造请求
• 前置依赖请求缺失：应用提交操作依赖前置页面加载、表单初始化等接口返回的临时状态值，脚本跳过前置环节直接发起提交请求，会因上下文缺失触发异常

排查解决步骤 #

• 全链路请求对比
  用浏览器开发者工具录制人工操作时从登录到提交应用的完整请求链路，逐次记录每个请求的请求头、Cookie集合、请求体参数、Content-Type配置，和JMeter脚本中对应步骤的请求逐一比对，优先排查非业务类自定义参数、请求头的差异。
• 修正动态值关联规则
  不要仅在登录步骤提取CSRF令牌，需要在每一次页面加载、交互请求的响应头、响应体中提取最新的CSRF-TOKEN、X-Mx-ReqToken、页面上下文ID（如mxpage、contextid类参数），动态替换后续请求中对应的硬编码值；同时为JMeter测试计划添加标准HTTP Cookie管理器，配置为兼容浏览器的Cookie存储策略，自动传递全流程会话Cookie，不要手动硬编码固定Cookie值。
• 补全请求链路与格式校验
  确认提交操作的所有前置依赖请求（表单页加载、初始化数据拉取、前置校验接口等）都已加入脚本执行序列，不要跳过前置步骤直接发起提交请求；核对请求体的编码格式、参数顺序、Content-Type配置和浏览器原生请求完全一致，Mendix对请求格式校验规则严格，格式不匹配也会触发560异常。
• 服务端日志定位
  若上述操作后异常仍存在，直接查看Mendix服务端运行日志，560异常的日志条目会明确标注具体校验失败原因（如令牌过期、上下文不存在、参数非法等），可根据日志提示直接修正脚本逻辑。

内容的提问来源于stack exchange，提问作者Jumana Haimour