How IPinfo Delivers Database Downloads (CDN, Request flow, SSL etc.)

General
1

When you download an IPinfo database using the documented URL pattern:

https://ipinfo.io/data/<filename>?token=$TOKEN

the response is not the database file itself. It is an HTTP 302 redirect to a short-lived, signed URL on one of our content delivery networks. Your client then follows the redirect and downloads the file from the CDN.

This page documents that delivery architecture so you can configure your clients, proxies, and firewalls correctly.

Why we redirect

IPinfo databases are large and are downloaded frequently by a global user base. Serving them directly from our API origin would be slow for customers far from our origin region and expensive to operate. Instead, our API authorizes each request and hands it off to a CDN that serves the bytes from an edge cache close to you. The practical benefits:

  • Faster downloads. Files are served from the CDN edge nearest to your client.
  • Authorization at the API, delivery at the edge. Your access token is validated once by ipinfo.io against your subscription. If authorized, we return a redirect to a signed URL that is valid only for that file, for a short window, from any IP. Your token is never sent to the CDN.
  • Integrity. The signed URL cannot be tampered with. Any modification invalidates the signature.

The request flow

  1. Your client sends GET https://ipinfo.io/data/<filename>?token=$TOKEN.
  2. Our API authenticates the token and checks that your subscription includes this database.
  3. If authorized, the API responds with 302 Found and a Location: header pointing to a signed URL on our CDN.
  4. Your client follows the redirect and downloads the file.

An abbreviated example:

$ curl -I "https://ipinfo.io/data/ipinfo_lite.mmdb?token=$TOKEN"
HTTP/1.1 302 Found
location: https://dl.assets.ipinfo.io/artifacts/v1/ipinfo_lite.mmdb?X-Amz-Expires=...&X-Amz-Signature=...

To have curl follow the redirect automatically, use -L:

curl -L "https://ipinfo.io/data/ipinfo_lite.mmdb?token=$TOKEN" -o ipinfo_lite.mmdb

Most HTTP libraries follow redirects by default. A few, such as Python’s urllib.request, do not — see Client requirements below.

CDN hosts you may see

The Location: header in the redirect currently points to one of the following hosts. Your client does not need to care which one, but your firewall does.

Host Backend When you’ll see it
dl.assets.ipinfo.io Cloudflare R2 + Cloudflare CDN Default for all accounts
dl.ipinfo.io Google Cloud Storage + Google Cloud CDN — Splunk integration downloads, and as a fallback path retained for vendor flexibility

Both paths serve the same file with the same bytes. We do not guarantee a specific host for a given download; treat the Location: header as authoritative.

Maintaining both paths gives us flexibility to fall back to direct GCS delivery if needed, and lets us serve the Splunk integration through the path it was originally configured against. The redirect target you receive depends on your account and the file requested.

Firewall and proxy configuration

If your client runs behind a firewall, web proxy, or corporate egress filter, make sure outbound HTTPS (TCP/443) is allowed to each of the following hosts:

  • ipinfo.io — API endpoint that authorizes your request and issues the redirect
  • api.ipinfo.io — API endpoint
  • dl.assets.ipinfo.io — CDN host that serves database files for most accounts (Cloudflare R2)
  • dl.ipinfo.io — CDN host used by the Splunk integration and retained as a fallback path
  • storage.googleapis.com — origin backing dl.ipinfo.io; some firewalls, TLS-inspecting proxies, and deep packet inspection appliances need this allowed in addition to dl.ipinfo.io

Allowlist all five hosts even if you expect to receive only one of the CDN hosts. Which host the redirect points to can change based on product path, file availability, and client integration.

Common failure modes

The most common failure we see is a firewall that allows ipinfo.io but blocks one of the CDN hosts. The first request succeeds with a 302, but the follow-up download fails — typically as Connection reset by peer, an SSL: CERTIFICATE_VERIFY_FAILED error, or a silent timeout.

A second, more subtle failure is when dl.ipinfo.io itself is allowed but its upstream origin is not. Some security appliances inspect SNI or resolve CDN hosts through to their origin and enforce rules against the backing domain. In these environments, allowing dl.ipinfo.io alone is not sufficient; storage.googleapis.com must also be allowed. If you see TLS handshake failures or connection resets on the redirect target despite dl.ipinfo.io being in your allowlist, this is the likely cause.

Client requirements

A compatible HTTP client must:

  1. Follow 302 redirects. With curl, pass -L. With wget, this is the default. Python’s requests follows redirects by default; urllib.request does not.
  2. Not forward the Authorization header across the redirect. The token is only required to reach ipinfo.io. The signed URL carries its own signature. If your client forwards Authorization: Bearer <token> to the CDN, you may receive an HTTP 401 because the CDN validates the Authorization header before checking the signed URL parameters. Python’s requests library strips cross-host Authorization headers automatically; urllib.request does not.
  3. Verify TLS certificates normally. We use public Certificate Authorities for every host listed above. If you see an SSL: CERTIFICATE_VERIFY_FAILED error, the issue is almost always a TLS-inspecting proxy in front of your client or an outdated CA bundle on the host — not a problem with our certificates.
  4. Treat the signed URL as single-use. Do not cache or share the resolved CDN URL. Always request a fresh redirect from ipinfo.io/data/... when you need to download the file again. Signed URLs have a limited validity window and will eventually return 403.

Troubleshooting

Connection reset by peer or timeout immediately after the 302. Your firewall is allowing ipinfo.io but blocking the CDN host in the Location: header. Check whether dl.assets.ipinfo.io, dl.ipinfo.io, or storage.googleapis.com is being blocked. If dl.ipinfo.io is allowed but the connection still fails, it’s usually storage.googleapis.com being blocked upstream.

HTTP 401 on the redirect target. Your client is forwarding the Authorization header to the CDN. Either switch to a library that strips cross-host auth headers (such as Python requests), or configure your client to drop Authorization on redirect.

SSL: CERTIFICATE_VERIFY_FAILED. A TLS-intercepting proxy is in the path, or your host’s CA bundle is out of date. Verify by running the relevant commands below from the affected host:

openssl s_client -connect dl.assets.ipinfo.io:443 -servername dl.assets.ipinfo.io
openssl s_client -connect dl.ipinfo.io:443 -servername dl.ipinfo.io
openssl s_client -connect storage.googleapis.com:443 -servername storage.googleapis.com

If ipinfo.io completes the TLS handshake but one of the above fails with write:errno=104 and no peer certificate, that host is being blocked or intercepted by a firewall.

File downloads but is zero bytes or an HTML page. Your client is not following the redirect. Pass -L to curl, or verify that your library follows 302 responses.

HTTP 403 on the signed URL. The signed URL has expired. Re-request from https://ipinfo.io/data/<filename>?token=$TOKEN to obtain a fresh redirect.

Verifying the redirect manually

To inspect the current redirect target for any file you have access to:

curl -sI "https://ipinfo.io/data/<filename>?token=$TOKEN" | grep -i location

This returns the signed URL without downloading the file. It is useful for debugging firewall rules and confirming which CDN host your account is currently routed to.

See Also: