当前位置： 首页 > news >正文

JMeter代理服务器配置与脚本录制实战指南

news 2026/6/26 4:22:25

1. 项目概述：为什么需要HTTP(S)代理服务器来录制脚本？

做性能测试，第一步也是最关键的一步，就是生成一个能真实模拟用户行为的测试脚本。很多新手朋友拿到JMeter，第一反应是去手动添加HTTP请求，一个个参数去填。这方法不是不行，但对于一个稍微复杂点的Web应用或移动端应用，手动构建脚本不仅效率低下，而且极易出错，漏掉一个关键的Cookie或者动态参数，整个压测结果就失去了意义。

这时候，录制脚本就成了最高效、最准确的方式。而录制脚本的核心，就是让JMeter作为一个“中间人”，拦截并记录下浏览器或手机App发出的所有网络请求。这个“中间人”角色，就是HTTP(S)代理服务器。它就像在客户端（你的浏览器）和服务器之间架设了一个透明的录音机，所有流经的请求和响应都会被原封不动地记录下来，并转换成JMeter可以理解和回放的测试元件。

我见过太多团队在性能测试初期，因为脚本录制不准确，导致后续的压测完全是在“测试一个错误的场景”，白白浪费了时间和资源。所以，掌握JMeter代理服务器的配置和使用，是构建精准性能测试脚本的基石。无论你是测试一个简单的网页登录，还是一个包含HTTPS加密、动态令牌、文件上传的复杂API流程，代理录制都是绕不开的必备技能。

2. 核心原理与工作流程拆解

要玩转代理录制，不能只停留在“点哪里”的操作层面，必须理解其背后的工作原理。这样当遇到证书错误、请求丢失、乱码等问题时，你才能快速定位并解决。

2.1 JMeter代理服务器如何工作？

JMeter的HTTP(S) Test Script Recorder本质上是一个内置的、可配置的代理服务器。它的工作流程可以概括为以下几个核心步骤：

  1. 启动与监听：你在JMeter中配置好代理服务器的端口（默认8888）和目标控制器（即录制下来的请求要放到哪个线程组里），然后启动它。此时，JMeter会在你本地机器的指定端口上开启一个监听服务。
  2. 客户端代理配置：你需要将浏览器或系统/手机的全局网络代理，设置为指向localhost:8888（即你运行JMeter的机器IP和上述端口）。这相当于告诉浏览器：“你所有要发出去的请求，别直接发给网站服务器了，先发给本机8888端口上的那个程序（JMeter代理）。”
  3. 请求拦截与转发：
    • 浏览器发起一个对https://www.example.com/login的请求。
    • 这个请求根据系统代理设置，被发送到localhost:8888。
    • JMeter代理服务器“听到”了这个请求，它首先会记录下这个请求的所有细节：URL、方法（GET/POST）、请求头（Headers）、请求体（Body）等。
    • 接着，JMeter代理会原样转发这个请求到真正的目标服务器www.example.com。
  4. 响应拦截与记录：
    • 服务器处理请求后，返回响应。
    • 这个响应首先回到JMeter代理服务器。
    • JMeter代理记录下响应的状态码、响应头、响应体（HTML、JSON等）等信息。
    • 最后，JMeter代理将响应原样返回给浏览器。
  5. 脚本生成：JMeter将记录下来的“请求-响应对”，在后台自动创建对应的HTTP Request采样器、HTTP Header Manager等元件，并放入你事先指定的“目标控制器”中。同时，它会自动添加一个Recording Controller来组织这些录制的请求。

整个过程对浏览器和服务器而言几乎是透明的（除了HTTPS需要安装证书），但对JMeter来说，它完整地捕获了一次网络交互，从而生成了一个可回放的测试脚本。

2.2 HTTP vs HTTPS录制的关键差异与证书机制

这是代理录制中最容易卡壳的地方。理解HTTP和HTTPS录制的区别，核心在于理解SSL/TLS加密。

  • HTTP录制：简单直接。因为HTTP是明文传输，JMeter代理可以直接看到请求和响应的全部内容，无需额外处理。
  • HTTPS录制：复杂但必须攻克。HTTPS在传输层对数据进行了加密。如果JMeter不进行特殊处理，它拦截到的只是一堆无法解读的加密乱码。

