DEV Community: Vix

Detecting VPNs and proxies with IP data — what actually works

Vix — Wed, 29 Jul 2026 11:49:24 +0000

Detecting VPNs and proxies with IP data — what actually works

VPN and proxy detection comes up constantly in fraud prevention, content licensing, and abuse mitigation discussions, and it's one of the most oversold capabilities in the IP data space. This article covers what IP-based detection can actually tell you, what it can't, and how to build detection logic that doesn't waste effort chasing false confidence.

What "VPN detection" actually means

There's no definitive signal that says "this connection is a VPN." What exists is a set of indicators that correlate with VPN/proxy usage, each with real false-positive and false-negative rates. Good detection combines several of these signals and produces a confidence level, not a yes/no answer.

The indicators, roughly in order of reliability:

Known VPN/hosting provider ASNs — the IP belongs to an organization that's a VPN provider or a datacenter, not a residential/mobile ISP
Datacenter hosting ranges — even without VPN-specific labeling, an IP registered to AWS, DigitalOcean, OVH, etc. is not a home user
Behavioral signals — port scanning patterns, unusual request timing, shared IP with many simultaneous sessions
Commercial VPN detection databases — curated lists mapping known VPN exit nodes (these require paid subscriptions and go stale quickly as providers rotate IPs)

For most applications without a paid detection service, you're working primarily with #1 and #2 — ASN and organization data.

Building basic detection with ASN/ISP data

IPPubblico.org returns the ISP name and ASN for any IP, which is the foundation for this kind of check:

curl "https://ippubblico.org/?api=1"

{
  "status": "ok",
  "ip": "203.0.113.42",
  "isp": "NordVPN",
  "asn": "AS205016",
  "geo": { "country": "Netherlands", "country_code": "NL" }
}

import requests

KNOWN_VPN_KEYWORDS = [
    'vpn', 'nordvpn', 'expressvpn', 'surfshark', 'privateinternetaccess',
    'protonvpn', 'cyberghost', 'mullvad', 'tunnelbear', 'ipvanish',
    'windscribe', 'hidemyass', 'purevpn',
]

KNOWN_DATACENTER_KEYWORDS = [
    'amazon', 'aws', 'google cloud', 'microsoft azure', 'digitalocean',
    'ovh', 'hetzner', 'linode', 'vultr', 'scaleway', 'oracle cloud',
    'alibaba cloud', 'tencent cloud',
]

def check_ip_type(ip: str = None) -> dict:
    url = 'https://ippubblico.org/?api=1'
    if ip:
        url += f'&ip={ip}'

    data = requests.get(url, timeout=5).json()
    isp = data.get('isp', '').lower()

    is_known_vpn = any(kw in isp for kw in KNOWN_VPN_KEYWORDS)
    is_datacenter = any(kw in isp for kw in KNOWN_DATACENTER_KEYWORDS)

    return {
        'ip': data.get('ip'),
        'isp': data.get('isp'),
        'is_known_vpn_provider': is_known_vpn,
        'is_datacenter': is_datacenter,
        'confidence': 'high' if is_known_vpn else ('medium' if is_datacenter else 'low'),
    }

This catches the obvious cases — someone using a well-known commercial VPN service, or traffic originating from a cloud server rather than a residential connection. It will miss VPN providers using residential IP pools (a growing and deliberately harder-to-detect category) and won't catch anyone running their own VPN on a home connection.

What this approach cannot detect

Be explicit about the limitations, both to yourself and in any documentation for whoever uses this logic downstream:

Residential proxy networks — services that route traffic through real residential IPs (often via consent-based apps or, less legitimately, compromised devices) are specifically designed to look identical to genuine home users. ASN-based detection has no signal here at all; the ISP genuinely is a residential provider.

Self-hosted VPNs — someone running their own WireGuard/OpenVPN server on a rented VPS will show up as "datacenter IP" (medium confidence) but with no way to distinguish "this person runs a personal VPN" from "this person runs a legitimate cloud service that happens to make API calls."

New or small VPN providers — any keyword-matching list is only as good as its maintenance. New providers, white-label VPN services, and rebranded resellers won't match known keywords until someone updates the list.

Mobile carrier NAT — as covered in earlier articles, CGNAT means many genuine users share IPs with carrier infrastructure that can superficially resemble proxy-like shared-IP patterns.

A more complete detection function

Combining multiple signals into a single confidence score, rather than a binary flag:

import requests

def assess_connection_risk(ip: str = None) -> dict:
    url = 'https://ippubblico.org/?api=1'
    if ip:
        url += f'&ip={ip}'

    data = requests.get(url, timeout=5).json()
    isp = data.get('isp', '').lower()
    asn = data.get('asn', '')

    signals = []

    if any(kw in isp for kw in KNOWN_VPN_KEYWORDS):
        signals.append(('known_vpn_provider', 40))
    if any(kw in isp for kw in KNOWN_DATACENTER_KEYWORDS):
        signals.append(('datacenter_hosting', 25))
    if 'hosting' in isp or 'server' in isp or 'colo' in isp:
        signals.append(('generic_hosting_keyword', 15))

    risk_score = sum(weight for _, weight in signals)
    risk_score = min(risk_score, 100)

    return {
        'ip': data.get('ip'),
        'isp': data.get('isp'),
        'asn': asn,
        'signals_triggered': [name for name, _ in signals],
        'risk_score': risk_score,
        'recommendation': (
            'block' if risk_score >= 60 else
            'flag_for_review' if risk_score >= 25 else
            'allow'
        ),
    }

The scoring weights here are illustrative, not authoritative — calibrate them against your own false-positive tolerance. A payment fraud system might weight datacenter detection heavily; a content licensing check might only care about known commercial VPN providers.

Where this fits in a larger system

IP-based VPN/proxy detection should never be the sole gate for any consequential decision. Reasonable places to use it:

One signal among several in a fraud score, combined with account history, payment method verification, behavioral analysis
Soft friction, not hard blocking — an extra verification step (CAPTCHA, email confirmation) rather than an outright block
Logging and monitoring — flagging sessions for review without acting on them automatically
Rate limiting adjustments — datacenter/VPN traffic might reasonably get a stricter rate limit without being blocked outright

Where it becomes a problem: using ASN-based VPN detection as a hard, silent block for account creation, checkout, or content access. This guarantees false positives against legitimate VPN users (a large and growing population using VPNs for entirely mundane privacy reasons) and does nothing against the residential-proxy services actively built to evade exactly this kind of check.

Testing your own detection logic

Before deploying VPN detection logic, test it against IPs you know the ground truth for — connect through a VPN yourself and check what the API returns:

# Connect via VPN, then check what IPPubblico sees
curl "https://ippubblico.org/?api=1" | python3 -m json.tool

Compare the isp and asn fields against what you'd expect. This is also a good way to verify that your own detection keyword list actually matches real-world ISP name formatting, which varies more than you'd expect ("NordVPN S.A." vs "NORDVPN" vs "M247 Ltd (NordVPN)" are all things you might see for the same provider).

Quick reference

Signal	Reliability	Catches
Known VPN provider keyword match	High confidence, low coverage	Major commercial VPN services only
Datacenter/cloud ASN	Medium confidence	Any non-residential hosting, including legitimate use
Residential proxy networks	Not detectable via ASN	Nothing — indistinguishable from real residential
Self-hosted VPN on a VPS	Appears as generic datacenter	Cannot distinguish from other cloud traffic

Conclusion

ASN and ISP data from a service like IPPubblico gives you a real, useful signal for VPN/proxy detection — but it's a signal with clear and specific blind spots, not a definitive check. The organizations actively trying to evade detection (residential proxy networks in particular) are specifically engineered to defeat exactly this method. Use it as one input in a broader risk assessment, weight it honestly against its real false-positive and false-negative rates, and never let it alone make a hard blocking decision.

Full documentation: ippubblico.org/docs.html
Try it yourself: ippubblico.org

Built VPN detection into a production system? Curious what false-positive rate you settled for as acceptable.

Why "your IP says you're in the wrong place" isn't a bug

Vix — Fri, 24 Jul 2026 08:37:45 +0000

Why "your IP says you're in the wrong place" isn't a bug

If you've ever seen a website confidently tell a user they're in a country they've never visited, you've witnessed IP geolocation doing exactly what it's designed to do — making a statistical guess, not reporting a fact. This is one of the most misunderstood pieces of everyday internet infrastructure, and misunderstanding it leads to real product decisions that hurt real users. This article explains why "wrong" geolocation is usually not a bug, and what that means for how you build with it.

The core misconception

Most people (and a surprising number of developers) assume an IP address is tied to a location the way a phone number is tied to an area code — fixed, verifiable, looked up rather than inferred. It isn't.

An IP address is assigned to an organization — an ISP, a company, a hosting provider. Geolocation databases infer a probable physical location for that organization's infrastructure using registry records, routing data, and probabilistic modeling. There is no authoritative global database that maps "this exact IP → this exact building." There never has been, and there isn't likely to be one, because IP allocation was never designed with precise physical location in mind.

This means every "your location" you've ever seen online was always a best guess dressed up as a fact.

Why organizations route traffic through single points

The deeper reason geolocation looks "wrong" so often: modern internet infrastructure is built around centralizing traffic, not distributing it.

Mobile carriers route thousands of users through shared carrier-grade NAT gateways — a rural user's traffic might exit through a datacenter in the nearest major city, sometimes hundreds of kilometers away.

Enterprises and institutions frequently centralize all internet-bound traffic through one gateway, one datacenter, one region — regardless of where individual employees or devices physically sit. A user in one city might show up as being wherever their organization's network egress point happens to be.

Cloud providers don't represent users at all — traffic from AWS, Google Cloud, or Azure represents whatever server is making the request, which could be anywhere the provider has a datacenter.

VPNs are explicitly designed to make this happen on purpose.

None of these are edge cases. Combined, they represent a very large share of real-world internet traffic. "Wrong" geolocation isn't a rare failure — it's the expected outcome for a substantial fraction of any real user base.

Verifying this yourself

You can see exactly what a geolocation service infers for any IP, including the organizational data that explains why it might not match a physical user:

curl "https://ippubblico.org/?api=1"

{
  "status": "ok",
  "ip": "203.0.113.42",
  "isp": "Some Corporate Network",
  "asn": "AS64500",
  "geo": {
    "city": "Frankfurt",
    "country": "Germany",
    "country_code": "DE"
  }
}

The isp and asn fields are often more informative than the city/country fields — they tell you whose infrastructure you're actually looking at, which is frequently the real answer to "why does this look wrong."

What "accuracy" actually means in this context

Geolocation accuracy is usually reported as a percentage — "99% accurate at the country level," for example. This number describes how often the inferred location matches a ground truth dataset, typically built from ISP registration records. It does not mean 99% of real users will see correct results, because ground truth datasets skew toward stable residential and fixed-line connections — exactly the segment least likely to have the failure modes described above.

Mobile users, corporate users, VPN users, and cloud traffic are systematically underrepresented in the datasets used to measure accuracy, and systematically overrepresented in real-world complaints about geolocation being wrong. The reported accuracy number and the accuracy your users experience can be very different things, and the direction of that gap is predictable.

The practical implication for developers

This isn't an argument against using IP geolocation — it's an argument for using it the way it actually works, rather than the way it's often marketed.

import requests

def get_location_context(ip: str = None) -> dict:
    """
    Returns geolocation as a *hint*, not a fact.
    Callers should treat this as a default to offer, never a
    determination to enforce.
    """
    url = 'https://ippubblico.org/?api=1'
    if ip:
        url += f'&ip={ip}'

    data = requests.get(url, timeout=5).json()

    return {
        'suggested_country': data.get('geo', {}).get('country_code'),
        'confidence_flags': {
            'is_datacenter': _looks_like_datacenter(data.get('isp', '')),
            'is_mobile_carrier': _looks_like_mobile(data.get('isp', '')),
        }
    }

def _looks_like_datacenter(isp: str) -> bool:
    keywords = ['amazon', 'google', 'microsoft azure', 'digitalocean',
                'ovh', 'hetzner', 'linode', 'vultr']
    return any(k in isp.lower() for k in keywords)

def _looks_like_mobile(isp: str) -> bool:
    keywords = ['mobile', 'wireless', 'cellular', '4g', '5g', 'lte']
    return any(k in isp.lower() for k in keywords)

The confidence_flags pattern matters more than most tutorials suggest — knowing when not to trust a result is often more useful than the result itself.

A concrete example of getting this wrong

A common real-world failure: an e-commerce site uses IP geolocation to lock in a currency and won't let users change it, "for their protection." A business traveler, a student abroad, or simply someone on a VPN sees prices in the wrong currency and cannot check out. This isn't a rare bug report — it's one of the most common geolocation-related complaints across e-commerce support forums, precisely because the assumption "IP accurately reflects the shopper's location" fails constantly for exactly the population most likely to be shopping while traveling.

The fix is almost always the same: use geolocation to pre-select a sensible default, and always, always let the user override it. This single design choice eliminates the vast majority of geolocation-related user complaints without sacrificing the convenience geolocation provides for the (large) majority of users for whom it's correct.

When "wrong" geolocation is actually a useful signal

Sometimes the mismatch itself is the interesting data point, not an error to hide.

def flag_suspicious_mismatch(claimed_country: str, ip: str) -> bool:
    """
    Not a security decision by itself — a signal to combine
    with other factors (never block solely on this).
    """
    data = requests.get(f'https://ippubblico.org/?api=1&ip={ip}').json()
    detected = data.get('geo', {}).get('country_code')

    if detected and claimed_country and detected != claimed_country:
        # Could mean: VPN, traveling, proxy, or genuinely fraudulent —
        # geolocation alone can't tell you which
        return True
    return False

