Your backend talks to a hosted LLM provider. The provider does not accept requests from your region — sometimes silently (timeouts), sometimes loudly (HTTP 403 with a "country" message). Routing the entire backend through a VPN is the obvious answer and the wrong one: now your database round-trips, message broker, object storage and observability all egress through a foreign network. Latency doubles. Bills triple.
The right shape is a domain-scoped tunnel. List the AI vendor's API hostnames as "tunnel only", point the SDK at QPOL's local SOCKS endpoint, and leave everything else native. Postgres, Redis, Kafka, Loki, Sentry — none of them go through the VPN. Only the request-to-LLM and its response do.
If the provider expects a stable client IP (some do, for abuse heuristics, even when not explicitly required), use a Personal server. The shared pool rotates exits, which is fine for chat-style usage and bad for batch jobs that get rate-limit-flagged when an IP suddenly differs from the one used 30 seconds earlier.
A surprising tripwire: many AI SDKs read system proxy variables (HTTPS_PROXY, ALL_PROXY) before honouring per-client config. Set the proxy at the client level explicitly. Otherwise unrelated HTTP calls in your app — analytics pings, third-party SDKs — start leaking through the tunnel without you noticing.
Finally, instrument the tunnel itself. A 1% failure rate on direct LLM calls becomes a 1% × tunnel-availability rate end-to-end. Watch SOCKS connect-time and surface it in your dashboards next to LLM latency.