为了让JMeter能“看懂”HTTPS流量，它采用了“中间人攻击”（Man-in-the-Middle, MITM）的技术方案。具体流程如下：

  1. 生成根证书：当你第一次启动JMeter的HTTP(S)代理服务器时，它会在其bin目录下自动生成一个自签名的根证书文件，通常名为ApacheJMeterTemporaryRootCA.crt。这个证书是JMeter代理自己颁发的，用于建立信任链。
  2. 动态签发站点证书：当浏览器试图与目标服务器（如https://www.example.com）建立HTTPS连接时，请求先被JMeter代理截获。
  3. “欺骗”浏览器：JMeter代理会动态地以自签名根证书为凭据，伪造一个针对www.example.com的站点证书，并发送给浏览器。
  4. 浏览器信任：为了让浏览器接受这个伪造的证书，你必须事先将JMeter生成的那个根证书导入到浏览器或操作系统的受信任根证书颁发机构列表中。一旦完成导入，浏览器就会信任由这个根证书签发的所有子证书，包括JMeter动态伪造的那些。
  5. 解密与再加密：浏览器信任证书后，与JMeter代理建立加密连接。JMeter代理因此获得了会话密钥，可以解密浏览器发来的加密请求。记录下明文请求后，JMeter代理再使用真正的服务器证书与目标服务器建立另一个HTTPS连接，将请求转发出去。响应回来的过程与之相反。

重要提示：正因为这个机制，绝对不要在非测试环境、或处理极其敏感的真实账户信息时使用JMeter代理录制。它本质上是一个安全的“中间人”工具，仅用于性能测试脚本开发。

3. 从零开始的环境配置与代理设置

理论清楚了，我们开始动手。这里我会以Windows/macOS下的Chrome浏览器和iOS/Android手机为例，覆盖最常见的场景。

3.1 JMeter侧配置：启动代理服务器

  1. 启动JMeter：确保你已安装JDK并正确配置了JMeter。
  2. 创建测试计划：新建一个测试计划，建议命名为“脚本录制模板”。
  3. 添加线程组：右键测试计划 -> 添加 -> 线程（用户） -> 线程组。这个线程组将作为我们录制的“容器”。你可以先设置线程数为1，循环次数为1。
  4. 添加录制控制器：右键线程组 -> 添加 -> 逻辑控制器 -> 录制控制器。这个控制器不是必须的，但它能很好地归类录制产生的请求，方便管理。
  5. 配置HTTP(S)测试脚本录制器：
    • 右键工作台（Workbench） -> 添加 -> 非测试元件 -> HTTP(S) Test Script Recorder。
    • 关键参数配置：
      • 端口：默认8888。如果被占用（如某些开发工具），可改为 8889, 9090 等。
      • 目标控制器：选择我们刚才创建的“线程组 -> 录制控制器”。这决定了录制的请求存放位置。
      • 分组：建议选择“每个组放入一个新的控制器”，这样能按页面或功能模块自动归类请求，脚本结构更清晰。
      • 请求过滤：这是提升录制效率的关键！在“Requests Filtering”区域添加包含模式（Include）和排除模式（Exclude）。
        • 添加建议排除：.*\.(js|css|png|jpg|jpeg|gif|ico|woff|woff2|ttf|eot|svg)。这可以过滤掉大部分的静态资源（图片、样式、脚本），让脚本专注于核心的业务请求（API接口、页面提交等），脚本更干净，回放更快。
    • 启动：点击下方的“启动”按钮。此时JMeter的代理服务器就开始在本地8888端口监听了。

3.2 客户端侧配置：让流量经过JMeter

3.2.1 桌面浏览器配置（以Chrome为例）

方法一：操作系统全局代理（推荐，一劳永逸）

  • Windows：设置 -> 网络和Internet -> 代理 -> 手动设置代理 -> 打开“使用代理服务器”，地址填127.0.0.1，端口填8888。
  • macOS：系统设置 -> 网络 -> 选择当前网络 -> 高级 -> 代理 -> 勾选“网页代理(HTTP)”和“安全网页代理(HTTPS)”，服务器填127.0.0.1，端口填8888。

方法二：浏览器命令行启动（灵活，不影响其他应用）关闭所有Chrome窗口，通过命令行启动：

