Skip to main content
Use Plainrouter’s generated forwarding block to collect Signals through a route on your own website. This is Path B — same-origin proxy. A working setup keeps browser requests on your website origin, passes forwarding verification, and records an authenticated arrival. Path A — managed hostname remains the default and uses your collection subdomain. Plainrouter uses the same managed collector, consent rules, and event contract for both serving paths. Only the route from your website to the collector changes.

​
Before you begin

  • Complete DNS validation and the initial Signals installation.
  • Use a workspace member with management permission to activate Path B and copy its forwarding block.
  • Have access to deploy your website’s rewrite or reverse-proxy configuration and edit the installed script tag.
  • Configure an exact HTTPS website domain for verification. Check whether visitors land on the apex domain, www, or another hostname.
  • Keep your consent integration in place. Same-origin forwarding does not grant advertising consent.

​
How Plainrouter selects a path

Path A sends collection traffic through your Plainrouter-managed subdomain. Path B transparently forwards a route on your website to the same collector. Path B does not run Plainrouter code in your hosting account and does not change which visitors are eligible for measurement.
Path A is the default and remains fully supported. Path B gives supported stacks a true same-origin route for consented, server-issued browser identifiers. Both paths send identity-free arrivals independently of consent and require full consent for conversion events and advertising identity.

​
Generate your setup

1

Open the serving setup

Open Signals → Install and expand Advanced: same-origin proxy. Before the first arrival, the same installation instructions are also available directly on Dashboard and Signals. You do not need to wait for traffic to access forwarding setup.When Path B is already selected, Advanced: same-origin proxy opens automatically so the forwarding instructions are visible. With the default managed-hostname path, expand it when you want to configure forwarding.
2

Let Plainrouter check your hosting stack

Plainrouter checks bounded DNS and response-header evidence in the background. While the check is running, the page shows Pending and refreshes the stored result automatically.If the stack cannot be determined, answer Where is your website hosted? with the exact provider or server, then click Detect hosting.
3

Copy the generated block

Plainrouter shows one block for the detected stack. For Path B, click Activate Path B first, then Copy code and add the complete block to your hosting configuration. Do not edit its generated prefix, destination, or secret.For Path A, keep the displayed CNAME in place. Plainrouter manages the collector and HTTPS certificate behind it.
4

Use the public same-origin script path

For Path B, replace the existing Signals script tag’s src with the public route on your website. Use the prefix from the source side of your generated forwarding block:
Replace YOUR_GENERATED_PREFIX with your generated prefix. Keep the existing signalq("init", ...) block and publishable key before this tag. Replace the old tag rather than loading both copies.The browser URL contains the public prefix only. The upstream destination and forwarding secret belong in the hosting configuration. Activating Path B and deploying a rewrite do not change an already-installed script tag.
5

Verify the live path

Deploy the hosting change and load your live website. The First arrival check turns green after Plainrouter stores the first valid arrival.For Path B, also click Run verification. The side-effect-free forwarding probe checks the deployed route without creating an event or arrival. Path B turns green only after both the probe passes and an authenticated arrival is observed.
Path A’s first successful arrival verification remains latched after recent activity ages out. It does not return to an unverified setup state merely because no new arrival appears in the recent window.

​
Path B forwarding requirements

Install the entire generated block. Transparent forwarding must preserve:
  • The original host and visitor path.
  • Cookie and Set-Cookie in both directions.
  • Request methods, bodies, content types, and the headers included in the generated configuration.
Arrival collection uses the snippet’s POST /v1/arrival through the generated prefix. Loading the website document alone is not the arrival transport. The snippet omits cookies from its arrival request, and the collector does not set visitor cookies in its arrival response. Cookie forwarding remains necessary for the separate consented event and identity routes.
Path B’s generated destination contains a low-privilege forwarding secret. Only members with workspace management permission can view or copy it. Do not publish it in documentation, logs, or a public repository.

​
Exact site domains

Configure the HTTPS origin visitors actually use. https://example.com and https://www.example.com are different origins. The forwarding probe requires an exact domain; a wildcard-only configuration does not provide a probe target. Add the apex domain explicitly when you need apex coverage. Managed-hostname browser collection also requires an exact origin for credentialed CORS. Wildcards do not grant that coverage. Correctly configured Path B stays on the website origin and does not need a CORS preflight. If an OPTIONS request or CORS error appears, inspect whether an old script URL, explicit endpoint override, or redirect moved collection to another origin. Do not add Access-Control-Allow-Origin: * to fix credentialed requests; see MDN’s credentialed CORS guidance.

​
Rotate a Path B secret

