JMeter HTTP请求经Fiddler正常，直接执行失败问题排查

这种直接运行JMeter失败、走代理却正常的情况，本质是两种运行模式下，发送给服务器的请求细节存在差异——代理工具（比如你用的127.0.0.1:8888大概率是Fiddler）可能自动修正了请求中的不规范部分，让服务器能正常识别。下面是具体的排查步骤：

1. 对比两种模式下的完整请求详情 #

这是最关键的一步，直接找到差异点：

• 在JMeter中添加「查看结果树」组件，分别执行直接运行和走代理运行两次测试。
• 打开两次测试中「Get eventId」请求的「请求」标签页，逐行对比以下内容：
  • HTTP请求方法、URL是否完全一致（注意URL中的编码、参数拼接细节）
  • 所有请求Header，重点看Authorization Header的格式：是不是严格的Bearer <你的token>（Bearer后面必须有一个空格，token不能有截断或多余字符）
  • 有没有缺失某些服务器要求的Header（比如Accept、Content-Type，代理可能自动补全了这些）

2. 验证Token提取与传递的正确性 #

虽然Login请求返回200，但有可能Token的提取或传递环节出了问题：

• 检查Login请求的提取器（比如正则表达式提取器、JSON提取器）：确认提取的Token变量名和你在HTTP Header Manager中使用的变量名一致（比如${auth_token}），且提取规则能正确捕获完整的Token。
• 在「查看结果树」中查看「Get eventId」请求的Authorization Header值：直接运行时，这个值是不是完整的Bearer + Token？有没有出现变量未替换（比如显示成${auth_token}）的情况？

3. 检查JMeter的默认配置与请求设置 #

JMeter的一些默认行为可能导致请求不符合服务器要求：

• 确认HTTP Header Manager的作用域：它必须在「Get eventId」请求的父层级（比如线程组）或直接依附于该请求，确保Header能被正确应用。
• 检查HTTP请求的「跟随重定向」「自动处理Cookie」选项：直接运行和走代理时这些选项的状态是否一致？（不过400是客户端错误，重定向问题概率较低，但也值得确认）
• 尝试手动添加必要Header：在HTTP Header Manager中添加Accept: application/json、Content-Type: application/json（有些服务器对GET请求也要求这些Header），再直接运行测试看是否恢复正常。

4. 排查代理的自动修正行为 #

像Fiddler这类代理工具会自动修正请求中的不规范内容，比如：

• 修正Header的大小写（比如把authorization改成Authorization）
• 补全缺失的Host Header
• 去除Header中的多余空格或无效字符
  如果直接运行时的请求存在这类不规范，服务器就会返回400，而代理帮你“修正”了这些问题。

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