Next.js fetch ignores HTTPS_PROXY by default. Wire undici's ProxyAgent once and every server-side call, Server Action, and route handler egresses through two fixed static EU IPs.
Works with App Router, Server Actions, route handlers, and self-hosted Node
import { ProxyAgent, setGlobalDispatcher }
from "undici";
// Next.js fetch needs this explicitly
setGlobalDispatcher(
new ProxyAgent(process.env.HTTPS_PROXY)
);
// now fetch() uses one of your two EU IPs
Server-side Next.js code calls partner APIs, but the platform it runs on gives it no stable egress.
Next.js uses Node's native fetch, powered by undici, which does not read HTTPS_PROXY from the environment. Setting the env var alone changes nothing, so developers think the proxy is on while calls still leave from the host IP.
On Vercel and other serverless platforms, route handlers and Server Actions run across many function instances, each with its own egress IP. A single allowlisted address can never cover them all.
Next.js inlines NEXT_PUBLIC_ values at build time. Proxy URLs set that way get baked into the bundle or vanish at runtime, so the egress you configured in dev is missing in production.
Route handlers set to the Edge runtime can't import undici's ProxyAgent. A proxy that works in local dev on the Node runtime then breaks the moment the route runs on the Edge.
"Send us the IP that will call our API."
You need an answer that is still true after the next deploy.
Next.js app
OutboundGateway
Two fixed EU IPs
Partner API
The partner API sees one of your two fixed EU IPs, from every route handler and Server Action.
Route handlers and Server Actions that call IP-whitelisted partner APIs.
Full-stack apps integrating with enterprise APIs behind firewalls.
Docker or Node deployments that need a predictable egress identity.
Apps that must keep outbound traffic inside the EU.
Next.js fetch needs undici wired explicitly. Set it once and every server-side call is proxied.
Set HTTPS_PROXY as a runtime env var, then register a global undici dispatcher once. Every fetch in your App Router then routes through the proxy.
# .env (runtime only, never NEXT_PUBLIC_)
HTTPS_PROXY=https://USER:PASS@eu-01.outboundgateway.com:8443// app/proxy.ts
import { ProxyAgent, setGlobalDispatcher } from "undici";
if (process.env.HTTPS_PROXY) {
setGlobalDispatcher(new ProxyAgent(process.env.HTTPS_PROXY));
}
// app/ip/route.ts
export async function GET() {
const res = await fetch("https://outboundgateway.com/ip/");
return Response.json(await res.json()); // one of your two EU IPs
}📖 Full guide: for per-request agents, retries, and timeout handling, see the Node.js SSL proxy guide.
If your Next.js app uses axios instead of fetch, attach an https-proxy-agent to the instance. Remember to URL-encode credentials if the password has special characters.
import axios from "axios";
import { HttpsProxyAgent } from "https-proxy-agent";
const api = axios.create({
httpsAgent: new HttpsProxyAgent(process.env.HTTPS_PROXY),
});
const { data } = await api.get("https://api.partner.example.com/data", {
headers: { Authorization: `Bearer ${process.env.PARTNER_TOKEN}` },
});Pass the proxy URL at runtime so credentials never end up in the image.
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
CMD ["npm", "start"]docker run --rm -p 3000:3000 \
-e HTTPS_PROXY=https://USER:PASS@eu-01.outboundgateway.com:8443 \
my-nextjs-appWhen a partner cares where your traffic originates, the location of the egress matters.
Your proxy runs on infrastructure inside the European Union, so outbound traffic stays within EU jurisdiction.
Data handling that aligns with European privacy expectations, for teams that keep processing inside the EU.
Traffic is not detoured through US-based servers, which keeps your compliance story simple.
Two fixed IPs give auditors and partners a stable, predictable answer about where requests come from.
A pair of static IPs with automatic failover. Allowlist once, keep working.
Works with undici ProxyAgent and https-proxy-agent. Covers fetch and axios.
Set the global dispatcher once. Every route handler inherits it.
No NAT gateway, no VPC changes, no custom networking. Just a runtime env var.
TLS passthrough. Your traffic is never decrypted or inspected by the proxy.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Stop fighting undici and rotating serverless IPs. Give your Next.js backend two fixed EU IPs today.
No. Next.js uses Node's native fetch, which is powered by undici, and undici does not read the HTTPS_PROXY environment variable. You have to register a proxy explicitly with undici's setGlobalDispatcher(new ProxyAgent(process.env.HTTPS_PROXY)). Once that runs, every server-side fetch in your App Router routes through OutboundGateway's two fixed EU IPs.
The Edge runtime cannot import undici, so the ProxyAgent approach does not apply there. For outbound calls that must go through the proxy, keep those route handlers on the Node.js runtime. That is a real Next.js constraint, not a proxy limitation, and it is the main reason to prefer the Node runtime for IP-whitelisted partner calls.
Yes. Because the global undici dispatcher is process-wide, every server-side code path in your Next.js app, including Server Actions, route handlers, and getServerSideProps, uses it. You set it once and the whole backend egresses through the same two fixed static EU IPs, which is exactly what partner APIs expect.
We're happy to help you check whether OutboundGateway fits your Next.js workload.
Contact Our Team →