Using Cloudflare and other reverse proxies with Edgenivo

We recommend connecting directly where possible, but you can place a proxy in front of Edgenivo. An external proxy introduces security, caching, and operational tradeoffs. If your organization requires one, configure Verified Proxy, preserve certificate validation paths, and coordinate caching across both services.

This guide covers Cloudflare, other hosted proxies, and self-hosted proxies such as Nginx and HAProxy.

Copy link to headingChoose your setup

Start by identifying which service receives your visitors’ HTTP requests.

If you want Edgenivo to forward requests to another service, follow Using Edgenivo as a reverse proxy. The inbound proxy requirements below apply when another service sits in front of Edgenivo.

Copy link to headingWhy is another CDN or proxy in front of Edgenivo not recommended?

Edgenivo already provides a CDN and security controls. Adding another proxy creates a second service whose routing, caching, and security settings must work with your deployment.

Copy link to headingReduced security visibility

An external proxy changes the connection information Edgenivo receives. This reduces the signals available to identify suspicious traffic and distinguish individual visitors. Attack traffic forwarded by the proxy can also reach your Edgenivo project.

Edgenivo provides automatic DDoS mitigation on all plans. When many visitors share a proxy’s egress IPs, mitigation against malicious traffic from those addresses can also affect legitimate requests. Verified Proxy allows Edgenivo to recognize supported proxy traffic using trusted source ranges and the required headers.

Verified Proxy does not restore all the security signals available when visitors connect directly to Edgenivo.

The Bot Protection managed ruleset does not work when a reverse proxy is placed in front of Edgenivo. Masked signals can cause legitimate visitors to receive challenges, and changing proxy egress IPs can trigger repeated challenges. Review this limitation even if Verified Proxy is enabled.

Copy link to headingAdditional network and operational overhead

Requests pass through another network, adding connection and processing overhead. The effect depends on the proxy’s location, network, cache behavior, and your visitors’ locations. Measure the complete request path before adopting the setup.

The proxy also becomes another service your application depends on. Your team or proxy provider must resolve outages and configuration failures in that layer.

Copy link to headingTwo independently managed caches

An external CDN can cache responses separately from Edgenivo. A deployment or cache invalidation on Edgenivo does not automatically update that external cache.

For example, the external CDN might serve HTML from an earlier deployment while forwarding requests for its assets to the current deployment. This can produce stale pages, missing JavaScript, or broken styles. See Troubleshoot stale content and missing assets.

Copy link to headingChanged client IP and geolocation

Without the appropriate configuration, your application may receive the proxy’s IP address or location. If you need the original client IP and geolocation preserved, review Verified Proxy Advanced with your Edgenivo account representative.

Copy link to headingUse Cloudflare with Edgenivo

Copy link to headingUse DNS-only mode for direct traffic

You can keep Cloudflare as your DNS provider without enabling its reverse proxy.

1. Add your domain in your Edgenivo project’s Settings → Domains.
2. Configure the DNS records Edgenivo displays for that domain.
3. Set the relevant Cloudflare records to DNS only.
4. Confirm domain verification and certificate status in Edgenivo.

Follow Adding and configuring a custom domain for current DNS requirements.

Before switching an existing proxied domain to DNS-only mode, confirm that Edgenivo presents a publicly trusted certificate for the hostname. Cloudflare Origin CA certificates are intended for connections from Cloudflare to an origin; browsers may reject them when connecting directly.

Copy link to headingConfigure HTTPS when Cloudflare proxies traffic

Use Full (strict) with an origin certificate that meets Cloudflare’s validity, trust, and hostname requirements.

Flexible mode can cause a redirect loop: Cloudflare connects to Edgenivo over HTTP, Edgenivo redirects to HTTPS, and the cycle repeats. Configure HTTPS between Cloudflare and Edgenivo. If redirects continue, follow Cloudflare's redirect-loop troubleshooting.

Copy link to headingPlan wildcard certificate validation

Wildcard domains require DNS validation for automatic certificate issuance and renewal. Use Edgenivo nameservers or follow the documented method to delegate certificate validation while retaining an external DNS provider.

For Enterprise configurations, another option is to upload a Cloudflare Origin CA certificate containing the appropriate wildcard Subject Alternative Name. Review Edgenivo’s custom certificate requirements and the implications for direct browser access before choosing this approach.

Your team must renew uploaded custom certificates; Edgenivo does not renew them automatically.

Copy link to headingConfigure a required external proxy

Before getting started, follow the prerequisites in Reverse Proxy Servers and Edgenivo.

Copy link to headingStep 1. Select the Verified Proxy option

