By the end, you’ll know how to verify DNS and SSL for your tagging domain, confirm that browser and app requests actually reach the cloud container, and identify exactly where requests are dropped or misrouted. You’ll have a clear process to pinpoint the failure layer and eliminate guesswork from your debugging.
DNS and Custom Domain Setup for Server-Side GTM
Start by confirming that your custom server container domain resolves to the correct IP address. Use dig or nslookup from a terminal to check DNS records. For example, run
dig your-gtm.example.com
or
nslookup your-gtm.example.com
and verify the returned IP matches the deployment target. If you see NXDOMAIN or an unexpected IP, your DNS is not configured correctly.
After updating DNS records, propagation delays can cause issues. TTL (time to live) values control how quickly changes take effect. If you recently modified a record, check the TTL in your DNS provider’s control panel. Some public resolvers hold onto old records for hours. Use multiple networks or mobile data to see if propagation is complete.
SSL certificate errors block requests before they reach your GTM container. Use curl -v https://your-gtm.example.com or an SSL checking tool to confirm the certificate is valid, not expired, and covers the exact custom domain (including subdomains if needed). If browsers or the client-side code log certificate trust errors, your SSL setup is broken or incomplete.
Network filtering can block traffic to your custom domain. Test domain access from the same network as your e-commerce clients. If you see connection timeouts or “network unreachable” errors, check corporate firewalls, VPNs, or proxy settings. Some security appliances block new subdomains by default. Use a tool like traceroute to pinpoint where the connection fails.
If you use Google-managed deployments (Cloud Run, App Engine), confirm the service is live and mapped to the custom domain. Check the Google Cloud Console for service status and recent errors. A stopped or crashed service, or an unmapped domain, will cause all requests to fail at the DNS or TLS handshake layer. Cloud Run’s domain mapping page will show if the mapping is incomplete or certificate provisioning is pending. If you see HTTP 502 or 404 errors from Google infrastructure, investigate hosting status before debugging GTM configurations.
Client-Side Tagging: Confirming Event Requests Are Sent
Open your site in Chrome and use DevTools (right-click, Inspect, then the Network tab). Reload the page and filter for outgoing requests to your server-side GTM endpoint. If you set up a custom domain, search for your subdomain (for example, https://gtm.yourbrand.com/g/collect). For default endpoints, filter for /g/collect or /collect depending on your server container setup.
If you see no requests, check the client-side tag configuration. In most e-commerce builds, the gtag('config', ...) or GTM web container should reference your server container URL as the transport_url. For example:
gtag('config', 'GA_MEASUREMENT_ID', {
'send_page_view': true,
'transport_url': 'https://gtm.yourbrand.com/g/collect'
});
In GTM web containers, use the Google Analytics: GA4 Configuration tag’s Fields to Set to specify transport_url. If this points to the wrong URL, requests will never reach your server container.
Expand a request in the Network tab and inspect the payload. For Measurement Protocol v2, look for required fields like client_id, events, and timestamp_micros. A malformed payload (missing fields, invalid JSON) will cause the server container to ignore the request. If you use custom endpoints, confirm your payload matches the expected structure for your server-side setup.
Check for ad blockers or privacy extensions. Many block requests to known analytics endpoints and custom subdomains containing “analytics”, “track”, or “gtm”. Disable extensions or test in a private window to rule out interference. Some browsers—Safari, Firefox with Enhanced Tracking Protection—may also block or delay requests. Cross-check in Chrome without extensions for a baseline.
Open the Console tab. Look for JavaScript errors or warnings about blocked requests. Misconfigured tags, missing scripts, or Content Security Policy errors can prevent requests from firing. In GTM Preview mode, verify that your tags trigger as expected and that no errors prevent their execution.
Claiming Requests: How the Server Container Handles Incoming Events
The server container does not process every HTTP request it receives. Each incoming request must be claimed by a tag or trigger in the container, based on the request path, headers, and sometimes the payload. This logic determines whether the container parses the event, ignores it, or returns an error. If claiming fails, the event never enters your server-side flows, regardless of DNS or client configuration.
To verify which requests your container claims, open the GTM server container UI and navigate to the Claim Requests section. Here, you define rules for matching incoming requests. For example, the default GA4 tag claims requests to /g/collect and /collect paths, often with a User-Agent header containing GoogleTagManager or known analytics libraries. If you use custom endpoints or alternate client libraries, check that your claim rules match the actual request patterns, not just the defaults.
To confirm your settings, trigger test events from your site or a tool like Postman using a known-good payload. In the GTM server container UI, open the Preview mode and watch for incoming requests. If a request appears but is listed as unclaimed, your claim rules do not match. If it does not appear at all, the problem is upstream.
Use the container’s logs to identify unclaimed or rejected requests. In your server container workspace, go to Logs and filter for unclaimed status. Review the path and header values on these entries. Mismatches between expected and actual values are common. For example, the presence or absence of trailing slashes, differences in capitalization, or unexpected custom headers can all break claiming.
Platform updates can change how requests are claimed, especially when Google updates supported event types or modifies default claim logic. Always check the current documentation for the exact claim behavior in your container version before assuming a request should be claimed.
Transport and Networking: Diagnosing Delivery Failures
If your server-side GTM container isn’t receiving events, start by inspecting HTTP responses at both the client and server. In browser dev tools, confirm each event request receives a 2xx status. Any 4xx (client error) or 5xx (server error) response means the request failed to reach or be processed by your container. On the server, check access and error logs for these same codes—location depends on your hosting, but Google Cloud users find them in Cloud Logging under the App Engine or Cloud Run service used for GTM.
Load balancers, reverse proxies, or CDNs like Cloudflare can disrupt traffic. Confirm that the GTM endpoint is routed correctly. In Cloudflare, for example, verify that your GTM subdomain’s DNS record is set to “DNS only” (gray cloud), not proxied (orange cloud), to avoid issues with header modifications or caching. If you use NGINX or a similar reverse proxy, confirm the proxy_pass rule forwards to the correct internal port and that request bodies are not being stripped or altered.
Review firewall settings and any rate-limiting rules. Firewalls should allow incoming traffic on the port your server container listens on—typically 443 for HTTPS. Check GCP firewall rules, AWS Security Groups, or your hosting panel for blocks on relevant IP ranges. Some CDNs or WAFs impose rate limits or bot filtering that unintentionally block GTM event traffic. Temporarily disable these features or set allowlists for your known event sources to test.
Use curl or Postman to send controlled test requests. For example, with curl:
curl -X POST "https://your-gtm-endpoint.com/collect" -H "Content-Type: application/json" -d '{"event":"test_event"}' -v
Check for expected 2xx responses. If you see timeouts, 4xx, or 5xx errors, the problem is at the network or server layer. In server logs, look for dropped requests, malformed payloads, or authentication errors. If logs show rejected requests, check for strict CORS, missing authentication headers, or payload size limits enforced by your server or proxy.
Debugging Tools and Best Practices for Server-Side GTM
Enable verbose logging in your server container to surface detailed request and processing errors. In the GTM server container UI, go to Admin > Container Settings and toggle Verbose Logging. This setting logs request payloads, claim status, and tag execution details. Review logs under Logs in the server container interface for rejected requests, malformed payloads, or unclaimed events. If you self-host, check your server logs directly.
Use the Preview mode in the server-side GTM container to trace event flow in real time. Click Preview in the container UI, then send test events from your browser or API client. The debugger shows each incoming request, which client or tag claimed it, and the triggered tags. Look for requests that appear but are not claimed, requests claimed by the wrong client, or tags that do not fire. For requests that never appear in Preview, check the previous layers: DNS, custom domain, and transport.
If you use Google Cloud’s managed server-side GTM, leverage Google Cloud Logging for deeper inspection. In Google Cloud Console, navigate to Logging > Logs Explorer and filter logs by your App Engine project. Search for HTTP errors, timeouts, or quota issues. These logs can show request headers, IPs, and raw payloads, which help isolate malformed requests or infrastructure throttling.
Document each diagnostic step as you go. Record the time, test case, expected versus actual result, and any configuration changes. Use a shared doc or ticket for the incident. This prevents repeating tests, especially when multiple engineers are involved, and establishes a clear rollback path if you change settings mid-debug.
Check platform release notes regularly. Breaking changes to event parameters, claim logic, or endpoint formats are not always announced in-product. For Google Tag Manager, review the official release notes and the Google Cloud updates page. Platforms sometimes deprecate or alter payload structures, which can silently cause containers to stop claiming events.
Frequently asked questions
Why do events appear in the client but not in the server-side GTM container?
Common causes include incorrect endpoint URLs, DNS misconfiguration, or the server container not claiming the request. Walk through network and claim diagnostics to isolate the issue.
How can I tell if my server container is rejecting or ignoring events?
Check server logs and the claim settings in the GTM UI. Use Preview mode to see if the event is processed or dropped.
Do privacy regulations like CCPA/CPRA affect server-side event delivery?
Yes, privacy regulations such as CCPA and CPRA can impact server-side event delivery. These laws may require that you obtain user consent before collecting or processing certain types of data, even when using server-side GTM. If a user opts out, your implementation must ensure that restricted data is not forwarded to analytics or advertising endpoints. Always verify that your server-side setup honors user privacy choices and complies with relevant legal requirements.
Not sure your tracking is telling you the truth?
Propulse Agency audits e-commerce tracking setups — server-side tagging, Meta CAPI, GA4 and consent — and fixes what is quietly costing you conversions.
Validate Your Event Flow Before Scaling Changes
Start by validating the full event flow—browser to server container—using a test environment. Use browser network tools to confirm outbound requests, then monitor the server container’s Preview mode for incoming events. If you see gaps, isolate the failure layer before making config changes. Always test with real events, not just synthetic ones, since ad blockers and privacy settings can block requests unpredictably.
Most persistent issues trace back to DNS misconfigurations or overlooked authentication requirements in the server container. Review your DNS and SSL setup before debugging tags or triggers. This avoids wasted time on tag logic when the root problem is infrastructure. Confirm all changes in a staging environment before rolling out to production.