Click Rotate forwarding secret, copy the newly generated block, and deploy it. Plainrouter accepts both the old and new secret during the transition. The overlap ends when Plainrouter successfully ingests the first authenticated arrival using the new secret or when you click Confirm new secret installed. A malformed or failed request does not acknowledge the new secret or end the overlap. Keep the old deployment available until one of those conditions is met. The side-effect-free forwarding probe attests only the currently active secret. A probe signed with the pending overlap secret cannot mark the path verified or complete rotation. If tracker key storage is temporarily unavailable, the probe fails closed with a retryable response instead of recording a pass.

​
Understand detection and verification states

Retry detection and Retry verification start fresh background checks. DNS and forwarding probes never run inside the page request.

​
What should I see in the Network panel?

Open the actual website origin, select Network, enable Preserve log, disable the browser cache for the check, and reload. Filter by the public forwarding prefix. Append the paths below to that prefix to find the full request URLs. For example, a script served at https://shop.example/YOUR_GENERATED_PREFIX/s/v4.js derives an events URL at https://shop.example/YOUR_GENERATED_PREFIX/v1/events. Configuration, identity, withdrawal and arrival requests keep that prefix too. An explicit endpoint in init overrides script-based endpoint selection; remove an obsolete override when switching to this generated route. A successful Run verification probe proves forwarding, not a browser visit or Meta delivery. It does not create an arrival, set a visitor cookie, or end secret rotation. Complete the browser arrival check separately.

​
Troubleshoot

​
The script or collector route returns HTML, a redirect, or 404

Use the complete block generated for your hosting stack. Preserve its upstream TLS host/SNI configuration as well as the original website host. Do not replace the destination with a bare collector hostname or remove path segments to silence a 404.

​
The probe passes but Path B is waiting for its first arrival

  1. Confirm the browser is loading the prefixed script and sending the prefixed POST /v1/arrival on the configured website.
  2. Inspect the response body and status. An HTML 200 from the application is not a collector receipt. A 429 requires a later retry after the rate limit; a failed arrival is not retried by the snippet.
  3. After correcting the issue, reload the page to create a new document and check for 202, then allow the dashboard to reflect stored ingestion.
Granting consent, calling track, or using the identity-free ingestion diagnostic does not substitute for this arrival. Conversely, an arrival alone does not prove the forwarding probe passed.

​
Arrivals work but conversions or visitor cookies do not

First check all three advertising permissions in your CMP integration. No visitor cookie on an arrival is expected; it is not evidence of broken forwarding. After a full grant, inspect the consented event response for Set-Cookie and the browser’s cookie-storage rejection reason, if any. The server-owned pr_vid first-party cookie is HttpOnly, so its absence from document.cookie is expected. Use the browser’s Application or Storage panel instead. MDN explains HttpOnly and Secure. If the browser receives the cookie but later consented requests do not retain it, check HTTPS, the actual request hostname, browser storage restrictions, and whether the proxy strips Cookie or Set-Cookie. Keep both headers intact. Do not add cookies to the identity-free arrival request as a workaround.

​
CSP blocks the script or a request

Check the browser console for the blocked URL and directive. The same-origin script needs permission under your site’s script-src; collector requests need permission under connect-src. Allowing 'self' in the applicable directive covers the same-origin route, subject to your complete policy. Keep your existing nonce or hash treatment for the inline initialization block. Do not replace the entire policy with an example allowlist or disable CSP. Follow the pixel CSP instructions and MDN’s connect-src reference. Meta’s external script remains a separate permission after you connect a dataset.

​
A deployment or secret rotation still uses old configuration

Check the rendered HTML and Network request URL with browser caching disabled. Then inspect your hosting deployment, CDN rules and any service worker that can serve an older page or intercept the prefix. Updating the forwarding block does not replace cached HTML containing the old script tag. Keep static snippet caching separate from collection traffic. Exclude the prefixed collector POST routes and cookie-setting responses from shared response caching; do not apply a blanket cache-everything rule to the whole prefix. Preserve the collector’s response headers. During rotation, deploy the complete new block to every serving instance before confirming installation. Follow Rotate a Path B secret: the probe does not acknowledge the replacement secret, and the first valid arrival using it can end the overlap. Instances still using the old secret can then fail.

​
Hosting detection cannot identify my stack

Enter the exact hosting provider or server name. Plainrouter uses that declaration when DNS and response headers are unavailable. If the answer is not recognized, confirm the public site domain and retry when the site is reachable.

​
I need to return to the managed hostname

A member with workspace management permission can click Revert to Path A, then confirm Revert to Path A? in the dialog. Cancel or Escape leaves the setting unchanged. Keep the validated CNAME in place and restore the managed-hostname script from the installation guide. Check the rendered page for a single initialization block and script, then verify a new arrival. Reverting the Plainrouter setting does not edit your website deployment.

​
Next step

Once forwarding and the arrival are verified, test consent and business events. If a conversion is ingested but Meta delivery needs attention, continue with Connect Meta troubleshooting.