Can Vercel serve content from another origin while retaining the public URL?

Definition: Yes. Vercel can forward a request to an API or website outside the project through an external rewrite while the browser continues to show the public URL. Vercel documents this routing as reverse proxy behavior.

Key facts

• Vercel defines a rewrite as routing a request to a different destination without changing the URL shown in the browser. Vercel's rewrite documentation distinguishes this from a redirect.
• An external origin is an API or website outside the Vercel project. Vercel says an external rewrite forwards requests to that destination and can serve content hosted elsewhere.
• In vercel.json, the source matches an incoming pathname and destination can be an absolute pathname or an external URL, according to Vercel's configuration reference.
• Vercel forwards x-real-ip, x-forwarded-for, x-forwarded-host, and x-forwarded-proto headers to the external origin.
• For projects created on or after 6 April 2026, Vercel says external rewrites respect selected upstream caching headers by default.

How does an external rewrite keep the public URL?

The rewrite matches the public request path at Vercel's edge and forwards the request to the external destination. The browser continues to display the public path because the routing happens inside the request handling flow. Vercel's documentation gives this example:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "rewrites": [
    {
      "source": "/api/:path*",
      "destination": "https://api.example.com/:path*"
    }
  ]
}

With this rule, Vercel says a request to /api/users is forwarded to https://api.example.com/users without changing the browser URL. The wildcard captures the path after /api/ and places it after the external host. The configuration reference describes source as a pattern for each incoming pathname, excluding the query string.

What counts as an external destination?

Vercel calls an API or website outside the project an external origin. The external rewrite feature can proxy API requests, combine multiple backends under one domain, serve externally hosted content, and use the Vercel network as a reverse proxy or standalone CDN. The documentation says the feature works with all frameworks.

The destination is written as an absolute URL. The vercel.json reference also documents external URLs as valid destination values for rewrite objects. The same reference describes rewrites as an array of rewrite objects, so the rule belongs in the project's root configuration file alongside the source pattern.

Which visitor details reach the origin?

Vercel says it forwards four request headers that identify the original visitor: x-real-ip and x-forwarded-for carry the visitor's public IP address, x-forwarded-host carries the requested host, and x-forwarded-proto carries the protocol used by the visitor. The origin does not need a custom header just to receive these values.

If the origin uses its own load balancer or proxy, Vercel advises configuring that layer to trust these headers only for requests that come from Vercel. The rewrite documentation also describes a routes transform that sets a secret request header when an origin must reject direct requests.

How does caching affect the response?

Vercel says external rewrites honor cache-control, CDN-Cache-Control, and Vercel-CDN-Cache-Control headers from upstream servers when rewrite caching is enabled. This behavior is enabled by default for projects created on or after 6 April 2026. Older projects keep the earlier uncached behavior unless the dashboard setting is enabled or the x-vercel-enable-rewrite-caching header is set.

The documented opt-out sets that header to 0 in a response header rule. This controls Vercel's caching of the upstream response; it does not turn the rewrite into a browser redirect. The rewrite documentation also says runtime logs include external origin events and that Observability exposes request counts and connection latency for proxied requests.

How can you check the configuration?

Vercel recommends using a preview deployment to test rewrites before production. Each pull request creates a unique preview URL where you can verify that the public path returns the intended upstream content while the address remains the public path. The external origin's access logs can then be checked against the forwarded host and protocol headers documented by Vercel.

Related terms

• How do I configure redirects in vercel.json?
• How do Vercel redirects handle query parameters?
• How do I read Vercel's request and cache response headers?
• HTTP redirects

FAQ

Does the visitor see the external hostname?

No. Vercel says an external rewrite forwards the request without changing the URL in the browser. The public hostname remains in the address bar while the response comes from the configured external destination.

Can the destination be an API as well as a website?

Yes. Vercel defines an external origin as an API or website outside the project and documents both API proxying and serving externally hosted content as uses for external rewrites.

Does an external rewrite always cache the upstream response?

Caching depends on the project's documented rewrite-caching behavior and the upstream headers. Vercel says the default changed for projects created on or after 6 April 2026, and provides x-vercel-enable-rewrite-caching: 0 to prevent caching.

Sources

1. Vercel, "Rewrites on Vercel", 11 August 2026
2. Vercel, "Static Configuration with vercel.json", 14 August 2026

---

Check how a page reads to answer engines. Open the GEO score analyzer