Transparent Proxy Mode

Serve another website's content through your domain — without the visitor ever seeing a redirect.

Two ways to proxy with RedirectIQ:

  • This page —Full-site transparent proxy. Your entire domain is routed through the edge to an origin server. Every unmatched request is proxied. Used for zero-downtime migrations and auto-healing.
  • See also —Reverse proxy rules. Individual rules with type: proxy that fetch a specific upstream URL and serve its response from your domain. No full-site proxy needed. The Plausible analytics pattern uses this.

What transparent proxy mode is

Normally, when a visitor hits a domain with a redirect rule, their browser is sent to a new URL — the address bar changes and the browser makes a second request. That is a redirect.

Transparent proxy mode is different. When a visitor hits your domain, our edge worker fetches the content from your origin behind the scenes and streams it back to the visitor — without changing the URL in their browser. To the visitor, your domain is the website. The origin is invisible.

Standard redirect
  1. 1. Visitor hits yourdomain.com
  2. 2. Browser receives 301/302
  3. 3. Browser navigates to new URL
  4. URL bar changes
Transparent proxy
  1. 1. Visitor hits yourdomain.com
  2. 2. Edge fetches from origin
  3. 3. Content streamed back
  4. URL bar stays the same

How requests flow

Every request goes through the same pipeline. Redirect rules are checked first — the proxy only activates if no rule matches.

1

Request arrives at the edge

A visitor requests a URL on your domain. Our Cloudflare Worker intercepts it before it reaches any origin server.

2

Redirect rules are checked

We look for an exact path match, then a wildcard match, then a catch-all rule. If any rule matches, we issue a standard 301 or 302 redirect and stop here.

3

No rule matched - proxy activates

If no redirect rule matches and proxy mode is enabled, we rewrite the request to point at your origin, preserving the full path and query string.

4

Origin responds

We fetch the response from your origin. If the origin follows its own internal redirects, we follow them too and serve the final response.

5

Response streamed to visitor

The origin's response — HTML, images, JSON, anything — is streamed directly to the visitor. Their browser sees your domain, not the origin.

Request flow
yourdomain.com/any-path
-> check redirect rules
-> rule match → 301/302 redirect
-> no match → fetch origin/any-path → stream response

Why enable proxy mode

Proxy mode is the foundation for everything intelligent this platform does at the edge. Without it, we can only act on paths you have explicitly configured. With it, we see every request your site receives — and can act on what we find.

Automatic broken link detection and healing

When your origin returns a 4xx for a proxied request, we record it as a broken link in real time — no crawler, no sitemap scan, no manual audit required. Once enough signal accumulates, the platform can automatically create a redirect rule to fix it. Visitors stop hitting dead ends without you touching a config file.

Redirect chain detection

If your origin follows its own internal redirects before settling on a final URL, we detect the gap between the requested path and where it lands. Chains slow down visitors and bleed link equity. The platform surfaces them so they can be flattened into a single direct redirect.

Edge-layer redirect rules without touching your origin

Once proxied, you can add redirect rules for any path without deploying code, editing config files, or involving your hosting provider. Rules fire at the edge before the request ever reaches your origin — instant, zero-downtime.

Using proxy mode for something else? We'd like to hear about it. Every use case we learn about shapes what we build next. Get in touch →

How to enable it

1

Connect your domain

Your domain must be connected and DNS validated before proxy mode can be enabled. Follow the getting started guide if you haven't done this yet.

2

Open the domain in the dashboard

From the Domains list, click on your domain to open its settings.

3

Find the Transparent Proxy section

Scroll past the Redirect Rules section. You will see the Transparent Proxy toggle.

4

Enter your origin URL

Enter the HTTPS URL of the website you want to proxy. This must be a different domain — you cannot proxy a domain to itself.

5

Enable the toggle and save

Toggle proxy mode on and click Save. The change deploys globally within about a minute.

CDN-hosted origins