A mismatch between a user's stated location (billing address, account settings) and detected IP location is a legitimate fraud-detection signal — one input among many, never a standalone determination. Treating the mismatch itself as useful information, rather than as a failure of the geolocation service, reframes the entire problem correctly.

The honest summary

IP geolocation is a probabilistic inference over organizational network assignment data, not a location lookup. It's "wrong" — meaning it doesn't match the individual user's physical location — for a substantial, structurally predictable share of real traffic: mobile users, corporate networks, VPNs, and cloud/datacenter sources. This isn't a quality problem with any particular provider's database; it's inherent to what the technology is doing.

The fix isn't a more accurate database. It's building software that treats geolocation as a default suggestion rather than a fact to enforce, checks ASN/ISP data to flag likely-unreliable cases, and always gives users a way to correct it.

Full documentation: ippubblico.org/docs.html
Try it yourself: ippubblico.org

What's the most memorably wrong geolocation result you've seen in production? Always curious to hear the specific war stories.

Best free IP APIs: server-side vs client-side — they're not the same problem

Vix — Tue, 21 Jul 2026 16:26:38 +0000

Best free IP APIs: server-side vs client-side — they're not the same problem

"What's the best free IP API?" is actually two different questions depending on where you're calling it from. Server-side and client-side IP detection have different constraints, different failure modes, and often need different tools. This article breaks down the distinction and compares the free options for each.

Why the distinction matters

Server-side, you already have the client's IP — it arrived with the incoming request (req.socket.remoteAddress, $_SERVER['REMOTE_ADDR'], etc.). What you need is a service to look up geolocation data for that IP. You're making a server-to-server call, so CORS doesn't matter, but request volume, latency, and reliability under load do.

Client-side, the browser doesn't inherently know its own public IP — NAT means the browser only sees its local network address. You need a service that the browser itself can call and that returns the public-facing IP as seen from the internet. This means CORS support is mandatory, and you're now exposed to browser-specific issues: ad blockers, privacy extensions, and CSP restrictions can all interfere.

Using a client-side-only tool server-side (or vice versa) is a common source of confusing bugs.

Server-side: what actually matters

When calling from your backend, you care about:

Reliability under your production load — not just your dev testing
No CORS needed — but check the service doesn't rate-limit by requesting IP in a way that breaks under a shared server IP (multiple app instances behind the same egress IP can look like abuse)
Batch/bulk lookup support if you're processing logs or analytics after the fact
Response time — added latency here directly slows your API/page response

Comparison for server-side lookups

Service	Key required	Free limit	Notes
IPPubblico.org	No	Fair use, no hard cap	Good default, EU-hosted
ip-api.com	No (HTTP only)	45 req/min	No HTTPS on free tier — a real constraint server-side too
ipinfo.io	Yes	50k/month	Good accuracy, Asia-based servers
ipapi.co	No	1,000/day	Lower daily cap
freeipapi.com	No	60 req/min

# Server-side lookup — Python
import requests

def lookup_ip(ip: str) -> dict:
    r = requests.get(f'https://ippubblico.org/?api=1&ip={ip}', timeout=5)
    return r.json()

# Called with an IP you already have from the request
info = lookup_ip(request.remote_addr)

Server-side, caching matters more than the raw rate limit — most applications look up the same IPs repeatedly (returning visitors), so a simple in-memory or Redis cache eliminates most of the API calls anyway:

import requests
from functools import lru_cache

@lru_cache(maxsize=10000)
def lookup_ip_cached(ip: str) -> dict:
    r = requests.get(f'https://ippubblico.org/?api=1&ip={ip}', timeout=5)
    return r.json()

Client-side: what actually matters

When calling from the browser, you care about:

CORS headers — non-negotiable, the request will fail silently or with a console error otherwise
HTTPS only — calling an HTTP endpoint from an HTTPS page is blocked as mixed content
Response time as perceived by the user — this blocks or delays what the user sees
Ad blocker / privacy extension resilience — some IP detection services get blocklisted by ad blockers because they're associated with tracking; a lesser-known service may actually work more reliably here

Comparison for client-side lookups

Service	CORS	HTTPS free tier	Notes
IPPubblico.org	Yes	Yes	No key needed in browser code
ipify.org	Yes	Yes	IP only, no geo data
ip-api.com	No	No (paid only)	Cannot be used client-side on free tier at all
ipinfo.io	Yes	Yes	Requires exposing your token in client code — a real problem

The ipinfo.io case is worth calling out specifically: using a key-based service client-side means your API key is visible in the browser's network tab to anyone who opens dev tools. Anyone can copy it and use your quota. This is a structural reason to prefer no-key services for client-side calls specifically, independent of any other feature comparison.

// Client-side — safe because no key is exposed
async function getClientIP() {
  const res = await fetch('https://ippubblico.org/?api=1');
  return res.json();
}

// If you must use a key-based service client-side,
// proxy it through your own backend instead:
async function getClientIPViaProxy() {
  const res = await fetch('/api/geolocate'); // your own backend holds the key
  return res.json();
}

The plain-text case — mostly a server-side / script tool

Plain text endpoints (just the IP, no JSON) are primarily useful server-side, in scripts, and in embedded/IoT contexts — less so in browser JavaScript, where you'll want structured JSON to work with in code anyway.

# Perfect for shell scripts, DDNS updaters, CI/CD pipelines
curl https://ipv4.ippubblico.org/

// Less useful client-side — you'd still need to parse it
// and you get no geo data, so just use the JSON endpoint instead

A common mistake: detecting IP client-side when you don't need to

If your goal is server-side logic (fraud checks, access control, logging) but you're detecting the IP client-side and sending it to your backend — stop. The IP the browser reports as its own public IP should match what your server already sees on the incoming connection. There's no reason to make an extra client-side call for information your server already has for free, and doing so opens a spoofing vector: a malicious client can report a fake IP.

// Don't do this for security-relevant logic
const clientReportedIP = await getClientIP();
sendToServer({ ip: clientReportedIP }); // client can lie about this

// Do this instead — server already knows the real IP
// (from req.socket.remoteAddress or X-Forwarded-For)

Client-side IP detection is legitimate for UX purposes (showing "You appear to be in Germany, switch language?") — never for anything security- or billing-relevant.

Decision guide

Need IP/geo data server-side?
├── High volume, need caching → any key-less API + your own cache layer
├── Need bulk/batch lookups → check specific bulk endpoints (varies by provider)
└── Low-medium volume, simple → IPPubblico.org or similar, no key setup needed

Need IP/geo data client-side (browser)?
├── Security/billing-relevant? → Don't detect client-side, use server data instead
├── UX personalization only → IPPubblico.org, ipify.org (key-less, CORS-enabled)
└── Need a paid/key-based service? → Proxy through your backend, never expose the key

Quick reference

Use case	Recommended approach
Backend geolocation lookup	IPPubblico.org, cached in your app
Browser-side IP/geo detection	IPPubblico.org, ipify.org (no key exposure risk)
DDNS / embedded / scripts	Plain text endpoint (`ipv4.ippubblico.org`)
Security-relevant IP checks	Server's own connection data — never client-reported
Key-based service needed client-side	Proxy through your own backend

Full documentation: ippubblico.org/docs.html

Conclusion

"Best free IP API" depends entirely on where the call originates. Server-side, you're optimizing for reliability and caching. Client-side, CORS support and not exposing API keys are non-negotiable constraints that rule out several otherwise-good services. Getting this distinction right upfront avoids a class of bugs that only show up in production — CORS errors in the console, leaked API keys, or spoofable client-reported data feeding into logic that should never have trusted the client in the first place.

Have you hit a CORS or key-exposure issue with an IP API? Worth sharing as a cautionary tale in the comments.

Building a country-based redirect — the right way (and the wrong ways)

Vix — Sat, 18 Jul 2026 19:10:19 +0000

Building a country-based redirect — the right way (and the wrong ways)

Redirecting users based on their country is one of those features that seems trivial until you actually build it. Get it wrong and you'll trap users in the wrong locale, break back buttons, annoy people on VPNs, and tank your SEO. This article covers a working implementation, the common mistakes, and when you shouldn't redirect at all.

What "country-based redirect" usually means

A visitor lands on example.com, and based on their detected location, you either:

Redirect them to a localized subdomain/path (example.com → example.com/de)
Redirect them to a country-specific TLD (example.com → example.de)
Show a banner suggesting a redirect, without forcing it
Adjust content in place without any URL change (no redirect at all)

The last two options are usually the better choice, and we'll get to why. First, the mechanics.

Basic implementation

Using IPPubblico.org to detect the country server-side and redirect:

// Node.js / Express
app.get('/', async (req, res) => {
  const forwarded = req.headers['x-forwarded-for'];
  const clientIP  = forwarded ? forwarded.split(',')[0].trim() : req.socket.remoteAddress;

  try {
    const geoRes = await fetch(`https://ippubblico.org/?api=1`, {
      signal: AbortSignal.timeout(3000)
    });
    const data = await geoRes.json();
    const countryCode = data.geo?.country_code;

    const routes = { DE: '/de', FR: '/fr', JP: '/ja', BR: '/pt-br' };
    if (routes[countryCode] && req.path === '/') {
      return res.redirect(302, routes[countryCode]);
    }
  } catch {
    // Geolocation failed — fall through to default
  }

  res.redirect('/en');
});

# Flask
from flask import request, redirect
import requests

ROUTES = {'DE': '/de', 'FR': '/fr', 'JP': '/ja', 'BR': '/pt-br'}

@app.route('/')
def index():
    try:
        data = requests.get('https://ippubblico.org/?api=1', timeout=3).json()
        country = data.get('geo', {}).get('country_code')
        if country in ROUTES:
            return redirect(ROUTES[country], code=302)
    except requests.RequestException:
        pass
    return redirect('/en', code=302)

This works, but it's also the version most likely to cause problems. Let's go through why.

Mistake 1 — using a permanent (301) redirect

// Don't do this
res.redirect(301, routes[countryCode]);

A 301 tells browsers and search engines "this redirect is permanent, cache it forever." If your geolocation is ever wrong for a user — VPN, CGNAT, traveling — that user's browser will cache the wrong redirect and keep sending them to the wrong locale even after the underlying condition changes.

Use 302 (temporary redirect) for anything based on IP geolocation. It should never be permanent, because IP-to-location mapping isn't permanent either.

Mistake 2 — redirecting on every page, not just the homepage

// Don't do this — redirects on every route
app.use(async (req, res, next) => {
  const country = await detectCountry(req);
  if (shouldRedirect(country, req.path)) {
    return res.redirect(302, buildLocalizedPath(req.path, country));
  }
  next();
});

If you redirect based on geolocation on every request, you break deep links. Someone shares example.com/pricing, and every visitor gets redirected to their own locale's pricing page, even if they wanted to see the original page a specific person linked to.

Detect and redirect once, typically only from the root path, and respect whatever locale the user is already on for every other page.

Mistake 3 — no way to override

This is the most common complaint about geolocation redirects, and for good reason. A French user living in Japan, a VPN user, someone testing your site from a different country — all get stuck.

app.get('/', async (req, res) => {
  // Respect explicit user choice first
  const savedLocale = req.cookies.locale;
  if (savedLocale) {
    return res.redirect(302, `/${savedLocale}`);
  }

  // Only geolocate if there's no saved preference
  const country = await detectCountry(req);
  const locale  = LOCALE_MAP[country] ?? 'en';
  res.redirect(302, `/${locale}`);
});

app.get('/set-locale/:locale', (req, res) => {
  res.cookie('locale', req.params.locale, { maxAge: 365 * 24 * 60 * 60 * 1000 });
  res.redirect(req.query.return ?? '/');
});

Always provide a visible language/region switcher on every page, and always let a saved cookie override geolocation on subsequent visits.

Mistake 4 — redirecting VPN and cloud users incorrectly

VPN exit nodes and cloud provider IPs geolocate to wherever the server physically sits, not where the user is. Redirecting these users based on IP alone routes them somewhere unexpected.

const CLOUD_ASNS = new Set([
  'AS16509', // AWS
  'AS15169', // Google Cloud
  'AS8075',  // Azure
  'AS14061', // DigitalOcean
]);

async function shouldSkipRedirect(ip) {
  try {
    const data = await fetch(`https://ippubblico.org/?api=1`).then(r => r.json());
    return CLOUD_ASNS.has(data.asn);
  } catch {
    return true; // fail safe — skip redirect if detection fails
  }
}

If the ASN belongs to a known cloud/VPN provider, skip the automatic redirect and default to English (or your primary locale) instead.

Mistake 5 — hurting SEO with redirect chains

Search engine crawlers are typically routed through US or EU datacenter IPs. If your redirect logic sends Googlebot to /en every time regardless of what page it's crawling, you can end up with every URL on your site resolving to the same redirected page in search console — collapsing your site's indexed pages into one.

const BOT_USER_AGENTS = /googlebot|bingbot|yandex|baiduspider|duckduckbot/i;

app.get('/', async (req, res) => {
  if (BOT_USER_AGENTS.test(req.headers['user-agent'] ?? '')) {
    return next(); // let crawlers see the default page, don't redirect them
  }
  // ... normal redirect logic
});

Always exclude known crawler user agents from geolocation redirects. Let them index your canonical/default version, and use hreflang tags to tell search engines about your other language versions instead of redirect-based discovery.

A better alternative — suggest, don't force

For most sites, a non-intrusive banner beats a hard redirect:

