Skyvern Proxy Setup: Route Agents via German Mobile IPs

Direct Answer

To route Skyvern through a mobile proxy, run it self-hosted and set ENABLE_PROXY=true with your endpoint in HOSTED_PROXY_POOL. Skyvern is an LLM-plus-vision browser agent that drives Chromium through Playwright, so the proxy binds to the browser it opens — not to the model. Every page the agent visits leaves through your German mobile IP, while the vision/LLM calls that read the DOM keep their own connection. You don't touch how the agent reasons or clicks; you only change where its page traffic comes from.

The One Thing Most Skyvern Proxy Guides Get Wrong

Skyvern is a browser agent: you give it a goal, and an LLM with vision reads the rendered page, decides where to click and type, and repeats until the task is done. Under the hood it is a Chromium instance driven by Playwright, not a single HTTP request. That one fact settles where the proxy goes.

The proxy binds to the browser, not the model. When Skyvern opens a German page to read it, that traffic is what should leave through your German mobile IP. The reasoning steps — the calls to the vision model — are a separate connection and usually don't need a German exit at all. Get this right and the setup is a config change; get it wrong and you route model traffic through a mobile connection for no reason while the browser still exits from your own address.

So the goal is precise: send the agent's page loads through the German mobile proxy, and leave everything else alone.

One caveat up front: Skyvern Cloud steers its own managed proxy network with a proxy_location country code — that is not a bring-your-own endpoint. To point Skyvern at your German mobile IP, run it self-hosted, where the proxy is a real config setting.

Before You Start

You'll need four values from your GermanProxy.io account:

Host and port of your endpoint
Username and password

The examples use PROXY_HOST, PORT, USER and PASS as placeholders — replace them with your own. There's no hardware to manage: the proxy is a dedicated mobile connection exposed as a host/port/credentials endpoint.

Run Skyvern locally with its CLI (self-hosted mode is what exposes the proxy config):

pip install skyvern
skyvern init

Step 1 — Enable the Proxy in Your Skyvern Config

Self-hosted Skyvern reads two settings for a bring-your-own proxy: ENABLE_PROXY turns the feature on, and HOSTED_PROXY_POOL holds one or more endpoints. Add them to your .env:

ENABLE_PROXY=true
HOSTED_PROXY_POOL=http://USER:PASS@PROXY_HOST:PORT

HOSTED_PROXY_POOL is a comma-separated list of proxy URLs. For one dedicated endpoint you list a single entry; Skyvern loads it into the arguments it uses to launch the Playwright browser. That's the whole binding — the browser the agent drives now exits through your German mobile IP.

Step 2 — Run a Task Through the Proxy

With the proxy enabled, start Skyvern and give it a task. The browser it opens carries the German mobile IP:

skyvern run server

from skyvern import Skyvern

skyvern = Skyvern()

# The browser Skyvern drives exits through the German mobile IP.
task = skyvern.run_task(
    prompt="Open https://www.example.de and report the page title and key public details.",
)
print(task)

The agent decides when to open a page and where to click; the proxy config decides how those page loads leave — and with ENABLE_PROXY set, they leave through your German mobile IP.

Step 3 — Confirm the Browser Launch Carries the Proxy

Because Skyvern builds the browser launch arguments from your config, the cleanest sanity check is to have a task open an IP-reflection page and read back the address it sees:

from skyvern import Skyvern

skyvern = Skyvern()

check = skyvern.run_task(
    prompt="Open https://api.ipify.org?format=json and report the exact IP address shown.",
)
print(check)

If the reported IP is your own address, the proxy settings didn't reach the browser launch — re-check that ENABLE_PROXY=true and that the credentials are inside the HOSTED_PROXY_POOL URL. If it shows a German mobile address, the binding is live.

Verify the IP First

Before a real run, confirm the exit IP is a German mobile address. The quickest independent check is a one-line request through the same endpoint, outside Skyvern:

curl -x "http://USER:PASS@PROXY_HOST:PORT" https://api.ipify.org?format=json

If that returns a German mobile IP but Skyvern still shows your own, the problem is in the Skyvern config, not the proxy. Confirm the ASN and geolocation look like a German mobile network, not a datacenter range. A full checklist is in validating the proxy connection. Because Skyvern drives a real browser, also watch for WebRTC and DNS leaks that can reveal your address outside the tunnel.

Sticky Sessions vs. Rotation

How the agent should handle IPs depends on the task:

