reincoder

I have been part of this community for over a decade, and in my experience the mods do take flagging and voting irregularities seriously when they are reported. If you believe there is manipulation happening on your posts, that is worth raising directly with them, since they have visibility we do not.

---

On the broader point, we process 3 trillion requests last year, have more than 80 employees, and run a dedicated privacy engineering team led by an ex-cybersecurity company founder. We invest in research on new detection methods and stay closely engaged with the developer community. If there are specific gaps you see in our product, I would be glad to hear them and discuss.

---

Whether any dataset, including residential proxy IP data, is valuable depends heavily on the application. Treating a dataset as invalid because it does not fit one particular model can lead to decisions on shaky ground.

We are regarded as one of the more if not the most accurate IP geolocation providers, and we spend considerable effort on education, solutions architecture, and documentation so customers understand what our data can and cannot support. For example, IP geolocation, even at highest level of accuracy, is not a person identifier. It will never be a 1:1 replacement of GPS geolocation.

Many of the largest companies in AI, anti-bot, fingerprinting, KYC, and CDN spaces use our data. If anti-bot systems and CAPTCHAs were fully reliable on their own, there would be less need for additional signals like residential proxy data. We do not assign a score or label an IP as good or bad. That judgment sits with the customer's own threat or analytics model.

Residential proxy IPs are, by and large, mostly used in web scraping operations of many different forms. If a company sees a moderate to high amount of traffic mimicking human behavior, it can struggle to tell bot traffic apart from real users. Anti-bot mechanisms can help, but they add friction to the user experience, and they are not cheap to run at scale.

Residential proxy detection data is one of the easiest zero-knowledge ways to gather intelligence. There is no need for users to solve a puzzle or for multi-page traversal to collect fingerprint data. All that is needed is the IP address.

Our residential proxy data customers tend to be on the more sophisticated side of cybersecurity. Suggesting that this data is a silver bullet for all their security needs would not reflect well on their expertise or ours. We present the data as is, and from there we work with customers on the right solution for their case.

I work for IPinfo. We offer a residential proxy detection service, which you can check at ipinfo.io/my.

We had a previous discussion about surfacing visitor IP address resproxy status explicitly. Should we have some sort of badge or a more explicit alert to show if a site visitor's IP address is part of a residential proxy network?

Even though it is great for demonstrating the product's value, it is kind of a low-tier value. What can a user actually do when they realize their IP address is part of a residential proxy pool?

The first issue is that residential proxy SDK infiltration is massive. If you start connecting to different IP addresses and constantly check your IP address on our website, you will often see that many of those IP addresses were, at some point, part of a residential proxy pool. We provide frequency information showing how many times an IP address was observed in a residential proxy pool, with a default observation period of 7 days.

Then there is the question of what a user can actually do about it. If it is a controlled IT environment with paranoid IT admins, sure, they can actively monitor traffic and identify why their IPs are showing up in residential proxy pools. They can attempt to do something about it. But it is not easy even then.

Residential proxy SDKs can simply be baked into almost any smartphone or smartphone-derived OS that allows app installation through marketplaces. So, many residential networks are already cooked (because of android TVs). Moderate-scale NAT connections almost always see residential proxy flags, as do public Wi-Fi hotspot IPs, which we also detect.

Identifying the apps that are generating background network traffic is quite hard. You need some level of DNS monitoring or a network sniffer. Alternatively, you need router-level firewall software.

These SDKs are not always sending high-volume, constant traffic that makes them easy to detect. If you see a 100% residential proxy flag for your IP address, then they probably are. But in many cases, the traffic is intermittent and much harder to identify.

Nobody has an answer to what I should do when I see my IP address in a residential proxy pool. It has been accepted in spirit as a "consented malware" for the last few years. It is undetectable and extremely hard to remove because the SDK has been baked into apps themselves.