function LocaleBanner() {
  const [suggestion, setSuggestion] = useState(null);

  useEffect(() => {
    if (document.cookie.includes('locale_dismissed=1')) return;

    fetch('https://ippubblico.org/?api=1')
      .then(res => res.json())
      .then(data => {
        const code = data.geo?.country_code;
        const suggested = LOCALE_MAP[code];
        const current = document.documentElement.lang;
        if (suggested && suggested !== current) {
          setSuggestion({ code, locale: suggested });
        }
      })
      .catch(() => {});
  }, []);

  if (!suggestion) return null;

  return (
    <div className="locale-banner">
      <p>{`Would you like to view this page in ${suggestion.locale}?`}</p>
      <a href={`/${suggestion.locale}`}>Yes, switch</a>
      <button onClick={() => {
        document.cookie = 'locale_dismissed=1; max-age=31536000';
        setSuggestion(null);
      }}>
        No, stay here
      </button>
    </div>
  );
}

This never breaks a shared link, never confuses a crawler, and respects a user's explicit choice permanently once dismissed.

When not to redirect at all

Single-language sites with regional pricing only — adjust price/currency display, don't change the URL or content structure
Documentation sites — deep links matter enormously here; a redirect that breaks a bookmarked doc page is actively harmful
API-first products — API consumers are developers, not casual browsers; geolocation-based redirects add friction with no benefit
Sites where SEO matters more than personalization — every redirect is a small SEO risk; if your primary traffic is organic search, weigh that against the personalization benefit

Quick reference

Approach	Use when
Hard redirect (302, cookie override, bot exclusion)	Multi-region product with genuinely different content per locale
Suggestion banner	Most content sites — safer default
No redirect, adjust content in place	Pricing/currency only, single-language UI
No geolocation at all	API products, documentation, anything link-sensitive

Conclusion

A country redirect done carelessly causes more problems than it solves — broken back buttons, cached wrong locales, confused VPN users, and collapsed SEO. Done carefully, with a 302, a cookie override, bot exclusion, and ASN-based cloud/VPN detection, it's a reasonable enhancement for genuinely multi-region products.

For most sites, a dismissible suggestion banner gets 80% of the benefit with a fraction of the risk.

Have you built (or been burned by) a country redirect? The comments are a good place for war stories.

Getting the public IP in PHP — no dependencies, no API key

Vix — Tue, 14 Jul 2026 09:46:36 +0000

Getting the public IP in PHP — no dependencies, no API key

PHP is still one of the most widely deployed server-side languages, running a significant share of the web's backend code. If you're building a PHP application that needs the public IP address — for geolocation, DDNS, diagnostics, or country detection — this article covers the common patterns using IPPubblico.org: free, no key, HTTPS, JSON and plain text endpoints.

Use case 1 — Your server's own public IP (one-liner)

The simplest case: a PHP script that needs to know its own public IP.

<?php
$ip = trim(file_get_contents('https://ipv4.ippubblico.org/'));
echo $ip; // 203.0.113.42

file_get_contents works if allow_url_fopen is enabled (it is by default on most servers). If not, use cURL (see below).

Use case 2 — With cURL (recommended for production)

file_get_contents has no timeout control and minimal error handling. For production code, cURL is better:

<?php
function getPublicIP(): ?string {
    $ch = curl_init('https://ipv4.ippubblico.org/');
    curl_setopt_array($ch, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_TIMEOUT        => 5,
        CURLOPT_FOLLOWLOCATION => true,
        CURLOPT_SSL_VERIFYPEER => true,
    ]);
    $response = curl_exec($ch);
    $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);

    if ($response === false || $httpCode !== 200) {
        return null;
    }
    return trim($response);
}

$ip = getPublicIP();
echo $ip ?? 'Unavailable';

Use case 3 — Full geolocation data

When you need country, city, ISP and timezone in addition to the IP:

<?php
function getIPInfo(?string $ip = null): ?array {
    $url = 'https://ippubblico.org/?api=1';
    if ($ip !== null) {
        $url .= '&ip=' . urlencode($ip);
    }

    $ch = curl_init($url);
    curl_setopt_array($ch, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_TIMEOUT        => 5,
        CURLOPT_SSL_VERIFYPEER => true,
    ]);
    $response = curl_exec($ch);
    $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);

    if ($response === false || $httpCode !== 200) {
        return null;
    }

    $data = json_decode($response, true);
    if (!$data || $data['status'] !== 'ok') {
        return null;
    }
    return $data;
}

$info = getIPInfo();
if ($info) {
    echo 'IP:       ' . $info['ip'] . PHP_EOL;
    echo 'Country:  ' . $info['geo']['country'] . PHP_EOL;
    echo 'City:     ' . $info['geo']['city'] . PHP_EOL;
    echo 'ISP:      ' . $info['isp'] . PHP_EOL;
    echo 'Timezone: ' . $info['timezone'] . PHP_EOL;
}

Use case 4 — Multilingual response

One of IPPubblico's distinct features: city, region and country names in the user's language. Add ?lang=XX:

<?php
function getIPInfoLocalized(string $lang = 'en'): ?array {
    $url = 'https://ippubblico.org/?api=1&lang=' . urlencode($lang);

    $ch = curl_init($url);
    curl_setopt_array($ch, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_TIMEOUT        => 5,
        CURLOPT_SSL_VERIFYPEER => true,
    ]);
    $response = curl_exec($ch);
    curl_close($ch);

    $data = json_decode($response, true);
    return ($data && $data['status'] === 'ok') ? $data : null;
}

// Japanese response
$info = getIPInfoLocalized('ja');
echo $info['geo']['country']; // 日本
echo $info['geo']['city'];    // 東京

// Portuguese response
$info = getIPInfoLocalized('pt');
echo $info['geo']['country']; // Japão
echo $info['geo']['city'];    // Tóquio

Supported localized languages: de, es, fr, ja, pt, ru, zh.

Use case 5 — Client IP geolocation in a web application

Detecting where your visitor is connecting from — the most common PHP web use case:

<?php
function getClientIP(): string {
    // Handle proxies and load balancers
    $headers = [
        'HTTP_CF_CONNECTING_IP',    // Cloudflare
        'HTTP_X_FORWARDED_FOR',     // Standard proxy header
        'HTTP_X_REAL_IP',           // Nginx
        'HTTP_X_FORWARDED',
        'REMOTE_ADDR',              // Direct connection fallback
    ];

    foreach ($headers as $header) {
        if (!empty($_SERVER[$header])) {
            $ip = trim(explode(',', $_SERVER[$header])[0]);
            if (filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
                return $ip;
            }
        }
    }
    return $_SERVER['REMOTE_ADDR'] ?? '0.0.0.0';
}

function getClientIPInfo(): ?array {
    $clientIP = getClientIP();
    return getIPInfo($clientIP);
}

// Usage in a web request
$info = getClientIPInfo();
$country = $info['geo']['country_code'] ?? 'US'; // fallback to US

Use case 6 — Country-based content in Laravel

A Laravel middleware that attaches country information to every request:

<?php
// app/Http/Middleware/DetectCountry.php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Cache;

class DetectCountry
{
    public function handle(Request $request, Closure $next)
    {
        $ip = $request->ip();

        // Cache by IP for 1 hour to avoid repeated API calls
        $countryCode = Cache::remember("country_{$ip}", 3600, function () use ($ip) {
            return $this->detectCountry($ip);
        });

        $request->attributes->set('country_code', $countryCode);

        return $next($request);
    }

    private function detectCountry(string $ip): string
    {
        $ch = curl_init("https://ippubblico.org/?api=1&ip=" . urlencode($ip));
        curl_setopt_array($ch, [
            CURLOPT_RETURNTRANSFER => true,
            CURLOPT_TIMEOUT        => 3,
            CURLOPT_SSL_VERIFYPEER => true,
        ]);
        $response = curl_exec($ch);
        curl_close($ch);

        $data = json_decode($response, true);
        return $data['geo']['country_code'] ?? 'US';
    }
}

protected $middlewareGroups = [
    'web' => [
        // ...
        \App\Http\Middleware\DetectCountry::class,
    ],
];

Use in any controller:

public function index(Request $request)
{
    $country = $request->attributes->get('country_code', 'US');

    return view('home', [
        'currency' => $this->getCurrencyForCountry($country),
        'country'  => $country,
    ]);
}

Use case 7 — WordPress plugin snippet

Detecting country in WordPress without a plugin or paid API:

<?php
function ipp_get_visitor_country(): string {
    $ip = $_SERVER['REMOTE_ADDR'] ?? '';

    // Check transient cache first (24 hours)
    $cacheKey = 'ipp_country_' . md5($ip);
    $cached    = get_transient($cacheKey);
    if ($cached !== false) {
        return $cached;
    }

    $response = wp_remote_get(
        'https://ippubblico.org/?api=1&ip=' . urlencode($ip),
        ['timeout' => 5, 'sslverify' => true]
    );

    if (is_wp_error($response)) {
        return 'US'; // fallback
    }

    $data = json_decode(wp_remote_retrieve_body($response), true);
    $country = $data['geo']['country_code'] ?? 'US';

    set_transient($cacheKey, $country, DAY_IN_SECONDS);
    return $country;
}

// Usage in any template
$country = ipp_get_visitor_country();
if ($country === 'IT') {
    echo '<p>Benvenuto! Visita il nostro negozio italiano.</p>';
}

Use case 8 — DDNS updater script (CLI)

A PHP CLI script that checks if the server's public IP changed and updates a Cloudflare DNS record:

<?php
// Run with: php ddns_updater.php

define('CF_API_TOKEN',  getenv('CF_API_TOKEN'));
define('CF_ZONE_ID',    getenv('CF_ZONE_ID'));
define('CF_RECORD_ID',  getenv('CF_RECORD_ID'));
define('RECORD_NAME',   'home.yourdomain.com');
define('CACHE_FILE',    '/tmp/ddns_last_ip.txt');

function getCurrentIP(): ?string {
    $ch = curl_init('https://ipv4.ippubblico.org/');
    curl_setopt_array($ch, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_TIMEOUT        => 10,
    ]);
    $ip = trim(curl_exec($ch));
    $ok = curl_getinfo($ch, CURLINFO_HTTP_CODE) === 200;
    curl_close($ch);
    return $ok ? $ip : null;
}

function getLastKnownIP(): ?string {
    return file_exists(CACHE_FILE) ? trim(file_get_contents(CACHE_FILE)) : null;
}

function updateCloudflare(string $ip): bool {
    $payload = json_encode([
        'type'    => 'A',
        'name'    => RECORD_NAME,
        'content' => $ip,
        'ttl'     => 60,
    ]);

    $ch = curl_init(sprintf(
        'https://api.cloudflare.com/client/v4/zones/%s/dns_records/%s',
        CF_ZONE_ID, CF_RECORD_ID
    ));
    curl_setopt_array($ch, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CUSTOMREQUEST  => 'PUT',
        CURLOPT_POSTFIELDS     => $payload,
        CURLOPT_HTTPHEADER     => [
            'Authorization: Bearer ' . CF_API_TOKEN,
            'Content-Type: application/json',
        ],
        CURLOPT_TIMEOUT        => 10,
    ]);
    $response = json_decode(curl_exec($ch), true);
    curl_close($ch);

    return $response['success'] ?? false;
}

// Main
$current = getCurrentIP();
if ($current === null) {
    echo '[ERROR] Failed to get public IP' . PHP_EOL;
    exit(1);
}

$last = getLastKnownIP();

if ($current === $last) {
    echo "[OK] IP unchanged: {$current}" . PHP_EOL;
    exit(0);
}

echo "[INFO] IP changed: {$last} → {$current}" . PHP_EOL;

if (updateCloudflare($current)) {
    file_put_contents(CACHE_FILE, $current);
    echo "[OK] DNS updated to {$current}" . PHP_EOL;
} else {
    echo '[ERROR] DNS update failed' . PHP_EOL;
    exit(1);
}

Add to cron:

*/5 * * * * /usr/bin/php /usr/local/bin/ddns_updater.php >> /var/log/ddns.log 2>&1

Handling rate limits

The API returns 429 Too Many Requests with a Retry-After header if the same IP sends too many requests in a short period:

<?php
function getPublicIPWithRetry(int $maxRetries = 2): ?string {
    for ($attempt = 0; $attempt <= $maxRetries; $attempt++) {
        $ch = curl_init('https://ipv4.ippubblico.org/');
        curl_setopt_array($ch, [
            CURLOPT_RETURNTRANSFER => true,
            CURLOPT_TIMEOUT        => 5,
            CURLOPT_HEADER         => true,
        ]);
        $response = curl_exec($ch);
        $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
        $headerSize = curl_getinfo($ch, CURLINFO_HEADER_SIZE);
        curl_close($ch);

        if ($httpCode === 200) {
            return trim(substr($response, $headerSize));
        }

        if ($httpCode === 429 && $attempt < $maxRetries) {
            $headers = substr($response, 0, $headerSize);
            preg_match('/Retry-After:\s*(\d+)/i', $headers, $matches);
            $wait = (int)($matches[1] ?? 10);
            sleep($wait);
            continue;
        }

        break;
    }
    return null;
}

Quick reference

Need	Endpoint	Response
IPv4 only	`https://ipv4.ippubblico.org/`	`203.0.113.42`
IPv6 only	`https://ipv6.ippubblico.org/`	`2001:db8::1` or `NONE`
Both protocols	`https://ippubblico.org/?text=1`	`IPv4: x\nIPv6: x`
Full geolocation	`https://ippubblico.org/?api=1`	JSON with country, city, ISP
Localized geo	`https://ippubblico.org/?api=1&lang=ja`	City/country in Japanese

Full documentation: ippubblico.org/docs.html
Code examples: github.com/ippubblico/examples

Conclusion

PHP's cURL extension covers every use case cleanly — plain text for scripts and DDNS tools, JSON for web applications, and all the caching and retry logic you need in a few dozen lines. The Laravel middleware and WordPress snippets are production-ready starting points that cache results correctly to avoid hitting the API on every request.

Using IPPubblico in a PHP project? Share your use case in the comments.

Why IP geolocation fails — and what to do about it

