Vercel AI SDK Proxy Setup with a German Mobile Proxy

Direct Answer

To route the Vercel AI SDK through a mobile proxy, build an undici ProxyAgent with your endpoint and register it with setGlobalDispatcher. The AI SDK's tools reach the web with Node's fetch, and once the global dispatcher is set, every fetch — including the ones your tools call — routes through the proxy. So your German mobile IP is what fetches the pages. If you'd rather route only a tool, pass a per-request dispatcher on that tool's fetch and leave the model on its own connection. You don't change how the agent reasons; you only change where its web requests come from.

The One Thing Most Vercel AI SDK Proxy Guides Get Wrong

The AI SDK is a TypeScript toolkit: you define tools, and the model calls them in a loop until the task is done — a model plus tools is an agent. The common mistake is thinking of "the proxy" as something the whole agent or the model sits behind. In Node, it's more precise than that.

The proxy belongs in Node's HTTP layer, and what you point at it is your choice. A tool that reads a German page does it with fetch; that request is what should leave through your German mobile IP. The model call is also a fetch, but it usually doesn't need a German exit. undici — the HTTP client behind Node's fetch — gives you both options: a global dispatcher that routes every fetch, or a per-request dispatcher that routes just one. Pick the scope you actually want instead of tunnelling everything by accident.

So the goal is precise: send the agent's tool web requests through the German mobile proxy, and decide deliberately whether the model call goes with them.

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.

Install the AI SDK and a provider (undici ships with Node.js):

npm install ai @ai-sdk/openai

Run the examples in the Node.js runtime — undici's ProxyAgent is a Node feature and isn't available in Edge or browser fetch.

Step 1 — Route Every fetch Through the Proxy

The simplest binding registers one undici ProxyAgent as the global dispatcher. After this, every Node fetch — the model call and each tool's request — exits through your German mobile IP:

import { ProxyAgent, setGlobalDispatcher } from "undici";

const PROXY = "http://USER:PASS@PROXY_HOST:PORT";

// From here on, every fetch() in this process uses the proxy.
setGlobalDispatcher(new ProxyAgent(PROXY));

That's the whole binding for the common case. It's the right choice when you want the entire agent — including the tools it calls — on the German mobile IP.

Step 2 — Give a Tool a Web Request and Run the Agent

Here's a runnable agent whose tool reads a German page. With the global dispatcher set above, the tool's fetch carries the German mobile IP:

import { generateText, tool } from "ai";
import { openai } from "@ai-sdk/openai";
import { z } from "zod";

const fetchGermanPage = tool({
  description: "Fetch a URL and return its text.",
  parameters: z.object({ url: z.string() }),
  // This fetch exits through the German mobile IP (global dispatcher).
  execute: async ({ url }) => {
    const res = await fetch(url);
    return await res.text();
  },
});

const { text } = await generateText({
  model: openai("gpt-4o"),
  tools: { fetchGermanPage },
  maxSteps: 5,
  prompt: "Fetch https://www.example.de and summarise the public product details.",
});

console.log(text);

The model decides when to call the tool; undici decides how the request leaves — and with the dispatcher set, it leaves through your German mobile IP.

Step 3 — Route Only the Tool, Not the Model

If you want the German exit on the tool's request alone and the model on your normal connection, skip the global dispatcher and pass a per-request dispatcher on that specific fetch:

import { ProxyAgent } from "undici";
import { tool } from "ai";
import { z } from "zod";

const PROXY = "http://USER:PASS@PROXY_HOST:PORT";
const proxyAgent = new ProxyAgent(PROXY);

const fetchGermanPage = tool({
  description: "Fetch a URL through the German mobile proxy.",
  parameters: z.object({ url: z.string() }),
  execute: async ({ url }) => {
    // dispatcher routes only THIS request through the mobile proxy.
    const res = await fetch(url, { dispatcher: proxyAgent } as RequestInit);
    return await res.text();
  },
});

dispatcher is an undici extension to the fetch options, not part of the standard Fetch API — which is why it's cast here. Only this tool's traffic carries the German mobile IP; the model call and any other fetch stay on your normal connection.

Verify the IP First

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

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

If it returns your own address, the dispatcher didn't take effect — re-check the ProxyAgent URL, that the credentials are in it, and that you're running in the Node runtime. Confirm the ASN and geolocation look like a German mobile network, not a datacenter range. A full checklist is in verifying your mobile proxy.

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 (fetch a page, follow links, extract) so a sequence of tool calls looks like one coherent visitor.
Rotation on demand — request a fresh IP at the proxy between runs to spread load across a longer job.

Keep request rates human-reasonable and cap how many tool calls fire at once. 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. Have your agent fetch a German site from a US datacenter range and it measures 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 data collection — it is not a tool to circumvent access controls or platform rules. An agent runs largely unattended, so the responsibility to keep it clean is higher, not lower:

Respect robots.txt and each site's terms — bake the check into the tool, not just into intentions.
Throttle — add a delay between tool calls and cap concurrency so you don't overload target servers.
Collect only public data you need, and handle any personal data in line with the GDPR.
Identify your client honestly — set a truthful User-Agent; don't impersonate someone else.

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 the AI SDK talks to the model?

Only if you route it there. With setGlobalDispatcher, every Node fetch uses the proxy — the model call and every tool request alike. If you want the model on your normal connection and only the tool on the German mobile IP, skip the global dispatcher and pass a per-request dispatcher on that tool's fetch instead.

Where does the proxy go in the Vercel AI SDK?

In Node's HTTP layer, via undici. Build new ProxyAgent("http://USER:PASS@PROXY_HOST:PORT") and either call setGlobalDispatcher(agent) to route every fetch, or pass { dispatcher: agent } to a specific fetch call inside a tool's execute. The AI SDK's tools use standard fetch, so both approaches work without extra middleware.

How do I route only the tool, not the model?

Skip the global dispatcher and pass dispatcher: proxyAgent on the individual fetch call your tool's execute makes. Only that request exits through the German mobile IP; the model call and any other fetch keep your normal connection.

Why do I get a 407 error?

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

Does this work in Edge or serverless runtimes?

undici's ProxyAgent is a Node.js feature, so run tool fetches in the Node runtime. Edge and browser fetch don't accept a Node dispatcher, so a proxy set this way won't apply there. For most AI SDK agents that scrape, running the tool on Node is the straightforward path.

Do I need a rotating pool for the AI SDK?

No. Pool middlewares exist to pick an IP from many. With one dedicated German endpoint you point every tool fetch at a single host and rotate on demand at the proxy — nothing to manage in the agent. See dedicated vs shared mobile proxy.

Related guides

Get Started

Give your Vercel AI SDK agent a real German mobile IP to collect from. Get a German mobile proxy — 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 try a shared 5G German proxy.