Debugging "No Client Claimed the Request": A Server-Side GTM First-Party Loader Post-Mortem

If you searched the exact phrase No client claimed the request and landed here, you are probably staring at an HTTP 400 with an empty response body, a server container that looks correctly configured, and no error message anywhere in Chrome DevTools. The fix is immediately below. The full diagnostic story — including two debugging tools that actively misrepresented what the browser was doing — follows after it.

Versions and dates: Diagnosed against Google Cloud and sGTM as of mid-2026, on a self-managed Cloud Run deployment. Google occasionally revises the loader URL patterns; verify against the official custom-path documentation before adopting any snippet verbatim.

The Fix

If your server container uses a custom tag serving path, your loader snippet must not include the ?id=GTM-XXXXXXX query parameter. The path itself is the identifier. Including both prevents any client from claiming the request.

<!-- Broken: query parameter on a custom serving path -->
<script async src="https://tracking.example.com/<serving-path>/?id=GTM-XXXXXXX"></script>

<!-- Fixed -->
<script async src="https://tracking.example.com/<serving-path>/"></script>

The GTM Web Container client supports two distinct identification modes, and they are not interchangeable:

One precision point worth stating explicitly, because it is easy to get backwards: the mode is determined by your configuration, not by what the path is named. If you configure a custom serving path and happen to name it /gtm.js, you are still in path-based mode and must still omit ?id=. Conversely, a container with no custom path configured needs the parameter regardless. "Is my path /gtm.js?" is therefore the wrong diagnostic question — "is a custom serving path configured?" is the right one.

On a custom serving path, the ?id= parameter is not merely redundant. Its presence produces a request that no configured client recognizes as its own — hence no client claimed the request, and hence the empty-bodied 400. Nothing is misconfigured on the server. The snippet is asking for a route that does not exist.

Diagnostic Checklist

If you are hitting an empty-bodied 400 on a server-side GTM loader endpoint, work these in order. The tiers are sequenced by how fast each item is to verify and how often it is the culprit — a full Tier 1 pass resolves most cases without touching infrastructure at all.

Tier 1: Server-Side Configuration

Fastest to check, and where the cause usually lives.

1. The Server container URLs list matches your request origin. Under Admin → Container Settings → "Server container URLs," every domain that will actually load the loader must be listed explicitly — production, staging, and any preview environments. A missing entry here produces origin-based rejections that look nothing like a configuration error.
2. The Web Container client's allowed container IDs and tag serving path match your snippet exactly. Character for character, including whether the path has a leading and trailing /. A mismatch is silent — the UI will not warn you, and everything will still look correct on inspection.
3. The query parameter pattern matches your serving mode. This post's root cause. Include ?id=GTM-XXXXXXX only if no custom serving path is configured; omit it entirely if one is.
4. The workspace change is published, not merely saved. Saving, previewing, and publishing are three different actions. Only publishing updates what is actually served.
5. The published version is marked "Live," not just "Latest." These diverge more often than you would expect. Check the Versions tab directly rather than assuming your most recent publish is the one serving traffic.

Tier 2: Infrastructure and Routing

1. The Cloud Run domain mapping points at the service you think it does. Run gcloud run domain-mappings list and confirm. A stale or misdirected mapping fails before any GTM code executes, so no amount of container debugging will surface it.
2. No load balancer or Cloud Armor rule is silently rejecting the path. Only applies if you front Cloud Run with a load balancer rather than a direct domain mapping — in which case check the URL map's path rules.
3. The serving revision is current, not a stale instance. Cloud Run serves from immutable revisions. If container configuration changed without a new revision, traffic keeps hitting the old one. Force a fresh deploy and confirm traffic migrated.

Tier 3: Client-Side and Verification

