Option 1: Reverse Proxy DNS

Cloudflare

Reverse Proxy via Path (Recommended)

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

1. Reserve a unique measurement path on your website domain for each domain on Addingwell you wish to apply a reverse proxy to. For website www.example.com, reserve for example: www.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… If you are setting up a reverse proxy on several domains, use the same path on each of them (a server-side GTM constraint).

2. 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.

Customize this guide for your setup

Set the values below, they will populate every example, code block, and URLs throughout this guide.

Your domain

Your chosen path

Addingwell endpoint

ApplyResetShare this config

Use the exact host your visitors see in the address bar. If your site is served at https://www.example.com, keep the www.; if it is served at https://example.com, remove it. The measurement path has to be on the same origin as your pages, otherwise the browser treats the tracking requests as cross-origin and blocks them (CORS).

Pre-flight checks

3. In the Cloudflare dashboard, select your domain and confirm that:
   • The domain is proxied through Cloudflare (orange cloud on the DNS record for www.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)

Set up the reverse proxy with a Cloudflare 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.

4. 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.

5. 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);
  },
};

Copy

6. Click Deploy to publish the Worker.

Bind the Worker to your domain and path

7. Still on the Worker’s page, open Settings → Domains & Routes → Add → Route.

8. Set:

   • Zone: the domain on which the reverse proxy will run, e.g. www.example.com
   • Route: www.example.com/w3ke4d/* (replace with your website domain and the path you chose at Step 1)

9. Save. The Worker now intercepts every request matching that route.

Bypass caching for the measurement path

Tracking endpoints must not be cached.

10. Go to Caching → Cache Rules and click Create rule.

11. Set the rule Name to Addingwell bypass cache.

12. Under “If incoming requests match…”, select Custom filter expression and build:

    • Field: URI Path
    • Operator: starts with
    • Value: /w3ke4d (replace with your chosen path)

13. Under “Then…”, set Cache eligibility to Bypass cache.

14. Save and Deploy.

Are you using our ad-blocker bypass? You can add caching for its assets, see (Optional) Ad-blocker bypass below.

Verify the setup

Now that the initial setup is done, let’s test that everything is correct before sending it live.

1. Go to */your-path/healthy, the page should read: ok

   https://www.example.com/w3ke4d/healthy

   Copy
   

2. Go to */your-path/transformer/reverse-proxy, as https://www.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://www.example.com/w3ke4d/transformer/reverse-proxy' \
   --header 'Cookie: gtm_preview=test123' \
   --header 'Origin: https://www.example.com'

   Copy

   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.

   

3. Go to the collect path below, to try and send “real” data, you should have a 200 response at minimum (depending on your configuration, some more elements might appear, like google ads remarketing).

   https://www.example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse

   Copy
   

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. www.example.com/w3ke4d

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://www.example.com/w3ke4d

