Option 1: Reverse Proxy DNS

How does this solution work?

By using a reverse proxy, you force the traffic from your tracking server to pass through the DNS of your browsing website. The IPs of your browsing website server (example.com) and your tracking server (tagging.example.com) will no longer appear when cookies are set on the user’s browser = only the IP of your reverse proxy will be visible. Thus, when the browser checks the IP of your browsing server and the IP of your tracking server, these IPs will be exactly the same. The cookies set by your tracking server will therefore be considered first-party cookies, and their lifespan will be 13 months.

Below we are listing different providers. Reach out to your team internally to see if you are already one, that will help you select the best option to continue maintaining your cookies in the new version of Safari.

Provider Choice

Cloudflare

Reverse Proxy via Subdomain

Once your reverse proxy setup is live, your tracking can lapse for a short moment until all changes are propagated, make sure to start things outside of business critical times.

Detailed setup

Go to your Cloudflare account.
Select your website on the interface.
Go to SSL/TLS then Overview, and make sure the encryption mode is set to Full or Full (Strict).

If not, you can create a configuration rule to be Full only on the tagging domain.

Go to SSL/TLS and select Origin Server.
Click on Create a certificate, and leave the options as default.
In the Hostname section, enter the domain defined in Addingwell, for example: metrics.example.com.

Click on Create.

Once you have created the certificate, Cloudflare will provide you with the certificate and the private key, keep them for later. Please note that the private key will only be given once.

In your Container on app.addingwell.com, under Dashboard > Domains, and on your domain, select Set reverse-proxy.

Fill in the fields with your certificate and key provided by Cloudflare.

Once the certificates have been registered, you should see an icon next to your domain.

Back on Cloudflare, in the left menu, select DNS and enable the Cloudflare proxy on the DNS record corresponding to the domain linked to Addingwell.

Reverse Proxy via Path

Once your reverse proxy setup is live, your tracking can lapse for a short moment until all changes are propagated, make sure to start things outside of business critical times.

Detailed setup

Reserve a unique measurement path on your website domain for each domain on Addingwell you wish to apply a reverse proxy to. For website example.com, reserve for example: example.com/w3ke4d

Paths must not already be in use on your domain, not be the root path ”/”, and not exceed 100 characters. To avoid future ad blocks, avoid transparent paths like /metrics, /ads, etc…

Contact us at [email protected] mentioning the name of your container, the domain you are setting the reverse proxy on, the path chosen, and add the Object “Cloudflare Reverse Proxy Setup”.

We will return a value under the format example.adding-sst.com, keep it. It will be set up on our side and used as the destination endpoint for the reverse proxy configuration.

Pre-flight checks

In the Cloudflare dashboard, select your domain and confirm that:
- The domain is proxied through Cloudflare (orange cloud on the DNS record for example.com)
- SSL/TLS → Overview is set to Full or Full (strict)
- Rules → Settings → URL normalization does not strip or sort query parameters (we require query parameters to be preserved unchanged)

Pick the configuration method that matches your Cloudflare plan:

Enterprise rules

If your Cloudflare plan is Enterprise, the reverse proxy can be set up with native rules. This keeps the proxy logic visible in the Cloudflare dashboard rather than in JavaScript. The required features (Resolve Override and SNI Override on Origin Rules) are gated to Enterprise — they are not available on Free, Pro or Business plans. If you are not on Enterprise, switch to the Worker tab.

Create the Origin Rule

Requests matching your measurement path are sent to the Addingwell destination instead of your normal origin, without touching the rest of your traffic.

Go to Rules → Overview, click Create rule, and choose Origin Rule.
Set the rule Name to something like Addingwell Reverse Proxy.
Under “If incoming requests match…”, select Custom filter expression and set Field to URI Path, Operator to starts with and Value to the path you’ve chosen at Step 1, e.g. /w3ke4d.
Under “Then…”, configure all three overrides, pointing to the domain we sent you in Step 2:
- DNS Record → Override → example.adding-sst.com
- Host Header → Override → example.adding-sst.com
- SNI → Override → example.adding-sst.com
Save and Deploy.

Strip the path prefix

Go to Rules → Transform Rules → Rewrite URL and click Create rule.
Set the rule Name to something like Addingwell path strip.
Use the same custom filter expression as Step 6 (URI Path starts with /w3ke4d).
Under “Then…”, set Path → Rewrite to… → Dynamic and Expression to regex_replace(http.request.uri.path, ”^/w3ke4d/?”, ”/”) (change w3ke4d by the path you chose at Step 1).
Save and Deploy.

