Hosting My Own Geofeed (and Making Sure It Actually Works)

Hosting My Own Geofeed (and Making Sure It Actually Works)

I recently set up a Geofeed for my ASN (AS215855) and figured I’d share how I’m hosting it — along with a small quirk I ran into around MIME types.

What’s a Geofeed?

A geofeed is a simple CSV file that helps geolocation providers (think MaxMind, IPinfo, etc.) map IP prefixes to physical locations. It’s useful if you’re running your own network or anycast services and want things like regional content delivery or latency-based routing to behave as expected.

Here’s a sample from mine:

2a0e:97c0:e60::/48,DE,DE-BY,Falkenstein
2a0e:97c0:e61::/48,US,US-NY,New York City
2a0e:97c0:e62::/48,SE,SE-AB,Stockholm
2a13:c007:8400::/48,US,US-NY,New York City

How I’m Hosting It

Originally, I had this file hosted behind an nginx container, reverse proxied by Caddy. That worked fine — mostly.

The Problem? MIME Types.

nginx was serving the file with the content type application/octet-stream, which is pretty generic. That’s fine for browsers, but it can cause problems if a geolocation provider expects the file to be served as text/csv. For example, isp.google.com always keept saying there was an issue with one of the rows.

I could’ve patched it by adding a proper MIME type override either in the nginx container or in Caddy, but honestly — that felt unnecessarily fiddly for such a simple static file.

The Solution: Let Caddy Handle It

Instead, I moved the file directly onto the Caddy server itself and served it from a static path — no container, no proxying, just a plain file.

Now the geofeed is available at:

👉 https://as215855.net/static/geofeed.csv

Caddy automatically sets the correct Content-Type: text/csv, and everything just works™.

Final Thoughts

If you’ve got your own IP space, hosting a geofeed is a low-effort, high-reward way to help improve the accuracy of IP geolocation.