# Windows chrome.exe --proxy-server="127.0.0.1:8888" --ignore-certificate-errors # macOS open -n -a "Google Chrome" --args --proxy-server="127.0.0.1:8888" --ignore-certificate-errors

--ignore-certificate-errors参数很重要，它让Chrome忽略证书错误，便于我们安装JMeter的根证书。

3.2.2 移动设备（手机/平板）配置

录制手机App流量是常见需求，尤其是测试混合应用或原生App的后端接口。

  1. 确保电脑和手机在同一局域网：连接同一个Wi-Fi。
  2. 查找电脑的局域网IP：
    • Windows: 命令提示符输入ipconfig，查看“无线局域网适配器 WLAN”或“以太网适配器”下的IPv4 地址。
    • macOS/Linux: 终端输入ifconfig | grep "inet "，找到类似192.168.1.105的地址。
  3. 在手机上配置代理：
    • iOS：设置 -> Wi-Fi -> 点击当前连接的Wi-Fi右侧的 (i) 图标 -> 配置代理 -> 手动 -> 服务器填电脑的IP（如192.168.1.105），端口填8888。
    • Android：设置 -> 网络和互联网 -> Wi-Fi -> 点击当前连接的Wi-Fi -> 修改网络 -> 高级选项 -> 代理选择“手动” -> 主机名填电脑IP，端口填8888，保存。
  4. 在手机浏览器中安装JMeter根证书：
    • 在手机浏览器中访问http://电脑IP:8888（例如http://192.168.1.105:8888）。这是JMeter代理提供的一个简单页面。
    • 点击页面上的链接（如ApacheJMeterTemporaryRootCA.crt）下载证书。
    • iOS：下载后进入设置 -> 通用 -> VPN与设备管理 -> 已下载的描述文件 -> 安装。然后还需进入 设置 -> 通用 -> 关于本机 -> 证书信任设置，找到该根证书并完全信任。
    • Android：不同品牌路径不同，通常在 设置 -> 安全 -> 加密与凭据 -> 安装证书 -> CA证书 中操作。安装时可能会要求设置锁屏密码。

实操心得：手机录制时，一个常见的坑是录不到任何请求。首先检查防火墙，确保电脑的8888端口对局域网是开放的（可在电脑上暂时关闭防火墙测试）。其次，有些App使用了证书绑定（SSL Pinning）技术，会拒绝JMeter的中间人证书，导致连接失败。对于这类App，需要更复杂的逆向工程手段来绕过，这超出了基础录制的范围。

4. 精准录制：过滤、增强与脚本优化

配置好就能录，但要想录得“精准”、“干净”，还需要一些技巧。

4.1 请求过滤：让脚本聚焦核心业务

在JMeter代理服务器的配置界面，Requests Filtering区域是你的核心武器。除了之前提到的排除静态资源，你还可以：

  • 包含模式（Include）：如果你只想录制特定域名的请求，比如.*\.myapp\.com.*。这在测试微服务或特定子系统时非常有用。
  • 排除模式（Exclude）：进一步排除一些已知的、无关的请求。例如，排除第三方分析SDK的请求：.*google-analytics\.com.*，或者排除一些健康检查接口：.*/health.*。

合理使用过滤可以大幅减少后期脚本清理的工作量。

4.2 自动添加监听器与断言

在代理服务器配置的底部，有一个“添加断言”的选项。你可以勾选“为录制的请求添加断言”，并选择断言类型，如“响应断言”，自动检查响应中是否包含特定文本。但我个人不推荐在录制阶段就自动添加过于复杂的断言，因为这可能因测试数据不同导致断言失败。更好的做法是录制完成后，根据业务逻辑手动添加针对性的断言。

4.3 录制后的脚本整理与增强

录制完成的脚本只是一个“毛坯房”，需要装修才能入住。

  1. 清理无用请求：删除那些过滤规则没拦住的、明显无关的请求（如favicon.ico、广告请求等）。
  2. 参数化与关联：这是脚本能否成功回放的灵魂。
    • 参数化：将脚本中的固定值（如用户名、密码、商品ID）替换为变量。使用__Random(),__CSVRead()或通过User Defined Variables配置元件来管理。
    • 关联：动态数据（如Session ID、订单号、CSRF Token）必须从服务器响应中提取出来，并用于后续请求。使用正则表达式提取器或JSON提取器来捕获这些值，并保存为变量（如${token}）。
  3. 添加事务控制器与思考时间：
    • 将一系列相关的请求（如“登录-浏览商品-加入购物车”）放入一个事务控制器下，这样JMeter会统计整个事务的响应时间。
    • 在请求之间添加固定定时器或高斯随机定时器来模拟用户操作间隔（思考时间），使测试更贴近真实场景。
  4. 添加监听器用于调试：在调试脚本阶段，添加查看结果树和调试取样器监听器，可以详细查看每个请求的发送内容和服务器响应，是排查问题的利器。注意：在正式压测时，务必禁用或移除这些非常消耗资源的监听器。

5. 高级场景与疑难问题排查实录

掌握了基础操作，我们来看看一些更复杂的场景和那些让人头疼的“坑”。

5.1 处理复杂身份验证（OAuth2, JWT）

现代应用常用OAuth2或JWT令牌。录制这类流程的关键在于捕获令牌的获取和使用。

  • 录制流程：正常操作登录流程。你会在录制结果中看到向授权服务器（如/oauth/token）发送的请求，其响应体里包含了access_token。
  • 关联处理：使用JSON提取器从该响应中提取access_token，存入变量如${access_token}。
  • 后续使用：在需要认证的API请求头中，添加Authorization: Bearer ${access_token}。这通常通过一个HTTP信息头管理器来实现，并将其作用域设置为全局或特定线程组。

5.2 处理文件上传与下载

录制文件上传时，JMeter会正确记录multipart/form-data格式的请求。回放时，你需要确保文件路径是有效的，并且文件存在于JMeter运行的机器上。对于文件下载，需要注意JMeter默认会处理响应数据，如果下载文件很大，可能会内存溢出。可以考虑使用Save Responses to a file监听器，或者直接不处理该请求的响应体。

5.3 常见错误与解决方案速查表

以下是我在多年实践中总结的典型问题及排查思路：

问题现象可能原因排查与解决步骤
浏览器提示“您的连接不是私密连接”或证书错误1. JMeter根证书未安装或未信任。
2. 浏览器代理设置错误，未指向JMeter。		1. 确认已从http://localhost:8888下载并安装证书，且在系统/浏览器中完全信任。
2. 检查浏览器代理设置是否为127.0.0.1:8888。用命令行启动Chrome并添加--ignore-certificate-errors参数临时绕过。
JMeter代理启动失败，提示“Address already in use”8888端口被其他程序占用（如Fiddler、Charles、其他JMeter实例）。1. 在JMeter中更换代理端口（如8899）。
2. 查找并关闭占用端口的进程（netstat -ano | findstr :8888）。
录制时无任何请求出现在JMeter中1. 客户端代理配置错误。
2. 防火墙阻止了连接。
3. JMeter代理的“目标控制器”设置错误。		1. 双重检查浏览器/系统/手机的代理IP和端口。
2. 暂时关闭电脑防火墙测试。
3. 确认JMeter中HTTP(S) Test Script Recorder的“目标控制器”指向了正确的线程组或控制器。
手机无法访问网络，或App提示网络错误1. 电脑和手机不在同一网络。
2. 手机未正确安装/信任JMeter CA证书。
3. App使用了SSL Pinning。		1. 确认IP地址是电脑的局域网IP，且手机能ping通。
2. 按照前述步骤重新在手机端安装并信任证书（特别是iOS的“完全信任”步骤）。
3. 对于SSL Pinning的App，标准代理录制无效，需寻求其他方案（如逆向修改App）。
录制到的请求响应乱码服务器响应头未指定正确编码，或JMeter解析有误。1. 在HTTP请求的“内容编码”处手动指定，如utf-8。
2. 在测试计划级别勾选“函数助手中的字符串使用编码”。
3. 使用后置处理器中的 “BeanShell PostProcessor” 手动转换编码。
回放脚本时，出现404/500等错误，但录制时正常1.动态参数未关联（如Session ID, Token）。
2. 请求顺序或依赖关系错误。
3. 测试环境与录制环境不同。		1.这是最常见原因！使用“查看结果树”对比录制和回放的请求详情，重点检查Cookie、Header和Body中的动态值。使用提取器（正则/JSON）捕获并替换。
2. 检查脚本逻辑，确保前置请求（如登录）已成功执行。
3. 检查脚本中的域名、IP地址是否指向正确的测试环境。