Add the required headers

Go to Rules → Transform Rules → Modify Request Header and click Create rule.
Set the rule Name to Addingwell headers.
Use the same custom filter expression as Step 6 (URI Path starts with /w3ke4d).
Under “Then…”, add two header modifications:
- Set static / dynamic header → Action: Set → Header name: x-forwarded-host → Value: Dynamic → http.host
- Set static / dynamic header → Action: Set → Header name: true-client-ip → Value: Dynamic → ip.src
Save and Deploy.

Bypass caching for the measurement path

Tracking endpoints must not be cached.

Go to Caching → Cache Rules and click Create rule.
Set the rule Name to Addingwell bypass cache.
Under “If incoming requests match…”, select Custom filter expression and build:
- Field: URI Path
- Operator: starts with
- Value: /w3ke4d (replace with your chosen path)
Under “Then…”, set Cache eligibility to Bypass cache.
Save and Deploy.

Worker

Create the Worker

The Worker intercepts requests matching your measurement path, strips the path prefix, sets the required headers, and forwards the request to the Addingwell destination.

In the Cloudflare dashboard, go to Workers & Pages → Create → Create Worker. Give it a name such as addingwell-reverse-proxy and click Deploy to create an empty Worker.

Workers may incur additional Cloudflare usage costs above the Free plan’s allowance. Check Cloudflare’s pricing page for current rates if your traffic exceeds the included quota.

On the deployed Worker’s page, click Edit code and replace the file contents with:

export default {
  async fetch(request) {
    const url = new URL(request.url);
    const originalHost = url.hostname;

    // Strip the /w3ke4d prefix; the trailing /? makes /w3ke4d,
    // /w3ke4d/ and /w3ke4d/anything all resolve correctly.
    url.pathname = url.pathname.replace(/^\/w3ke4d\/?/, "/");

    // Route the request to the Addingwell destination
    const destination = "example.adding-sst.com";
    url.hostname = destination;

    // Forward the original host so Addingwell knows the first-party domain,
    // and the real client IP so Addingwell can geolocate the end user
    // (Cloudflare would otherwise hide it behind the edge IP).
    const newRequest = new Request(url, request);
    newRequest.headers.set("Host", destination);
    newRequest.headers.set("x-forwarded-host", originalHost);
    newRequest.headers.set("true-client-ip", request.headers.get("CF-Connecting-IP"));

    return fetch(newRequest);
  },
};

Click Deploy to publish the Worker.

Bind the Worker to your domain and path

Still on the Worker’s page, open Settings → Domains & Routes → Add → Route.
Set:
- Zone: the domain on which the reverse proxy will run, e.g. example.com
- Route: example.com/w3ke4d/* (replace with your website domain and the path you chose at Step 1)
Save. The Worker now intercepts every request matching that route.

Bypass caching for the measurement path

Tracking endpoints must not be cached.

Go to Caching → Cache Rules and click Create rule.
Set the rule Name to Addingwell bypass cache.
Under “If incoming requests match…”, select Custom filter expression and build:
- Field: URI Path
- Operator: starts with
- Value: /w3ke4d (replace with your chosen path)
Under “Then…”, set Cache eligibility to Bypass cache.
Save and Deploy.

Verify the setup

Go to */your-path/healthy, as https://example.com/w3ke4d/healthy, the page should read: ok
Go to */your-path/transformer/reverse-proxy, as https://example.com/w3ke4d/transformer/reverse-proxy, the page must:
- Display your IP in “currentIp”
- Display the current host in “host”
- If cookies are being passed they should not be changed
See for example this request:
```
curl --location 'https://example.com/w3ke4d/transformer/reverse-proxy' \
--header 'Cookie: gtm_preview=test123' \
--header 'Origin: example.com'
```
Response should look like:
```
{
  "currentIp": "X.X.X.X",
  "origin": "www.example.com",
  "host": "www.example.com",
  "cookieGtmPreview": "test123"
}
```
In host, the domain looking like example.adding-sst.com should not be displayed.
Go to https://example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse. This is to try and send “real” data via the collect path, you should have a 200 response at minimum (depending on your configuration, some more elements might appear, like google ads remarketing).

Apply these changes and send your data via this path

Last but not least, now that the reverse proxy is configured, what is left to do is propagate these changes so data is sent through this newly created path.

Google Configuration Tag

To do so we will have to add or modify the server url in your GTM web container, to indicate the new destination for your data transporter tags.