Vix — Fri, 03 Jul 2026 12:13:42 +0000

Why IP geolocation fails — and what to do about it

IP geolocation is one of those technologies that works well enough that people use it everywhere, and badly enough that it regularly causes real problems. If you've ever been locked out of a service because you were "in the wrong country," or seen a website serve you the wrong currency, or had a VPN break an app — you've experienced the failure modes firsthand.

This article explains why geolocation fails, when it fails most, and how to build software that handles those failures gracefully.

What IP geolocation actually does

Every IP address is assigned to an organization — an ISP, a company, a university, a cloud provider. That assignment is public record, documented in databases maintained by regional internet registries (ARIN, RIPE, APNIC, LACNIC, AFRINIC). Geolocation databases map those organizational assignments to physical locations using a combination of:

Registry data (where the organization is headquartered)
BGP routing data (where traffic for that IP originates)
Active probing and latency measurements
Commercial data purchases from ISPs

The result is an educated guess, not a lookup. The databases are updated periodically — MaxMind, for example, updates GeoLite2 twice per week — but IP assignments change faster than updates can track, and the underlying mapping is inherently approximate.

The five most common failure modes

1. VPNs and proxies

When a user connects through a VPN, the IP address you see is the VPN exit node — which might be in a completely different country from the user. This is by design from the user's perspective, but it means your geolocation data is wrong for that session.

VPN usage has grown substantially. Estimates vary, but surveys consistently show 25-30% of internet users use a VPN at least monthly. In some regions — particularly in countries with content restrictions — it's the majority of users.

What to do: if accurate location matters for your application, don't rely on IP alone. Use geolocation as a default, but let users override it. Never silently use IP geolocation for anything with legal or financial consequences.

2. Mobile carrier NAT

Mobile networks frequently use carrier-grade NAT (CGNAT), where thousands of users share a single public IP address. That shared IP may be located at a carrier data center in a different city or region from the actual users behind it.

A user in a rural area connecting through a mobile carrier might have their traffic exit at a major city hub, making them appear to be in that city.

What to do: for mobile users, IP geolocation accuracy drops significantly at the city level. Treat city-level data from mobile IPs as approximate at best.

3. Corporate networks and offices

Companies often route all employee internet traffic through a central gateway, sometimes in a different country from where the employee is actually working. Remote workers, in particular, frequently appear to be in the location of their company's headquarters or VPN server.

What to do: be especially cautious about IP geolocation for B2B applications where users are likely to be on corporate networks.

4. Cloud and datacenter IPs

Traffic originating from cloud providers (AWS, Google Cloud, Azure, Oracle) doesn't represent a user's location — it represents a data center location. If your application is being accessed by another application running in the cloud, the geolocation will reflect where that server is, not where the actual user or operator is.

import requests

def get_ip_info():
    r = requests.get('https://ippubblico.org/?api=1')
    data = r.json()
    return {
        'ip':  data['ip'],
        'isp': data['isp'],
        'asn': data['asn'],
    }

# Check if traffic is from a cloud provider
CLOUD_ASNS = {
    'AS16509',  # Amazon AWS
    'AS15169',  # Google Cloud
    'AS8075',   # Microsoft Azure
    'AS396982', # Google Cloud (secondary)
    'AS14061',  # DigitalOcean
    'AS20473',  # Vultr
}

info = get_ip_info()
is_cloud = info['asn'] in CLOUD_ASNS

What to do: check the ASN of incoming connections. If it belongs to a known cloud provider, treat the geolocation as unreliable and either skip geolocation-based logic or flag the request for additional verification.

5. Stale database entries

IP blocks get reassigned. A block that belonged to an ISP in Germany might be sold and reassigned to a company in Brazil. Database providers update their data, but there's always a lag — and during that lag, every request from those IPs returns wrong data.

This is particularly common with IPv6, where the geolocation databases are less complete and less frequently updated than IPv4.

What to do: for IPv6 addresses, treat geolocation data as less reliable than for IPv4. Design your application to degrade gracefully when geolocation data is missing or uncertain.

How to check what geolocation actually returns

Before building on top of geolocation data, test what your users actually see. IPPubblico.org returns the full geolocation data for the requesting IP with no setup:

curl "https://ippubblico.org/?api=1"

{
  "status": "ok",
  "ip": "203.0.113.42",
  "isp": "NTT Communications",
  "asn": "AS2914",
  "geo": {
    "city": "Tokyo",
    "region": "Tokyo",
    "country": "Japan",
    "country_code": "JP",
    "lat": 35.6893,
    "lon": 139.6899
  }
}

The asn and isp fields are particularly useful for detecting the failure modes above — a VPN, cloud provider, or CGNAT carrier shows up clearly in those fields even when the country/city data looks plausible.

Accuracy by use case

Use case	Accuracy	Notes
Country detection	~95%	Good for most users, breaks for VPN/corporate
Region/state	~75%	Acceptable for content personalization
City	~50-60%	Rough approximation, unreliable for mobile
Coordinates	Variable	Treat as center of city/region, not actual location
Street address	Not possible	Never attempt this with IP geolocation

These numbers are rough industry estimates — real accuracy depends heavily on your user base. A B2C consumer app will see higher accuracy than a B2B tool used by people on corporate networks.

Building geolocation-aware code that handles failures

Always provide a fallback

async function getUserCountry() {
  try {
    const res  = await fetch('https://ippubblico.org/?api=1', {
      signal: AbortSignal.timeout(3000)
    });
    const data = await res.json();
    return data.geo?.country_code ?? 'US'; // fallback to US
  } catch {
    return 'US'; // fallback on network error
  }
}

Let users override

function getEffectiveCountry(detectedCountry) {
  // Check if user has manually set their country
  const userOverride = localStorage.getItem('user_country');
  return userOverride ?? detectedCountry;
}

Use geolocation for defaults, not enforcement

// Good: use geolocation to pre-select a currency, but let users change it
const detectedCountry = await getUserCountry();
const defaultCurrency = CURRENCY_MAP[detectedCountry] ?? 'USD';

// Bad: block users based on geolocation alone
if (detectedCountry === 'XX') {
  throw new Error('Service not available in your country'); // Don't do this
}

Check ASN for cloud/VPN detection

import requests

def get_connection_type(ip=None):
    url = 'https://ippubblico.org/?api=1'
    if ip:
        url += f'&ip={ip}'

    data = requests.get(url, timeout=5).json()
    asn = data.get('asn', '')
    isp = data.get('isp', '').lower()

    # Known cloud/VPN indicators
    cloud_keywords = ['amazon', 'google', 'microsoft', 'digitalocean',
                      'vultr', 'linode', 'ovh', 'hetzner']
    vpn_keywords   = ['vpn', 'proxy', 'tunnel', 'nordvpn', 'expressvpn']

    is_cloud = any(kw in isp for kw in cloud_keywords)
    is_vpn   = any(kw in isp for kw in vpn_keywords)

    return {
        'country':   data['geo']['country_code'],
        'is_cloud':  is_cloud,
        'is_vpn':    is_vpn,
        'reliable':  not is_cloud and not is_vpn,
    }

What geolocation is good for

Despite the failure modes, IP geolocation is genuinely useful when used appropriately:

Default language/locale selection — reasonable default, easy to override
Content delivery optimization — CDN routing, selecting the nearest server
Fraud detection signals — one signal among many, not a definitive check
Analytics and traffic analysis — aggregate country-level data is reliable even if individual lookups sometimes aren't
Regulatory compliance logging — logging the detected country for audit purposes, while accepting that it may be wrong

What geolocation should never be used for alone

Access control or blocking — VPNs and CGNAT mean the "wrong" people will always get through, and the "right" people will sometimes get blocked
Legal jurisdiction determination — use user-provided and verified information instead
Payment fraud prevention — a signal, not a decision
Anything with permanent consequences — detected location can change on the next request

Conclusion

IP geolocation is a useful heuristic, not a reliable fact. The failure modes — VPNs, CGNAT, corporate gateways, cloud IPs, stale data — are common enough that any production system should be designed with them in mind from the start.

The practical rule: use geolocation for defaults and personalization, never for enforcement. Let users override it. Check ASN data to flag likely-unreliable cases. And test what your actual users see before making architectural decisions based on geolocation accuracy assumptions.

Have you run into a particularly bad geolocation failure in production? The comments are a good place to share war stories.

ipinfo.io vs IPPubblico.org — which free IP API should you use in 2026?

Vix — Tue, 30 Jun 2026 09:06:36 +0000

ipinfo.io vs IPPubblico.org — which free IP API should you use in 2026?

ipinfo.io is one of the most established IP geolocation services, with good data quality and a generous free tier. If you're evaluating it for a project, this article gives you a practical, technical comparison against IPPubblico.org — covering what each does well, where they differ, and which fits which use case.

The basics

	ipinfo.io	IPPubblico.org
API key required	Yes (free tier)	No
Free tier limit	50,000 req/month	No hard limit, fair use
HTTPS	Yes	Yes
Plain text endpoint	No	Yes
JSON endpoint	Yes	Yes
Multilingual response	No	Yes (43 languages, 7 fully localized)
Pricing beyond free tier	Paid plans from $99/mo	Free

API key — the core difference

ipinfo.io requires a token even on the free tier:

curl "https://ipinfo.io/8.8.8.8/json?token=YOUR_TOKEN"

{
  "ip": "8.8.8.8",
  "city": "Mountain View",
  "region": "California",
  "country": "US",
  "loc": "37.4056,-122.0775",
  "org": "AS15169 Google LLC",
  "timezone": "America/Los_Angeles"
}

This is fine for most backend applications — you register once, store the token in an environment variable, done. But it's a real constraint for:

Embedded devices and firmware — a key baked into deployed hardware can't be rotated easily, and if ipinfo.io invalidates it, every device in the field breaks
Quick scripts and prototypes — registering for a key adds friction when you just want to test something
Open source projects — shipping a default token in a public repo is a bad practice; asking every user to get their own key adds setup steps

IPPubblico has no key at all:

curl "https://ippubblico.org/?api=1"

{
  "status": "ok",
  "ip": "8.8.8.8",
  "isp": "Google LLC",
  "asn": "AS15169",
  "timezone": "America/Los_Angeles",
  "geo": {
    "city": "Mountain View",
    "region": "California",
    "country": "United States",
    "country_code": "US",
    "lat": 37.4056,
    "lon": -122.0775
  }
}

Same data, same depth, zero setup.

Rate limits

ipinfo.io's free tier: 50,000 requests/month, which works out to roughly 1,660/day or about one request every 52 seconds on average if spread evenly. In practice traffic isn't evenly spread, so bursts can hit the limit faster than the daily average suggests.

IPPubblico: no monthly cap, with a soft rate limit per IP (currently 10 seconds between requests) to keep the service stable. For a single application or device, this is effectively unlimited for normal use — DDNS updates, geolocation lookups, periodic checks all sit comfortably under that threshold.

If you're building something with unpredictable or bursty traffic and don't want to think about monthly quotas, this matters.

Data quality and depth

ipinfo.io is well known for accurate data, particularly around ASN and organization details, and offers additional paid datasets (privacy detection, carrier data, abuse contacts) that IPPubblico doesn't provide.

IPPubblico's data comes from MaxMind GeoLite2 — the same open dataset used by a large share of the free IP geolocation ecosystem. For city/country/ISP-level data, the two are comparable in accuracy for most use cases. If you specifically need VPN/proxy detection or carrier-level mobile data, ipinfo.io's paid tiers cover that; IPPubblico doesn't.

Multilingual responses — IPPubblico's distinct feature

This is the one capability the comparison isn't close on. IPPubblico returns city, region, and country names in the requester's language:

curl "https://ippubblico.org/?api=1&lang=ja"

{
  "geo": {
    "city": "東京",
    "region": "東京都",
    "country": "日本"
  }
}

Localized data is available for German, Spanish, French, Japanese, Portuguese, Russian, and Chinese — all interface languages (43 total) work for the website, but geo-field localization is currently limited to those seven. ipinfo.io always returns English regardless of any language parameter, because it doesn't have one.

For applications with non-English-speaking users where you want to display "Tokyo, Japan" as "東京、日本" without maintaining your own translation table, this removes a real chunk of work.

Plain text endpoint

ipinfo.io's API is JSON-first; getting just the IP without parsing requires hitting ipinfo.io/ip:

curl "https://ipinfo.io/ip?token=YOUR_TOKEN"
# 203.0.113.42

This works but still requires a token. IPPubblico has dedicated subdomains for this exact case, no key needed:

curl https://ipv4.ippubblico.org/
# 203.0.113.42

curl https://ipv6.ippubblico.org/
# 2001:db8::1  (or NONE if unavailable)

For embedded firmware parsing a one-line response with minimal memory, this is a meaningfully simpler integration — no JSON parser needed at all.

Code comparison — Python

ipinfo.io:

import requests

TOKEN = 'your_token_here'

def get_ip_info():
    r = requests.get(f'https://ipinfo.io/json?token={TOKEN}')
    return r.json()

info = get_ip_info()
print(info['city'], info['country'])

IPPubblico:

import requests

def get_ip_info():
    r = requests.get('https://ippubblico.org/?api=1')
    return r.json()

info = get_ip_info()
print(info['geo']['city'], info['geo']['country'])

Nearly identical, minus the token management.

When ipinfo.io is the better choice

You need VPN/proxy/abuse detection — IPPubblico doesn't offer this
You need carrier-level mobile network data
You're already paying for a higher tier and need SLA guarantees
Your traffic genuinely exceeds what a free, key-less service should reasonably handle, and you want a commercial relationship with uptime commitments

When IPPubblico is the better choice

You're building IoT/embedded firmware where API key management is impractical
You want zero setup for a prototype or internal tool
You need localized geo names for a non-English-speaking user base
You don't want to track or worry about a monthly request quota
You want a plain text endpoint with no parsing overhead

