Proxy the Admaxxer pixel through Apache

Prefer no server work at all? A managed first-party subdomain does the same job with one DNS record; the comparison below helps you choose.

Why route the pixel through your own domain

• Requests stay on your domain. The script and every event go to your own hostname, so blockers and DNS filters that work from lists of tracking hostnames have no admaxxer.com request to match.
• A simpler Content Security Policy. Both requests are same-origin, so 'self' already covers them. See CSP troubleshooting.
• Always the current pixel. You forward the script instead of copying it, so pixel updates reach your visitors with no re-install.

What it doesn't change

Visitors who opt out stay opted out, and tools that inspect scripts on your own pages can still interfere. A proxy also changes which network address Admaxxer sees — read what Admaxxer sees through your proxy before you switch.

Before you start

• Apache 2.4 serving your site over HTTPS, with permission to edit its virtual host configuration and reload it.
• The mod_proxy, mod_proxy_http and mod_ssl modules, and outbound HTTPS from the server to admaxxer.com.
• Your Admaxxer Website ID (it starts with admx_), from the pixel install page.

What your proxy must forward

With data-proxy-origin set, the pixel sends every request to that address instead of admaxxer.com. Forward each of these paths to the same path on https://admaxxer.com. A proxy that forwards only some of them silently loses data: custom events, purchases and identify calls each travel on a path of their own.

Pass requests through unchanged (same method, same JSON body), addressed to admaxxer.com in both the Host header and the TLS server name. Two browser headers must survive the trip:

• User-Agent. Requests without one are treated as bots and quietly discarded.
• Origin or Referer. Admaxxer only accepts events from your site's domains; with neither header, events are rejected with a 403.

Cookies aren't needed: the pixel sends its visitor and session IDs inside the request body.

Already using one of these paths?

The pixel appends these paths to whatever data-proxy-origin you give it, so you can keep everything under a folder. With data-proxy-origin="https://yourdomain.com/admx" and the script at /admx/pixel.js, the pixel calls /admx/api/event, /admx/api/event/batch and so on. Forward each one to the same path on admaxxer.com without the /admx prefix.

Step 1: Enable the modules

On Debian and Ubuntu:

sudo a2enmod proxy proxy_http ssl

On other distributions these modules are usually loaded already; apachectl -M lists what's active (look for proxy_module, proxy_http_module and ssl_module).

Step 2: Add the proxy rule

Virtual host configuration

# Inside the <VirtualHost *:443> block that serves your site.
# Requires mod_proxy, mod_proxy_http and mod_ssl.
SSLProxyEngine on
ProxyPreserveHost Off
ProxyPassMatch "^/(pixel\.js|api/event|api/event/batch|api/identify)$" "https://admaxxer.com/$1"

• The anchored pattern matches exactly the four paths, so none of your own routes are captured.
• SSLProxyEngine on lets Apache connect to admaxxer.com over HTTPS. ProxyPreserveHost Off addresses the request to admaxxer.com rather than to your hostname.
• Apache checks ProxyPass and ProxyPassMatch rules in order and uses the first match, so put this line above any catch-all such as ProxyPass / http://localhost:3000/.
• Apache passes the browser's headers, including User-Agent, Origin and Referer, through by default.

Only have .htaccess?

If you can't edit the virtual host, the same forwarding works from .htaccess, provided mod_rewrite, mod_proxy and mod_proxy_http are available and SSLProxyEngine on is already set in the server configuration (it can't be set from .htaccess). Shared hosts often don't allow this; if the rule returns a 403 or 500, ask your host or use the managed subdomain instead.

.htaccess

# Admaxxer first-party proxy (needs mod_rewrite, mod_proxy, mod_proxy_http,
# and SSLProxyEngine on in the server configuration)
RewriteEngine On
RewriteRule ^(pixel\.js|api/event|api/event/batch|api/identify)$ https://admaxxer.com/$1 [P,L]

Put it above any existing rewrite rules, such as a CMS front-controller block. Running WordPress? Follow the WordPress guide, which covers the plugin settings too.

Step 3: Test the configuration and reload

sudo apachectl configtest
sudo systemctl reload apache2

The service is called httpd on some distributions (sudo systemctl reload httpd).

Step 4: Update your pixel snippet

Replace the Admaxxer snippet on every page with this version. Use your own Website ID (it starts with admx_; copy it from the snippet on the pixel install page) and the exact hostname your pages load from, such as www.yourdomain.com if that is your site's address.

<script async
  src="https://yourdomain.com/pixel.js"
  data-website-id="admx_your_website_id"
  data-proxy-origin="https://yourdomain.com">
</script>

• src loads the script through your proxy.
• data-proxy-origin sends every event through your proxy. Without it the script still loads from your domain, but events go straight to admaxxer.com.
• It's the same snippet Admaxxer generates for a managed first-party subdomain; only the hostname differs.

Replace, don't add

Keep exactly one Admaxxer snippet per page. If two load, only the first one runs, so a leftover standard snippet can keep sending events to admaxxer.com.

Using Pro tracking or another script variant

