Blog
The config call has its own transport URL setting that the rest of your gtag setup does not inherit.
You set up a custom domain. You configured your GA4 tag in GTM to send to it. Yet when you watch the network tab, the very first GA4 request still goes to www.google-analytics.com. The cause is the gtag config call, which has its own transport URL setting that does not inherit from the rest.
When the gtag.js script loads, it makes one initialisation call to fetch the GA4 measurement config. This is a separate request from the events that follow. It typically goes to https://www.google-analytics.com/g/collect with a small payload describing the property.
Ad blockers recognise this hostname and block the request. When that happens, gtag falls back to default settings, which means subsequent events may not be enriched with property-level configuration.
gtag('config', 'G-XXXXXXX', {
transport_url: 'https://data.example.com',
first_party_collection: true
});
The first_party_collection: true flag is what tells gtag to send subsequent events to the custom URL too. Without it, only the config call is redirected; events still go to google-analytics.com.
If you load gtag through GTM (rather than as a separate script), the GA4 Configuration tag has fields for transport_url and first_party_collection. Set both. The settings apply to the whole tag, including the config call.
In Chrome DevTools, Network tab, filter by your tagging hostname. After the change, every GA4-related request should hit your custom domain. Filter by google-analytics.com; you should see zero requests. If you see any, those are coming from somewhere not yet configured.
For each one, either add the transport_url override or accept that some traffic will continue hitting Google directly. The goal is not 100 percent coverage; the goal is to recover the traffic that ad blockers were specifically targeting.
For a deeper dive, the custom domain setup covers the prerequisite steps.