Quick reference

Need	Best choice
VPN/proxy detection	ipinfo.io
No API key, zero setup	IPPubblico.org
Embedded/IoT firmware	IPPubblico.org
Localized language responses	IPPubblico.org
Carrier/mobile network data	ipinfo.io
Plain text IP only	IPPubblico.org
Enterprise SLA	ipinfo.io

Full IPPubblico documentation: ippubblico.org/docs.html
Code examples (ESP32, Raspberry Pi, OpenWRT, Python, Node.js, Go): github.com/ippubblico/examples

Which one are you using in production? Curious to hear real-world experiences with either.

Getting the public IP in Go — no dependencies, no API key

Vix — Mon, 29 Jun 2026 03:05:03 +0000

Getting the public IP in Go — no dependencies, no API key

Go's standard library is famously self-contained, and IP detection is a case where that pays off directly. Everything in this article uses only the standard library plus one optional third-party HTTP client — no SDK, no configuration file, no API key required. The API is IPPubblico.org: free, HTTPS, plain text and JSON endpoints, no authentication.

Use case 1 — Your server's own public IP (one-liner)

The simplest case: a Go program or script that needs to know its own public IP.

package main

import (
    "fmt"
    "io"
    "net/http"
    "strings"
    "time"
)

func getPublicIP() (string, error) {
    client := &http.Client{Timeout: 10 * time.Second}
    resp, err := client.Get("https://ipv4.ippubblico.org/")
    if err != nil {
        return "", err
    }
    defer resp.Body.Close()
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return "", err
    }
    return strings.TrimSpace(string(body)), nil
}

func main() {
    ip, err := getPublicIP()
    if err != nil {
        fmt.Printf("Error: %v\n", err)
        return
    }
    fmt.Printf("Public IP: %s\n", ip) // Public IP: 203.0.113.42
}

No imports beyond the standard library. The Timeout on the HTTP client prevents the program from hanging indefinitely if the network is unavailable.

Use case 2 — Full geolocation data

When you need country, city, ISP and ASN in addition to the IP address:

package main

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "time"
)

type GeoData struct {
    Country     string  `json:"country"`
    CountryCode string  `json:"country_code"`
    City        string  `json:"city"`
    Region      string  `json:"region"`
    Lat         float64 `json:"lat"`
    Lon         float64 `json:"lon"`
}

type IPInfo struct {
    Status   string  `json:"status"`
    IP       string  `json:"ip"`
    IPv4     string  `json:"ipv4"`
    IPv6     *string `json:"ipv6"`
    ISP      string  `json:"isp"`
    ASN      string  `json:"asn"`
    Timezone string  `json:"timezone"`
    Geo      GeoData `json:"geo"`
}

func getIPInfo() (*IPInfo, error) {
    client := &http.Client{Timeout: 10 * time.Second}
    resp, err := client.Get("https://ippubblico.org/?api=1")
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, err
    }

    var info IPInfo
    if err := json.Unmarshal(body, &info); err != nil {
        return nil, err
    }
    if info.Status != "ok" {
        return nil, fmt.Errorf("API returned status: %s", info.Status)
    }
    return &info, nil
}

func main() {
    info, err := getIPInfo()
    if err != nil {
        fmt.Printf("Error: %v\n", err)
        return
    }
    fmt.Printf("IP:       %s\n", info.IP)
    fmt.Printf("Country:  %s (%s)\n", info.Geo.Country, info.Geo.CountryCode)
    fmt.Printf("City:     %s, %s\n", info.Geo.City, info.Geo.Region)
    fmt.Printf("ISP:      %s\n", info.ISP)
    fmt.Printf("Timezone: %s\n", info.Timezone)
}

Use case 3 — Reusable client with caching

In a real application you rarely want to call the API on every request. This client caches the result for a configurable duration:

package ipdetect

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "sync"
    "time"
)

type Client struct {
    httpClient *http.Client
    cacheTTL   time.Duration

    mu        sync.Mutex
    cached    *IPInfo
    cachedAt  time.Time
}

type IPInfo struct {
    IP      string `json:"ip"`
    Country string `json:"country"`
    City    string `json:"city"`
    ISP     string `json:"isp"`
    ASN     string `json:"asn"`
}

func NewClient(cacheTTL time.Duration) *Client {
    return &Client{
        httpClient: &http.Client{Timeout: 10 * time.Second},
        cacheTTL:   cacheTTL,
    }
}

func (c *Client) Get() (*IPInfo, error) {
    c.mu.Lock()
    defer c.mu.Unlock()

    if c.cached != nil && time.Since(c.cachedAt) < c.cacheTTL {
        return c.cached, nil
    }

    resp, err := c.httpClient.Get("https://ippubblico.org/?api=1")
    if err != nil {
        return nil, fmt.Errorf("request failed: %w", err)
    }
    defer resp.Body.Close()

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, fmt.Errorf("read body: %w", err)
    }

    var raw struct {
        Status string  `json:"status"`
        IP     string  `json:"ip"`
        ISP    string  `json:"isp"`
        ASN    string  `json:"asn"`
        Geo    struct {
            Country string `json:"country"`
            City    string `json:"city"`
        } `json:"geo"`
    }
    if err := json.Unmarshal(body, &raw); err != nil {
        return nil, fmt.Errorf("parse JSON: %w", err)
    }

    info := &IPInfo{
        IP:      raw.IP,
        ISP:     raw.ISP,
        ASN:     raw.ASN,
        Country: raw.Geo.Country,
        City:    raw.Geo.City,
    }
    c.cached = info
    c.cachedAt = time.Now()
    return info, nil
}

Usage:

client := ipdetect.NewClient(1 * time.Hour)

info, err := client.Get() // calls API
info, err  = client.Get() // returns cached result

Use case 4 — DDNS updater

A production-ready DDNS updater that detects IP changes and updates a Cloudflare DNS record:

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "log"
    "net/http"
    "os"
    "strings"
    "time"
)

const (
    cfAPIToken  = "your_cloudflare_api_token"
    cfZoneID    = "your_zone_id"
    cfRecordID  = "your_record_id"
    recordName  = "home.yourdomain.com"
    cacheFile   = "/tmp/ddns_last_ip.txt"
    checkEvery  = 5 * time.Minute
)

var httpClient = &http.Client{Timeout: 10 * time.Second}

func getPublicIP() (string, error) {
    resp, err := httpClient.Get("https://ipv4.ippubblico.org/")
    if err != nil {
        return "", err
    }
    defer resp.Body.Close()
    body, _ := io.ReadAll(resp.Body)
    return strings.TrimSpace(string(body)), nil
}

func getLastKnownIP() string {
    data, err := os.ReadFile(cacheFile)
    if err != nil {
        return ""
    }
    return strings.TrimSpace(string(data))
}

func saveIP(ip string) {
    os.WriteFile(cacheFile, []byte(ip), 0644)
}

func updateCloudflare(ip string) error {
    url := fmt.Sprintf(
        "https://api.cloudflare.com/client/v4/zones/%s/dns_records/%s",
        cfZoneID, cfRecordID,
    )
    payload := map[string]interface{}{
        "type":    "A",
        "name":    recordName,
        "content": ip,
        "ttl":     60,
    }
    body, _ := json.Marshal(payload)

    req, _ := http.NewRequest("PUT", url, bytes.NewReader(body))
    req.Header.Set("Authorization", "Bearer "+cfAPIToken)
    req.Header.Set("Content-Type", "application/json")

    resp, err := httpClient.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()

    var result map[string]interface{}
    json.NewDecoder(resp.Body).Decode(&result)
    if result["success"] != true {
        return fmt.Errorf("cloudflare error: %v", result["errors"])
    }
    return nil
}

func checkAndUpdate() {
    current, err := getPublicIP()
    if err != nil {
        log.Printf("Failed to get IP: %v", err)
        return
    }

    last := getLastKnownIP()
    if current == last {
        log.Printf("IP unchanged: %s", current)
        return
    }

    log.Printf("IP changed: %s → %s", last, current)
    if err := updateCloudflare(current); err != nil {
        log.Printf("DNS update failed: %v", err)
        return
    }
    saveIP(current)
    log.Printf("DNS updated to %s", current)
}

func main() {
    log.Println("DDNS updater started")
    checkAndUpdate()
    for range time.Tick(checkEvery) {
        checkAndUpdate()
    }
}

Build as a single static binary — no runtime dependencies:

go build -o ddns_updater .
# or cross-compile for Linux ARM (e.g. Raspberry Pi)
GOOS=linux GOARCH=arm64 go build -o ddns_updater_arm64 .

Use case 5 — HTTP middleware for Gin

Detect the client's country and attach it to the Gin context for use in any handler:

package middleware

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "strings"
    "sync"
    "time"

    "github.com/gin-gonic/gin"
)

var (
    geoCache   = make(map[string]string)
    geoCacheMu sync.RWMutex
    httpClient = &http.Client{Timeout: 3 * time.Second}
)

func getCountry(ip string) string {
    geoCacheMu.RLock()
    if c, ok := geoCache[ip]; ok {
        geoCacheMu.RUnlock()
        return c
    }
    geoCacheMu.RUnlock()

    resp, err := httpClient.Get("https://ippubblico.org/?api=1")
    if err != nil {
        return ""
    }
    defer resp.Body.Close()
    body, _ := io.ReadAll(resp.Body)

    var data struct {
        Geo struct {
            CountryCode string `json:"country_code"`
        } `json:"geo"`
    }
    json.Unmarshal(body, &data)

    geoCacheMu.Lock()
    geoCache[ip] = data.Geo.CountryCode
    geoCacheMu.Unlock()

    return data.Geo.CountryCode
}

func GeoMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        ip := c.ClientIP()
        country := getCountry(ip)
        c.Set("country_code", country)
        c.Next()
    }
}

Usage in any Gin handler:

r := gin.Default()
r.Use(middleware.GeoMiddleware())

r.GET("/content", func(c *gin.Context) {
    country, _ := c.Get("country_code")
    c.JSON(200, gin.H{
        "country": country,
        "content": "Hello from " + fmt.Sprint(country),
    })
})

Use case 6 — IPv4 and IPv6 detection

package main

import (
    "bufio"
    "fmt"
    "net/http"
    "strings"
    "time"
)

type DualStackIP struct {
    IPv4 string
    IPv6 string
}

func getBothIPs() (*DualStackIP, error) {
    client := &http.Client{Timeout: 10 * time.Second}
    resp, err := client.Get("https://ippubblico.org/?text=1")
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    result := &DualStackIP{}
    scanner := bufio.NewScanner(resp.Body)
    for scanner.Scan() {
        line := scanner.Text()
        if strings.HasPrefix(line, "IPv4: ") {
            v := strings.TrimPrefix(line, "IPv4: ")
            if v != "NONE" {
                result.IPv4 = v
            }
        } else if strings.HasPrefix(line, "IPv6: ") {
            v := strings.TrimPrefix(line, "IPv6: ")
            if v != "NONE" {
                result.IPv6 = v
            }
        }
    }
    return result, scanner.Err()
}

func main() {
    ips, err := getBothIPs()
    if err != nil {
        fmt.Printf("Error: %v\n", err)
        return
    }
    fmt.Printf("IPv4: %s\n", ips.IPv4) // IPv4: 203.0.113.42
    fmt.Printf("IPv6: %s\n", ips.IPv6) // IPv6:  (empty if unavailable)
}

Handling rate limits

The API returns 429 Too Many Requests with a Retry-After header if the same IP sends requests too frequently. A robust wrapper with retry logic:

func getPublicIPWithRetry(maxRetries int) (string, error) {
    client := &http.Client{Timeout: 10 * time.Second}

    for attempt := 0; attempt <= maxRetries; attempt++ {
        resp, err := client.Get("https://ipv4.ippubblico.org/")
        if err != nil {
            return "", err
        }

        if resp.StatusCode == http.StatusTooManyRequests {
            retryAfter := resp.Header.Get("Retry-After")
            wait := 20 * time.Second
            if secs, err := time.ParseDuration(retryAfter + "s"); err == nil {
                wait = secs
            }
            resp.Body.Close()
            if attempt < maxRetries {
                time.Sleep(wait)
                continue
            }
            return "", fmt.Errorf("rate limited after %d attempts", maxRetries)
        }

        body, err := io.ReadAll(resp.Body)
        resp.Body.Close()
        if err != nil {
            return "", err
        }
        return strings.TrimSpace(string(body)), nil
    }
    return "", fmt.Errorf("max retries exceeded")
}

Quick reference

Need	Endpoint	Response
IPv4 only	`https://ipv4.ippubblico.org/`	`203.0.113.42`
IPv6 only	`https://ipv6.ippubblico.org/`	`2001:db8::1` or `NONE`
Both protocols	`https://ippubblico.org/?text=1`	`IPv4: x\nIPv6: x`
Full geolocation	`https://ippubblico.org/?api=1`	JSON with country, city, ISP

Full API documentation: ippubblico.org/docs.html

Conclusion

Go's standard library handles all the HTTP and JSON work cleanly — the code you write for IP detection in Go is shorter and more explicit than most other languages, with no hidden magic. The DDNS updater compiles to a single static binary that you can drop on any Linux server or embedded device without installing a runtime.

The caching client and Gin middleware patterns shown here are production-ready starting points — they handle concurrent access correctly with sync.RWMutex and fail gracefully when the API is unavailable.

Building something with Go and IPPubblico? Share your use case in the comments.

How to build a DDNS updater with no API key

Vix — Wed, 24 Jun 2026 14:05:51 +0000

How to build a DDNS updater with no API key

Dynamic DNS (DDNS) is one of those problems that sounds simple — keep a DNS record pointing at your current IP — but tends to involve more moving parts than expected. Most solutions require creating an account, generating an API key, and depending on a third-party service to detect your own IP address. This article shows how to build a complete DDNS updater that detects your public IP without any API key, using IPPubblico.org as the IP detection layer.

The DDNS update step (writing to your DNS provider) still requires your DNS provider's credentials, but the IP detection part — which is what breaks or goes stale most often — is completely key-free.

How DDNS updaters work

The basic loop is always the same:

Get your current public IP address
Compare it to the last known IP (stored locally or retrieved from DNS)
If it changed, update the DNS record
Wait and repeat

The IP detection step (step 1) is where most updaters introduce unnecessary dependencies. Many use ip-api.com, ipify.org, or similar services that require rate limit management, API keys for higher tiers, or have unreliable uptime. IPPubblico returns a plain text response with no authentication overhead — ideal for scripts that run every few minutes.

Shell script (Linux / OpenWRT / router firmware)

The most portable version. Runs on any system with curl and a cron daemon — including OpenWRT routers, NAS devices, and embedded Linux boards.

#!/bin/sh
# ddns_updater.sh
# Detects public IP change and updates a Cloudflare DNS record

# --- Configuration ---
CF_API_TOKEN="your_cloudflare_api_token"
CF_ZONE_ID="your_zone_id"
CF_RECORD_ID="your_record_id"
CF_RECORD_NAME="home.yourdomain.com"
IP_CACHE_FILE="/tmp/ddns_last_ip.txt"
LOG_FILE="/var/log/ddns_updater.log"

# --- Functions ---
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOG_FILE"
}

get_public_ip() {
    curl -s --max-time 10 https://ipv4.ippubblico.org/
}

update_cloudflare() {
    local NEW_IP="$1"
    curl -s -X PUT \
        "https://api.cloudflare.com/client/v4/zones/${CF_ZONE_ID}/dns_records/${CF_RECORD_ID}" \
        -H "Authorization: Bearer ${CF_API_TOKEN}" \
        -H "Content-Type: application/json" \
        --data "{\"type\":\"A\",\"name\":\"${CF_RECORD_NAME}\",\"content\":\"${NEW_IP}\",\"ttl\":60}"
}

# --- Main ---
CURRENT_IP=$(get_public_ip)

if [ -z "$CURRENT_IP" ]; then
    log "ERROR: Failed to get public IP"
    exit 1
fi

LAST_IP=""
if [ -f "$IP_CACHE_FILE" ]; then
    LAST_IP=$(cat "$IP_CACHE_FILE")
fi

if [ "$CURRENT_IP" = "$LAST_IP" ]; then
    log "IP unchanged: $CURRENT_IP"
    exit 0
fi

log "IP changed: $LAST_IP -> $CURRENT_IP. Updating DNS..."

RESULT=$(update_cloudflare "$CURRENT_IP")

if echo "$RESULT" | grep -q '"success":true'; then
    echo "$CURRENT_IP" > "$IP_CACHE_FILE"
    log "DNS updated successfully to $CURRENT_IP"
else
    log "ERROR: DNS update failed. Response: $RESULT"
    exit 1
fi

Add to cron (runs every 5 minutes):

*/5 * * * * /usr/local/bin/ddns_updater.sh

Python (cross-platform)

A more robust version with proper error handling, structured logging, and support for multiple DNS providers.

#!/usr/bin/env python3
# ddns_updater.py

import requests
import json
import logging
import time
from pathlib import Path
from dataclasses import dataclass
from typing import Optional

# --- Configuration ---
CLOUDFLARE_API_TOKEN = "your_cloudflare_api_token"
CLOUDFLARE_ZONE_ID   = "your_zone_id"
CLOUDFLARE_RECORD_ID = "your_record_id"
RECORD_NAME          = "home.yourdomain.com"
CACHE_FILE           = Path("/tmp/ddns_last_ip.txt")
CHECK_INTERVAL       = 300  # seconds

logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s %(levelname)s %(message)s',
    handlers=[
        logging.FileHandler('/var/log/ddns_updater.log'),
        logging.StreamHandler()
    ]
)
log = logging.getLogger(__name__)


def get_public_ip() -> Optional[str]:
    """Get current public IPv4 address — no API key required."""
    try:
        res = requests.get('https://ipv4.ippubblico.org/', timeout=10)
        res.raise_for_status()
        return res.text.strip()
    except requests.RequestException as e:
        log.error(f"Failed to get public IP: {e}")
        return None


def get_cached_ip() -> Optional[str]:
    try:
        return CACHE_FILE.read_text().strip()
    except FileNotFoundError:
        return None


def save_ip(ip: str) -> None:
    CACHE_FILE.write_text(ip)


def update_cloudflare(new_ip: str) -> bool:
    """Update an A record on Cloudflare."""
    url = f"https://api.cloudflare.com/client/v4/zones/{CLOUDFLARE_ZONE_ID}/dns_records/{CLOUDFLARE_RECORD_ID}"
    headers = {
        "Authorization": f"Bearer {CLOUDFLARE_API_TOKEN}",
        "Content-Type": "application/json",
    }
    payload = {
        "type": "A",
        "name": RECORD_NAME,
        "content": new_ip,
        "ttl": 60,
    }
    try:
        res = requests.put(url, headers=headers, json=payload, timeout=10)
        data = res.json()
        if data.get("success"):
            return True
        log.error(f"Cloudflare API error: {data.get('errors')}")
        return False
    except requests.RequestException as e:
        log.error(f"Cloudflare request failed: {e}")
        return False


def check_and_update() -> None:
    current_ip = get_public_ip()
    if not current_ip:
        return

    last_ip = get_cached_ip()

    if current_ip == last_ip:
        log.info(f"IP unchanged: {current_ip}")
        return

    log.info(f"IP changed: {last_ip or 'unknown'} → {current_ip}")

    if update_cloudflare(current_ip):
        save_ip(current_ip)
        log.info(f"DNS updated successfully to {current_ip}")
    else:
        log.error("DNS update failed")


if __name__ == "__main__":
    log.info("DDNS updater started")
    while True:
        check_and_update()
        time.sleep(CHECK_INTERVAL)

Run as a systemd service:

[Unit]
Description=DDNS Updater
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/python3 /usr/local/bin/ddns_updater.py
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target

Node.js

// ddns_updater.js — requires Node 18+
import fs   from 'fs/promises';
import path from 'path';

const CF_API_TOKEN  = 'your_cloudflare_api_token';
const CF_ZONE_ID    = 'your_zone_id';
const CF_RECORD_ID  = 'your_record_id';
const RECORD_NAME   = 'home.yourdomain.com';
const CACHE_FILE    = '/tmp/ddns_last_ip.txt';
const INTERVAL_MS   = 5 * 60 * 1000;

async function getPublicIP() {
  const res = await fetch('https://ipv4.ippubblico.org/', {
    signal: AbortSignal.timeout(10000)
  });
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return (await res.text()).trim();
}

async function getCachedIP() {
  try { return (await fs.readFile(CACHE_FILE, 'utf-8')).trim(); }
  catch { return null; }
}

async function updateCloudflare(ip) {
  const res = await fetch(
    `https://api.cloudflare.com/client/v4/zones/${CF_ZONE_ID}/dns_records/${CF_RECORD_ID}`,
    {
      method: 'PUT',
      headers: {
        'Authorization': `Bearer ${CF_API_TOKEN}`,
        'Content-Type':  'application/json',
      },
      body: JSON.stringify({ type: 'A', name: RECORD_NAME, content: ip, ttl: 60 }),
      signal: AbortSignal.timeout(10000),
    }
  );
  const data = await res.json();
  return data.success === true;
}

async function check() {
  try {
    const current = await getPublicIP();
    const last    = await getCachedIP();

    if (current === last) {
      console.log(`[${new Date().toISOString()}] IP unchanged: ${current}`);
      return;
    }

    console.log(`[${new Date().toISOString()}] IP changed: ${last ?? 'unknown'} → ${current}`);

    if (await updateCloudflare(current)) {
      await fs.writeFile(CACHE_FILE, current, 'utf-8');
      console.log(`[${new Date().toISOString()}] DNS updated to ${current}`);
    } else {
      console.error('DNS update failed');
    }
  } catch (err) {
    console.error('Error:', err.message);
  }
}

check();
setInterval(check, INTERVAL_MS);

Go

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "log"
    "net/http"
    "os"
    "strings"
    "time"
)

const (
    cfAPIToken  = "your_cloudflare_api_token"
    cfZoneID    = "your_zone_id"
    cfRecordID  = "your_record_id"
    recordName  = "home.yourdomain.com"
    cacheFile   = "/tmp/ddns_last_ip.txt"
    checkInterval = 5 * time.Minute
)

func getPublicIP() (string, error) {
    client := &http.Client{Timeout: 10 * time.Second}
    resp, err := client.Get("https://ipv4.ippubblico.org/")
    if err != nil {
        return "", err
    }
    defer resp.Body.Close()
    body, _ := io.ReadAll(resp.Body)
    return strings.TrimSpace(string(body)), nil
}

func getCachedIP() string {
    data, err := os.ReadFile(cacheFile)
    if err != nil {
        return ""
    }
    return strings.TrimSpace(string(data))
}

func updateCloudflare(ip string) error {
    url := fmt.Sprintf(
        "https://api.cloudflare.com/client/v4/zones/%s/dns_records/%s",
        cfZoneID, cfRecordID,
    )
    payload := map[string]interface{}{
        "type":    "A",
        "name":    recordName,
        "content": ip,
        "ttl":     60,
    }
    body, _ := json.Marshal(payload)

    req, _ := http.NewRequest("PUT", url, bytes.NewReader(body))
    req.Header.Set("Authorization", "Bearer "+cfAPIToken)
    req.Header.Set("Content-Type", "application/json")

    client := &http.Client{Timeout: 10 * time.Second}
    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()

    var result map[string]interface{}
    json.NewDecoder(resp.Body).Decode(&result)
    if result["success"] != true {
        return fmt.Errorf("cloudflare error: %v", result["errors"])
    }
    return nil
}

func checkAndUpdate() {
    current, err := getPublicIP()
    if err != nil {
        log.Printf("Failed to get IP: %v", err)
        return
    }

    last := getCachedIP()
    if current == last {
        log.Printf("IP unchanged: %s", current)
        return
    }

    log.Printf("IP changed: %s → %s", last, current)

    if err := updateCloudflare(current); err != nil {
        log.Printf("DNS update failed: %v", err)
        return
    }

    os.WriteFile(cacheFile, []byte(current), 0644)
    log.Printf("DNS updated to %s", current)
}

func main() {
    log.Println("DDNS updater started")
    checkAndUpdate()
    for range time.Tick(checkInterval) {
        checkAndUpdate()
    }
}

How the IP detection works

All examples use https://ipv4.ippubblico.org/ — a dedicated endpoint that forces an IPv4 connection and returns nothing but the bare IP address as plain text. This makes parsing trivial in every language:

203.0.113.42

No JSON to unwrap, no status fields to check, no authentication headers. For a script that runs every 5 minutes, this simplicity matters — fewer things to break.

If you want to verify DNS propagation after an update (checking that the IP in the DNS matches your current IP), a quick way to confirm your current IP without a DNS lookup:

CURRENT=$(curl -s https://ipv4.ippubblico.org/)
DNS_IP=$(dig +short home.yourdomain.com @8.8.8.8)
echo "Current IP : $CURRENT"
echo "DNS record : $DNS_IP"
[ "$CURRENT" = "$DNS_IP" ] && echo "In sync" || echo "Update pending"

What about IPv6?

If your setup supports IPv6 and your DNS provider supports AAAA records, you can detect the IPv6 address the same way:

IPV6=$(curl -s https://ipv6.ippubblico.org/)
# Returns the IPv6 address or nothing if not available

If the endpoint returns an empty response or fails to connect, the client has no IPv6 connectivity — handle it gracefully and fall back to IPv4 only.

Summary

Language	Dependency	Runs as
Shell	`curl`	cron / init script
Python	`requests`	systemd service / cron
Node.js	none (native fetch)	systemd service / PM2
Go	none (stdlib)	systemd service / binary

IP detection across all examples: https://ipv4.ippubblico.org/ — no API key, no account, plain text response.

Full documentation: ippubblico.org/docs.html

Which DNS provider are you using for DDNS? Share your setup in the comments.

Getting the public IP in Node.js and Express — no API key, no rate limits, no hassle

Vix — Mon, 22 Jun 2026 18:47:49 +0000

Getting the public IP in Node.js and Express — no API key, no rate limits, no hassle

Node.js is one of the most popular runtimes for building APIs, backend services, and CLI tools that need to know about network context. This article covers how to get the public IP address — your own server's or your client's — across the most common Node.js scenarios, using IPPubblico.org: free, no key required, HTTPS, CORS enabled.

Use case 1 — Your server's own public IP (script / CLI)

The simplest case: a Node.js script that needs to know its own public IP. Useful in deployment scripts, diagnostics, DDNS updaters, or any automation that needs to report its own address.

With fetch (Node 18+):

async function getPublicIP() {
  try {
    const res = await fetch('https://ipv4.ippubblico.org/', { signal: AbortSignal.timeout(5000) });
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return (await res.text()).trim();
  } catch (err) {
    console.error('Failed to get public IP:', err.message);
    return null;
  }
}

const ip = await getPublicIP();
console.log('Public IP:', ip); // 203.0.113.42

With axios:

import axios from 'axios';

async function getPublicIP() {
  try {
    const { data } = await axios.get('https://ipv4.ippubblico.org/', { timeout: 5000 });
    return data.trim();
  } catch (err) {
    console.error('Failed to get public IP:', err.message);
    return null;
  }
}

With node-fetch (older Node versions):

import fetch from 'node-fetch';

async function getPublicIP() {
  const res = await fetch('https://ipv4.ippubblico.org/');
  return (await res.text()).trim();
}

Use case 2 — Full geolocation data

When you need country, city, ISP and timezone in addition to the IP:

async function getIPInfo() {
  const res = await fetch('https://ippubblico.org/?api=1', {
    signal: AbortSignal.timeout(5000)
  });
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  const data = await res.json();

  return {
    ip:          data.ip,
    country:     data.geo?.country,
    countryCode: data.geo?.country_code,
    city:        data.geo?.city,
    region:      data.geo?.region,
    isp:         data.isp,
    timezone:    data.timezone,
    lat:         data.geo?.lat,
    lon:         data.geo?.lon,
  };
}

const info = await getIPInfo();
console.log(info);
// {
//   ip: '203.0.113.42',
//   country: 'Italy',
//   countryCode: 'IT',
//   city: 'Milan',
//   region: 'Lombardy',
//   isp: 'Telecom Italia',
//   timezone: 'Europe/Rome',
//   lat: 45.4654,
//   lon: 9.1859
// }

Use case 3 — Express middleware for client IP geolocation

The most common Express scenario: detecting where your users are connecting from. This middleware resolves the client's IP using IPPubblico and attaches the result to req.ipInfo for use in any route.

import express from 'express';

const app = express();

// Simple in-memory cache to avoid hitting the API on every request
const geoCache = new Map();
const CACHE_TTL = 60 * 60 * 1000; // 1 hour

async function resolveIP(ip) {
  const cached = geoCache.get(ip);
  if (cached && Date.now() - cached.ts < CACHE_TTL) {
    return cached.data;
  }

  try {
    const res = await fetch(`https://ippubblico.org/?api=1`, {
      signal: AbortSignal.timeout(3000)
    });
    const data = await res.json();
    const result = {
      ip:          data.ip,
      country:     data.geo?.country,
      countryCode: data.geo?.country_code,
      city:        data.geo?.city,
      isp:         data.isp,
      timezone:    data.timezone,
    };
    geoCache.set(ip, { data: result, ts: Date.now() });
    return result;
  } catch {
    return null;
  }
}

// Middleware
app.use(async (req, res, next) => {
  const forwarded = req.headers['x-forwarded-for'];
  const clientIP  = forwarded ? forwarded.split(',')[0].trim() : req.socket.remoteAddress;
  req.clientIP  = clientIP;
  req.ipInfo    = await resolveIP(clientIP);
  next();
});

// Use in any route
app.get('/hello', (req, res) => {
  const country = req.ipInfo?.country ?? 'Unknown';
  res.json({
    message: `Hello from ${country}!`,
    ip:      req.clientIP,
    info:    req.ipInfo,
  });
});

app.listen(3000);

Use case 4 — Country-based access control

Restricting or customising content based on country — without a paid API key:

const BLOCKED_COUNTRIES = ['XX', 'YY']; // ISO country codes
const PREMIUM_COUNTRIES  = ['US', 'GB', 'DE', 'FR', 'IT'];

app.use(async (req, res, next) => {
  const forwarded = req.headers['x-forwarded-for'];
  const ip = forwarded ? forwarded.split(',')[0].trim() : req.socket.remoteAddress;

  try {
    const geoRes = await fetch('https://ippubblico.org/?api=1', {
      signal: AbortSignal.timeout(3000)
    });
    const data = await geoRes.json();
    req.countryCode = data.geo?.country_code ?? null;
  } catch {
    req.countryCode = null;
  }
  next();
});

app.get('/content', (req, res) => {
  if (BLOCKED_COUNTRIES.includes(req.countryCode)) {
    return res.status(403).json({ error: 'Not available in your region' });
  }

  const isPremiumRegion = PREMIUM_COUNTRIES.includes(req.countryCode);
  res.json({
    content:  'Here is your content',
    tier:     isPremiumRegion ? 'premium' : 'standard',
    currency: req.countryCode === 'GB' ? 'GBP' : 'EUR',
  });
});

Use case 5 — DDNS updater script

A complete Node.js DDNS updater that checks the public IP every 5 minutes and logs when it changes:

import fs   from 'fs/promises';
import path from 'path';

const CACHE_FILE  = '/tmp/last_known_ip.txt';
const CHECK_INTERVAL = 5 * 60 * 1000; // 5 minutes

async function getPublicIP() {
  const res = await fetch('https://ipv4.ippubblico.org/', {
    signal: AbortSignal.timeout(5000)
  });
  return (await res.text()).trim();
}

async function getLastKnownIP() {
  try {
    return (await fs.readFile(CACHE_FILE, 'utf-8')).trim();
  } catch {
    return null;
  }
}

async function saveIP(ip) {
  await fs.writeFile(CACHE_FILE, ip, 'utf-8');
}

async function updateDDNS(newIP) {
  // Add your DDNS provider API call here
  console.log(`[DDNS] Updating record to ${newIP}`);
}

async function check() {
  try {
    const currentIP  = await getPublicIP();
    const lastKnownIP = await getLastKnownIP();

    if (currentIP !== lastKnownIP) {
      console.log(`[IP changed] ${lastKnownIP ?? 'unknown'} → ${currentIP}`);
      await updateDDNS(currentIP);
      await saveIP(currentIP);
    } else {
      console.log(`[IP unchanged] ${currentIP}`);
    }
  } catch (err) {
    console.error('[Error]', err.message);
  }
}

// Run immediately then every 5 minutes
check();
setInterval(check, CHECK_INTERVAL);

Use case 6 — IPv4 and IPv6 detection

When you need to know both protocols:

async function getBothIPs() {
  const res = await fetch('https://ippubblico.org/?text=1', {
    signal: AbortSignal.timeout(5000)
  });
  const text = await res.text();
  const lines = text.trim().split('\n');

  const parse = (line, prefix) => {
    const val = line.replace(prefix, '').trim();
    return val === 'NONE' ? null : val;
  };

  return {
    ipv4: parse(lines[0], 'IPv4:'),
    ipv6: parse(lines[1], 'IPv6:'),
  };
}

const ips = await getBothIPs();
console.log(ips);
// { ipv4: '203.0.113.42', ipv6: null }
// or
// { ipv4: '203.0.113.42', ipv6: '2001:db8::1' }

Handling rate limits

If your application makes many requests from the same IP in a short period, the API responds with 429 Too Many Requests and a Retry-After header. A robust fetch wrapper:

async function fetchWithRetry(url, maxRetries = 2) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const res = await fetch(url, { signal: AbortSignal.timeout(5000) });

    if (res.status === 429) {
      const retryAfter = parseInt(res.headers.get('Retry-After') ?? '20', 10);
      console.warn(`Rate limited. Waiting ${retryAfter}s...`);
      await new Promise(resolve => setTimeout(resolve, retryAfter * 1000));
      continue;
    }

    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return res;
  }
  throw new Error('Max retries exceeded');
}

// Usage
const res  = await fetchWithRetry('https://ippubblico.org/?api=1');
const data = await res.json();

In practice, caching results (as shown in the Express middleware above) eliminates most rate limit concerns.

Quick reference

Need	Endpoint	Response
IPv4 only	`https://ipv4.ippubblico.org/`	`203.0.113.42`
IPv6 only	`https://ipv6.ippubblico.org/`	`2001:db8::1` or `NONE`
Both protocols	`https://ippubblico.org/?text=1`	`IPv4: x\nIPv6: x`
Full geolocation	`https://ippubblico.org/?api=1`	JSON with country, city, ISP

Full API documentation: ippubblico.org/docs.html

Conclusion

IPPubblico covers Node.js use cases from a one-liner in a CLI script to a full Express middleware with caching and retry logic. The native fetch API available since Node 18 makes the integration particularly clean — no extra dependencies for the basic case.

The DDNS updater pattern is worth bookmarking: it's a complete, production-ready script that works on any server or VPS with Node.js installed, handling IP change detection, persistence, and error recovery in under 50 lines.

Using this in a Node.js project? Share what you built in the comments.

IPv4 vs IPv6 in 2026 — what every developer should know

Vix — Fri, 19 Jun 2026 10:41:38 +0000

IPv4 vs IPv6 in 2026 — what every developer should know

For most of the last decade, IPv6 felt like a topic you could safely ignore. "Still mostly IPv4 out there" was a reasonable excuse. That excuse stopped being true in 2026.

In March 2026, native IPv6 access to Google exceeded 50% globally for the first time in the 18 years Google has tracked this data. Around the same time, IPv6 overtook IPv4 as the majority protocol for global internet traffic as a whole. If you're building anything that touches the network — a backend service, a mobile app, an IoT device — this is no longer a future problem. It's a today problem.

This article covers what changed, why it matters for how you write code, and practical examples for detecting and handling both protocols correctly.

Why this happened now

IPv6 has existed since 1998. The slow adoption for most of its life wasn't a technical failure — it was an economic one. IPv4 addresses, while exhausted, kept getting recycled, traded, and NAT'd around for years longer than anyone expected. Migrating an entire network stack costs money and carries risk; as long as IPv4 kept limping along, there was no urgent reason to switch.

Three forces changed the calculus:

Mobile carriers went IPv6-first. Akamai data shows 88.4% of T-Mobile's network running on IPv6, with AT&T at 74% and Verizon at 74.8%. Most phone users today are on IPv6 without knowing it.

IoT made IPv4 impractical at scale. The number of IoT devices grew from roughly 15 billion in 2015 to over 75 billion in 2025, and these devices increasingly default to IPv6 because it removes the need to manage NAT rules and port forwarding for every single device.

Adoption is wildly uneven by country. France sits at 73% IPv6 adoption, India at 72%, Saudi Arabia at 65% — while Italy is at 17%, Spain at 10%, and Egypt at 4%. If your users are concentrated in IPv6-heavy regions, you're already serving majority-IPv6 traffic whether you've planned for it or not.

What actually changes for you as a developer

IPv6 isn't "IPv4 but longer." A few practical differences matter immediately:

No more NAT assumptions. With IPv4, most consumer devices sit behind NAT, so the IP you see is shared across a household or office. With IPv6, every device commonly gets its own globally routable address. This changes how you think about rate limiting, abuse detection, and geolocation — one IP no longer reliably maps to "one network", it often maps to "one device."

Address format is different everywhere. 2001:db8::1 instead of 203.0.113.42. This breaks naive regex validation, log parsers, and URL construction (IPv6 literals in URLs need brackets: https://[2001:db8::1]:8080/).

Dual-stack is the norm, not the exception. Most networks today run both protocols simultaneously. Your server, your client libraries, and your monitoring all need to handle a connection coming in on either protocol gracefully — not as an edge case.

Detecting IPv4 vs IPv6 in your stack

Here's how to handle both protocols correctly across common languages and frameworks.

JavaScript / Node.js

function getIPVersion(ip) {
  if (ip.includes(':')) return 'IPv6';
  if (ip.includes('.')) return 'IPv4';
  return 'unknown';
}

// Express middleware to log both correctly
app.use((req, res, next) => {
  const ip = req.ip; // may be IPv4 or IPv6 depending on connection
  console.log(`${getIPVersion(ip)} request from ${ip}`);
  next();
});

A common bug: Express and many proxies report IPv4 addresses as IPv6-mapped, like ::ffff:203.0.113.42. Strip the prefix before doing anything with it:

function normalizeIP(ip) {
  if (ip.startsWith('::ffff:')) {
    return ip.substring(7); // back to plain IPv4
  }
  return ip;
}

Python

import ipaddress

def get_ip_version(ip: str) -> str:
    try:
        addr = ipaddress.ip_address(ip)
        return f"IPv{addr.version}"
    except ValueError:
        return "invalid"

print(get_ip_version("203.0.113.42"))      # IPv4
print(get_ip_version("2001:db8::1"))       # IPv6

ipaddress is in the standard library and handles validation, version detection, and even subnet math — no need for regex.

Go

package main

import (
    "fmt"
    "net"
)

func getIPVersion(ipStr string) string {
    ip := net.ParseIP(ipStr)
    if ip == nil {
        return "invalid"
    }
    if ip.To4() != nil {
        return "IPv4"
    }
    return "IPv6"
}

func main() {
    fmt.Println(getIPVersion("203.0.113.42"))  // IPv4
    fmt.Println(getIPVersion("2001:db8::1"))   // IPv6
}

PHP

function getIPVersion(string $ip): string {
    if (filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4)) {
        return 'IPv4';
    }
    if (filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV6)) {
        return 'IPv6';
    }
    return 'invalid';
}

Detecting client IP and protocol from the browser

If you need to know whether your visitor is reaching you over IPv4 or IPv6 (useful for diagnostics, dual-stack debugging, or simply curiosity), the cleanest approach is hitting protocol-specific endpoints — not parsing user agent strings or making assumptions.

IPPubblico.org exposes dedicated subdomains for exactly this:

// Forces an IPv4-only connection and returns the IPv4 address
fetch('https://ipv4.ippubblico.org/')
  .then(res => res.text())
  .then(ip => console.log('IPv4:', ip.trim()));

// Forces an IPv6-only connection — fails gracefully if the client has no IPv6
fetch('https://ipv6.ippubblico.org/')
  .then(res => res.text())
  .then(ip => console.log('IPv6:', ip.trim()))
  .catch(() => console.log('No IPv6 connectivity'));

Or get both in one call:

fetch('https://ippubblico.org/?text=1')
  .then(res => res.text())
  .then(text => {
    const lines = text.trim().split('\n');
    console.log(lines[0]); // IPv4: x.x.x.x or NONE
    console.log(lines[1]); // IPv6: x or NONE
  });

This pattern is genuinely useful: if ipv6.ippubblico.org times out or fails, you know definitively that the client has no IPv6 path to the public internet — not just that your app didn't request it.

