docs(proxy): say whether the managed proxy forwards cookies

[posthog]

Managed reverse proxy customers ask whether PostHog strips the Cookie header, and the page had no answer. This adds one FAQ entry that answers it, states what our ingestion does with the header, and gives two ways to keep cookies inside your own domain. Prose only, one file.

Problem

• A managed proxy customer cannot find out what happens to their users' cookies, so the question reaches support instead of the docs. The ask is about authentication material, so silence costs trust.
• Every self-hosted guide tells the reader to delete the header, and _snippets/proxy-cookies.mdx exists for exactly that. The managed page says nothing, which reads as a contradiction.
• The concern is real, not theoretical. A managed proxy sits on a subdomain of a domain the customer owns, so any cookie scoped to their apex is in scope for the proxy host.

Changes

• One FAQ entry on the managed reverse proxy page, placed with the other data-handling questions. It answers four things a reader needs together: what the proxy does with the header, what ingestion does with it, which single request can carry cookies, and what the reader can change.
• Names the one request that carries cookies, so the answer is bounded rather than alarming. Normal SDK traffic is cross-origin fetch/XHR and sends no cookies. The page-unload flush uses navigator.sendBeacon, and the Beacon spec fixes its credentials mode at include, so the browser attaches apex-scoped cookies to that request and the SDK cannot opt out.
• Corrects a remedy a reader would otherwise carry over. The existing self-hosted snippet suggests persistence: "localStorage", which only moves PostHog's own state and does nothing about the reader's other cookies. The two remedies that work here are host-scoping your auth cookies, or running a self-hosted proxy that deletes the header.

I wrote a purpose-fitted entry rather than importing proxy-cookies.mdx. That snippet's main remedy is "delete the header in your proxy code", which a managed proxy customer cannot do.

Evidence

What each claim in the entry rests on

Claim	Checked against
Do not rely on the proxy to remove Cookie	Managed proxy route config in PostHog/charts and the ingress values it includes, for both regions. The only request header policy sets X-Forwarded-Proto, and no header removal is configured. See the caveat below.
Ingestion does not read or store the header	rust/capture reads content-encoding and gateway provenance headers only. No path reads Cookie, and no code puts it on the event.
fetch/XHR carry no cookies	packages/browser/src/request.ts in posthog-js sets neither credentials nor withCredentials, so both default to sending none cross-origin.
The unload beacon carries cookies	The same file's beacon transport calls navigator.sendBeacon, whose credentials mode the Beacon spec fixes at include.

Important

The entry states the conservative answer on purpose, and an owner can tighten it. Two edge paths serve managed proxies. I verified the route config for the Contour path, which is what the setup steps on this page describe. The Cloudflare Workers path is not in a public repo, so I could not check whether its worker deletes the header. Rather than publish a definite "we do not remove it" that may be wrong for one path, the entry says do not rely on removal. If you know the worker deletes the header, that first sentence should become a plain yes.

Note

One follow-up is out of scope here and needs an infra owner. Deleting Cookie at both managed proxy edges would remove the exposure rather than describe it, but that config lives in the infra repos and I cannot test an edge change. If it lands, this entry needs its first sentence flipped.

Checklist

• I've read the docs and/or content style guides.
• Words are spelled using American English
• Use relative URLs for internal links
• I've checked the pages added or changed in the Vercel preview build
• If I moved a page, I added a redirect in vercel.json — no page moved, so no redirect is needed

Notes on the pre-PR checks: pnpm format covers html,js,ts,tsx,json,yml,css,scss and not .mdx, so there was nothing for it to format. I did not start the dev server. Instead I compiled the changed file with @mdx-js/mdx and it compiled clean, and I confirmed the three internal links resolve to existing pages. The change adds no imports, no JSX, and no navigation entry. The Vercel preview is the remaining check, and it needs this PR to exist first.

---

Created with PostHog Desktop from this inbox report.

[github-actions]

Deploy preview

Status	Details	Updated (UTC)
🟢 Ready	View preview	Sep 09, 2026 09:49PM

[github-actions]

Vale prose linter → found 0 errors, 6 warnings, 0 suggestions in your markdown

Full report → Copy the linter results into an LLM to batch-fix issues.

Linter being weird? Update the rules!

contents/docs/advanced/proxy/_snippets/managed-reverse-proxy.mdx — 0 errors, 6 warnings, 0 suggestions

Line	Severity	Message	Rule
110:53	warning	'erroring' is a possible misspelling.	PostHogBase.Spelling
151:4	warning	'FAQ' heading should be in sentence case, and product names should be capitalized.	PostHogBase.SentenceCase
153:40	warning	'erroring' is a possible misspelling.	PostHogBase.Spelling
165:5	warning	'For EU Cloud, is managed reverse proxy traffic guaranteed to terminate only at EU Cloudflare edges?' heading should be in sentence case, and product names should be capitalized.	PostHogBase.SentenceCase
167:85	warning	'anycast' is a possible misspelling.	PostHogBase.Spelling
178:66	warning	Capitalize 'Logs' for PostHog's product. Use 'logs' for the general industry concept.	PostHogBase.ProductNames

[github-actions]

Bundle report

Total JS (gzip)

8.86 MiB (+0.7 KiB / +0.0%)

Eager graph (modules shipped in each entrypoint's initial chunks)

Entrypoint	Eager size	Budget	Modules
✅ app	18.47 MiB (+5.0 KiB / +0.0%)	report-only	2054

Largest modules in the app closure

Module	Size
./src/data/mcp-tools.json	1119.1 KiB
css ./node_modules/.pnpm/css-loader@5.2.7_webpack@5.101.3/node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[8].oneOf[1].use[1]!./node_modules/.pnpm/postcss-loader@4.3.0_postcss@8.5.6_webpack@5.101.3/node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[8].oneOf[1].use[2]!./src/styles/global.css	761.0 KiB
./src/components/Stickers/Stickers.tsx	696.4 KiB
./node_modules/.pnpm/@radix-ui+react-icons@1.3.2_react@18.3.1/node_modules/@radix-ui/react-icons/dist/react-icons.esm.js	481.4 KiB
./node_modules/.pnpm/@posthog+brand@0.8.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/x-ray.mjs	480.8 KiB
./node_modules/.pnpm/rehype-raw@7.0.0/node_modules/rehype-raw/lib/index.js + 29 modules	395.1 KiB
./node_modules/.pnpm/@posthog+brand@0.8.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/im-the-driver.mjs	385.7 KiB
./src/hooks/useCustomers.tsx + 55 modules	370.0 KiB
./node_modules/.pnpm/@posthog+icons@0.36.6_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@posthog/icons/dist/posthog-icons.es.js	354.8 KiB
./node_modules/.pnpm/react-markdown@8.0.7_@types+react@16.14.66_react@18.3.1/node_modules/react-markdown/lib/react-markdown.js + 88 modules	351.4 KiB
./src/components/ProductComparisonTable/index.tsx + 126 modules	302.5 KiB
./node_modules/.pnpm/cloudinary-core@2.14.0_lodash@4.17.21/node_modules/cloudinary-core/cloudinary-core.js	281.9 KiB
./node_modules/.pnpm/@posthog+brand@0.8.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/doll-house.mjs	281.7 KiB
./node_modules/.pnpm/@posthog+brand@0.8.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/director.mjs	275.6 KiB
./src/components/SearchUI/index.tsx + 87 modules	273.0 KiB

---

Eager-graph budgets are report-only until a baseline is established. Sizes are gzip of public/**/*.js; eager size is webpack module source bytes for the modules actually shipped in the entrypoint's initial chunks (post-tree-shake).