Unable to get IP geolocation working

[plausible]

Unable to get IP geolocation working

[birjj]

@ukutaht Looks like that was it! Thanks for the pointer; I hadn't even considered my reverse proxy being the problem.

Would there be interest in a PR adding documentation for how to setup NGINX in front of Plausible in the self-hosting docs? I see that the docs mention there being instructions "below", but I couldn't find them. Alternatively (or additionally) a pre-made NGINX config could be added to this repo if there is interest.

[birjj]

If it helps, my Plausible instance is public at https://plausible.jfagerberg.me/jfagerberg.me

[ukutaht]

Hey, thanks for the report.

I maintain a testing instance for the self-hosted configuration over at testing.plausible.io (our prod setup is a bit different). So far I didn't have geoip configured so I thought I would follow the same steps to see what works.

After updating the geoip/docker-compose.geoip.yml with the volume and the geoip/geoip.conf with my credentials, I rebooted the system with docker-compose down and then docker-compose -f docker-compose.yml -f geoip/docker-compose.geoip.yml up -d.

As you can see, countries are being captured now: https://testing.plausible.io/plausible.io

Unfortunately without being able to reproduce the issue, it's difficult to debug. My first thought is that maybe you're sitting behind a proxy that doesn't implement X-Forwarded-For correctly? This would throw off the Plausible server, not just for countries but also for unique user counting. Let me know if you think that's a possibility.

Otherwise we can think about adding some logging around the country lookup and you could deploy that image with log_level: :debug to get some more intel.

[ukutaht]

Yeah I think we'll get a PR with configuration for Traefik soon: https://plausible.discourse.group/t/self-hosting-https-how-to/87/5

I'd also love to have read-made configs for Nginx and Caddy.

Just out of curiosity, how was your nginx configured? What change made it work?

[birjj]

@ukutaht My NGINX config is super simple. The part that isn't managed by Certbot is:

server {
	server_name plausible.jfagerberg.me;

	location / {
		proxy_pass http://127.0.0.1:7654;

		# added line below to fix issue
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	}
}

(where 7654 is the port I'm binding Plausible to)

---

I'll hopefully get around to throwing together a PR for the self-hosting docs sometimes tomorrow. I'm assuming a new page under the self-hosting category would be preferable over adding it as a subsection of the Getting started page?

[ukutaht]

Looks good! I wish nginx automatically sent X-Forwarded-For when using proxy_pass

Would be best to add a new docker-compose override in addition to adding documentation. I think runnable code is the best way to document something.

[birjj]

If we're adding a docker-compose override, then I'm assuming that the goal is to be as plug-and-play as possible. Since it doesn't really make much sense to offer multiple different reverse proxy images, it'd probably be best to choose between caddy-gen for its simplicity, nginx-proxy for being semi-simple and well-maintained, or Traefik for its maturity (and then hope that anyone who's running an existing reverse proxy know how to configure it ;) )

I'll try to get around to it tomorrow.

[ukutaht]

I'd be quite happy to offer all 3 as well and let the user pick depending on which docker-compose override file they include

[birjj]

It's obviously your decision in the end, but may I ask why? Since running a reverse proxy as a docker container only makes sense if users aren't running a reverse proxy to begin with (otherwise it will clash with the existing instance), there's very little point in letting people choose, assuming all the reverse proxies have feature parity which they do for this case.

I can see the point in providing configs for both Caddy, NGINX and Traefik so users can choose the appropriate one if they're already running a reverse proxy - but bundling the reverse proxy as a docker-compose override would only make sense if they aren't running one to begin with.

[ukutaht]

@birjolaxew I think you're right, it's best to choose one to bundle in the docker-compose and provide example configs for different servers for when they run separately.