Common pitfalls

Storing IPs as 32-bit integers. A classic IPv4-era optimization that breaks completely with IPv6. If your schema has an INT UNSIGNED column for IP storage, it cannot hold an IPv6 address. Use VARCHAR(45) or a native INET/CIDR type if your database supports one (PostgreSQL does).

Regex-based IP validation. Most handwritten IPv4 regexes don't even attempt IPv6, and IPv6's flexible notation (leading zero compression, :: shorthand, embedded IPv4) makes a correct regex genuinely hard to write by hand. Use your language's built-in IP parsing library instead — ipaddress in Python, net.ParseIP in Go, inet_pton in C, FILTER_VALIDATE_IP in PHP.

Rate limiting by IP alone. Since IPv6 commonly gives each device its own address while IPv4 often shares one address across many users behind NAT, identical rate-limiting logic produces very different real-world behavior depending on which protocol a request arrives on. A single aggressive IPv6 client looks like one bad actor; a misbehaving app on a shared IPv4 NAT can look like — and inadvertently punish — hundreds of innocent users at once.

CIDR notation differences. IPv4 subnets you're used to (/24, /16) map to wildly different scales in IPv6, where /64 is the standard allocation for a single network segment — already larger than the entire IPv4 address space.

Should you do anything about this right now?

If your stack already uses standard library IP parsing and your database can store variable-length strings, you're probably fine technically — dual-stack support is mostly already there in modern frameworks by default.

What's worth auditing:

Any handwritten IP validation or parsing logic
Database columns storing IPs as fixed-size integers
Rate limiting or abuse detection logic that assumes IPv4-style address sharing
Log analysis tools or dashboards that choke on the longer IPv6 format
Any hardcoded assumption that "an IP" is 4 bytes

None of this requires a rewrite. It requires checking that the assumptions baked into older code still hold — and increasingly, for a majority of your traffic, they don't.

Quick reference

Task	IPv4	IPv6
Example address	`203.0.113.42`	`2001:db8::1`
URL with port	`203.0.113.42:8080`	`[2001:db8::1]:8080`
Typical subnet	`/24` (256 addresses)	`/64` (≈1.8×10¹⁹ addresses)
NAT behavior	Usually shared across users	Usually one address per device
Detect with IPPubblico	`https://ipv4.ippubblico.org/`	`https://ipv6.ippubblico.org/`

Conclusion

IPv6 crossing the 50% threshold in March 2026 is the kind of milestone that's easy to miss because nothing visibly "switched over" — there was no flag day, no announcement, just a slow curve that quietly crossed the midpoint. But for anyone writing code that touches the network, the practical implication is concrete: code that silently assumes IPv4 is now wrong for roughly half of real-world traffic, and that share is still climbing.

The fix isn't dramatic. Use your language's built-in IP libraries, store IPs as strings, and stop assuming one IP equals one user. The protocol your code runs on increasingly isn't your choice to make — it's the network's.

Have you run into IPv6-related bugs in production? Share them in the comments — the edge cases are usually the most instructive part.

Getting the public IP in Python — scripts, Django, FastAPI

Vix — Mon, 15 Jun 2026 06:17:15 +0000

Getting the public IP in Python — scripts, Django, FastAPI

Whether you're writing a quick script, building a Django web app, or designing a FastAPI microservice, knowing the public IP of your server or client is a recurring need. This article covers all three scenarios with practical code, using IPPubblico.org — a free API with no key required, HTTPS, and CORS enabled.

Why IPPubblico?

Before diving into code, here's a quick summary of why it's worth using:

No API key — works immediately, zero setup
HTTPS only — secure by default
Plain text endpoint — no parsing for simple cases
Full JSON endpoint — city, country, ISP, ASN, timezone when needed
No hard rate limit — soft limiting applies for abuse prevention
Commercial use allowed on the free tier

Use case 1 — Simple script with `requests`

The most common scenario: a standalone script that needs to know its own public IP.

import requests

def get_public_ip():
    try:
        response = requests.get(
            'https://ipv4.ippubblico.org/',
            timeout=5
        )
        response.raise_for_status()
        return response.text.strip()
    except requests.RequestException as e:
        print(f"Failed to get IP: {e}")
        return None

if __name__ == '__main__':
    ip = get_public_ip()
    print(f"Public IP: {ip}")
    # Public IP: 203.0.113.42

Use case 2 — Full geolocation with `requests`

When you need country, city, ISP and timezone in addition to the IP:

import requests
from dataclasses import dataclass
from typing import Optional

@dataclass
class IPInfo:
    ip: str
    country: Optional[str]
    country_code: Optional[str]
    city: Optional[str]
    region: Optional[str]
    isp: Optional[str]
    timezone: Optional[str]
    lat: Optional[float]
    lon: Optional[float]

def get_ip_info(ip: str = None) -> Optional[IPInfo]:
    """
    Get geolocation info for an IP address.
    If ip is None, returns info for the current public IP.
    """
    url = 'https://ippubblico.org/?api=1'
    if ip:
        url += f'&ip={ip}'

    try:
        response = requests.get(url, timeout=5)
        response.raise_for_status()
        data = response.json()

        if data.get('status') != 'ok':
            return None

        geo = data.get('geo', {})
        return IPInfo(
            ip=data.get('ip', ''),
            country=geo.get('country'),
            country_code=geo.get('country_code'),
            city=geo.get('city'),
            region=geo.get('region'),
            isp=data.get('isp'),
            timezone=data.get('timezone'),
            lat=geo.get('lat'),
            lon=geo.get('lon'),
        )
    except requests.RequestException as e:
        print(f"Request failed: {e}")
        return None

if __name__ == '__main__':
    info = get_ip_info()
    if info:
        print(f"IP:       {info.ip}")
        print(f"Country:  {info.country} ({info.country_code})")
        print(f"City:     {info.city}, {info.region}")
        print(f"ISP:      {info.isp}")
        print(f"Timezone: {info.timezone}")

Use case 3 — Async script with `httpx`

For async Python scripts using httpx:

import asyncio
import httpx

async def get_public_ip() -> str | None:
    async with httpx.AsyncClient(timeout=5.0) as client:
        try:
            response = await client.get('https://ipv4.ippubblico.org/')
            response.raise_for_status()
            return response.text.strip()
        except httpx.HTTPError as e:
            print(f"Failed to get IP: {e}")
            return None

async def get_ip_info() -> dict | None:
    async with httpx.AsyncClient(timeout=5.0) as client:
        try:
            response = await client.get('https://ippubblico.org/?api=1')
            response.raise_for_status()
            data = response.json()
            return data if data.get('status') == 'ok' else None
        except httpx.HTTPError as e:
            print(f"Failed to get IP info: {e}")
            return None

async def main():
    ip = await get_public_ip()
    print(f"Public IP: {ip}")

    info = await get_ip_info()
    if info:
        print(f"Country: {info['geo']['country']}")
        print(f"City:    {info['geo']['city']}")

asyncio.run(main())

Use case 4 — Django middleware for country detection

A Django middleware that detects the user's country on every request and adds it to request.country_code. Useful for region-based content, currency selection, or logging.

# myapp/middleware.py

import requests
from django.core.cache import cache

CACHE_TIMEOUT = 3600  # 1 hour per IP

class CountryDetectionMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        client_ip = self._get_client_ip(request)
        request.client_ip = client_ip
        request.country_code = self._get_country(client_ip)
        response = self.get_response(request)
        return response

    def _get_client_ip(self, request):
        x_forwarded_for = request.META.get('HTTP_X_FORWARDED_FOR')
        if x_forwarded_for:
            return x_forwarded_for.split(',')[0].strip()
        return request.META.get('REMOTE_ADDR')

    def _get_country(self, ip: str) -> str | None:
        if not ip:
            return None

        cache_key = f'country_{ip}'
        cached = cache.get(cache_key)
        if cached:
            return cached

        try:
            response = requests.get(
                'https://ippubblico.org/?api=1',
                timeout=3
            )
            data = response.json()
            country_code = data.get('geo', {}).get('country_code')
            if country_code:
                cache.set(cache_key, country_code, CACHE_TIMEOUT)
            return country_code
        except Exception:
            return None

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'myapp.middleware.CountryDetectionMiddleware',  # add here
    # ... rest of middleware
]

Use it in any view:

# views.py

from django.http import JsonResponse

def my_view(request):
    return JsonResponse({
        'ip': request.client_ip,
        'country': request.country_code,
    })

Use case 5 — Django view with per-request geolocation

For cases where you need full geolocation data in a specific view, not globally:

# views.py

import requests
from django.http import JsonResponse
from django.views import View

class UserLocationView(View):
    def get(self, request):
        ip = request.META.get('HTTP_X_FORWARDED_FOR', '').split(',')[0].strip() \
             or request.META.get('REMOTE_ADDR')

        try:
            response = requests.get(
                'https://ippubblico.org/?api=1',
                timeout=5
            )
            data = response.json()
            geo = data.get('geo', {})

            return JsonResponse({
                'ip': data.get('ip'),
                'country': geo.get('country'),
                'country_code': geo.get('country_code'),
                'city': geo.get('city'),
                'timezone': data.get('timezone'),
            })
        except Exception as e:
            return JsonResponse({'error': str(e)}, status=500)

Use case 6 — FastAPI dependency injection

The cleanest FastAPI pattern: a reusable dependency that injects IP info into any route.

# dependencies.py

import httpx
from functools import lru_cache
from fastapi import Request, Depends
from typing import Optional
from pydantic import BaseModel

class GeoInfo(BaseModel):
    city: Optional[str] = None
    region: Optional[str] = None
    country: Optional[str] = None
    country_code: Optional[str] = None
    lat: Optional[float] = None
    lon: Optional[float] = None

class IPInfo(BaseModel):
    ip: str
    isp: Optional[str] = None
    timezone: Optional[str] = None
    geo: GeoInfo = GeoInfo()

def get_client_ip(request: Request) -> str:
    forwarded = request.headers.get('X-Forwarded-For')
    if forwarded:
        return forwarded.split(',')[0].strip()
    return request.client.host

async def get_ip_info(request: Request) -> Optional[IPInfo]:
    ip = get_client_ip(request)
    async with httpx.AsyncClient(timeout=5.0) as client:
        try:
            response = await client.get('https://ippubblico.org/?api=1')
            data = response.json()
            if data.get('status') == 'ok':
                return IPInfo(**{
                    'ip': data.get('ip', ip),
                    'isp': data.get('isp'),
                    'timezone': data.get('timezone'),
                    'geo': GeoInfo(**data.get('geo', {}))
                })
        except Exception:
            pass
    return None

Use in any route:

# main.py

from fastapi import FastAPI, Depends
from dependencies import IPInfo, get_ip_info

app = FastAPI()

@app.get('/location')
async def location(ip_info: IPInfo = Depends(get_ip_info)):
    if not ip_info:
        return {'error': 'Could not detect location'}
    return {
        'ip': ip_info.ip,
        'country': ip_info.geo.country,
        'city': ip_info.geo.city,
        'timezone': ip_info.timezone,
    }

Use case 7 — FastAPI with caching (Redis)

For high-traffic APIs, cache the geolocation result per IP to avoid repeated external calls:

# dependencies_cached.py

import httpx
import json
from fastapi import Request
from typing import Optional
import redis.asyncio as redis

redis_client = redis.Redis(host='localhost', port=6379, decode_responses=True)
CACHE_TTL = 3600  # 1 hour

async def get_ip_info_cached(request: Request) -> Optional[dict]:
    forwarded = request.headers.get('X-Forwarded-For')
    ip = forwarded.split(',')[0].strip() if forwarded else request.client.host

    cache_key = f'ipinfo:{ip}'
    cached = await redis_client.get(cache_key)
    if cached:
        return json.loads(cached)

    async with httpx.AsyncClient(timeout=5.0) as client:
        try:
            response = await client.get('https://ippubblico.org/?api=1')
            data = response.json()
            if data.get('status') == 'ok':
                await redis_client.setex(cache_key, CACHE_TTL, json.dumps(data))
                return data
        except Exception:
            pass
    return None

Handling rate limits

If your application makes many requests from the same IP in a short period, you may receive a 429 Too Many Requests response. The API returns a Retry-After header indicating how many seconds to wait:

import time
import requests

def get_ip_with_retry(max_retries: int = 3) -> str | None:
    for attempt in range(max_retries):
        response = requests.get(
            'https://ipv4.ippubblico.org/',
            timeout=5
        )

        if response.status_code == 200:
            return response.text.strip()

        if response.status_code == 429:
            retry_after = int(response.headers.get('Retry-After', 20))
            print(f"Rate limited. Waiting {retry_after}s before retry {attempt + 1}/{max_retries}")
            time.sleep(retry_after)
            continue

        response.raise_for_status()

    return None

In practice, caching results at the application level eliminates most rate limit concerns.

Quick reference

Need	Endpoint	Response
IPv4 only	`https://ipv4.ippubblico.org/`	`203.0.113.42`
IPv6 only	`https://ipv6.ippubblico.org/`	`2001:db8::1` or `NONE`
Both protocols	`https://ippubblico.org/?text=1`	`IPv4: x\nIPv6: x`
Full geolocation	`https://ippubblico.org/?api=1`	JSON with country, city, ISP

Full API documentation: ippubblico.org/docs.html

Conclusion

IPPubblico covers the full range of Python use cases — from a one-liner in a shell script to a properly typed FastAPI dependency with Redis caching. The consistent API across plain text and JSON endpoints means you can start simple and add complexity only when you need it.

The Django middleware and FastAPI dependency patterns shown here are production-ready starting points: they handle client IP extraction behind proxies, cache results to avoid redundant API calls, and fail gracefully when the external service is unavailable.

Using a different approach for IP detection in Python? Share it in the comments.