(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://subdomain.example.com/a1b2c3d4e5f6g7h8.js... or https://subdomain.adding-sst.com/a1b2c3d4e5f6g7h8.js...

Replace the “subdomain.example.com” (or “subdomain.adding-sst.com”) by your domain and chosen path, like www.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.

Note on caching: if you use our ad-blocker bypass feature and want to reduce the associated CDN requests, consider adding a rule so static *.js assets are served from your provider’s cache. Careful: any caching must respect Addingwell’s cache-control headers and use a cache key that includes all query parameters, unmodified, so tracking queries are not affected. We recommend the cache duration to be somewhat short (10min - one hour), as affected assets include your web GTM container, an overly long cache will delay your web GTM changes going live.

Akamai

Detailed setup

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

2. 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

3. Go to the Cloudfront page in Amazon Web Services.

4. Select your Cloudfront Distribution.

5. 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. www.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

6. Going back to your Distribution, this time select the Behaviors tab, and create a new Behavior.

7. Set Path pattern to the path you’ve chosen in Step 1 (for example we used /w3ke4d/*).

8. Set Origin and origin groups to to the domain we replied with, looking like example.adding-sst.com.

9. Set Compress objects automatically to No.

10. Set Viewer protocol policy to HTTPS only.

11. Set Allowed HTTP Methods to GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE.

12. Under Cache key and origin requests choose Cache policy and origin request policy

    • Set Cache policy to CachingDisabled.
    • Set Origin request policy to AllViewerExceptHostHeader.

13. In the Behavior list verify the precedence of the new behavior is higher than all other behaviors.

Verify the setup

Now that the initial setup is done, let’s test that everything is correct before sending it live.

1. Go to */your-path/healthy, the page should read: ok

   https://www.example.com/w3ke4d/healthy

   Copy
   

2. Go to */your-path/transformer/reverse-proxy, as https://www.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://www.example.com/w3ke4d/transformer/reverse-proxy' \
   --header 'Cookie: gtm_preview=test123' \
   --header 'Origin: https://www.example.com'

   Copy

   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.

   

3. Go to the collect path below, to try and send “real” data, you should have a 200 response at minimum (depending on your configuration, some more elements might appear, like google ads remarketing).

   https://www.example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse

   Copy
   

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. www.example.com/w3ke4d

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://www.example.com/w3ke4d

(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://subdomain.example.com/a1b2c3d4e5f6g7h8.js... or https://subdomain.adding-sst.com/a1b2c3d4e5f6g7h8.js...

Replace the “subdomain.example.com” (or “subdomain.adding-sst.com”) by your domain and chosen path, like www.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.

NGINX

Detailed setup

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

2. 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 Akamai”.

   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

3. Create a new version of your delivery configuration in the property manager

4. Under the Property Configuration Settings section add a new Rule. Enter a name, such as Measurement Path

5. Add a new Match, set the match dropdowns to Path and is one of

6. Then, set the match value to the path you defined in Step 1, for example /w3ke4d/*

7. Add a new Behavior and select Standard Property Behavior and choose the Origin Server behavior.

8. Set Origin Server Hostname to the value we sent you in Step 2, under the format example.adding-sst.com

9. Set Forward Host Header to Origin Hostname

10. In Origin SSL Certificate Verification, set Match CN/SAN to “{{Origin Hostname}}”, as well as the value we sent you in Step 2, under the format example.adding-sst.com.

11. Add a Modify Outgoing Request Path behavior. Set Action to Remove fixed path segment, and set the Path segment to remove as the path you’ve chosen in Step 1, here /w3ke4d.

12. Add a Modify Outgoing Request Header behavior to forward the original host. Set Action to Add, Custom header name as x-forwarded-host, with Header value as {{builtin.AK_HOST}}, and set Avoid duplicate headers as On.

13. Add another Modify Outgoing Request Header behavior to forward the client IP. Set Action to Add, Custom header name as true-client-ip, Header value as {{builtin.AK_CLIENT_IP}}, and set Avoid duplicate headers as On.

Verify the setup

Now that the initial setup is done, let’s test that everything is correct before sending it live.

1. Go to */your-path/healthy, the page should read: ok

   https://www.example.com/w3ke4d/healthy

   Copy
   

2. Go to */your-path/transformer/reverse-proxy, as https://www.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://www.example.com/w3ke4d/transformer/reverse-proxy' \
   --header 'Cookie: gtm_preview=test123' \
   --header 'Origin: https://www.example.com'

   Copy

   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.

   

3. Go to the collect path below, to try and send “real” data, you should have a 200 response at minimum (depending on your configuration, some more elements might appear, like google ads remarketing).

   https://www.example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse

   Copy
   

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_container_url parameter in your GTM web container, to indicate the new server destination for your data transporter tags.

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

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://www.example.com/w3ke4d

(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://subdomain.example.com/a1b2c3d4e5f6g7h8.js... or https://subdomain.adding-sst.com/a1b2c3d4e5f6g7h8.js...

Replace the “subdomain.example.com” (or “subdomain.adding-sst.com”) by your domain and chosen path, like www.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.

Fastly

Detailed setup

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

2. 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 GCP”.

   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.

Backend Rules

3. Open GCP load balancer, and then the Backend configuration section. Select Create a new backend service

4. To start the configuration, specify a name, such as “measurement-path”

5. Set Backend type to Internet network endpoint group

6. For Protocol, select HTTPS and leave Timeout as the default value

7. Under Backends, select the Internet network endpoint group drop-down and create a new one

8. Set Network endpoint group type to Internet NEG (Global, Regional), Scope to Global, Add through to Fully qualified domain name and port

9. Under Fully qualified domain name, write the domain we sent you in Step 2 as a hostname (no protocol prefix), e.g. example.adding-sst.com

10. Click CREATE to create the endpoint, and close the Network endpoint group tab to return to the New backend service one.

11. Search for the name of the new network endpoint group you chose in Step 4, select it, then open the Advanced configurations section. Add the following request headers:

    • Host with the value of the domain we sent you in Step 2, under the format example.adding-sst.com
    • x-forwarded-host with the value of your domain, e.g. www.example.com
    • true-client-ip with the value {client_ip_address}, GCP’s placeholder for this custom header variable.

12. Save the configuration

Routing rules

13. Going back to GCP load balancer, this time open the Routing rules section

14. Add the following host and path rules:

    • Host: *
    • Path: the path you defined in Step 1, (e.g. /w3ke4d) under the format /w3ke4d/*
    • Backend: the name of the backend defined in Step 4

15. Still in the Routing rules section, expand the path rule you just created and open Advanced URL rewrite. Then set the Path prefix rewrite to /.

16. Update and save the load balancer configuration.

Verify the setup

Now that the initial setup is done, let’s test that everything is correct before sending it live.

1. Go to */your-path/healthy, the page should read: ok

   https://www.example.com/w3ke4d/healthy

   Copy
   

2. Go to */your-path/transformer/reverse-proxy, as https://www.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://www.example.com/w3ke4d/transformer/reverse-proxy' \
   --header 'Cookie: gtm_preview=test123' \
   --header 'Origin: https://www.example.com'

   Copy

   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.

   

3. Go to the collect path below, to try and send “real” data, you should have a 200 response at minimum (depending on your configuration, some more elements might appear, like google ads remarketing).

   https://www.example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse

   Copy
   

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_container_url parameter in your GTM web container, to indicate the new server destination for your data transporter tags.

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

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://www.example.com/w3ke4d

(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://subdomain.example.com/a1b2c3d4e5f6g7h8.js... or https://subdomain.adding-sst.com/a1b2c3d4e5f6g7h8.js...

Replace the “subdomain.example.com” (or “subdomain.adding-sst.com”) by your domain and chosen path, like www.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.

undefined

Detailed setup

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

2. 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 NGINX”.

   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.

Implement Changes

3. The following configuration is an example for a configuration on NGINX with the domain www.example.com, and a path chosen to be www.example.com/w3ke4d. The different instances of these should be replaced with your domain, the path chosen and the domain we shared in Step 2. If your server side tracking is already running, some parts of this are not needed as ssl certificates might already have been set up. We list in the next section the technical requirements for a proper implementation.

server {
  listen 443 ssl http2;

  server_name www.example.com;

  error_log /var/log/nginx/error.log;
  access_log /var/log/nginx/access.log;

  ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem; # managed by Certbot
  ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem; # managed by Certbot

  location /w3ke4d {
      proxy_pass https://example.adding-sst.com/;

      proxy_ssl_server_name on;
      proxy_ssl_name example.adding-sst.com;

      proxy_set_header true-client-ip $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Host 'www.example.com';
  }
}

Technical Requirements

4. The following HTTP methods must be supported:
   GET, POST, OPTIONS

5. For Headers:

   • The end-user IP address must be forwarded in the header: true-client-ip
   • The original host (e.g. www.example.com, not the Addingwell destination domain we shared in Step 2, i.e. example.adding-sst.com) must be forwarded: x-forwarded-host

6. If Caching is enabled on your proxy:

   • The proxy cache must respect Addingwell’s cache-control headers.
   • The cache key must include all query parameters.
   • Regarding query parameters, they:
     • Must not be modified
     • Must not be reordered
     • Must not have additional parameters added

7. All Cookies must be forwarded without modification.

8. When the reverse proxy is exposed through a path (e.g. www.example.com/w3ke4d/):

• The path prefix (e.g. /w3ke4d) must be removed when forwarding the request to the Addingwell destination domain (e.g. the domain we shared in Step 2 under the format example.adding-sst.com).
• The full remaining path must be preserved.
• E.g. /w3ke4d/test/collect must be forwarded as: /test/collect

Verify the setup

Now that the initial setup is done, let’s test that everything is correct before sending it live.

1. Go to */your-path/healthy, the page should read: ok

   https://www.example.com/w3ke4d/healthy

   Copy
   

2. Go to */your-path/transformer/reverse-proxy, as https://www.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://www.example.com/w3ke4d/transformer/reverse-proxy' \
   --header 'Cookie: gtm_preview=test123' \
   --header 'Origin: https://www.example.com'

   Copy

   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.

   

3. Go to the collect path below, to try and send “real” data, you should have a 200 response at minimum (depending on your configuration, some more elements might appear, like google ads remarketing).

   https://www.example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse

   Copy
   

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_container_url parameter in your GTM web container, to indicate the new server destination for your data transporter tags.

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

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://www.example.com/w3ke4d

(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://subdomain.example.com/a1b2c3d4e5f6g7h8.js... or https://subdomain.adding-sst.com/a1b2c3d4e5f6g7h8.js...

Replace the “subdomain.example.com” (or “subdomain.adding-sst.com”) by your domain and chosen path, like www.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.

undefined

Detailed setup

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

2. 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 Apache”.

   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.

Implement Changes

3. The following configuration is an example for a configuration on Apache (2.4+) with the domain www.example.com, and a path chosen to be www.example.com/w3ke4d. The different instances of these should be replaced with your domain, the path chosen and the domain we shared in Step 2. If your server side tracking is already running, some parts of this are not needed as ssl certificates might already have been set up. We list in the next section the technical requirements for a proper implementation.

<VirtualHost *:443>
  ServerName www.example.com

  ErrorLog /var/log/apache2/error.log
  CustomLog /var/log/apache2/access.log combined

  SSLEngine on
  SSLCertificateFile /etc/letsencrypt/live/www.example.com/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/www.example.com/privkey.pem

  SSLProxyEngine on
  ProxyPreserveHost Off

  ProxyPass "/w3ke4d/" "https://example.adding-sst.com/"
  ProxyPassReverse "/w3ke4d/" "https://example.adding-sst.com/"

  <Location "/w3ke4d/">
      RequestHeader set true-client-ip "expr=%{REMOTE_ADDR}"
      RequestHeader set X-Forwarded-Host "www.example.com"
  </Location>
</VirtualHost>

Technical Requirements

4. The following HTTP methods must be supported:
   GET, POST, OPTIONS

5. For Headers:

   • The end-user IP address must be forwarded in the header: true-client-ip
   • The original host (e.g. www.example.com, not the Addingwell destination domain we shared in Step 2, i.e. example.adding-sst.com) must be forwarded: x-forwarded-host

6. If Caching is enabled on your proxy:

   • The proxy cache must respect Addingwell’s cache-control headers.
   • The cache key must include all query parameters.
   • Regarding query parameters, they:
     • Must not be modified
     • Must not be reordered
     • Must not have additional parameters added

7. All Cookies must be forwarded without modification.

8. When the reverse proxy is exposed through a path (e.g. www.example.com/w3ke4d/):

• The path prefix (e.g. /w3ke4d) must be removed when forwarding the request to the Addingwell destination domain (e.g. the domain we shared in Step 2 under the format example.adding-sst.com).
• The full remaining path must be preserved.
• E.g. /w3ke4d/test/collect must be forwarded as: /test/collect

Verify the setup

Now that the initial setup is done, let’s test that everything is correct before sending it live.

1. Go to */your-path/healthy, the page should read: ok

   https://www.example.com/w3ke4d/healthy

   Copy
   

2. Go to */your-path/transformer/reverse-proxy, as https://www.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://www.example.com/w3ke4d/transformer/reverse-proxy' \
   --header 'Cookie: gtm_preview=test123' \
   --header 'Origin: https://www.example.com'

   Copy

   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.

   

3. Go to the collect path below, to try and send “real” data, you should have a 200 response at minimum (depending on your configuration, some more elements might appear, like google ads remarketing).

   https://www.example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse

   Copy
   

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_container_url parameter in your GTM web container, to indicate the new server destination for your data transporter tags.

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

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://www.example.com/w3ke4d

(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://subdomain.example.com/a1b2c3d4e5f6g7h8.js... or https://subdomain.adding-sst.com/a1b2c3d4e5f6g7h8.js...

Replace the “subdomain.example.com” (or “subdomain.adding-sst.com”) by your domain and chosen path, like www.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.

undefined

Detailed setup

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

2. 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 Fastly”.

   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.

Condition and Host

3. Create a new Condition with the following settings: in Type, set Request, for Name, use Measurement Path (or any name you prefer), and for the option Apply if…, set req.url.path ~ ”^/w3ke4d” replacing w3ke4d by the path chosen at Step 1.

4. Create a new Host and set the Host name/Address field to the domain we sent you in Step 2, under the format example.adding-sst.com.

5. Still for that new Host, click Attach a condition and select the condition you created in Step 3.

6. Then, Set Override host to the domain we sent you in Step 2, under the format example.adding-sst.com. Leave other settings as default, and click on Update to save the host.

7. Still under your Fastly service configuration, open Content then Headers and create three new headers, each with Condition set to the condition created in Step 3 (e.g. Measurement Path).

8. First, to strip the path prefix, set Type to Request, Action to Set, Destination to url and for source, input regsub(req.url, ”^/w3ke4d/?”, ”/”) (replace w3ke4d with your chosen path).

9. Then to forward the real client IP, set Type to Request, Action to Set, Destination to http.true-client-ip and Source to client.ip.

10. Thirdly, to forward the original host, set Type to Request, Action to Set, Destination to http.x-forwarded-host and source to req.http.host.

11. Lastly, activate the new version of the service.

Technical Requirements

12. The following HTTP methods must be supported:
    GET, POST, OPTIONS

13. For Headers:

    • The end-user IP address must be forwarded in the header: true-client-ip
    • The original host (e.g. www.example.com, not the Addingwell destination domain we shared in Step 2, i.e. example.adding-sst.com) must be forwarded: x-forwarded-host

14. If Caching is enabled on your proxy:

    • The proxy cache must respect Addingwell’s cache-control headers.
    • The cache key must include all query parameters.
    • Regarding query parameters, they:
      • Must not be modified
      • Must not be reordered
      • Must not have additional parameters added

15. All Cookies must be forwarded without modification.

16. When the reverse proxy is exposed through a path (e.g. www.example.com/w3ke4d/):

    • The path prefix (e.g. /w3ke4d) must be removed when forwarding the request to the Addingwell destination domain (e.g. the domain we shared in Step 2 under the format example.adding-sst.com).
    • The full remaining path must be preserved.
    • E.g. /w3ke4d/test/collect must be forwarded as: /test/collect

Verify the setup

Now that the initial setup is done, let’s test that everything is correct before sending it live.

1. Go to */your-path/healthy, the page should read: ok

   https://www.example.com/w3ke4d/healthy

   Copy
   

2. Go to */your-path/transformer/reverse-proxy, as https://www.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://www.example.com/w3ke4d/transformer/reverse-proxy' \
   --header 'Cookie: gtm_preview=test123' \
   --header 'Origin: https://www.example.com'

   Copy

   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.

   

3. Go to the collect path below, to try and send “real” data, you should have a 200 response at minimum (depending on your configuration, some more elements might appear, like google ads remarketing).

   https://www.example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse

   Copy
   

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_container_url parameter in your GTM web container, to indicate the new server destination for your data transporter tags.

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

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://www.example.com/w3ke4d

(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://subdomain.example.com/a1b2c3d4e5f6g7h8.js... or https://subdomain.adding-sst.com/a1b2c3d4e5f6g7h8.js...

Replace the “subdomain.example.com” (or “subdomain.adding-sst.com”) by your domain and chosen path, like www.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.

undefined

Detailed setup

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

2. 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 + the name of the provider you intend to use (e.g. Cloudfront, Nginx, etc)”.

   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.

Technical Requirements

3. The following HTTP methods must be supported:
   GET, POST, OPTIONS

4. For Headers:

   • The end-user IP address must be forwarded in the header: true-client-ip
   • The original host (e.g. www.example.com, not the Addingwell destination domain we shared in Step 2, i.e. example.adding-sst.com) must be forwarded: x-forwarded-host

5. If Caching is enabled on your proxy:

   • The proxy cache must respect Addingwell’s cache-control headers.
   • The cache key must include all query parameters.
   • Regarding query parameters, they:
     • Must not be modified
     • Must not be reordered
     • Must not have additional parameters added

6. All Cookies must be forwarded without modification.

7. When the reverse proxy is exposed through a path (e.g. www.example.com/w3ke4d/):

   • The path prefix (e.g. /w3ke4d) must be removed when forwarding the request to the Addingwell destination domain (e.g. the domain we shared in Step 2 under the format example.adding-sst.com).
   • The full remaining path must be preserved.
   • E.g. /w3ke4d/test/collect must be forwarded as: /test/collect

Verify the setup

Now that the initial setup is done, let’s test that everything is correct before sending it live.

1. Go to */your-path/healthy, the page should read: ok

   https://www.example.com/w3ke4d/healthy

   Copy
   

2. Go to */your-path/transformer/reverse-proxy, as https://www.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://www.example.com/w3ke4d/transformer/reverse-proxy' \
   --header 'Cookie: gtm_preview=test123' \
   --header 'Origin: https://www.example.com'

   Copy

   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.

   

3. Go to the collect path below, to try and send “real” data, you should have a 200 response at minimum (depending on your configuration, some more elements might appear, like google ads remarketing).

   https://www.example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse

   Copy
   

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_container_url parameter in your GTM web container, to indicate the new server destination for your data transporter tags.

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

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://www.example.com/w3ke4d

(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://subdomain.example.com/a1b2c3d4e5f6g7h8.js... or https://subdomain.adding-sst.com/a1b2c3d4e5f6g7h8.js...

Replace the “subdomain.example.com” (or “subdomain.adding-sst.com”) by your domain and chosen path, like www.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.