1. View source on the deployed environment to confirm the HTML matches your intended snippet — the real environment, not your local template or what you believe shipped.
2. curl -sv the endpoint to see the raw response. This bypasses DevTools' summarization and establishes whether the body is genuinely empty or a message is being hidden from you.
3. Check the server container Preview/Debug Console tab for the actual client-matching decision. This is the only surface that reports why a client did or did not claim the request.
4. Reproduce in a clean incognito window, extensions disabled, on a real page load before trusting any DevTools or debug-tool capture. Rule out tooling artifacts before you debug them.
5. Check the DevTools Initiator chain on any request you cannot account for. A chrome-extension:// initiator means you are debugging someone else's request, not your loader's.

The Real Lesson: "First-Party" Is Not Automatically Ad-Blocker Resistant

Here is the broader trap, and it is more consequential than the 400.

Teams migrate their loader to a first-party domain, see requests to their own hostname, and conclude they have solved ad-blocker resilience. They often have not — because major ad-blocker filter lists match on path and filename patterns, not only on domain.

A request to https://tracking.yourbrand.com/gtm.js is first-party by domain and still trivially matched by any filter rule targeting /gtm.js. You have moved the hostname and kept the fingerprint. The filter list does not care whose domain it is; /gtm.js is a signature.

This is why the client's custom randomized serving path existed in the first place. It is not cosmetic:

• A generic path (/gtm.js) — first-party by domain, but the path string is a known signature. Blockable by pattern rules that do not need to know your domain at all.
• A randomized path (/a7f3k9x2/) — nothing generic to pattern-match. Blocking it requires a rule specifically targeting your domain and path, which generic community filter lists do not carry.

The irony is direct: the configuration that made this deployment actually resilient is the same configuration that made the legacy snippet fail. The custom path was correct. The snippet was written for the default path. Two right decisions, one wrong combination.

If you are planning a first-party loader migration, decide the serving path first, then write the snippet to match that decision. Doing it in the other order is how you end up here. For the wider set of tradeoffs in first-party serving, see Server-Side Tagging Best Practices and the vendor comparison — managed providers make this choice for you, with different defaults.

The Full Story

Everything above is the actionable part. What follows is how we actually got there — worth reading if you are debugging something adjacent, or if you want to know which false leads to skip.

The Setup

A multi-property hospitality client runs a full server-side stack: GA4, Meta CAPI, Pinterest CAPI, and Microsoft UET all dispatched server-side from a self-managed Cloud Run deployment, roughly the architecture described in Server-Side GTM on Cloud Run.

The work in question was the last mile of that migration: moving the gtm.js loader itself from googletagmanager.com to their own domain. This is the step most teams skip. You can dispatch every downstream event server-side and still have the loader — the script that bootstraps the whole thing — served from a third-party domain that ad blockers block by default. If the loader never executes, your immaculate server-side pipeline receives nothing. First-party loading closes that gap.

The container was already configured with a custom tag serving path rather than the default /gtm.js — a deliberate choice whose significance becomes the whole point of this post.

The Symptom

Deploy to staging. Load the page. The loader request returns:

HTTP/2 400
server: Google Frontend
content-length: 0

An empty body. No JSON error, no plaintext reason, nothing in the response at all. DevTools showed a bare red 400 and offered no further detail. Cloud Run request logs recorded the 400 but no application-level error, because — as it turned out — no application code ever ran. The request was rejected before any client claimed it.

An empty-bodied 400 from Google Frontend is a genuinely hostile error to debug: it is indistinguishable from a malformed request, a routing failure, a domain-mapping problem, or a container misconfiguration. So we ruled them out in order.

The Investigation

1. Ruling out DNS and domain mapping. With Cloud Run you have two ways to attach a custom domain: a direct Cloud Run domain mapping, or a Cloud Load Balancer with a serverless NEG. These fail differently, so establishing which one is in play matters. This deployment used a direct domain mapping — no load balancer, no Cloud Armor rule that could be silently rejecting requests. The domain resolved correctly and TLS terminated cleanly. A misrouted request would not reach Google Frontend and return a Cloud Run–shaped 400 at all, so this was mostly confirmation.

2. Confirming the published container configuration. The most common cause of a loader 400 is a container that was configured but never published. Server container changes require a publish to take effect, and previewing your own changes in the GTM UI does not publish them. We verified the live published version contained the Web Container client, with both the container ID and the custom serving path matching the snippet exactly, character for character.

