{"id":356191,"date":"2026-07-09T06:05:54","date_gmt":"2026-07-09T06:05:54","guid":{"rendered":"https:\/\/peraltafinancing.com\/analytics\/add-ipv6-support-to-your-server-side-gtm-load-balancer\/"},"modified":"2026-07-09T06:05:54","modified_gmt":"2026-07-09T06:05:54","slug":"add-ipv6-support-to-your-server-side-gtm-load-balancer","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=356191","title":{"rendered":"Add IPv6 Support To Your Server-side GTM Load Balancer"},"content":{"rendered":"


\n<\/p>\n

\n
\n

UPDATED 20 March 2026<\/strong>: Shortly after publishing this article, Google Cloud changed how Load Balancer frontend certificate management works. Instead of directly mapping a frontend to a certificate, GCP now wants you to use a certificate map<\/strong>. Luckily, creating one is (fairly) simple, and I\u2019ve updated the guide below to instruct how to do this.<\/p>\n<\/blockquote>\n

If you\u2019re running server-side Google Tag Manager<\/a> on Google Cloud Run<\/strong> behind an External Application Load Balancer<\/strong><\/a>, your tagging endpoint is currently reachable only over IPv4 with a default installation.<\/p>\n

For most of your visitors, that\u2019s fine. But for users on IPv6 networks<\/strong>, it creates a silent data quality problem that directly affects how well vendor tags like Meta\u2019s Conversions API (CAPI)<\/strong> can match server-side events to their client-side counterparts.<\/p>\n

\"Meta<\/a><\/div>\n

When a user on an IPv6 network fires the Meta pixel<\/strong> on your site, Meta records the event alongside the user\u2019s IPv6 address. Your server-side CAPI tag is then supposed to send the server-side version of that same event<\/strong>, including the client_ip_address<\/code> field<\/a>, so that Meta can deduplicate the two and improve match quality.<\/p>\n

The problem: if your SGTM load balancer only has an IPv4 frontend, that IPv6 user\u2019s request goes through NAT64<\/strong> address translation before it ever reaches sGTM. The IP address SGTM reads from the incoming request is a translated IPv4 address<\/strong>. Your CAPI tag dutifully forwards it to Meta, which then compares it against the IPv6 address the pixel recorded. They don\u2019t match. The deduplication is degraded and the match score drops.<\/p>\n

The fix is to give your load balancer a dual-stack frontend<\/strong>: one IPv4 address (already in place) and one IPv6 address. When an IPv6 user connects, they reach SGTM natively over IPv6. No translation, no mismatch. The CAPI tag reads the real IPv6 address and sends it to Meta. Events match correctly.<\/p>\n

In practice, this is very easy to do<\/strong>. You need to reserve a static external IPv6 address<\/strong> in Google Cloud, attach it as a second frontend on your existing load balancer, and add an AAAA<\/code> record to your DNS. Cloud Run itself needs no changes: IPv6 termination<\/strong> happens at the load balancer, and the LB continues to forward traffic to Cloud Run over IPv4 internally. You\u2019ll need a certificate map<\/strong> to configure the frontend, but luckily that isn\u2019t too difficult to do.<\/p>\n

Read on to learn how to do this!<\/p>\n

X<\/span><\/p>\n


\nThe Simmer Newsletter<\/strong><\/p>\n

Subscribe to the Simmer newsletter<\/a> to get the latest news and content from Simo Ahava into your email inbox!<\/p>\n

<\/span><\/p>\n

How IP address matching breaks without IPv6<\/h2>\n

It\u2019s worth being precise about the mechanism, because the failure is silent and won\u2019t show up as an error anywhere in your setup.<\/p>\n

When SGTM receives a request, it reads the client IP address<\/strong> from the incoming connection. The load balancer forwards this via the X-Forwarded-For<\/code> header. The official Meta CAPI tag template (and most other vendor templates) reads this header and uses the value as the client_ip_address<\/code> parameter in the outgoing server-to-server request to Meta\u2019s API.<\/p>\n

\"X-Forwarded-For\"\/<\/a><\/div>\n

On Meta\u2019s side, incoming pixel events and CAPI events are compared using a set of customer information parameters<\/a>: IP address, user agent, email hash, and so on. IP address is one of the stronger signals. When both events carry the same IP, Meta can confidently deduplicate them and attribute the conversion to the correct user journey.<\/p>\n

Here is what happens step by step when an IPv6 user hits an IPv4-only<\/strong> SGTM endpoint:<\/p>\n

    \n
  1. The user\u2019s device is on 2001:db8::1<\/code> (an IPv6 address).<\/li>\n
  2. The client-side<\/strong> Meta pixel fires. Meta logs the event with client_ip_address: 2001:db8::1<\/code>.<\/li>\n
  3. The browser sends a request to your SGTM endpoint to trigger the CAPI event.<\/li>\n
  4. Your SGTM endpoint has no IPv6 frontend. The user\u2019s device connects via NAT64, which translates the source address to something like 192.0.2.1<\/code>.<\/li>\n
  5. SGTM reads 192.0.2.1<\/code> from the X-Forwarded-For<\/code> header.<\/li>\n
  6. The CAPI tag sends client_ip_address: 192.0.2.1<\/code> to Meta.<\/li>\n
  7. Meta compares 192.0.2.1<\/code> against 2001:db8::1<\/code>. No match. Deduplication is incomplete.<\/li>\n<\/ol>\n

    With a dual-stack load balancer, step (4)<\/strong> changes: the user connects natively over IPv6, the address reaches SGTM untranslated, and the CAPI tag sends the correct value. Meta matches the events cleanly.<\/p>\n

    Meta is the most visible example here, but the same logic applies to any vendor tag that uses the client IP as a matching or enrichment signal.<\/p>\n

    Prerequisites<\/h2>\n

    This guide assumes you already have:<\/p>\n