Direct Answer
To route LlamaIndex through a mobile proxy, set HTTP_PROXY and HTTPS_PROXY on the process that runs your reader. LlamaIndex's web readers — SimpleWebPageReader fetches with Python's urllib, BeautifulSoupWebReader with requests — both read those variables automatically, so pages load through your German mobile IP. The call to your LLM or embedding model keeps its own connection unless you route it through the proxy on purpose. You don't touch how the index is built or queried; you only change where the page fetches come from.
The One Thing Most LlamaIndex Proxy Guides Get Wrong
LlamaIndex is a data framework: you load documents, build an index, and query it with an LLM. The common mistake is thinking of "the proxy" as something the whole pipeline or the model sits behind. It isn't.
The proxy binds to the web reader, not the model. When SimpleWebPageReader or BeautifulSoupWebReader reads a German page into your index, that request is what should leave through your German mobile IP. The reasoning steps — the calls to your LLM and embedding provider — are a separate connection and usually don't need a German exit at all. Get this distinction right and the setup is a two-line change; get it wrong and you route model traffic through a mobile connection for no reason while your page fetch still exits from your own address.
So the goal is precise: send the reader's outbound page fetches through the German mobile proxy, and leave everything else alone.
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 LlamaIndex with the web reader package:
pip install llama-index llama-index-readers-web
Step 1 — Set the Proxy on the Reader's Environment
SimpleWebPageReader fetches with urllib and BeautifulSoupWebReader with requests — both honour HTTP_PROXY / HTTPS_PROXY automatically. Set them before you build the reader:
import os
PROXY = "http://USER:PASS@PROXY_HOST:PORT"
os.environ["HTTP_PROXY"] = PROXY
os.environ["HTTPS_PROXY"] = PROXY
That's the whole binding. Every reader built on urllib or requests now fetches through your German mobile IP — no per-reader configuration needed for the common case.
Step 2 — Load German Pages Through the Proxy
Here's a runnable load that reads German pages into documents through the proxy. The reader is the piece that carries the German mobile IP:
import os
from llama_index.readers.web import SimpleWebPageReader
PROXY = "http://USER:PASS@PROXY_HOST:PORT"
os.environ["HTTP_PROXY"] = PROXY
os.environ["HTTPS_PROXY"] = PROXY
# These fetches exit through the German mobile IP.
documents = SimpleWebPageReader(html_to_text=True).load_data(
["https://www.example.de"]
)
print(documents[0].text[:500])
From here you build an index (VectorStoreIndex.from_documents(documents)) and query it as usual — the pages already came in through your German mobile IP. BeautifulSoupWebReader works the same way if you want per-hostname extraction.
Step 3 — Proxy One Reader Only With an Explicit Client
If you want the German exit on one load only, fetch the HTML yourself with a proxied client and hand the text to LlamaIndex, instead of relying on the environment:
import httpx
from llama_index.core import Document
PROXY = "http://USER:PASS@PROXY_HOST:PORT"
# proxy= routes both http:// and https:// through the mobile proxy
with httpx.Client(proxy=PROXY, timeout=30) as client:
resp = client.get("https://www.example.de")
resp.raise_for_status()
documents = [Document(text=resp.text)]
This is the right choice when one pipeline mixes a German-exit fetch with, say, a direct call to your own internal API — only the load you configure carries the mobile IP.
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 env vars didn't reach the process or the explicit client isn't using the proxy — re-check the URL and that the credentials are in it. Confirm the ASN and geolocation look like a German mobile network, not a datacenter range. A full checklist is in testing your proxy setup.
Sticky Sessions vs. Rotation
How a load should handle IPs depends on the task:
- Sticky session — keep the same German mobile IP across a multi-page load (crawl a set of related URLs) so a sequence of fetches looks like one coherent visitor.
- Rotation on demand — request a fresh IP at the proxy between loads to spread load across a longer job.
Keep request rates human-reasonable and don't fan out dozens of parallel fetches. 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 a reader fetch a German site from a US datacenter range and your index 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, so your index fills up with challenge pages instead of content. 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 indexing job can pull many pages unattended, so the responsibility to keep it clean is higher, not lower:
- Respect
robots.txtand each site's terms — check them before you point a reader at a domain. - Throttle — add a delay between fetches 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 is web scraping legal in the EU.
[!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 LlamaIndex talks to the LLM?
No. The proxy binds to the web readers — the requests they make to target sites. The calls your pipeline makes to your LLM and embedding provider stay on their own connection unless you deliberately route them through the proxy too. In practice you set HTTP_PROXY / HTTPS_PROXY so the page fetches exit through the German mobile IP, and leave the model traffic alone.
Which LlamaIndex readers honour HTTP_PROXY?
Readers built on Python's urllib or requests — SimpleWebPageReader (urllib) and BeautifulSoupWebReader (requests) — read HTTP_PROXY and HTTPS_PROXY from the environment automatically, because that's the default behaviour of those libraries. For a reader that uses a different client, pass the proxy to that client directly, as in the explicit-client example above.
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 proxy URL you exported (http://USER:PASS@PROXY_HOST:PORT). See how to fix 407 proxy authentication required.
Do I need a rotating pool for LlamaIndex?
No. Pool services exist to pick an IP from many. With one dedicated German endpoint you point every reader at a single host and rotate on demand at the proxy — nothing to manage in code. See dedicated vs shared mobile proxy.
HTTP or SOCKS5?
urllib and requests work with an HTTP endpoint out of the box, which is why the examples use http://. SOCKS5 and OpenVPN are available too; reach for SOCKS5 only when a specific client needs it — for most LlamaIndex work, HTTP is simplest.
Can I set the proxy on one reader only?
Yes. Fetch the HTML yourself with a proxied requests or httpx client, then wrap the text in a Document and hand it to LlamaIndex — that way only that load uses the German mobile IP while the rest of your pipeline keeps its normal connection. If you drive a real browser to render a page first, set the proxy on the browser launch; see mobile proxy for AI browser agents.
Related guides
- Firecrawl Proxy Setup: Bring Your Own German Mobile IP
- LLM Web Scraping: Extract Structured Data From German Sites
- Per-GB Proxy Cost for AI Agents — Why It's the Wrong Bill
Get Started
Build your index from real German mobile IPs. 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 — compare German mobile proxy plans or start with a dedicated 5G proxy.