Select your Google Configuration Tag, and edit the configuration settings, either adding or changing the server_container_url parameter to reflect the destination with your domain/your path, e.g. example.com/w3ke4d

Google Configuration Tag adapted with the server container url filled with the new path

Server Side Preview

In your GTM server container, should you need to do some tests before pushing changes, you will need to also edit the server url.

In Admin (top left), select Container Settings on the right and add a the URL to the server, under the format https://example.com/w3ke4d

GTM Server Admin tab adapted with the server container url filled with the new path

(Optional) Ad-blocker bypass

If you are using or want to use our CDN to bypass ad-blockers, there is a snippet you can use to load all the components you need for tracking using URLs that are not detectable. See our related documentation for more information.

If you followed this guide for implementing a reverse proxy, the snippet must be edited to reflect the changes.

Normally in this CDN tab you can find a snippet that has a line looking like https://w3ke4d.example.com/a1b2c3d4e5f6g7h8.js…

Replace the w3ke4d.example.com by your domain and chosen path, like example.com/w3ke4d

This will ensure you load the gtm via the reverse proxy we just set up and bypass all the ad-blockers on the market.

Akamai

Once your reverse proxy setup is live, your tracking can lapse for a short moment until all changes are propagated, make sure to start things outside of business critical times.

Detailed setup

Reserve a unique measurement path on your website domain for each domain on Addingwell you wish to apply a reverse proxy to. For website example.com, reserve for example: example.com/w3ke4d

Paths must not already be in use on your domain, not be the root path ”/”, and not exceed 100 characters. To avoid future ad blocks, avoid transparent paths like /metrics, /ads, etc…

Contact us at [email protected] mentioning the name of your container, the domain you are setting the reverse proxy on, the path chosen, and add the Object “Reverse Proxy Setup via Path Cloudfront”.

We will return a value under the format example.adding-sst.com, keep it. It will be set up on our side and used as the destination endpoint for the reverse proxy configuration.

Change the Origin

Go to the Cloudfront page in Amazon Web Services.
Select your Cloudfront Distribution.
In the Origins tab, create an origin with the following settings:
- Set Origin domain to the domain we replied with in Step 2, looking like example.adding-sst.com.
- Set Protocol to HTTPS Only.
- Under Add custom header, add a header with Header name x-forwarded-host and Header value set to your first-party domain, e.g. example.com. This forwards the original host to the Addingwell server, which Cloudfront does not pass natively when using the AllViewerExceptHostHeader origin request policy. For the end-user IP, Cloudfront populates X-Forwarded-For automatically with the viewer’s IP.

Create the redirect behavior

Going back to your Distribution, this time select the Behaviors tab, and create a new Behavior.
Set Path pattern to the path you’ve chosen in Step 1 (for example we used /w3ke4d/*).

The path prefix (e.g. /w3ke4d) must be removed when forwarding the request to the Addingwell destination domain (e.g. example.adding-sst.com). The full remaining path must be preserved, E.g. /w3ke4d/test/collect must be forwarded as: /test/collect

Set Origin and origin groups to to the domain we replied with, looking like example.adding-sst.com.
Set Compress objects automatically to No.
Set Viewer protocol policy to HTTPS only.
Set Allowed HTTP Methods to GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE.
Under Cache key and origin requests choose Cache policy and origin request policy
- Set Cache policy to CachingDisabled.
- Set Origin request policy to AllViewerExceptHostHeader.
In the Behavior list verify the precedence of the new behavior is higher than all other behaviors.

Verify the setup

Go to */your-path/healthy, as https://example.com/w3ke4d/healthy, the page should read: ok
Go to */your-path/transformer/reverse-proxy, as https://example.com/w3ke4d/transformer/reverse-proxy, the page must:
- Display your IP in “currentIp”
- Display the current host in “host”
- If cookies are being passed they should not be changed
See for example this request:
```
curl --location 'https://example.com/w3ke4d/transformer/reverse-proxy' \
--header 'Cookie: gtm_preview=test123' \
--header 'Origin: example.com'
```
Response should look like:
```
{
  "currentIp": "X.X.X.X",
  "origin": "www.example.com",
  "host": "www.example.com",
  "cookieGtmPreview": "test123"
}
```
In host, the domain looking like example.adding-sst.com should not be displayed.
Go to https://example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse. This is to try and send “real” data via the collect path, you should have a 200 response at minimum (depending on your configuration, some more elements might appear, like google ads remarketing).

Apply these changes and send your data via this path

Last but not least, now that the reverse proxy is configured, what is left to do is propagate these changes so data is sent through this newly created path.