Home / Guides / Tools with one endpoint / Langflow SSRF hosts

Langflow: when the endpoint host is blocked, not the key

You pasted a working key and a working base URL into Langflow, ran the flow, and got a connection failure. The key is fine. The endpoint answers fine from curl. Nothing about the credential is wrong.

What happened is a server-side request forgery guard. Langflow is a server application that makes outbound calls on your behalf, so it restricts which hosts those calls may reach. A gateway hostname it has not been told to trust is refused before authentication is ever attempted.

That ordering is what makes this error confusing: there is no 401, because the request never got as far as presenting your key.

You need a key before the code below runs. Create an account, generate a key, and copy the base URL (https://aicomp.ai/v1). Create one free →
Check current rates → Free to sign up · $1 minimum top-up · No prepayment

Confirm you are looking at a host block

The tell is that the same call succeeds from the shell and fails from the flow.

Don't have an account yet? You need an API key from the gateway before the steps below will work — how the discount works and what you take on. Create one free → (no prepay, $1 minimum top-up) 
# Works here...
curl -s -o /dev/null -w "%{http_code}\n" --max-time 15 \
  https://aicomp.ai/v1/models -H "Authorization: Bearer $OPENAI_API_KEY"

# ...but Langflow reports it cannot connect

If curl returns 200 and Langflow cannot reach the host, you are not debugging credentials or paths. You are debugging an allowlist.

Note where Langflow runs. If it runs in Docker, "the machine" is the container. A host that resolves from your laptop may not resolve from inside it, and the container has its own DNS and network namespace. Test from inside before concluding the allowlist is the only issue:

docker exec -it <container> sh -c \
  'curl -s -o /dev/null -w "%{http_code}\n" --max-time 15 https://aicomp.ai/v1/models'

Where the allowlist is set

The setting travels as an environment variable. The name people search for is LANGFLOW_SSRF_ALLOWED_HOSTS, and it takes the hosts that outbound calls are permitted to reach.

# Docker: pass it at run time
docker run -d -p 7860:7860 \
  -e LANGFLOW_SSRF_ALLOWED_HOSTS="aicomp.ai,api.openai.com,api.anthropic.com" \
  langflowai/langflow:latest
# docker-compose: same variable, declared once
services:
  langflow:
    image: langflowai/langflow:latest
    ports:
      - "7860:7860"
    environment:
      - LANGFLOW_SSRF_ALLOWED_HOSTS=aicomp.ai,api.openai.com,api.anthropic.com

Two things to verify rather than assume, because both vary by version:

# 1. What is actually set inside the container?
docker exec -it <container> sh -c 'env | grep -i ssrf || echo "not set"'

# 2. What does your version call it?
docker exec -it <container> sh -c 'env | grep -i -E "allowed|host" | head'

Environment variable names and accepted formats, comma-separated hostnames versus a list, hostname versus full URL, have moved between releases. Run those two commands against your own container and use what it reports. If your build exposes the allowlist in the UI instead, set it there; the variable and the UI write to the same restriction.

Restart after changing it. The guard is read at startup. Editing the environment of a running container changes nothing until the process restarts, and "I set it and it still fails" is most often a missing restart.

Why the guard exists, and why not to turn it off

This is not an obstacle to route around. If your Langflow instance is reachable by anyone other than you, an unrestricted outbound caller is a way to probe your internal network (cloud metadata endpoints, internal services, anything the host can reach). Keep the list narrow: the hosts your flows actually call, and nothing else.

Adding one gateway hostname is the smallest change that works. It is also, conveniently, the smallest list you will ever need, one endpoint covers every model you route through it, where direct vendor keys would mean one host per vendor.

Get API access

FAQ

FAQ

Why does curl work but Langflow cannot connect?

Two possibilities, in order. Either the SSRF guard is refusing the host (most likely, and it fails before any credential is checked) or the container has different network access than your shell. Test from inside the container with docker exec to separate them.

Is this a credentials problem?

No, and that is what makes it hard to spot. A credential failure returns 401 or 403. A host block prevents the request from being made, so no status code ever comes back from the endpoint. If your key works in curl, the key is not the variable.

Do I need the full URL or just the hostname?

It depends on your version, hostname-only and full-URL forms have both been used. Check what the running container already has with env | grep -i ssrf and match that format. If the variable is unset, try hostname-only first, since that is the more common shape.

Why did it fail only after I switched to a custom endpoint?

Because the default allowlist covers the vendors Langflow knows about. A gateway hostname is not on it, so the first request to it is refused even though the endpoint is reachable. Nothing about your flows changed; the destination is simply new to the guard.

Can I allow everything instead?

You can, and on a machine only you can reach it is tempting. Do not, if the instance is shared or exposed. An open outbound caller turns your Langflow host into a probe for whatever that host can see (internal services, metadata endpoints, neighbouring containers). Add the one hostname.

Related

Get API access

GPT rate card