When your origin is behind a CDN (such as AWS CloudFront, Amplify, or similar), the raw CDN domain URL is often not the right value to use as your origin. CDN distributions typically only serve content when the Host header matches a domain they are configured to accept. Our proxy network cannot override the Host header on outbound requests — it is set automatically from the origin URL you provide.

Symptom

If your origin returns a 404 or 403 immediately after enabling proxy mode, even though the origin works fine when visited directly, this is almost always a Host header mismatch caused by a CDN in front of your origin.

How to find the right origin URL

Instead of using the CDN distribution URL, use the URL that your CDN platform exposes as the app's own default domain — before any custom domain is attached. This URL is always valid regardless of what custom domain you have pointed at it.

AWS Amplify

Use the branch URL, not the CloudFront distribution domain. The branch URL looks like https://<branch>.<appid>.amplifyapp.com — find it in the Amplify console under your app → the branch name.

Amplify returns a 301 redirect (not a 404) for missing pages. The edge automatically detects this and surfaces a correct 404 to visitors and crawlers.

Vercel

Use the project URL assigned by Vercel: https://<project-name>.vercel.app. Find it in the Vercel dashboard under your project → Domains.

Netlify

Use the Netlify subdomain for your site: https://<site-name>.netlify.app. Find it in the Netlify dashboard under your site → Site overview.

Other CDN or hosting

Look for the platform's own subdomain or default URL for your project — the one that existed before you attached your custom domain. Use that as your origin URL.

Quick test: Paste your intended origin URL directly into a browser. If it loads your site correctly, it will work as a proxy origin. If it returns a 404 or error page, find the platform-specific default URL instead.

SEO and duplicate content

Important: canonical tags

When proxy mode is active, two domains serve identical content — your domain and the origin. Search engines may treat this as duplicate content and suppress one from results. The standard fix is canonical tags.

A canonical tag tells search engines which URL is the authoritative version of a page. It looks like this in the <head> of your HTML:

<link rel="canonical" href="https://your-origin.com/the-page" />

Because our worker streams the origin's response unchanged, if your origin already sets canonical tags pointing to itself, they pass through automatically — no extra configuration needed.

If your origin sets canonical tags

You are covered. Most CMSs (WordPress, Webflow, Framer, Ghost) set canonicals by default pointing to the page's own URL on the origin domain. These pass through the proxy unchanged, telling Google that the origin is authoritative.

If your origin does not set canonical tags

Add canonical tags to your origin before enabling proxy mode. Where you add them depends on your CMS or framework — most have a built-in field or plugin for this. Without canonicals, both domains may compete in search results.

If you want the proxied domain to rank

Set the canonical tags on your origin to point to the proxied domain (your domain), not the origin. This tells search engines that your domain is the authoritative source. This only makes sense if you eventually plan to fully migrate off the origin.

Limitations

Origin must be HTTPS: The origin URL must use HTTPS. HTTP origins are not supported.
No same-domain proxying: You cannot proxy a domain to itself. The origin must be a different hostname.
Cookies and sessions: If your origin sets cookies with a specific domain attribute, those cookies may not work correctly when served under a different domain. Test login flows and session-dependent pages carefully.
Absolute URLs in HTML: If your origin renders absolute links or asset URLs pointing to the origin domain, those references will still point to the origin. Visitors will see the correct content, but some links may take them to the origin domain.
No HTML rewriting: We stream the origin response without modifying it. We do not inject canonical tags, rewrite links, or transform the HTML in any way. This is intentional &mdash; rewriting adds latency and can break pages.
CDN-hosted origins require the platform default URL: If your origin is behind a CDN, use the platform's own default subdomain as the origin URL, not the CDN distribution domain. See the CDN-hosted origins section above for details.
Proxy vs. redirect rules are separate: Redirect rules always fire first. Proxy mode handles only paths that have no matching redirect rule. You can mix both on the same domain.

Have questions that are not covered here?

Contact us →