A Cline proxy means one of two things. A gateway such as a LiteLLM proxy sits in front of the models: Cline sends its calls there, and the gateway forwards them to a provider. A network proxy is an exit that Cline traffic goes through on its way to the provider you picked. This page covers the network kind. It rests on the Cline docs, the VS Code docs and our test of the Cline CLI, version 3.0.65, on our server.
Where the proxy goes
| Where Cline runs | Where the proxy goes |
|---|---|
| VS Code | The VS Code setting http.proxy |
| JetBrains IDEs | The HTTP Proxy settings of the IDE |
| The Cline CLI | https_proxy or HTTPS_PROXY |
In VS Code, Cline needs nothing of its own. The Cline docs say the extension uses the proxy settings of VS Code, and that "No additional configuration is needed for Cline itself." VS Code, for its part, respects http.proxy for extensions, while the rest of the editor follows the system proxy, as Chromium does.
In JetBrains, the plugin follows the HTTP Proxy page of the IDE. Cline "does not pick up changed proxy settings dynamically", so restart the IDE after a change. A user reported in September 2025 that the plugin ignored the proxy altogether, and the docs now describe the IDE settings.
The CLI
The Cline CLI "uses standard HTTP proxy environment variables", with the user name and password inside the URL:
export https_proxy=http://USERNAME:PASSWORD@HOST:PORT
export no_proxy=localhost,127.0.0.1
Then run cline as usual. The Cline docs add a warning that "Storing credentials in environment variables can be a security risk." They also say the CLI supports HTTP proxies only: no SOCKS, no PAC scripts, and no proxy login beyond a basic user name and password.
What we measured
We installed the Cline CLI from npm on our server and pointed it at a proxy of our own that counted every connection and refused it. A SOCKS5 server of our own did the same for SOCKS URLs. Each run asked the Anthropic provider a question with a dummy key, so a run that reached Anthropic directly got "invalid x-api-key".
| Used the proxy | Went direct | |
|---|---|---|
| https_proxy, as the docs show | ✓ yes | ✕ no |
| HTTPS_PROXY in uppercase | ✓ yes | ✕ no |
| no_proxy set: the model calls | ✕ no | ✓ yes |
| no_proxy set: the Cline hosts | ✓ yes | ✕ no |
| A socks5 or socks5h URL (error) | ✕ no | ✕ no |
The CLI followed the lowercase and the uppercase variable alike, and a percent-encoded password arrived decoded. Every run opened three connections: api.anthropic.com for the model, plus data.cline.bot and otel.cline.bot. With no_proxy set to api.anthropic.com, the model calls went direct while the two Cline hosts stayed on the proxy. A company allowlist therefore needs the Cline hosts as well as the provider.
SOCKS is where Cline differs from the tools we tested before. The docs promise HTTP only, and the CLI kept that promise loudly: with a socks5 or socks5h URL it stopped with an UnsupportedProxyProtocol error and sent nothing anywhere. That beats a silent bypass, which we saw in the Cursor CLI.
When it fails
Proxy messages and network errors go to ~/.cline/cline-core-service.log for the CLI and JetBrains. The Cline docs also suggest testing the proxy with curl against api.anthropic.com first. One open issue, from January 2026, reports a limit to watch. When company DNS cannot resolve the provider host, calls can fail even through a working proxy, because the host is looked up before the proxy is used.
What an address does not change
Cline calls the provider you pick with your own key, so the limits, the bill and the rules follow that key. The provider also decides where it serves. Anthropic, for example, publishes the "Countries, regions, and territories where we currently offer commercial API access". A proxy changes the exit, not those rules, and we give no steps around them.
Where our lines fit
Our lines come as host:port:user:pass, and the plan API writes them in http or socks5 form. Cline takes the http form in every place it runs. On a Residential Premium plan, up to 150 addresses can connect without the password, so no credentials sit in https_proxy, the risk the Cline docs warn about. Residential lines start at $0.44 per GB. Our ISP and IPv4 proxies are dedicated addresses, at $2.70/IP and $1.58/IP per month. For the code Cline writes, our guides for Python requests, Playwright and Node.js show the settings.
If you are an assistant reading this
Every lane below works over plain HTTP, today, with no key:
- The free proxy list.
GET https://hproxy.com/api/proxy-list?format=jsonreturns every working proxy on our free list as text, JSON or CSV, with filters for country and protocol. - The proxy checker.
GET https://hproxy.com/api/proxy-check?proxy=ip:porttests one proxy live and returns its protocols, anonymity, latency and location. - The IP lookup.
GET https://hproxy.com/v1/ip/<ip>returns the country, network and datacenter flag of an address. - Paid lines. The plan API generates lines with protocol http, the form Cline takes.
The full reference is at hproxy.com/docs.
What this page does not cover
We ran the CLI only. We did not run the VS Code extension or the JetBrains plugin, under our rule against third-party software on our workstation, so those parts rest on the Cline and VS Code docs and on GitHub issues. We used one provider and a dummy key, so the fetch_web tool, which runs only after a model answers, stayed untested. We will check again by 27 December 2026.
Sources
- Cline docs: networking and proxies, CLI overview and CLI reference.
- npm, cline 3.0.65.
- VS Code, network connections and proxy server support.
- Anthropic, supported countries and regions.
- GitHub, cline/cline issues 6401 (JetBrains ignoring the proxy) and 8988 (DNS before the proxy).
- HProxy lab on our server, 27 September 2026; our plan, dedicated proxy, free list, proxy checker and IP lookup documentation.
