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:

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:

YAML
- 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
Some systems have size limits (e.g. AWS WAF defaults to 8kb) which can cause problems if they are used as or with a reverse proxy. PostHog events can be up to 1MB and session recordings can be up to 64MB per message, so you may need to adjust your limits.

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.

Does PostHog Cloud provide static IP addresses for firewall allowlisting?

No, PostHog Cloud does not provide static IP addresses for its public API endpoints. These domains handle event ingestion, feature flag evaluation, session replay, and asset delivery. They use AWS infrastructure with load balancing, which rotates IPs for scalability and performance.

Domains that require access:

  • US Cloud: us.i.posthog.com, us-assets.i.posthog.com
  • EU Cloud: eu.i.posthog.com, eu-assets.i.posthog.com
  • Toolbar/internal metrics: internal-t.posthog.com

We recommend one of two approaches:

1. Domain-based filtering (if your firewall supports FQDN resolution)

Allow outbound HTTPS (port 443) traffic to:

  • *.posthog.com (covers all PostHog domains), or
  • Specific domains listed above for your region

2. Reverse proxy with static IP (most reliable)

  • Set up a reverse proxy in your infrastructure with a known static IP
  • Configure that proxy to forward requests to PostHog Cloud domains
  • Allowlist only your own proxy's IP in your firewall
  • This gives you full control over the IP addressing

The reverse proxy solution is particularly useful for enterprise firewalls (like F5 BIG-IP, Palo Alto, etc.) that require IP-based rules, since you maintain complete control over the network path.

Note: PostHog does provide static IP addresses for data warehouse sources that need to connect to your databases, but these are separate from the public API endpoints.

Community questions

Was this page useful?

Questions about this page? or post a community question.