3. Ruling out propagation and stale revisions. Cloud Run serves from immutable revisions. If a container image or an environment variable changed without a new revision, traffic keeps hitting the old configuration. We forced a fresh revision deploy and confirmed traffic had fully migrated to it. Same 400.

4. Getting past DevTools with curl -sv. DevTools summarizes. curl does not:

curl -sv "https://tracking.example.com/<serving-path>/" 2>&1 | head -40

This confirmed the response body was genuinely empty — not an error message DevTools was collapsing or failing to render. That is a meaningful finding: it means the rejection happened at the routing layer, before any client could generate a response. A misconfigured-but-claimed request usually produces something.

5. Finding the real error. The actual reason was never in the HTTP response. It was in GTM's Preview/Debug mode, under the Console tab of the server container debug view:

No client claimed the request.

That single line is the entire diagnosis, and it is visible in exactly one place. If you take one operational lesson from this post: for any unexplained server container response, the server-side Preview/Debug Console tab is the first place to look, not the last. The HTTP layer will not tell you why a client declined a request.

The False Leads

This is the part worth your attention, because both of these are traps that will waste your afternoon regardless of what your actual root cause turns out to be.

False lead 1: a browser extension firing its own requests. Partway through, requests to the endpoint appeared that did not correspond to anything on the page. The tell was DevTools' Initiator column: expanding the initiator chain showed the request originating from a chrome-extension:// script, not from page HTML or any first-party JavaScript.

Analytics and tag-debugging extensions routinely probe endpoints on their own initiative. Their requests carry different headers, different origins, and sometimes different CORS modes than the real page load — so they fail for reasons that have nothing to do with your implementation. Diagnosing an extension's synthetic request as though it were your loader is a genuine time sink.

False lead 2: GTM's own debug tooling issuing synthetic requests. More insidious: GTM's debug tooling itself generated CORS-mode requests that did not reflect how a browser actually loads the loader script. A <script src> tag and a fetch() in CORS mode are not the same request. They differ in headers, in Sec-Fetch-* metadata, and in how failures surface. We spent real time debugging a request shape that would never occur in production.

The discipline that resolves both:

Verify in a clean incognito window with all extensions disabled, on a real page load, before you trust any debug tool's request capture. Reproduce there or treat the finding as an artifact. Every debug tool is itself a client, and its requests are not your users' requests.

Once the failure reproduced in clean incognito on a genuine page load, we knew it was real and not tooling noise. That step is what separated "a real bug" from "three hours chasing a phantom."

Why It Took That Long

Deleting the query parameter resolved it immediately — loader served, container bootstrapped, downstream GA4 and CAPI events flowing normally on the first reload.

What made the failure expensive is that every individual component was correct. The domain mapping was right. The container was published. The serving path matched. The container ID was accurate. Each artifact passed inspection in isolation; the defect was the combination of a custom path with a legacy query parameter. Checklist-style verification cannot catch that class of bug, which is precisely why the Preview/Debug Console — the one surface that reports the request-claiming decision — matters so much.

How TagSpecialist Helps

We diagnose and operate self-managed server-side deployments as our primary work — the server-side tagging and GTM implementation engagements both include first-party loader configuration, with the serving-path decision made before the snippet is written.

If you have an existing deployment where events are arriving but the numbers feel low, the loader is worth checking before anything downstream. A loader blocked for a share of your traffic looks exactly like a tracking problem three layers deeper, and it is a much cheaper fix. Ongoing managed tracking covers the drift side of this: sGTM image updates, platform API changes, and loader patterns that Google revises without notice.

Book a 15-minute scoping call if you want a second pair of eyes on a deployment that is returning errors you cannot explain.

The takeaway: every component in this failure was individually correct, and the system still returned a bare 400. Two debugging tools generated requests that did not represent real browser behavior and pointed the investigation at phantoms. The fix was deleting eight characters from a script tag. Server-side tracking failures are rarely dramatic — they are combinations of correct-looking decisions that happen not to compose, found only by looking at the one log surface that reports the decision itself.