Open WebUI reads the web from your server. The search query, each page behind a result, a link you paste into a chat and every model call leave from the same address. One pair of variables on the container moves almost all of it, which is why a working setup needs a careful NO_PROXY list as much as it needs a proxy. YouTube transcripts are the exception: they have a field of their own. We read every setting on this page in Open WebUI v0.11.3, released on 31 August 2026.
Why would Open WebUI need a proxy?
Sites answer a server differently than a home connection. We tested that on 19 September 2026: thirteen sites, twice from our server in a hosting network and twice through a residential line. A residential IP changed the answer at four of them: Zillow, Instagram, Reddit and DuckDuckGo. Indeed, Glassdoor, Amazon and Booking refused both. The table per site is on our OpenClaw page.
The header is not the lever. With the USER_AGENT variable unset, Open WebUI sends User-Agent: DefaultLangchainUserAgent on every page request. We sent the same thirteen sites both that header and a Chrome one from our server, twice each. Not one refusal became an answer. Zillow went the other way: it served the default header and refused the browser one, in both runs. The address changed answers, the header did not.
YouTube is its own case. When a transcript request is refused, Open WebUI says the address "belongs to a cloud provider" and names the setting that exists for it.
What follows HTTP_PROXY?
| Traffic | Follows HTTP_PROXY? |
|---|---|
| The search query (SearXNG, DuckDuckGo, search APIs) | yes, always |
| Pages behind the results | yes, while Trust Proxy Environment is on |
| A link pasted into a chat | yes, with the default loader |
| Calls to Ollama and OpenAI-compatible APIs | yes, always |
| YouTube transcripts | no, only the Youtube Proxy URL field |
| The Firecrawl or Tavily loader | the call to the vendor only, which reads the page itself |
The Playwright loader belongs in the second row. Since version 0.11.1 the browser no longer fetches the page: Open WebUI intercepts every request and fetches it from the backend, so the browser container needs no proxy of its own.
How do I set it up?
On the Open WebUI service, in your Compose file:
environment:
HTTP_PROXY: http://USERNAME:PASSWORD@GATEWAY_HOST:GATEWAY_PORT
HTTPS_PROXY: http://USERNAME:PASSWORD@GATEWAY_HOST:GATEWAY_PORT
NO_PROXY: localhost,127.0.0.1,ollama,searxng,host.docker.internal
http_proxy: http://USERNAME:PASSWORD@GATEWAY_HOST:GATEWAY_PORT
https_proxy: http://USERNAME:PASSWORD@GATEWAY_HOST:GATEWAY_PORT
no_proxy: localhost,127.0.0.1,ollama,searxng,host.docker.internal
Three details decide whether this works.
- The address starts with
http://. A scheme ofhttps://asks for a TLS connection to the proxy itself. The library behind the model calls and the page fetches drops such an address with only a warning in the log, and it has no SOCKS support at all. - Both spellings, same value. Python prefers the lower case variable, and an empty
no_proxycancelsNO_PROXY. A user whose model list stopped loading behind a company proxy fixed it by setting all six. - NO_PROXY lists hosts by name. The check matches host names and domain endings, never address ranges, so
10.0.0.0/8matches nothing. Name every service Open WebUI reaches inside your network: the model backend, SearXNG, a vector database.
The switch in the admin panel
Pages behind the search results follow the proxy only while Trust Proxy Environment is on, under Admin Settings, Web Search. It has been on by default since version 0.9.3, in May 2026.
Saving that page writes the switch into the database, and the saved value then wins over WEB_SEARCH_TRUST_ENV. So on an instance that is older than May 2026, look at the switch itself rather than at your variables. Open WebUI's own troubleshooting page still says the page fetcher ignores the proxy variables by default, which stopped being true in 0.9.3.
Where SearXNG and the search APIs sit
With SearXNG as the engine, two hops matter. Open WebUI sends the query to SearXNG, and that request follows HTTP_PROXY unless NO_PROXY names the SearXNG host. SearXNG then queries Google, Bing or DuckDuckGo from its own container, and those requests take the proxies in SearXNG's settings.yml, under outgoing. Our SearXNG page covers that side, including which engines a fresh install has on.
The built-in DuckDuckGo engine is simpler: it reads HTTPS_PROXY or HTTP_PROXY itself, whatever the switch says. If you want the proxy for DuckDuckGo searches alone, set DDGS_PROXY and leave the other variables unset. With a key-based search API, the vendor does the searching, so only the small call to the API takes your line.
YouTube transcripts
Transcripts ignore HTTP_PROXY. The address goes into Youtube Proxy URL under Admin Settings, Web Search, or into YOUTUBE_LOADER_PROXY_URL, and the same URL is used for both schemes. Open WebUI's documentation shows the form with https://, which asks for a TLS connection to the proxy; a gateway that takes plain HTTP needs http://.
One attempt is all you get. The client Open WebUI builds never retries a blocked request, so a refused transcript fails once. Attaching the video again opens a new connection, which on a rotating line means a new address.
Which proxy type fits Open WebUI?
Residential, for the sites that refuse a hosting address. Each page is read on its own connection, with no cookies kept between pages, so a rotating line suits the reading. A sticky line only pays off when you point the loader at a site that expects one visitor across several pages.
HProxy residential gateways fit either way. Allow your server's address on a Residential Premium plan, up to 150 per plan, and the proxy needs no password: HTTP_PROXY then carries no login, and none reaches a log file. An allowed address takes no country or city targeting. For a country, use a generated line, whose username carries the targeting. Rotating ports change the address, a sticky port holds one, and a sticky address can still change early if its device leaves the network. The residential proxies page lists the plans, and the plan API generates lines and manages allowed addresses from code.
What breaks when the proxy is on?
- The models are gone, or every chat fails. The model backend is being sent to the proxy. Put its host in
NO_PROXY, by name, in both spellings. - Web search returns nothing at all. The same thing happened to the query. Add the SearXNG host to
NO_PROXY. - The variable seems to do nothing. The saved admin setting wins. Check Trust Proxy Environment in the panel.
- Pages still come back empty or refused. A proxy changes the address, not the browser. Sites that ask for a JavaScript check refuse a plain request whatever its address, and a browser User-Agent changed nothing in our test. The Playwright loader runs the page, which helps where the text is drawn by scripts.
- 407 Proxy Authentication Required. The password is wrong, or the line belongs to another plan. Our 407 guide walks through it.
- The site logs your server anyway. With the Playwright loader and certificate checks on, Open WebUI opens its own direct connection to each site first, to look at the certificate.
- Traffic climbs faster than expected. Model calls run through the same line, and a residential line is billed per gigabyte.
What this page does not cover
We read Open WebUI v0.11.3's code, changelog and documentation, plus the code of the libraries it pins, and we did not run Open WebUI. Our tests were plain requests from one server address and one residential line, over one day. If you meant the other kind of proxy, the one that carries your users to Open WebUI, that is a reverse proxy and Open WebUI's own documentation covers it. Open WebUI ships new versions most weeks, so we will read these settings again by 19 October 2026.
Where to go from here
Proxies for SearXNG covers the search side in full. Proxies for n8n and proxies for Dify cover two other self-hosted tools whose proxy variables reach more than people expect. Sticky vs rotating sessions explains the choice above, and how websites detect proxies explains the refusals.
Sources
- The web loader and its Playwright path (backend/open_webui/retrieval/web/utils.py), the shared HTTP session (utils/session_pool.py), the DuckDuckGo engine, the SearXNG engine, the YouTube loader, the settings in config.py and models/config.py, the retrieval router, the built-in tools and the CHANGELOG. open-webui/open-webui, release v0.11.3, 31 August 2026.
- Environment variable reference and Troubleshoot Web Search. Open WebUI documentation, docs.openwebui.com, read 19 September 2026.
- Proxies from the environment (helpers.py, connector.py). aiohttp 3.13.5, the version v0.11.3 pins.
- getproxies_environment and proxy_bypass_environment (Lib/urllib/request.py). CPython 3.11, the Python of Open WebUI's image.
- WebBaseLoader and get_user_agent. langchain-community 0.4.2. DDGS_PROXY: ddgs 9.14.4. GenericProxyConfig: youtube-transcript-api 1.2.4. HTTP and HTTPS proxies: urllib3 2.8.0 documentation.
- The outgoing section of settings.yml. SearXNG, master e831fc2a1cad, read 19 September 2026.
- Plans, IP whitelist and sticky sessions; errors; the proxy API. HProxy documentation, hproxy.com/docs, 19 September 2026.
- Our own tests of 19 September 2026: the default and a browser User-Agent from our server (16 URLs, two runs each), and the paired server and residential runs of our OpenClaw page. Raw output is kept in the research folders of both pages.
