Deploying a reverse proxy to PostHog Cloud

A reverse proxy enables you to send events to PostHog Cloud using your own domain.

This means setting up a service to redirect requests from a subdomain you choose (like e.yourdomain.com) to PostHog.

You then use this subdomain as your api_host in the initialization of PostHog instead of us.i.posthog.com or eu.i.posthog.com.

Why do we recommend deploying one?

Using a reverse proxy means that events are less likely to be intercepted by tracking blockers.

You'll be able to capture more usage data without having to self-host PostHog, ensuring you get a complete view of your users.

Deploying a reverse proxy

Using our managed reverse proxy is the easiest way to do this.

It's available as part of our platforms add-ons, which includes automatic provisioning, SSO and 2FA enforcement, priority support, and additional collaboration features.

Other documented options for deploying a reverse proxy include:

• AWS CloudFront
• Caddy
• Cloudflare
• Kubernetes Ingress Controller
• Netlify
• Next.js rewrites
• Next.js middleware
• nginx
• node
• Railway
• Remix
• SvelteKit
• Vercel
• Nuxt
• Pomerium

Best practices

• We require that the proxy sets the Host header to the same host it's calling. Check the guides above on how to do that for several proxies.
• Don't use a subdomain that includes posthog, analytics, tracking, or other similar words which might cause events to be blocked.
• Make sure to pass the proper ui_host parameter when initializing PostHog, so that links to PostHog point to the correct host (like us.posthog.com). This is required for tasks like authenticating the toolbar.

• Avoid using generic or common path names like /analytics, /tracking, /ingest, or /posthog for your reverse proxy. They will most likely be blocked. Instead, use a non-obvious path name or something random and unique to your application that's unlikely to appear in a filter list.

Reverse proxy requirements

If you want to use an alternative reverse proxy that we have not documented, it must meet the following requirements:

- route: e.yourdomain.com/static/*
  reverse_proxy: https://us-assets.i.posthog.com/static/*
  host_header: us-assets.i.posthog.com

- route: e.yourdomain.com/*
  reverse_proxy: https://us.i.posthog.com/*
  host_header: us.i.posthog.com

FAQ

Why doesn't PostHog use its own proxy?

We do use a proxy for our own analytics! However, ad blockers specifically target well-known analytics and tracking domains. When ad blockers visit posthog.com, they identify and catalog the tracking scripts and domains we use, then add them to their block lists.

This means that even if we proxy our own tracking through a subdomain like e.posthog.com, ad blockers will still block it because they've specifically identified it as a PostHog tracking endpoint. You might notice this if you use an ad blocker on us.posthog.com - some of our internal feature flags may not load properly because the ad blocker is intercepting those requests.

Your proxy works differently because ad blockers haven't specifically visited your domain to catalog your tracking setup. When you use a domain like e.yourdomain.com, it appears to ad blockers as just another part of your application rather than a known tracking service.