Langflow builds flows in a browser and runs them on a server. Every URL component and every API request leaves from the server's address. The obvious way to change that address is a proxy variable on the machine. On a default installation it will not be used, and a security setting is why. We read release v1.12.2 on 20 September 2026.
One warning first. A search for the word proxy here returns hundreds of files. Almost all are two other things: a helper that points the frontend at the backend, and a component that routes model calls through a gateway. Neither one touches the address your requests come from.
Two clients
Both fetching components end their client factory with the same two lines:
if is_ssrf_protection_enabled() and validated_ips:
return create_ssrf_protected_client(hostname=hostname, validated_ips=validated_ips)
return httpx.AsyncClient()
The second is an ordinary client, and an ordinary client reads the usual proxy variables. The first is built on a custom transport. That transport pins the addresses already validated for the hostname and connects straight to them. It also replaces the part of the library that would have applied your environment proxy, and the factory passes no proxy of its own.
The setting is ssrf_protection_enabled, it defaults to true, and it can be switched with LANGFLOW_SSRF_PROTECTION_ENABLED.
They did not hide the clash. The protected transport takes a proxy argument and refuses it:
DNS pinning with proxies is not currently supported
That error exists in both transports. Pinning an address and handing the connection to a proxy are two answers to one problem. This project picked pinning.
The switch and its price
You can turn the protection off and get your proxy back. Before you do, read what it was doing.
With protection on, a URL is resolved first. It is refused if it points at a private, loopback, link local or cloud metadata address. Redirects are not followed by the client at all. The component follows them itself, so every hop is checked again. Their reason: a validated public URL can redirect to an internal one that was never checked.
| Choice | You gain | You give up |
|---|---|---|
| leave the protection on | private targets refused, redirects re-validated | your proxy on these components |
| switch it off | the usual environment proxy behaviour | both of those protections |
| route below the application | both, and a different address | a little setup on the host |
Routing underneath
The third row is the one we would pick, and it is the general answer whenever a tool pins its own addresses.
A pinned client connects straight to an address it checked. Nothing inside the process can redirect that, which is the point. Everything outside the process still can: the container's network, the host's routing, a forwarder the machine sends traffic through. Route there and the component never has to know. The protection it was given stays in place.
That is more setup than exporting a variable. It is also the only way to have both.
The MCP exception
One more place a proxy variable appears, and it is blocked on purpose.
A flow can embed a configuration for an MCP server that Langflow then runs. The proxy variables are blocked for those configurations, next to the certificate bundle variables and the package manager settings. Their comment gives the reason. A proxy override redirects a fetch somebody else set up, towards a host the flow author controls.
The rule is careful. The no proxy variable is deliberately not blocked. It can only narrow proxy use, never redirect anything.
So giving an MCP server its own address from inside a flow is closed by design. Set it in the environment of the server itself.
Which proxy type fits it?
Residential, for the sources that answer a hosting address differently. Our own paired test is the size of that effect: 4 of 13 sites answered a residential address differently from a server one, with plain requests of the kind these components send.
The routing belongs to the host rather than the application, which suits address authentication: one machine, allowed by its address, with no password in a flow or a settings file. On a Residential Premium plan your machine's address can be allowed, up to 150 per plan. Flows fetch pages and APIs rather than media, so a per gigabyte line goes a long way. The residential proxies page lists the plans, and the plan API manages allowed addresses from code.
What breaks
- Flows still leave from the server address. The protection is on, so the client is the pinned one.
- A flow fails with an unsupported message. Something passed a proxy to the pinned transport. That combination raises by design.
- Turning the protection off fixed the proxy and broke something else. Redirect re-validation went with it.
- An MCP server ignores the proxy you set in the flow. Those variables are blocked for flow supplied configurations.
- You searched the code for proxy and found hundreds of hits. Most are a frontend helper and a model gateway component.
What this page does not cover
We read the release as text and did not run Langflow. So we did not watch a flow use an address, did not switch the setting and did not measure a run's traffic. We also did not prove by experiment that the pinned client ignores the environment. We describe what the code builds and what that means. A reader who needs certainty should test it on their own instance. We read the two fetching components, the transport, the protection helper, the security settings and the MCP blocklist closely, and used a code search rather than reading a very large repository. This project releases about weekly and its branch was pushed to hours before we read it. We will read it again by 20 October 2026.
Where to go from here
Proxies for nanobot covers the same conflict resolved the other way, by dropping the pinning when a proxy is configured. Proxies for PicoClaw covers a third answer, keeping the guard and allowing one hop to your proxy. Proxies for World Monitor covers a fourth, moving the fetch to a second host entirely.
Sources
- The client factory in both fetching components, the pinned transport and its refusal of a proxy, the protection helper and its environment variable, the security settings default, and the manual redirect re-validation (src/lfx/src/lfx/components/data_source/api_request.py, components/data_source/url.py, utils/ssrf_transport.py, utils/ssrf_protection.py, services/settings/groups/security.py). langflow-ai/langflow, release v1.12.2 of 16 September 2026, read 20 September 2026.
- The blocked environment variables for flow supplied MCP server configurations, and the comment explaining why the no proxy variable is not among them (src/lfx/src/lfx/base/mcp/security.py). Same release.
- 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. Raw output is kept in the research folder of our OpenClaw page.
- Plans, allowed addresses and per gigabyte pricing. HProxy documentation, hproxy.com/docs, 20 September 2026.