/pixel.js always serves the standard script. To use another variant, such as script.plus.js for Pro tracking, forward /js/script.plus.js instead of /pixel.js and point src at https://yourdomain.com/js/script.plus.js. Leave data-proxy-origin as it is: every variant reads it.

Step 5: Check that it works

Run these from any terminal, replacing yourdomain.com with your site's hostname:

# 1. The script loads through your domain: expect HTTP 200 and a JavaScript content type
curl -sI https://yourdomain.com/pixel.js

# 2. Each endpoint reaches Admaxxer. An empty body is rejected on purpose,
#    so nothing is recorded; the error reply proves the route works.
curl -s -X POST https://yourdomain.com/api/event -H 'Content-Type: application/json' -d '{}'
#    expect: {"error":"validation_failed", ...}
curl -s -X POST https://yourdomain.com/api/event/batch -H 'Content-Type: application/json' -d '{}'
#    expect: {"error":"empty_batch"}
curl -s -X POST https://yourdomain.com/api/identify -H 'Content-Type: application/json' -d '{}'
#    expect: {"error":"validation_failed", ...}

Only Admaxxer answers with those error messages. If you get your own site's 404 page or HTML instead, that path isn't being forwarded.

Then load your site with the browser's developer tools open on the Network tab. The script and the api/event requests should go to your own domain (none to admaxxer.com), and accepted events are answered with 202. Finally, open the pixel install page: the Verify install card turns green once events arrive.

What Admaxxer sees through your proxy

Visitors and sessions are counted from the IDs the pixel sends, so those numbers don't change. What changes is the network address: Admaxxer uses the address of whatever connects to it, and through a self-run proxy that is your proxy, not your visitor. Forwarding headers such as X-Forwarded-For are not used for this.

• Country. Read from a country header when one arrives with the request (CF-IPCountry, X-Vercel-IP-Country or X-Real-Country, holding a two-letter country code). Otherwise it is looked up from the connecting address, which through a proxy is your proxy's location. If Cloudflare sits in front of your server, its CF-IPCountry header is passed through with the request. If Apache can determine the visitor's country itself (for example with a GeoIP module), send it as an X-Real-Country request header.
• Rate limit. Each network address can send up to 100 requests every 10 seconds to a site. Through a proxy your visitors share your proxy's address, so a busy site can reach that limit at peak times; requests over it are rejected with 429 and those events are lost.
• Excluding your own traffic. IP-based exclusion rules can't match visitors through a proxy. To keep your own visits out, run admaxxer.optOut() in your browser's console on your site (see the consent API).
• Server-side purchase matching. When a purchase captured by the pixel is passed on to ad platforms, the shopper's network address is one of the match signals. Through a proxy it is your proxy's address, which can lower match quality.

Troubleshooting

• Your own 404 page or HTML instead of Admaxxer's reply. The forwarding rule isn't matching that path. Check the exact path and hostname, and that the rule sits ahead of any catch-all rule.
• 403 with origin_not_allowed. The Origin and Referer headers aren't reaching Admaxxer, or the page's domain isn't one of your site's domains in Admaxxer.
• Requests answer 204 but no pageviews appear. 204 means Admaxxer received the event and deliberately dropped it, most often because the User-Agent header was removed (requests without one are treated as bots). A 204 is also normal for the once-a-day install check and for visitors who opted out.
• 429 responses. Your combined traffic reached the per-address rate limit described in what Admaxxer sees.
• Every visitor shows the same country. No country header is reaching Admaxxer; see what Admaxxer sees.
• 500 errors on the forwarded paths. Usually SSLProxyEngine on is missing or a proxy module isn't loaded. Apache's error log names the cause.
• 502 or SSL errors connecting to admaxxer.com. From the server, run curl -sI https://admaxxer.com/pixel.js to confirm it can reach Admaxxer over HTTPS, and keep the server's CA certificates up to date.

Self-run proxy or managed subdomain?

Admaxxer can also serve the pixel from a subdomain of yours with no proxy to run: in Integrations, open First-party tracking domain, add a subdomain such as t.yourdomain.com and create the one DNS record it shows. Both options load the pixel and send events from your own domain.

Choose a self-run proxy when you can't add DNS records, don't want a separate tracking subdomain, or need every request to pass through infrastructure you control. Otherwise the managed subdomain is less to maintain; see the first-party tracking domain guide.

Undo the setup

Put the standard snippet back first (copy it from the pixel install page), then remove the ProxyPassMatch line (or the .htaccess rule), run sudo apachectl configtest and reload Apache. In that order, no page ever points at a path that has stopped working.

Same setup on another platform: Cloudflare Workers · NGINX · Vercel · Next.js · Netlify · Nuxt · WordPress

Frequently asked questions

Related guides

• First-party tracking domain — The managed alternative: one DNS record, nothing to run yourself.
• Proxy through NGINX — Four exact-match location blocks.
• Proxy through WordPress — Server rules plus the plugin's Proxy Origin.
• Proxy through Cloudflare Workers — A small Worker on four exact routes.
• Install the pixel — Script variants, cookieless mode and the standard snippet.