5.4 性能测试脚本的“瘦身”与优化

一个直接从生产环境录制下来的脚本，如果不加处理直接用于压测，往往会包含大量冗余请求，导致施压机资源浪费，测试结果也不纯粹。

  1. 删除静态资源请求：利用过滤规则和手动清理，彻底移除.js,.css,.png等文件的请求。这些请求通常可以通过Web服务器的缓存策略解决，不应作为后端压力的主要来源。
  2. 合并重复请求：检查是否有完全相同的URL被重复请求多次，可以考虑只保留一次，或使用循环逻辑控制器来控制请求次数。
  3. 关掉“自动重定向”和“跟随重定向”：在HTTP请求默认值或单个HTTP请求中，将“Redirect Automatically”和“Follow Redirects”取消勾选。让JMeter明确地处理每一个重定向请求（状态码302/301），这样你才能清晰地看到重定向链路上的每一步性能，而不是一个合并后的模糊时间。
  4. 使用模块化控制器：将通用的操作（如登录、退出）封装成模块控制器或测试片段，在不同场景中复用，使脚本结构更清晰，维护更方便。

构建一个精准的性能测试脚本，远不止是点一下录制按钮。从理解代理工作的原理，到跨客户端的证书配置，再到录制后的深度清洗与参数化，每一步都藏着细节。最核心的教训永远是：录制只是开始，关联和参数化才是让脚本“活”起来的关键。下次当你回放脚本失败时，第一个动作就应该是打开“查看结果树”，逐字逐句地对比录制与回放的请求差异，九成的问题都能在这里找到答案。把代理录制玩熟了，你就掌握了性能测试一半的主动权。

http://www.jsqmd.com/news/1079114/

相关文章：

  • 网络安全深度预警实战推演：从漏洞爆发到纵深防御体系构建
  • SQL创建表简单示例：手把手教你写出第一行CREATE TABLE代码
  • 卡梅德生物技术快报｜人源 scFv 抗体蛋白噬菌体文库搭建全流程实操与数据复盘
  • 玄通数据，专业用户行为数据分析 SaaS 系统正式入驻企业应用市场
  • 线弹性有限元计算机床自重，并添加切削力负载
  • 构建机器学习前沿动态信息流操作系统
  • 从势函数到声子谱：材料计算中的晶格动力学原理与实操指南
  • Crewdle AI 智能体协作落地实战指南
  • 南康好用的广告设计哪家靠谱
  • XSKY AIMesh 新版本发布：一站式 AI 数据基础设施，驱动数据全链路流转
  • 数字货币安全机制研究——应用密码学课程调研总结
  • 2026求职必备：8款 AI简历工具盘点（自动生成+智能润色+一键导出）
  • 逆向工程基础：如何读懂没有源代码的二进制程序
  • 学术打假越来越像流量生意，MedPeer用技术做了一件不一样的事
  • 2026年线上考试用什么软件？一文说清如何挑选
  • env与argv的区别与应用场景
  • 纤维素纳米纤维接枝聚丙烯酸(CNF-g-PAA)pH响应水凝胶的性能
  • 【6.18】射频基础：混频器与 PLL 锁相环的绑定关系，一条链路讲透。
  • 36-任务作业模型与异步控制台：长任务为什么不能直接绑在页面请求上
  • LDFEditor：LIN网络配置与诊断文件编辑的核心工具详解
  • dockurwindows：在 Docker 里跑 Windows
  • 做Ozon怎么实现一件代发？Ozon一件代发操作流程！
  • 如何通过RDP Wrapper Library解锁Windows多用户远程桌面功能？
  • 【每日复盘与反思】2026.6.25
  • Cmake 基础用法
  • DMX 报 Agent RPC error (-1): com.kingbase8.utiL.KSQLException: ERROR: relation “sys _database“ does n
  • 跨越语言的二进制光纤（下篇）：gRPC 微服务重构与 HTTP/2 多路复用深度拆解
  • 锌离子Zn2+响应水凝胶的结构与响应机制
  • Shopee虾皮API｜根据ItemID获取商品详情 完整对接教程
  • Sunshine游戏串流完全指南：打造个人专属云游戏服务器终极教程