使用JMeter测试IdentityServer登录时POST请求返回200而非302求助

我之前也踩过IdentityServer和JMeter配合的类似坑，给你梳理几个大概率的排查方向，应该能帮你定位问题：

1. 检查Cookie的传递是否完整 #

IdentityServer严重依赖会话Cookie，尤其是idsrv.session这类核心Cookie。Fiddler里的浏览器请求会自动带上所有关联Cookie，但JMeter如果没配置好Cookie管理器，很可能漏传了关键凭证：

• 确保测试计划最顶部添加了HTTP Cookie管理器，它会自动保存和发送后续请求的Cookie。
• 对比Fiddler请求头的Cookie字段，和JMeter请求实际发送的Cookie内容，保证所有会话Cookie、防伪令牌关联Cookie完全一致。

2. 验证Anti-Forgery Token（防伪令牌）是否正确 #

IdentityServer的登录请求必须携带动态生成的防伪令牌（通常是__RequestVerificationToken或类似字段），这个令牌和当前会话绑定，不能硬编码：

• 先添加一个HTTP请求获取登录页面，用正则表达式提取器或CSS选择器，从页面HTML中提取令牌值。
• 确保登录请求的表单参数里正确填入这个令牌，参数名称要和Fiddler抓包的表单字段完全匹配。
• 注意：每次加载登录页面都会生成新令牌，必须动态提取，不能重复使用旧值。

3. 补全请求头的关键字段 #

浏览器发送的请求会带上User-Agent、Accept、Referer等标准头，JMeter默认的请求头可能不全，导致IdentityServer判定请求非法：

• 把Fiddler中请求的所有非自动生成头（除Cookie和Host）复制到JMeter的HTTP信息头管理器中。
• 重点检查Referer头：登录请求的Referer必须是登录页面的URL，IdentityServer会验证请求来源的合法性。

4. 深挖响应和日志的隐藏信息 #

你提到返回的HTML只有“Error”，可以通过以下方式获取更多细节：

• 在JMeter的HTTP请求中勾选「Save Response to file」，把完整响应保存下来，查看HTML的注释、隐藏DOM元素里的错误描述。
• 打开JMeter的jmeter.log文件，搜索请求相关的日志，看有没有参数错误、Cookie缺失之类的警告。
• 可以在IdentityServer服务器端开启调试日志，直接查看拒绝请求的具体原因（比如令牌无效、来源验证失败等）。

5. 调整重定向的处理逻辑 #

Fiddler显示的是302重定向，但JMeter默认会自动跟随重定向，可能你看到的200是重定向后的错误页面：

• 暂时把HTTP请求的「Follow Redirects」和「Auto-Redirects」都改成false，这样就能看到原始的302响应，以及Location头指向的目标地址。
• 如果Location指向错误页面，说明登录请求本身已被拒绝，还是要回到Cookie、令牌、请求头的排查环节。

我之前就是因为漏传了X-XSRF-TOKEN这个请求头，导致IdentityServer直接返回200错误页面，补全字段后就正常返回302重定向到登录成功页面了，你可以参考这个思路试试。

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