Three meanings, one phrase
| Type | What it is | Examples |
|---|---|---|
| Commercial relay | Third party resells API access; you pay them, they hold your balance | The former AIProxy.io and dozens like it |
| Self-hosted gateway | Software you run: one endpoint, many providers, per-key quotas | One API, New API, LiteLLM |
| Network proxy | Changes the IP your requests originate from | Static residential / ISP proxies |
Confusion between these is why so much advice online seems contradictory. A relay includes the other two layers (that's its value and its risk); the self-hosted approach means assembling them yourself.
Layer 1: the gateway
One API (and its actively-maintained fork New API) deploys with a single Docker command and gives you the dashboard former relay users know: channels (upstream provider keys), tokens (keys you hand out, with quotas), and usage logs. Point any OpenAI-compatible SDK at your gateway URL and every tool you own works unchanged.
from openai import OpenAI
client = OpenAI(
api_key="your-gateway-token",
base_url="https://your-gateway.example.com/v1")LiteLLM does the same job with a Python-first flavour and 100+ provider adapters. Either way: the gateway manages who can spend what — it does nothing about where your traffic appears to come from.
Layer 2: the network route
OpenAI applies different treatment by origin IP: unsupported regions are blocked outright, and datacenter ranges attract extra scrutiny (many VPS ranges are flagged from abuse history). If your gateway runs in a region OpenAI doesn't serve — or on a VPS with a noisy IP neighbourhood — you route its outbound traffic through a proxy:
- Static residential — a fixed IP from a real ISP. The right choice for API access: consistent, clean, looks like home broadband.
- Rotating residential — changes IP per request. Built for scraping, wrong for API accounts: providers read constant IP churn as account compromise.
- Datacenter — cheap and fast but exactly what you're trying to avoid for this use case.
Wiring them together
Most gateways honour standard proxy environment variables, so the whole integration is two lines in your Docker config:
environment:
- HTTPS_PROXY=socks5://user:pass@your-static-ip:portVerify with a request to a model endpoint and check the gateway's channel test passes. From that point every key you issue inherits the clean route automatically — teammates and tools never need to know the proxy exists.