Qwen Code reads four different origin variables — and two of them must NOT be redirected

[xizhuomengcontin]

While building recording support for Qwen Code I had to work out exactly which origin it reads, and the answer turned out to be four separate variables with genuinely different consequences. Writing it down because anyone putting qwen behind a proxy or gateway will hit this, and getting it wrong can leak a key to the wrong vendor.

Disclosure: I work on OrcaReplay (Apache-2.0). The analysis below is about Qwen Code and holds whatever proxy you use.

The four

Variable	Safe to redirect?
OPENAI_BASE_URL	✅ yes
ANTHROPIC_BASE_URL	✅ yes
DASHSCOPE_PROXY_BASE_URL	❌ no
GEMINI_NEXT_GEN_API_BASE_URL	❌ no

The first two are safe because a proxy can put the right provider back on the other end — the wire dialects are well known and default to api.anthropic.com / api.openai.com.

Why the other two are dangerous to move

Most proxies resolve an upstream by wire dialect, not by provider. So:

• A DashScope call arrives as POST /v1/chat/completions. That is claimed by the OpenAI dialect and forwarded to api.openai.com — carrying your DashScope key in Authorization: Bearer.
• A Gemini call arrives at /v1beta/models/…, which no OpenAI/Anthropic dialect claims. Header-sniffing fallbacks typically recognise only Anthropic's header and treat everything else as OpenAI — which sends x-goog-api-key the same way.

A wrong guess here does not merely fail. It hands one vendor a key issued by another. So the correct behaviour is to leave those two pointing at their own APIs and capture below the agent instead, by terminating TLS.

If you do want to capture Qwen's own models

One host is not enough — the coding plan, regions and token plan all live on different domains:

dashscope.aliyuncs.com                      (default)
coding.dashscope.aliyuncs.com               coding-intl.dashscope.aliyuncs.com
cn-hongkong.dashscope.aliyuncs.com          dashscope-intl.aliyuncs.com
dashscope-us.aliyuncs.com
token-plan.cn-beijing.maas.aliyuncs.com     token-plan.ap-southeast-1.maas.aliyuncs.com
api-inference.modelscope.cn                 (ModelScope)

Note the wildcard *.dashscope.aliyuncs.com is narrower than it looks: sign-in lives on bailian.console.aliyun.com and modelstudio.console.alibabacloud.com, different domains entirely.

Two smaller findings

• WEB_SEARCH_BASE_URL is the web-search tool's endpoint, keyed separately by WEB_SEARCH_API_KEY and off unless ENABLE_WEB_SEARCH is set. Redirecting it without the matching key breaks a tool that works today.
• Environment beats config. Config::get_param reads the environment before config.yaml, so a persisted file cannot silently win — which is what makes per-process redirection viable at all.
• Qwen signs in on its own (~/.qwen/oauth_creds.json). Inventing an OPENAI_API_KEY in front of that can change which provider answers, so a tool should only supply placeholders when there is genuinely nothing to disturb.

What it is for

Recorded sessions can be served back to the agent — same run, no provider called, no tokens spent — or forked from a checkpoint onto a different model. There is an ecosystem PR open at #10895; not asking for review here.

Happy to be told I have any of this wrong; I would rather fix the adapter than keep pinning the wrong variable.