I was looking into the IPv6 adoption of US government websites (https://community.ipinfo.io/t/the-state-of-ipv6-across-us-go...) when we discovered that Cloudflare had essentially dethroned Akamai for government content hosting over a number of years. The post primarily focuses on IPv6, but according to our data, Cloudflare hosts 70% of US government websites.

You can block entire ASNs. If you are frustrated with bots, blocking Tencent's entire IP address space would have very few downsides.

If you have fail2ban or NGINX logs, you can use our CLI to summarize those IPs and identify the ASNs you want to block. But before you block entire ASNs, make sure they are not classified as "ISP" type. For that, visit our website's ASN page first.

I have quite a few community posts around this approach. https://community.ipinfo.io/

If you have raw logs, you can send them to me as well, and I can review them and provide some guidance.

I work for IPinfo. We offer IPinfo Lite for free. With a little bit of time in identifying the ASNs, you can implement a decent way to block a good number of bots fairly easily using the free data alone.

The project directly references us, so it is only fair we provide more context.

The idea of a pitch means that there is some sort of price attached to it, which IPinfo Lite does not have. In fact, it is designed as commercially permissive as possible.

According to MaxMind, they offer a variety of databases with different pricing tiers of accuracy. Geolite2 as a database service is free but its accuracy is compromised by design. If you want a more accurate version of their database, you have to pay for the GeoIP2 database. Now, this applies to country-level data as well. They have a free, accuracy-compromised country database, and then they have their database with better accuracy available for purchase.

We would rather not compromise on accuracy at all and provide the highest possible accurate country-level data for free. We do not have a compromised accuracy variant of any database. We sell the city database and offer the country database for free to anyone.

There are three layers of cost here with a self-hosted project. You pay for the VM, you set up the project, and you have to maintain it. So, for some folks, the API service makes sense because the cost maintaining the infrastructure for it is on us.

We offer an offline version of the IPinfo Lite database for download: https://ipinfo.io/developers/ipinfo-lite-database

We do not comment to advertise. We participate in IP geolocation discussions because there is a lot of misinformation in this space, and we feel a responsibility to provide accurate information publicly.

In this case, the recommendation was for a free product that requires no setup and no VM cost. The opposite of a sales pitch.

I work at IPinfo. We offer unlimited free requests through the IPinfo Lite API. By unlimited, I mean millions of requests per day. The free API provides country and ASN data.

As far as I know, GeoLite2 does not have city-level data for a large number of IP addresses. Even when it does, the city-level accuracy can be quite poor.

So I'd suggest just using our API and pointing to the capital city. That would also remove the need to pay for a VM.

I work for IPinfo. We do not provide reputation scoring, by the way. Reputation is such a subjective matter.

It would be easy for us to make a very quick sales if we start offering reputation scoring, but we, as a company, would rather support fraud detection, threat intelligence and bot detection services with raw data from us.

In fact, the 1400 servers we operate for internet measurement all have very sophisticated honeypots baked into them, but still, we have not productized that data. In our experience of the fast-moving world of IP addresses, reputation scoring, even with the best intentions, can introduce some downsides. We can do many things which will be better than most things out there, but we have to really balance the consequences of our product.

Yes, we do use user agents to separate requests to our websites and API service. However, we request users to switch to api.ipinfo.io (dedicated API infrastructure) and use ipinfo.io/json for an explicit request for the API endpoint.

There are indeed some limitations to this implementation. The primary one being IPv6 support. The implementation prioritizes convenience over internet limitations, requiring us to roll out IPv6 dual stacking on the web request level as opposed to the DNS level. On an API level, this results in users with IPv6 addresses making API requests to v6.ipinfo.io.

So, last year we rolled out dedicated API infrastructure for api.ipinfo.io

You have to ask them. I tried but did not get a clear answer.

We operate nearly 1,400 servers across almost 160 countries ourselves. From our perspective, it is VERY hard to maintain and expand a network infrastructure of this scale. When you start getting servers in West Africa, Northern Africa, the plains in North America, or Oceania, the Eastern Indian Ocean, you are expected to pay magnitudes more compared to servers with equal performance in NYC or Amsterdam. Maintaining such a diversified network infrastructure from a technical point of view is extremely challenging. Then there is the official and bureaucratic process.

Now, we are just scratching the surface. VPNs require high volume traffic throughput. Some countries (entire countries) just do not have the capacity to offer that.

So, most of the time VPN companies tend to work with specialty VPN infrastructure companies. They provide everything from hosting to networking across dozens of locations they operate in. I believe there are even white-label VPN companies that handle everything from infrastructure handling all the way to billing and even support handling. You just bring your branding. It can be argued that there is little incentive to go out there, do it all from scratch.

Is it intentional or just obscuring? From what we see, it leans intentional. The location they report is not inaccurate information by accident, it looks quite deliberate. Legacy IP geolocation services rely on something called a geofeed. A geofeed is a self-reported unverifiable report published by a network operator. Geofeeds are not widely adopted (1.5% of IPv4 and 0.70% of IPv6 allocated prefixes, 2023 data), but VPN providers maintain theirs diligently. They actively publish the locations they want IP geolocation providers to report.

One point raised by a journalist on the reporting side: imagine your VPN server points to one of the offshore islands in the Caribbean that sit outside US jurisdiction, only to find out the actual VPN server is in Miami. That is a bit risky.

Windsribe and iVPN.

https://ipinfo.io/vpnreport

I work for IPinfo. Even though we are in the VPN detection business, I will give Mullvad the benefit of the doubt, to be honest. They were one of the three VPN providers we found that did not attempt to submit inaccurate geolocation information to IP geolocation providers like us. I am sure they will fix the issue.

I used the same methodology to observe AI crawlers. This is not an investigative blog but is rather designed to address our (IPinfo) customers who are asking us to identify IP addresses as "AI Agents" or, more accurately, "AI Crawlers".

https://community.ipinfo.io/t/can-we-detect-ai-agents-we-can...

Most AI crawlers self-identify with a UA. However, Grok uses resproxies and sends a high volume of simultaneous requests. Even though we can detect resproxies, it is not possible to map these resproxy IPs to grok.

I still could not figure out why I saw legitimate Googlebot IPs when I requested Perplexity to review the website. I verified those Googlebot IPs using both using UA and the listed IP address ranges published by Google.

  ---
  Edit to my parent company
  ---

I am scaling back this enthusiasm a bit. We need to work with mature organizations instead of individuals.

We need SSH through a public IP address and use Ubuntu as an operating system. Since we need to determine where these servers are located, we need to collaborate with universities, various organizations, IXP, DCs, telecom/ISP consulting companies with a mature understanding of network engineering.

We actually have app-based data collection capabilities and initiatives. Our goal, or more appropriately, vision, is to map the internet in real time. This involves SSH access to devices to run different forms of measurements at a very high frequency and have control over those devices.

Managing 70k probes is not going to be super hard.

Managing 1,400 servers is just a normal business operation, not a technical challenge. Each probe has a standard OS-level configuration. Automation and configuration are deployed from a central system. Each probe is actively monitored and troubleshot. Data is dumped to a data warehouse. We make incremental improvements to our network. When servers go down, we talk to vendors.

We do a lot of novel engineering things from the infrastructure, data, and research team. Having a very identical set of servers really allows us to focus on product and performance engineering, not troubleshooting engineering. With application-based probing, I assume it will complicate things quite a bit, as there are different operating systems, different devices, etc.

For us, lately the challenge is not technical. It has been exclusively procurement. This quarter (https://ipinfo.io/blog/probenet-q1-2026-expansion), we exclusively focused on regional diversity which involved outreach to national ISPs or telecoms. Securing servers from telecoms is an extremely bureaucratic and expensive process. So, we are hoping to partner up with eyeball networks and the larger NOG community.

I work for IPinfo and we operate a distributed network consisting of around 1,400 servers. I think we have reached a point where it is extremely hard for us purchase VPSes from interesting ASNs.

To support lots of ISPs, universities, and different organizations we have been asking them if they have an old laptop lying around that they can host our software on. Goal is to reach 70,000 probes within the next couple of years.

It is a simple probe software and we share some data or we can pay 20-30 bucks a month for it. We have a couple of NUCs in remote regions but no laptops yet. Basically, we are even happy if an ISP (or any one) hosts our software from a laptop dangling by a charging cable from a socket in some random corner.

We can send over a RPI or NUC, but with remote hands, and setup and all that it can get quite expensive. So, we always first ask if they have an old laptop lying around and can install our software there.

For us, at least, we are not interested in the hardware aspect. We are interested in the network. The old laptop approach only acts as a last resort. We will be more than happy to go with the predictability of a traditional VPS hosted in a traditional data center. Colocation, no matter what form it takes, involves a lot of moving parts.

> I couldn't get /lite/ to work.

Email me: abdullah@ipinfo.io

I think there is an issue with setting up our API.

> Do you happen to know if anyone is compiling all of this data about VPNs into one place? It would be super interesting to know which VPNs are providing genuine services vs masquerading the locations. Maybe even an SEO for you.

We made that report independently and, according to our analysis, we only identified three VPNs: Windscribe, Mullvad, and iVPN to not have virtual VPN server locations.

> Just to clarify: You are suggesting that we don't pro-actively enrich every IP address, store IPs, and only enrich them when troubleshooting something?

I think you should experiment with this yourself a little. The Lite API is completely free. So you can do ingestion enrichment and post-enrichment enrichment. See what works best for you.

> I am assuming the inferred data, but that also feels counter-intuitive (since the data does not align with what ASN/ISP are reporting).

That is a very good question. Now, geofeed does not have a verification system. Active measurement is something we use to verify ASN or ISP itself.

Even active measurement has its own limitations. Now in those case where we see active measurements not producing reliable data, we do reach out to ISPs and ASNs to purchase a server in their facility. Geofeed as a system is voluntary and most major ISPs actually do not maintain or even publish that. For example, today I found out a major UK-based telecom geolocated 500k IP addresses in a town with 200k people. ISPs are not inherently incentivized to maintain the accuracy of their self-reported, voluntarily published location data. So, we do proactive outreach to purchase a server from them so we can provide consistent accurate data for their IP addresses.

On the matter of advertised locations not matching actual location, I highly recommend reading this: https://ipinfo.io/blog/vpn-location-mismatch-report

For residential ISPs, we do a lot of outreach and open communication to build a good partnership with them. The goal is that we pay for the privilege to report accurate data for them.

> How often does your active measurement data disagree with geofeed data?

Very frequently.

Here is the summary peer reviewed research paper on this matter: https://community.ipinfo.io/t/ip-geolocation-and-geofeeds-wh...

Active Measurement (1,330 probes, 27.7M RTTs):

  - Country-level: 92.0% accurate → 8% wrong country
  - City-level: 79.6% accurate → 20.4% wrong city

Mobile Device GPS (169 devices, 24 countries):

  - Country-level: 84.5% accurate
  - City-level: 29.9% accurate → 70% wrong city

> How do you handle mobile/cellular IPs

Primarily through active measurement, we are also running a lot of research around more reliable mobile geolocation data.

Because our data is updated daily, I think due to the refresh rate we have an accuracy advantage.

> If I am troubleshooting a support case that is days/weeks/months old, wouldn't this mean that enriching this information at a later date may give me different data than what it was associated with at the time the requests were made? My understanding was that IPs get re-assigned.

You will be surprised to know that historical IP location does not have much demand.

If you are evaluating a support case after some time, you should work with your current data. If the customer raises a question, you address this in real time with their current IP address.

Usually, I do not recommend storing historic IP geolocation information. In most operations, the enrichment happens in real time within the day. Unless you want to do periodic reporting of some sort.

Internally, we of course have the data, but because our IP geolocation is so accurate, it currently sits at around 700 MB. If you add a historical layer to that data, it will be a terabyte of data. There is not much consumer need for it.

> How frequently do IP-to-location mappings change in practice?

https://ipinfo.io/blog/how-many-ips-change-geolocation-over-...

On the city level is 1.3% each day and 16% each month.

> Do you offer historical IP data snapshots?

I highly recommend that you work with current day's data.

In cases where we provide historical data, it is usually for academic research.

---

Let me know if you have any more questions.

I work for IPinfo. We provide a free country and ASN database on a free tier with an unlimited amount of requests. You can download the entire database or use the API services. For country and ASN, it is free.

However, we do not offer city level data for free. > How would one even go about verifying it?

We believe we are the most accurate IP data provider out there, but you should come to that conclusion yourself.

I can tell you why our data is super accurate compared to the rest of the industry. The industry as a whole uses self-reported information that is offered by ASN and ISPs. It is called "geofeed". The issue with geofeed is that IP geolocation providers do not tend to verify the accuracy. Many providers just aggregate these public records and repeat what the ISPs and ASNs want them to tell them. This is a quite bad practice.

So we built a network of distributed servers (currently 1360 servers across 160 countries) that run ping, traceroute and other internet measurements and try to infer the location of IP geolocations. This means when you come to asking how do I know you are accurate, we can share our active measurement data and tell you that this is the evidence.

Now, comes the qustions of how you identify accuracy yourself.

First, if you have access to a large pool of known locations of IP addresses, you can run comparisons across different vendors. You need a GPS-backed device to locate IP addresses.

If you do not have a large pool of well-known location IPs, you can take a sample of IP addresses and check them yourself across multiple vendors. You can then use a tool like ping.sx or our own tool ipinfo.io/probenet/live to see evidence of where these IP addresses are located based on latency.

Do not bet on consensuses among IP geolocation providers; run your own tests.

Our data was evaluated by peer-reviewed academic research. You can take a look at that as well, if you want.

> I am not really using this data for anything other than have enough data to troubleshoot customer support/fraud.

Now, I will be honest...you should not pay anything to us. The way you have describing your issue, it seems like the free services we already offer that should satisfy your need.

Do you really need large scale IP address enrichment of all the IP addresses that visit your website? If yes, then for the first layer use our free data that provides ASN and country information.

Then, when you need troubleshooting with your customers, you can look up those individual IP addresses for free on our website, where we provide all our data for free access.

---

Let me know if you need any help, always happy to answer questions.

I work for IPinfo. The accuracy you see is inferred data actually. Our IP address location should not perfectly pinpoint anyone, unless that IP address is a data center of some sort. The highest accuracy for a non-data center IP address is usually at the ZIP code level. In terms of carrier IP addresses, currently we do one data update per day. If we did more, I guess the accuracy of mobile IP addresses would improve, but on an overall scale, it would be quite miniscule.

Our country-level data (which is free) is 10-15 times larger than the free/paid country-level data out there. We constantly hear that the size of the database is an issue. The size is a consequence of accuracy in the first place. So, it is a balancing act.

I work for IPinfo. Has our data been inconsistent for you? We actually invest heavily and continuously in data accuracy. I think for hosting IP addresses we are nearing the highest level of accuracy possible, especially with data center addresses. We are investing in novel, cutting-edge research for carrier IP geolocation.

I am curious about your experience with us so far.

I work for IPinfo. We track close to a hundred resproxy providers. So, if OP's router is compromised, the device IPs will likely be flagged.

From what I know, whenever a router is backdoored or a resproxy SDK gains access to a device to use their bandwidth, the access to that pool of devices is often shared among multiple resproxy vendors. Many resproxy vendors do not have their own SDKs for their services.

Also, as far as I know, not many resproxy operators manage their sim farms or hardware pools. It is mostly based on compromised devices or SDK access.

This is called a geofeed. Companies that own or operate IP addresses can customarily share the location of those IP addresses. This is less of "IP-based Geolocation" rather "Geolocation of IP addresses.

From our data side, we focus on network diversity and conduct continuous measurements. Due to the nature of our measurements and our knowledge of the precise locations of all 1330 servers, we understand how network packets travel across the internet. We simplify this information into algorithms and know how to accommodate detours that packets may take. There are specific patterns that we can identify and map, like some African servers route their traffic through LINX or a French IXP. If you are not connecting to private networks or even major telecoms on EU-based IXPs.

To help the system, we are reaching out to IXPs, major telecoms and peering agencies to advise them on how to peer and make critical internet routing decisions. We want to tell them on how to engage in data-focused peering, how their IXP is perceived from a broader internet data perspective, and how their packets from the IXP travel across the internet. We hope this colloboration will bring much needed efficiency in internet routing.

Thank you, Dimitry. Everyone at IPinfo really appreciates the shoutout!

---

Our research scientist, Calvin, will be giving a talk at NANOG96 on Monday that delves into active measurement-based IP geolocation.

https://nanog.org/events/nanog-96/content/5678/

I work for IPinfo. We are launching a collaborative project with IXPs and major internet organizations to share raw measurement for routing and peering data for this purpose.

Latency variability is a huge issue. We run both traceroute and ping data, and we observe that there are entire countries that peer with IXP thousands of miles away in a different continent.

We bought a server from the oldest telecom company in the country and recently activated it. Currently, there is a 20 ms latency when traffic is directed towards the second oldest telecom. The packets have to travel outside the country before coming back in. This is a common phenomenon that occurs frequently. So, we usually have multiple servers in major cities since various ASNs have different peering policies.

For us we can map those behaviors and have algorithms and other data sources, make measurement-based geolocation perform well.

We are hoping to support IXPs, internet governance agencies, and major telcoms in identifying these issues and resolving them.

That is a great point! For us, it is 100% of end users not limited to our customers. If you are impacted by our data in any way, it is on us. We are accountable for that.

https://community.ipinfo.io/t/wrong-geolocation-based-on-ip-...

Our free database is licensed under "CC-BA-SA" (freely distributable but requires attribution) because of accountability. If you use our data as an enterprise or a free open-source project, if there is any issue, you can come to us and talk with us.

It is not even end-users. We maintain open communication policies in general. Even if a streaming service does not use our data, if they come to us, we try our best to help them based on our industry knowledge.

I am not sure whether this kind of IP spoofing will impact our accuracy because we will likely identify the noise and behavioral anomaly and discard the location hint derived from traceroute.

We have tons of historical traceroute data patterns, and generic traceroute behaviors are likely modeled out internally. So, if you can spoof the traceroute to your IP address, our traceroute-based location hint scoring weight for that IP address will decrease, and we will rely on the other location hints.

You have to be extremely deliberate to misguide us. But I would love to see this in action, though.