Route the Admaxxer pixel through your WordPress site

This guide assumes the Admaxxer WordPress plugin is installed with your Website ID. If you add the pixel to your theme by hand instead, follow the NGINX or Apache guide; they include the snippet to paste.

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.

How the plugin's Proxy Origin works

In Settings → Admaxxer, the Proxy Origin field tells the plugin to load the tracking script from your own address instead of admaxxer.com. When you press Save Settings, the plugin first checks that the script really loads from that address and refuses one that doesn't, so a mistake can't switch your tracking off.

The setting moves the script, not the events

In the current plugin (version 1.4.1), Proxy Origin changes only where the script loads from. Events still go to admaxxer.com unless the script tag also carries data-proxy-origin, which Step 3 adds.

Before you start

• The Admaxxer plugin is active with your Website ID saved.
• Your server lets you add proxy rules: Apache with .htaccess proxy support, or NGINX configuration access. Managed WordPress hosts often don't allow this.
• A place for a few lines of PHP: your child theme's functions.php or a code-snippets plugin.

Can't add proxy rules? Create a managed first-party subdomain instead (it needs only a DNS record), then follow Steps 2 and 3 below using your subdomain's address, such as https://t.yourdomain.com.

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.

With the plugin's Enable Cookieless Tracking option on, it loads /js/script.cookieless.js instead; with Enable SPA Hash Mode, /js/script.hash.js. The rules below cover all three.

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.

Step 1: Add the forwarding rules

Apache (.htaccess)

Add this to the .htaccess file in your WordPress root, above the # BEGIN WordPress block. WordPress regenerates everything inside that block, and its catch-all rule would otherwise handle these paths first:

.htaccess

# Admaxxer first-party proxy: keep this above "# BEGIN WordPress".
# Needs mod_rewrite, mod_proxy, mod_proxy_http, and SSLProxyEngine on in the server configuration.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(js/script(\.cookieless|\.hash)?\.js|api/event|api/event/batch|api/identify)$ https://admaxxer.com/$1 [P,L]
</IfModule>

SSLProxyEngine on can't be set from .htaccess; whoever manages the server has to enable it. If the rule returns a 403 or 500, a required module or that setting is missing. The Apache guide has the details.

NGINX

Inside the HTTPS server { } block for your site, add these exact-match blocks, then run sudo nginx -t and reload NGINX. If you enabled cookieless or hash mode, change the first block's path to match. The NGINX guide explains each line.

# Admaxxer first-party proxy: inside the HTTPS server { } block for your site.
# Exact matches (=) take priority over every other location, so these never
# capture your own routes and can't be shadowed by a regex rule for .js files.
location = /js/script.js {
    proxy_pass https://admaxxer.com;
    proxy_set_header Host admaxxer.com;
    proxy_ssl_server_name on;
}
location = /api/event {
    proxy_pass https://admaxxer.com;
    proxy_set_header Host admaxxer.com;
    proxy_ssl_server_name on;
}
location = /api/event/batch {
    proxy_pass https://admaxxer.com;
    proxy_set_header Host admaxxer.com;
    proxy_ssl_server_name on;
}
location = /api/identify {
    proxy_pass https://admaxxer.com;
    proxy_set_header Host admaxxer.com;
    proxy_ssl_server_name on;
}

Step 2: Set the plugin's Proxy Origin

1. In WordPress, open Settings → Admaxxer.
2. In Proxy Origin, enter your site's address, such as https://yourdomain.com: the exact scheme and hostname your pages use, with no path.
3. Press Save Settings. If the plugin reports that it couldn't load the script, the forwarding from Step 1 isn't working yet; the field stays blank and tracking carries on from admaxxer.com.

Step 3: Send events through your domain

Add this filter to your child theme's functions.php or a code-snippets plugin. It adds data-proxy-origin to the Admaxxer script tag so events follow the script onto your domain:

functions.php

// Send Admaxxer events through your own domain as well as the script.
// Use the same address you entered as the plugin's Proxy Origin.
add_filter( 'script_loader_tag', function ( $tag ) {
	$proxy_origin = 'https://yourdomain.com';
	if ( false === strpos( $tag, 'data-website-id=' ) || false !== strpos( $tag, 'data-proxy-origin=' ) ) {
		return $tag; // Not the Admaxxer tag, or already set.
	}
	return str_replace( ' src=', ' data-proxy-origin="' . esc_attr( $proxy_origin ) . '" src=', $tag );
}, 20 );

• It only touches the tag that carries data-website-id (the Admaxxer pixel), and leaves it alone if data-proxy-origin is already there, so it never adds the attribute twice.
• Priority 20 runs after the plugin has added its own attributes.
• If you use a page-caching plugin, clear its cache so visitors get the updated tag.

Step 4: 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/js/script.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.

Also view your page source: the Admaxxer script tag should load from your domain and carry both data-website-id and data-proxy-origin.

WooCommerce order events are sent by the plugin server-to-server and aren't affected by any of these steps.

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 site, its CF-IPCountry header is passed through with the request.
• 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.
• The plugin won't save the Proxy Origin. It fetches the script from your address when you save. If the script loads in your browser but the check still fails, your host may block a site from requesting its own address; developers can skip the check with add_filter( 'admaxxer_skip_proxy_origin_check', '__return_true' );.
• Script loads from your domain, but events still go to admaxxer.com. The Step 3 filter isn't running: check that it's in the active theme or snippet, and clear any page cache.

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 clear the plugin's Proxy Origin field and press Save Settings, remove the Step 3 filter, and then remove the forwarding rules. In that order, no page ever points at a path that has stopped working.

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

Frequently asked questions

Related guides

• Admaxxer WordPress plugin — Install the plugin, add your Website ID and connect WooCommerce.
• First-party tracking domain — The managed alternative: one DNS record, nothing to run yourself.
• Proxy through Apache — One ProxyPassMatch rule, or .htaccess.
• Proxy through NGINX — Four exact-match location blocks.
• Install the pixel — Script variants, cookieless mode and the standard snippet.