请求过滤器中 set header 疑似未生效

[Clouder0]

在请求过滤器中设置 Header 后，观察 Session 中请求的 Header 发现未生效。

可能的原因：

1. 请求过滤器的 set header 未生效
2. Session 记录的请求和请求过滤器 set header 存在时序上微妙的问题，导致记录了过滤前的 header(less likely)

[github-actions]

感谢您报告这个问题。

分析结论：

您的第二个猜测是正确的。这确实是一个时序问题，但并非记录了"过滤前"的 header，而是有两个不同的 header 存储位置：

1. headerLog（日志用途）：在 ProxySession.fromContext() 中创建（src/app/v1/_lib/proxy/session.ts:130），此时请求过滤器尚未执行
2. storeSessionRequestHeaders（Session 详情用途）：在 ProxyForwarder 中调用（src/app/v1/_lib/proxy/forwarder.ts:1008 和 1149），此时请求过滤器已经执行完毕

根本原因：

在 session.ts:130 中：

const headerLog = formatHeadersForLog(headers);

这个 headerLog 是在 session 创建时立即生成的只读快照，而请求过滤器（requestFilter step）在 Guard Pipeline 中是第 7 步执行（参见 src/app/v1/_lib/proxy/guard-pipeline.ts:155-169）。

虽然 RequestFilterEngine.applyHeaderFilter() 确实会修改 session.headers 对象（src/lib/request-filter-engine.ts:165 和 174），但 headerLog 是独立的字符串，不会被更新。

潜在影响：

• Session 详情页面中显示的 请求 Headers（通过 storeSessionRequestHeaders 存储）应该是过滤后的 headers
• 但如果 UI 使用的是 headerLog，则会显示过滤前的 headers

需要确认的信息：

• 您观察到未生效的 header 是在哪个位置查看的？（Session 详情页面的请求 Headers 区域？日志？）
• 能否提供一个具体的过滤器配置示例（target 和 replacement 值）？

---

Automated response from Claude AI

[miraserver]

iv check SET user-agent rules and its works, but u will see it only if u run trance log and looking ur rules in log
like

{"level":"trace","time":"2025-12-25T20:18:04.584Z","pid":13528,"hostname":"","provider":"privnode","providerType":"claude","headers":{"accept":"application/json","accept-encoding":"identity","accept-language":"*","anthropic-beta":"claude-code-20250219, interleaved-thinking-2025-05-14, extended-cache-ttl-2025-04-11","anthropic-dangerous-direct-browser-access":"true","anthropic-version":"2023-06-01","authorization":"Bearer ","content-type":"application/json","host":"privnode.com","sec-fetch-mode":"cors","user-agent":"claude-cli/2.0.69 (external, cli)","x-api-key":"","x-app":"cli","x-stainless-arch":"x64","x-stainless-lang":"js","x-stainless-os":"Windows","x-stainless-package-version":"0.70.0","x-stainless-retry-count":"0","x-stainless-runtime":"node","x-stainless-runtime-version":"v22.19.0","x-stainless-timeout":"600"},"msg":"ProxyForwarder: Final request headers"}

I'm not entirely sure about all the rules, but at least I checked this and it works.