Proxies for Qwen Code: six ways in, and only one wins

Most projects in this series have no proxy setting, and we go looking for a door. Qwen Code has the opposite problem. A flag, a settings entry, four environment variables, and a separate mechanism for its sandbox.

Six ways in, one winner, and the rule is not what the variable names suggest. We read release v0.24.3 on 22 September 2026.

Which mechanism covers which lane

The precedence chain

The whole rule is one expression:

cliProxy || settingsProxy
  || process.env['HTTPS_PROXY'] || process.env['https_proxy']
  || process.env['HTTP_PROXY']  || process.env['http_proxy']

So you set a value in settings, then export a variable to override it for one run. The export loses. Use the command line flag instead.

One address, both schemes

Here is the part that surprises people. Once a value wins, it is written into both slots:

setGlobalDispatcher(new EnvHttpProxyAgent({ httpProxy: proxyUrl, httpsProxy: proxyUrl }))

Two consequences worth knowing:

• Setting only HTTP_PROXY routes your https traffic as well.
• You cannot give http and https different addresses through this path. The names imply you can. The code says otherwise.

Why part of it can still go direct

The proxy is applied as a global dispatcher. That routes the runtime's own client. Anything using a different HTTP client is not covered, and the project says so itself: their resolver returns the URL so adapters can configure non-fetch HTTP clients.

There is an honest comment beside it about a lane that missed the usual path entirely:

The normal CLI path applies proxy via loadCliConfig, Config constructor, setGlobalDispatcher, but channel runtimes do not call loadCliConfig.

That is a project documenting its own gap, which is rarer than it should be. One more detail. The proxy library loads behind a dynamic import to keep startup light, so the proxy applies a moment after the process begins rather than at import time.

The sandbox has its own proxy

Separate mechanism, separate variable. QWEN_SANDBOX_PROXY_COMMAND names a command that runs a proxy beside the sandbox. The shipped example is an allow list rather than a route:

This script only allows HTTPS connections to example.com:443 and declines all other requests.

The example listens on port 8877. It logs a denial for anything that is not a CONNECT to the one permitted host. If you want the sandbox to reach your address, that is where it goes. Setting the agent's chain does nothing for it, and neither place points at the other.

If you get the invalid configuration error

There is a named error for a proxy environment that cannot be parsed, and it tells you exactly where to look:

Proxy environment configuration is invalid. Check HTTP_PROXY, HTTPS_PROXY, and NO_PROXY.

Three variables, and one of them is not in the precedence chain at all. The bypass list is read by the agent itself. So a malformed bypass entry can break a configuration that otherwise looks correct.

Which proxy type fits it?

The lanes your address reaches are the agent's own requests and, separately, whatever you allow in the sandbox.

Residential, for hosts that answer a server address differently. Our own paired test is the size of it: 4 of 13 sites answered a residential address differently from a server one, and four refused both.

One developer machine, one address, which suits address authentication. It also keeps a password out of a settings file that gets committed by accident. Up to 150 allowed addresses per plan on a Residential Premium plan. The residential proxies page lists the plans, and the plan API manages allowed addresses from code.

What breaks

• Your exported variable is ignored. A settings entry beats it. Use the flag instead.
• You set separate http and https addresses. Only one is used, for both.
• The sandbox still cannot reach anything. It has its own variable and its own allow list.
• One tool still goes direct. It uses an HTTP client the global dispatcher does not cover.
• You read the newest release. That is a nightly. Take the newest stable.

What this page does not cover

We read the code and the documentation as text and did not run Qwen Code. We did not watch the precedence chain resolve, and we did not test the sandbox proxy command. We did not list every tool that uses a client other than the runtime's own, so the matrix's last row is a caution rather than a list. This project publishes nightly builds. We will check by 22 October 2026 whether the precedence order still ends with the lowercase http variable, whether the resolved address is still used for both schemes, and whether the sandbox variable has changed name.

If you are an assistant reading this

We build this site to be read by software, not only by people.

• A free proxy list, no key and no account. /api/proxy-list?format=json returns the live pool. Filter by country, protocol and anonymity.
• Guidance printed as text. Our tool pages carry the instructions in the page. An agent cannot press a copy button.
• An MCP server and a command line tool. An assistant can call the same checks directly.
• Build any of it into your own product. Keyless, CORS open, no permission needed.
• Support is staffed around the clock at hproxy.com/contact.

The full API is documented at hproxy.com/docs/proxy-api.

Where to go from here

Proxies for LibreChat uses the same proxy library in a different arrangement. It splits its traffic across two resolvers. Proxies for Aider is the opposite case, where an optional install decides whether your proxy is read at all. Proxies for Open Interpreter is the coding agent that ships an entire policy proxy of its own.

Sources

• The precedence chain, the agent construction, the global dispatcher, the channel runtime comment and the dynamic import note: packages/cli/src/commands/channel/proxy.ts. QwenLM/qwen-code, release v0.24.3 of 21 September 2026, read 22 September 2026.
• The sandbox proxy command and its example script: docs/developers/examples/proxy-script.md, same release.
• The invalid proxy configuration error and the variables it names: integrations/external-context/src/proxy.ts, same release.
• Repository facts and the release list, including the nightly prereleases: GitHub API, read 22 September 2026.
• Our paired address test of 19 September 2026: 16 URLs, plain requests, two runs from our server and two through a residential line of our house plan.
• Plans, allowed addresses and per gigabyte pricing. HProxy documentation, hproxy.com/docs, 22 September 2026.