Browse documentation
sGTM Containers

Debugging HTTP 400 Errors

A checklist for tracking down a 400 response from your sGTM container, and when it's on Google's side rather than FlyNode's.

1 min readUpdated Sep 25, 2026

A 400 response from your Server-Side GTM container almost always means the container itself rejected the request, not a FlyNode infrastructure issue. Work through these in order:

1. Check your container configuration

An empty or placeholder container configuration will reject every request. Confirm a real configuration (copied from your Tag Manager server container's Admin then Container Settings) is set on your FlyNode container.

2. Confirm the request actually reaches your container

Use your container's live logs to see whether the request is arriving at all, and with what path. A request that never shows up in your logs is a DNS or proxy issue, not a 400.

3. Isolate the endpoint

GA4's client-side loader (/gtm.js) and its measurement endpoint (/g/collect) are handled differently inside the container. If one path 400s and the other doesn't, that narrows the problem to a specific part of your tag configuration rather than the container as a whole.

4. When it's Google's side, not yours

Some 400 responses are account-specific, on Google's own backend, and reproducible even outside any hosting environment - for example with a bare docker run of the official image on your own machine, using your own container config. If you can reproduce the same 400 that way, it isn't something FlyNode's infrastructure can fix, and is worth raising with Google support directly.

Still stuck?

Open a support ticket from your dashboard with your container name and the exact path that's failing, that's usually enough for us to tell which of the above it is.

Still stuck?

Open a support ticket from your dashboard and include the container name.

Contact support