Tracking stopped working - Plausible requests sent to wrong domain

[nicbou]

Prerequisites

• I have searched open and closed issues to make sure that the bug has not yet been reported.

Bug report

Since a day or more, the tracking script stopped working. Requests are made to https://allaboutberlin.com/api/event instead of either plausible.io/api/event or stats.allaboutberlin.com/api/event.

This follows a change in the plausible.outbound-links.js scripts, since it does not seem to contain either domain anymore. For some reason, it uses currentScript.src.origin as the domain.

Expected behavior

Plausible requests should be made to the correct domain. Script updates should not break tracking on my website.

[nicbou]

This breaking change seems to be caused by the introduction of data-api, which seemingly defaults to the currentScript domain. Since I was already proxying the Plausible script to save a DNS query (allaboutberlin.com/*.js), it defaulted to the script's domain, which is the current domain.

My previous setup: allaboutberlin.com/whoisthere.js -> stats.allaboutberlin.com/js/plausible.js -> plausible.io/js/plausible.js

The requests usually went to stats.allaboutberlin.com/api/event, but the introduction of data-api broke it.

[ukutaht]

Yes, we moved to document.currentScript for the event endpoint. You can fix your setup by adding data-api="stats.allaboutberlin.com/api/event"

[nicbou]

I have fixed it now, but a warning would have been nice. I only noticed because of the sudden, massive dip in tracked visits.

[ukutaht]

My apologies. I did consider declaring this a breaking change and moving to new versioned filename (plausible-v1.js or something like that). I was on the fence but went with just updating the current script because it would only affect people who use our script in unofficial and undocumented ways. The change did not affect 99% who is using the script in the ways shown in our docs.

Sorry you were a casualty in this move. I will add a warning to the other threads about proxy setups where people might be running Plausible in similar ways. I'm not used to so many people using my work in ways I can't even predict :)

[ItalyPaleAle]

Sounds like a case where Hyrum's law would apply 😃

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

I self-host so I always look at the script before updating. But it would be awesome if changes in the script could be in the changelog!

[nicbou]

It has been a few days since I implemented the data-api change, and I only see 5% of the traffic I normally saw. I have zero idea of what is happening with the rest of the traffic, but Google Search Console does not show any dip in search engine traffic.

    location = /whoisthere.js {
        proxy_pass https://stats.allaboutberlin.com/js/plausible.outbound-links.js;
        proxy_buffering on;
        proxy_cache jscache;
        proxy_cache_valid 200 6h;
        proxy_cache_use_stale updating error timeout invalid_header http_500;

        proxy_set_header Host stats.allaboutberlin.com;
        proxy_ssl_name stats.allaboutberlin.com;
        proxy_ssl_server_name on;
        proxy_ssl_session_reuse off;

        add_header X-Cache $upstream_cache_status;
    }

    location = /whoisthere/event {
        proxy_pass https://stats.allaboutberlin.com/api/event;
        proxy_buffering on;
        proxy_http_version 1.1;

        proxy_set_header Host stats.allaboutberlin.com;
        proxy_ssl_name stats.allaboutberlin.com;
        proxy_ssl_server_name on;
        proxy_ssl_session_reuse off;

        proxy_set_header X-Forwarded-For   $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host  $host;

        add_header X-Cache $upstream_cache_status;
    }

[ukutaht]

Hey - looks like all the traffic is being tracked but our backend is getting the wrong IP address. Looks to me like this is because our custom domain server wasn't intended to be behind a proxy when I first set it up. It always takes the $remote_addr and uses that as the client IP address which is not correct when you have a proxy in front of it.

I've changed it now so it takes your X-Forwarded-For setting in account and passes it on to our backend server. This should make sure the correct IP address is used. Give it some time and let me know if your stats are looking better.

[nicbou]

Thanks for the fast reply. I swapped the custom domain for plausible.io after posting this, suspecting that it could be the cause. I realise that we're charting new territory and that there should be bumps along the way, and I really appreciate your help.

Hopefully, everything should work fine today. I'll keep you posted.

[ukutaht]

Yeah going straight to plausible.io/api/event is also a potential fix - the custom domain isn't really needed anymore once you have a proxy set up.

[nicbou]

Quick update: it's working as expected now. The measured numbers are significantly higher than yesterday, and match the normal trend. I think that these nginx rules would be a useful addition to your documentation:

Solution

On the page:

<script async defer data-api="https://website.com/whoisthere/event" data-domain="website.com" src="https://website.com/whoisthere.js"></script>

In the nginx config:

# Only needed if you cache the plausible script. Speeds things up.
proxy_cache_path /var/run/nginx-cache/jscache levels=1:2 keys_zone=jscache:100m inactive=30d  use_temp_path=off max_size=100m;

server {
    ...
    location = /whoisthere.js {
        # Change this if you use a different variant of the script
        proxy_pass https://plausible.io/js/plausible.outbound-links.js;

        # Tiny, negligible performance improvement. Very optional.
        proxy_buffering on;

        # Cache the script for 6 hours, as long as plausible.io returns a valid response
        proxy_cache jscache;
        proxy_cache_valid 200 6h;
        proxy_cache_use_stale updating error timeout invalid_header http_500;

        proxy_set_header Host plausible.io;
        proxy_ssl_name plausible.io;
        proxy_ssl_server_name on;
        proxy_ssl_session_reuse off;

        # Optional. Adds a header to tell if you got a cache hit or miss
        add_header X-Cache $upstream_cache_status;
    }

    location = /whoisthere/event {
        proxy_pass https://plausible.io/api/event;
        proxy_buffering on;
        proxy_http_version 1.1;

        proxy_set_header Host plausible.io;
        proxy_ssl_name plausible.io;
        proxy_ssl_server_name on;
        proxy_ssl_session_reuse off;

        proxy_set_header X-Forwarded-For   $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host  $host;
    }

[metmarkosaric]

thanks @nicbou! we'll include those instructions!

[ukutaht]

Thanks again @nicbou. I'm adjusting this setup a bit for our documentation. What's the reasoning behind this block?

        proxy_set_header Host plausible.io;
        proxy_ssl_name plausible.io;
        proxy_ssl_server_name on;
        proxy_ssl_session_reuse off;

[nicbou]

My initial setup only proxied the plausible.js script. I loaded the script from the custom domain - not plausible.io - because I wanted the API call to use that custom domain.

If I didn't set these, I got SSL errors between the nginx reverse proxy and Plausible. I am not sure if this is necessary anymore.

[ukutaht]

Ah I see. I'll probably remove them. Thanks!

[thepra]

Thanks again @nicbou. I'm adjusting this setup a bit for our documentation. What's the reasoning behind this block?

        proxy_set_header Host plausible.io;
        proxy_ssl_name plausible.io;
        proxy_ssl_server_name on;
        proxy_ssl_session_reuse off;

@metmarkosaric this is the piece that made it work for me for my hosted instance(hi from the fediverse), but instead of plausible.io I put mine