Edge Proxy
Serve another website's content through your domain — without the visitor ever seeing a redirect.
Two ways to proxy with RedirectIQ:
- This page —Edge 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: proxythat fetch a specific upstream URL and serve its response from your domain. No full-site proxy needed. The Plausible analytics pattern uses this.
What Edge Proxy 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.
Edge Proxy 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, transparently. To the visitor, your domain is the website. The origin is invisible.
- 1. Visitor hits
yourdomain.com - 2. Browser receives 301/302
- 3. Browser navigates to new URL
- URL bar changes
- 1. Visitor hits
yourdomain.com - 2. Edge fetches from origin
- 3. Content streamed back
- URL bar stays the same
Coming from domain forwarding with masking at your registrar? See why masking hurts SEO and how Edge Proxy gets you the same result without the risk.
How requests flow
Every request goes through the same pipeline. Redirect rules are checked first — the proxy only activates if no rule matches.
Request arrives at the edge
A visitor requests a URL on your domain. Our Cloudflare Worker intercepts it before it reaches any origin server.
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.
No rule matched - proxy activates
If no redirect rule matches and Edge Proxy is enabled, we rewrite the request to point at your origin, preserving the full path and query string.
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.
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.
Why enable Edge Proxy
Redirect rules alone are already complete if every request to this domain is meant to be a redirect — a dedicated short-link domain, or a domain you're retiring or consolidating into a new site. You don't need Edge Proxy for that; a default redirect rule covers it.
If this is still your live site, Edge Proxy isn't optional the way it might sound — it's what makes sure any path you haven't written a rule for still reaches your real site instead of returning a 404. On top of that, it's the foundation for everything else intelligent this platform does at the edge:
Real traffic analytics
See what's actually happening on your domain, not just the paths you've configured. Verified hit counts from real requests — not Search Console impression estimates — included automatically once Edge Proxy is on, no extra toggle, no separate plan.
Technical SEO Autopilot
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. When your origin follows its own internal redirects before settling on a final URL, we detect the gap and can flatten it into a single direct redirect. Included automatically once Edge Proxy is on, no extra toggle, no separate plan.
Malicious traffic visibility
We classify every request that hits your domain — human, search engine, AI crawler, bot, or exploit scanner — so you can see when someone's probing for .env files or old WordPress admin paths, not just when a real visitor hits a dead link. Included automatically once Edge Proxy is on, no extra toggle, no separate plan.
Using Edge Proxy 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
Connect your domain
Your domain must be connected and DNS validated before Edge Proxy can be enabled. Follow the getting started guide if you haven't done this yet.
Open the domain in the dashboard
From the Domains list, click on your domain to open its settings.
Find the Edge Proxy section
Scroll past the Redirect Rules section. You will see the Edge Proxy toggle.
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.
Enable the toggle and save
Toggle Edge Proxy 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 Edge Proxy, 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.
SEO and duplicate content
Important: canonical tags
When Edge Proxy 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 Edge Proxy. 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
Have questions that are not covered here?
Contact us →