[bug] 相同URL不同请求头的接口，重定向-重写之后，请求头会复用第一个接口的请求头

[Sisyphean-a]

Describe the bug
在 Windows 版 Reqable 中，对 HTTP/2（h2）请求使用「重写 → 重定向」功能时，如果多个请求的 URL 相同，但请求头中的 apiName 不同，重定向到另一个地址后，后续请求的 apiName 会变成第一个请求的值。

例如原始请求分别为：

请求 1：apiName = A
请求 2：apiName = B
请求 3：apiName = C

经过重定向后，目标服务实际收到：

请求 1：apiName = A
请求 2：apiName = A
请求 3：apiName = A

其他重写规则均未启用，仅启用了这一条「重定向」规则。

另外，如果将重定向目标设置为原请求自身的地址，则不会出现该问题。

To Reproduce
Steps to reproduce the behavior:

1. 在 Reqable 中抓取多个 HTTP/2 请求，这些请求 URL 相同，但请求头中的 apiName 值不同。

2. 新建一个「重写 → 重定向」规则。

3. 例如将：

   https://api.test.com/api/chile/*
   

   重定向到：

   http://127.0.0.1:22333/api/chile/*
   

4. 不启用「保留 Host 头部」，启用正则表达式。

5. 连续发送多个 URL 相同、apiName 不同的请求。

6. 在目标服务端查看实际收到的请求头。

7. 可以观察到，后续请求的 apiName 被固定为第一次请求中的值。

8. 将重定向目标改为原请求自身地址后，再次测试，该问题不会出现。

另外，这个bug有的时候是百分百复现，有的时候是前几个接口正常，然后再次稳定复现
此外，这是通过手机协同工作的时候，监控手机端（安卓）出现的问题

Expected behavior
重定向只应改变请求的目标地址。每个请求原本携带的请求头内容应分别保留。

例如：

apiName = A
apiName = B
apiName = C

经过重定向后，目标服务仍应分别收到 A、B、C，而不是全部变为 A。

Information

• Platform: Windows
• OS: Windows 11 10.0.26200
• Arch: x86_64
• App Version: 3.2.23 (221)

[MegatronKing]

您好，我测试了下没有能复现这个问题，检查了下代码，也不存在Header复用的逻辑。