Sticky session — keep the same German mobile IP across a multi-step flow (open a page, click, fill a form, navigate) so the sequence looks like one coherent visitor. This is the right default for an agent, because a mid-task IP change looks inconsistent to the target.
Rotation on demand — request a fresh IP at the proxy between separate runs to spread load across a longer job, not in the middle of one.

Keep request rates human-reasonable. The mechanics are in sticky sessions and IP rotation.

Why a Mobile IP at All

German content is localised. German marketplaces and Google.de serve different results, pricing and stock by country and network. Point a Skyvern agent at a German site from a US datacenter range and it reads the wrong market. A German IP gives it the in-country view the task needs.

Mobile IPs carry high IP reputation. German sites filter datacenter ranges aggressively — often a 403 Forbidden within a handful of requests. Mobile IPs sit in shared CGNAT pools used by thousands of real subscribers, so they carry high IP reputation — the reason a mobile IP keeps working where a datacenter range stalls.

For the trade-offs between IP types, see mobile vs residential vs datacenter proxy and, on cost, dedicated mobile vs pay-per-GB residential. For the wider agent picture, see mobile proxies for AI agents.

Scrape Responsibly

A mobile proxy improves reliability for legitimate, authorized automation — it is not a tool to circumvent access controls or platform rules. A Skyvern agent runs largely unattended, so the responsibility to keep it clean is higher, not lower:

Automate only what you're permitted to — respect robots.txt and each site's terms, and stay inside any contract or API you're granted.
Throttle — add human-reasonable delays between actions so you don't overload target servers.
Collect only the public data you need, and handle any personal data in line with the GDPR.
Identify your client honestly — don't impersonate a system you're not authorized to use.

Whether a specific task is lawful depends on your jurisdiction and the target's terms — this is general information, not legal advice. See are mobile proxies legal and the legal side of web scraping in Europe.

[!NOTE]
Note: This article is general information, not legal advice. Whether a specific data-collection task is lawful depends on your jurisdiction, the target site's terms and the data involved.

FAQ

Does the proxy change how Skyvern talks to the LLM?

No. The proxy binds to the Chromium browser Skyvern launches through Playwright — the pages the agent opens. The vision/LLM calls that read the DOM and decide the next action stay on their own connection unless you deliberately route them through the proxy too. In practice you set ENABLE_PROXY and HOSTED_PROXY_POOL so the browser traffic exits through the German mobile IP, and leave the model traffic alone.

Can I use a custom proxy with Skyvern Cloud?

Skyvern Cloud steers its own managed proxy network through a proxy_location country code — that selects an IP from Skyvern's pool, not a bring-your-own endpoint. To route through your German mobile IP, run Skyvern self-hosted and set ENABLE_PROXY=true with your endpoint in HOSTED_PROXY_POOL.

What format does HOSTED_PROXY_POOL expect?

A comma-separated list of proxy URLs in the form http://USER:PASS@PROXY_HOST:PORT. For a single dedicated German endpoint you list one entry; Skyvern reads the pool, picks an endpoint, and passes it into the Playwright browser launch arguments.

Why do I get a 407 error?

407 Proxy Authentication Required means the username and password didn't reach the proxy. Confirm they're embedded in the HOSTED_PROXY_POOL URL (http://USER:PASS@PROXY_HOST:PORT). See how to fix 407 proxy authentication required.

HTTP or SOCKS5 for Skyvern?

Skyvern's Chromium launch accepts an HTTP(S) endpoint directly, which is why the examples use http://. SOCKS5 and OpenVPN are available too; reach for SOCKS5 only when a specific setup needs protocol-agnostic routing — for most Skyvern work, HTTP is simplest. See HTTP or SOCKS5 — which fits your stack.

Do I need a rotating pool for Skyvern?

No. A pool exists to pick an IP from many. An agent's multi-step flow needs a stable IP (a sticky session) so it isn't re-challenged on every action, so one dedicated German endpoint is the better fit. Rotate on demand at the proxy when you start a fresh run, not mid-task. See dedicated vs shared mobile proxy.

Related guides

Get Started

Give your Skyvern agent a real German mobile IP to work from. Get your German mobile endpoint — HTTP/SOCKS5/OpenVPN, sticky sessions, on-demand rotation, fair-use 20 GB/day, from a transparent EU provider. Browse the plans to get started.

Get a German mobile proxy: Real 4G/5G IPs from Germany, fair-use 20 GB/day — browse German mobile proxy plans or start small with a shared 5G proxy.