同样是200消息.可否增加自定义函数过滤处理,然后返回处理结果.

[s6yoho]

响应头

UPSTREAM: HTTP 200 https://ai.hybgzs.com/claude/v1/messages?beta=true

alt-svc: h3=":443"; ma=86400
cache-control: no-cache, no-cache
cf-cache-status: DYNAMIC
cf-ray: 9cb803951e1f33ad-LAX
connection: keep-alive
content-type: text/event-stream
date: Tue, 10 Feb 2026 02:00:39 GMT
expect-ct: max-age=86400, enforce
nel: {"report_to":"cf-nel","success_fraction":0.0,"max_age":604800}
referrer-policy: same-origin
report-to: {"group":"cf-nel","max_age":604800,"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=7OFOxtAzpQysLTbaMWBu%2B6jVbgdVvairXBrFFTewDHQ40C1UF29cfKy48gZR4qEOS4EAYd%2FOmpTdKjJDsC%2FpQRHUZ8fG0yrwakChCr0%3D"}]}
server: cloudflare
set-cookie: serv******th=/
transfer-encoding: chunked
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-oneapi-request-id: 20260210100038120065382BLdxI5EY
x-xss-protection: 1; mode=block

响应

event: message_start
data: {"type": "message_start", "message": {"id": "msg_6dc3032704af417f9419eb3b", "type": "message", "role": "assistant", "content": [], "model": "claude-opus-4-6-20260206", "stop_reason": null, "stop_sequence": null, "usage": {"input_tokens": 0, "output_tokens": 0}}}

event: content_block_start
data: {"type": "content_block_start", "index": 0, "content_block": {"type": "text", "text": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "text_delta", "text": "\n\n错误: 错误: 429 {\"message\":\"I am experiencing high traffic, please try again shortly.\",\"reason\":\"INSUFFICIENT_MODEL_CAPACITY\"}"}}

event: content_block_stop
data: {"type": "content_block_stop", "index": 0}

event: message_delta
data: {"type": "message_delta", "delta": {"stop_reason": "end_turn", "stop_sequence": null}, "usage": {"input_tokens": 0, "output_tokens": 0}}

event: message_stop
data: {"type": "message_stop"}

---

不太了解cch的实现机制,但是是否可以添加一个功能,
可以让用户添加一个自定义函数之类的,接受请求与响应,返回 通过, 熔断,临时熔断 , 切换供应商, 重试.
然后用户可以自己根据请求与响应, 改变结果处理.

感觉这种方式就是是侵入性最低的,而且可定制能力更强.

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• 这种请求被记录为了200 成功 怎么解决啊? #749

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

Thank you for this feature suggestion. You've identified a real gap in the current architecture: upstream providers returning HTTP 200 with error content in the response body (like the 429 wrapped in a 200 SSE stream you showed) are not detected by the existing error handling or circuit breaker systems.

Analysis of the Current Architecture

Why this happens:

The proxy pipeline flow is:

Request -> GuardPipeline -> ProxyForwarder -> ProxyResponseHandler -> Response

In src/app/v1/_lib/proxy/forwarder.ts (line 2184), the forwarder only checks response.ok (i.e., HTTP status 2xx). If the upstream returns HTTP 200, the response is passed directly to ProxyResponseHandler.dispatch() without inspecting the body content. The circuit breaker (src/lib/circuit-breaker.ts) only records failures for non-2xx responses, timeouts, and protocol errors.

Existing mechanisms that are close but insufficient:

1. Error Rules (src/lib/error-rule-detector.ts) - A pattern-matching engine (regex/contains/exact) that detects error patterns in response text and can override the response body or status code. However, it only operates on actual ProxyError instances (non-2xx responses) via src/app/v1/_lib/proxy/error-handler.ts (line 100). It does not inspect HTTP 200 response bodies.

2. Request Filters (src/app/v1/_lib/proxy/request-filter.ts) - Support header/body modification on requests, but only operate before the request is sent upstream. There is no equivalent "response filter" mechanism.

3. Response Fixer (src/app/v1/_lib/proxy/response-fixer/index.ts) - Pre-processes responses to fix encoding, JSON, and SSE formatting issues, but has hardcoded fixers with no plugin architecture for custom logic.

4. Guard Pipeline (src/app/v1/_lib/proxy/guard-pipeline.ts, lines 172-189) - Configurable chain of request guards, but all guards execute before the upstream request. There is no post-response guard chain.

What's missing:

• No response body inspection for HTTP 200 responses
• No "response filter engine" (equivalent to RequestFilterEngine for responses)
• No post-processing hook between receiving the upstream response and forwarding to the client
• No way for users to define custom actions (circuit-break, retry, switch provider) based on response content

Feasibility Assessment

The feature you're describing - a user-configurable response filter that can inspect both request and response, then return actions like pass/circuit-break/temporary-circuit-break/switch-provider/retry - would require changes in several areas:

1. Response interception point - A new processing step between ProxyForwarder.send() and ProxyResponseHandler.dispatch() in src/app/v1/_lib/proxy-handler.ts (lines 81-82), or integrated into the forwarder's retry loop.

2. Response filter engine - A new engine similar to RequestFilterEngine (src/lib/request-filter-engine.ts) but for response content, with configurable rules stored in the database.

3. Action dispatcher - Logic to handle the different return actions (pass, circuit-break, retry, switch provider), which would need to integrate with the existing circuit breaker (src/lib/circuit-breaker.ts) and the forwarder's provider failover chain.

4. SSE stream inspection - For streaming responses (like your case), the filter would need to buffer or inspect SSE chunks before forwarding, which adds complexity and latency.

Architectural considerations:

• For non-streaming responses, this is relatively straightforward: read the body, run the filter, decide the action.
• For streaming (SSE) responses, this is more complex. The response body is a stream that can only be read once. Inspecting it requires either buffering the entire response (defeating the purpose of streaming) or inspecting chunks as they arrive (which means the error might only be detected partway through the stream, after some data has already been sent to the client).
• The existing Error Rules system (src/lib/error-rule-detector.ts) already has a well-designed pattern matching engine with regex/contains/exact matching, hot-reload, and ReDoS protection. Extending it to also inspect HTTP 200 response bodies could be a pragmatic first step before building a full custom function system.

Related Existing Code

Component	File	Relevance
Proxy entry point	src/app/v1/_lib/proxy-handler.ts	Where response interception would be added
Forwarder retry loop	src/app/v1/_lib/proxy/forwarder.ts	Retry/switch-provider logic lives here
Response handler	src/app/v1/_lib/proxy/response-handler.ts	Current response processing
Circuit breaker	src/lib/circuit-breaker.ts	Circuit-break action target
Error rule detector	src/lib/error-rule-detector.ts	Existing pattern matching engine
Error handler	src/app/v1/_lib/proxy/error-handler.ts	Where error rules are currently applied
Request filter engine	src/lib/request-filter-engine.ts	Architectural reference for a response filter
Response fixer	src/app/v1/_lib/proxy/response-fixer/index.ts	Existing response pre-processing

---

Automated response from Claude AI