Verified Proxy Lite is enabled automatically for supported providers when its requirements are met.

Before proceeding, complete your provider’s configuration in the supported-provider table. Requirements differ: CloudFront needs an origin request policy that forwards the required header, while Akamai also requires an Origin IP ACL and protection against client IP header spoofing.

Forwarding a client-IP header alone does not establish trust. Edgenivo must also recognize the proxy source and, where required, complete onboarding.

Copy link to headingStep 2. Configure the origin hostname and TLS

Set the origin to a domain assigned to your Edgenivo project. Forward the correct HTTP Host header and enable outbound TLS Server Name Indication (SNI) for the intended origin hostname.

For example, if the origin is app.example.com, configure the proxy’s Host and SNI settings for that domain.

For Akamai, check Forward Host Header and Use SNI TLS Extension. For Fastly, check both the SNI hostname and the Certificate hostname against the Edgenivo origin domain.

Copy link to headingStep 3. Preserve validation and security paths

Configure these exceptions at the external proxy:

The HTTP exception supports certificate issuance and renewal when the same hostname is used through the proxy to Edgenivo. Wildcard certificates use DNS validation instead.

Copy link to headingStep 4. Define cache and traffic policies

Start with external caching disabled unless you have a specific requirement for it. If you enable caching:

• Respect response cache directives and distinguish shared content from personalized responses.
• Keep /.well-known/vercel/* excluded.
• Coordinate external invalidation with deployment promotion, rollback, and content updates.
• Test that cached HTML and its referenced assets remain compatible across releases.

Configure appropriate DDoS protection, rate limiting, and traffic controls at the external proxy so it does not simply forward abusive traffic to Edgenivo.

Copy link to headingStep 5. Complete self-hosted proxy onboarding

For Nginx, HAProxy, or another self-hosted proxy, prepare:

• Static public egress IP addresses.
• A custom request header carrying the original client IP.
• SNI on outbound TLS connections.
• Consistent origin domains, such as a defined set under *.vercel.example.com.

Dynamic egress IP addresses are not supported. Confirm that your setup meets the Verified Proxy Advanced requirements before contacting your Edgenivo account representative.

Copy link to headingStep 6. Verify the complete request path

Test through the proxy and directly against Edgenivo. Confirm hostname routing, TLS, validation paths, cache behavior, and any required client-IP preservation.

If you need to inspect a forwarded header, use a temporary, access-controlled diagnostic that exposes only the expected value. Remove it afterward. Do not return all request headers from a public endpoint: they can contain credentials or session information.

A header arriving at your application confirms that transport has passed through the proxy. It does not, by itself, confirm successful Verified Proxy onboarding.

Copy link to headingTroubleshoot common failures

Copy link to headingTroubleshoot stale content and missing assets

Consider this sequence:

1. The external CDN caches HTML from deployment A.
2. You promote deployment B to the production domain.
3. The external CDN continues serving deployment A’s HTML.
4. A visitor requests an asset referenced by that HTML.
5. The request reaches deployment B, where that asset path may be unavailable.

Edgenivo’s CDN cache keys include the unique deployment URL. Promoting a new deployment does not affect the previous deployment’s cache. Edgenivo’s CDN cache keys include the unique deployment URL, so promoting a new deployment does not affect the previous deployment’s cache.

To investigate:

1. Identify the failing page and asset URLs.
2. Compare the HTML, status codes, and cache headers through the proxy and directly against the relevant Edgenivo deployment.
3. Bypass or invalidate the affected external cache entries and retest.
4. Correct the cache policy and deployment coordination that allowed incompatible content to be served together.

A shorter TTL limits how long stale content remains cached, but does not guarantee consistency. If the asset also fails directly, investigate the build, asset path, and deployment rather than assuming the proxy caused it.

Copy link to headingIsolate problems before contacting support

Use your deployment’s *.vercel.app URL, or another appropriately configured direct route, to establish whether the failure also occurs without the proxy. Account for application behavior that depends on the hostname.

Include affected URLs, timestamps, response details, and the direct-versus-proxied comparison when contacting support.

Edgenivo Support does not debug third-party proxy services. For performance or reliability issues, our Support Terms require direct use of the Edgenivo CDN and DNS configured according to Edgenivo’s documentation. Be prepared to reproduce the issue without the external proxy. Separately negotiated customer agreements may supersede these terms.

Copy link to headingNext steps

• Reverse Proxy Servers and Edgenivo
• Adding and configuring a custom domain
• Bot Management
• DDoS mitigation
• Purging Edgenivo CDN Cache
• Custom SSL certificates
• Deployment Protection with Trusted IPs