Turn Off Address Logging With a Single Switch

Starting today, you can disable address logging for your entire account from a single place. Head over to your Customer Dashboard and you'll find a new setting called Address Logging. Switch it off and from that point on, none of the addresses you check with us, whether IPs or emails, get saved anywhere. Each address is used to answer your request and then discarded the instant that request finishes, no address is written to a log, a database, or anywhere else.

Above is a screenshot showing the new toggle positioned below the Main API and Dashboard API access toggles.

The Trouble With Per-Request Flags

Long-time users will know we've offered a way to do this on a per-query basis for years. Supplying &tag=0 with a request to our API tells us not to log that particular check at all, and it still works exactly as it always has. But it has some limitations we wanted to solve.

First, it has to be added to every single request. That's a minor inconvenience if you're calling our API from your own server-side code, but if you're using one of our plugins, a third-party library, or a CMS integration that doesn't give you a way to bolt custom query flags onto the request URL, you simply couldn't use it, the flag had no way to reach us.

Second, &tag=0 only ever worked on requests made to the API itself. If you checked an address directly through our Single Lookup or Batched Lookup pages, there was no request URL for you to add a flag to in the first place, so those checked addresses were always logged somewhere if only briefly.

Third, this helps you with compliance. Some customers really cannot have any addresses logged and they don't want to mistakenly ever have an address logged by us simply because they forgot to send &tag=0. We respect the need for a bulletproof anti-logging feature and that is what this toggle provides.

One Setting, Every Request

The new Address Logging toggle solves all these problems by moving the decision out of the request and into your account. With logging disabled, every address you check is treated the way &tag=0 already treats a single request, except now that applies automatically and everywhere: server-side API calls, the client-side snippets on the CORS tab, our plugins, and both of our web lookup tools. It also takes priority over anything you send in the tag flag itself, so even a request with a descriptive tag attached won't be logged. You don't need to touch a single line of code or a single request URL to benefit from this toggle.

And to be clear, &tag=0 isn't going anywhere. If you'd rather keep logging on generally and just exclude a handful of especially sensitive requests, that flag is still there for exactly that. The new setting is for when you'd rather make the decision once, for your whole account, instead of repeating it on every request.

Worth Knowing Before You Flip the Switch

Disabling Address Logging doesn't change the answers you get back. If an IP address is anonymous, or an email address is disposable, we'll still tell you so, the detection data we hold is unaffected. What changes is purely what we keep about your own account's activity afterwards. Your positive detection log relies on us keeping a record of your positively identified addresses, so with address logging switched off you won't see new entries appear there. If you lean on that data to spot brute-force login attempts or see which pages are taking the most abuse, it's worth keeping that in mind before you switch this on account-wide.

You'll find a little notice like the screenshot above if you've disabled address logging globally to let you know why it's not updating.

Where to Find It

The new Address Logging setting is live right now in your Customer Dashboard. If data minimisation matters to you or your customers, this is the simplest way we offer to accomplish that. You can read more about how and why we handle addresses the way we do on our GDPR compliance page.

This new feature has been implemented across all supported versions of our API which means it works for all v1, v2 (2023+) and v3 requests.

Thanks for reading and have a wonderful week!

Say Hello to Fermi and Kepler, Our Newest Servers

If you've been with us for a while, you'll know that every server in the proxycheck.io network gets a name pulled from space. Today we're welcoming two more members to that family: Fermi, now serving North America, and Kepler, now serving Europe.

Both names are a nod to two scientists whose work still shapes how we look at the universe, and, fittingly, both have NASA space telescopes named after them too. Here's a bit about where the names come from, and why these particular servers matter more than most.

Meet Fermi

Enrico Fermi (1901–1954) was an Italian physicist whose career touched almost every corner of modern nuclear and particle physics. He won the Nobel Prize in Physics in 1938 for his work on induced radioactivity, and a few years later led the team that built the world's first nuclear reactor, achieving the first self-sustaining nuclear chain reaction in 1942. The class of particles called fermions, and the element fermium, are both named in his honour.

NASA's Fermi Gamma-ray Space Telescope has carried his name into orbit since 2008. It scans the sky for the highest-energy light there is, gamma rays, tracking everything from pulsars and supernova remnants to flares from supermassive black holes.

Our new Fermi server is deployed in North America and features AMD's latest Zen 5 architecture.

Meet Kepler

Johannes Kepler (1571–1630) was a German mathematician and astronomer best known for his three laws of planetary motion, which described, for the first time, how planets actually move around the sun in ellipses rather than perfect circles. Working from the painstaking observational data of his mentor Tycho Brahe, Kepler's laws went on to form much of the foundation Isaac Newton later built his theory of gravity on.

NASA's Kepler Space Telescope carried that legacy forward from 2009 to 2018, staring at a single patch of sky and watching for the tiny brightness dips caused by planets passing in front of their stars. It's responsible for confirming thousands of exoplanets, and for fundamentally changing how we think about the prevalence of other worlds.

Our new Kepler server is deployed in Europe, and also features AMD's latest Zen 5 architecture.

Why these two servers are special

Fermi and Kepler aren't just new additions, they're currently the most powerful servers in our entire fleet, built on AMD's latest Zen 5 architecture with plentiful DDR5 memory and PCIe 4.0 NVMe drives, like all our other server nodes these are bare metal servers, we do not share their resources with any other tenants which guarentees performance and security.

Now we do want to discuss the less than glamorous reason we brought these two servers online now rather than next year when we intended to refresh all our server hardware:

• DRAM and NAND flash storage prices have been climbing noticeably, and the trend doesn't look like it's reversing any time soon.
• Server availability from our datacenter hosts has been drying up fast, with lead times stretching out and stock becoming harder to secure.

Put those together, and the risk became clear: even though we didn't strictly need Fermi and Kepler online today, we could see a real possibility of needing that capacity in 2027 and simply not being able to get our hands on it when the time came. Rather than gamble on availability and pricing one-to-two years from now, we decided to secure our own supply early while we still could.

What this means for you

In practical terms, this means more headroom, more redundancy, and faster responses across North America and Europe as traffic continues to grow. As always, our full server status and locations are visible on our service status page, so you can see all our nodes and their health status.

Thanks for reading and have a wonderful weekend!

v3 API Goes Stable: The Beta Tag Comes Off

Ten months ago we launched an open beta of our v3 API and as of today, the v3 API is officially out of beta and is now our new stable API.

Before we get into what's changed, we want to say thank you. A beta is only as good as the people willing to use it before it's finished, breaking things, filing reports and rebuilding their integrations against a target that kept moving. Many people did exactly that for the better part of a year, and v3 is a far better API for it.

A Quick Look Back

We introduced the v3 beta back in August 2025, and since then we've shipped several major beta releases, each one chipping away at rough edges like the output format and adding new capability:

• August 2025: First beta with a brand new output format featuring nested categories and a new detections array.
• October 2025: Timestamps moved to the ISO 8601 format making them both machine and human readable without sacrificing per-second accuracy.
• November 2025: Confidence scores arrived, alongside first_seen and last_seen timestamps for every detection.
• February 2026: detection_history and attack_history became permanent fixtures of every response, and the operator section gained services and additional_operators.
• May 2026: A full OpenAPI v3.1.0 specification was published, covering both the v3 API and our Dashboard APIs.

Each release was a stepping stone, and today's stable version is all of that put together, polished, with an output format that can take us into the next decade.

What Actually Changed From v2

If you haven't been following the beta closely, here's the short version of what makes v3 a genuinely different API rather than just a version number bump.

Everything is nested and consistent. Instead of a flat list of fields that may or may not appear, you now get clearly organised sections: network, location, operator, and detections. Every section is always present. If we have nothing to tell you, you'll get a null rather than a missing key, so your code never has to guess whether a field exists at all.

Booleans instead of strings. No more checking if a string equals "yes". Proxy, VPN, TOR, hosting and the rest of our detections now return true or false, the way they always should have.

Multiple detections at once. An address can now be flagged as a VPN and a scraper and have a history of compromise simultaneously, rather than forcing a single label onto an address that's clearly doing more than one thing.

A far fuller response by default. Almost every query flag from v2 has been retired because v3 simply gives you the full picture without you needing to ask for it piece by piece. This lets us optimise for always generating a full result which improves cache hit rates and lowers response times for every request.

Real HTTP status codes. Denied and failed requests now come back with proper 401, 403, 429 and 400 codes instead of a 200 OK hiding a denial in the body of the response, so your monitoring and error handling can finally behave the way you'd expect from a modern API.

Confidence scores alongside risk scores. Risk tells you how dangerous an address looks. Confidence tells you how sure we are about the detection behind that score. Used together they let you build far more nuanced rules than a simple yes or no ever could.

Detection history and attack history as standard. You can now see whether a positive detection is still live or has been delisted, and exactly when, plus a clean breakdown of the kinds of attacks an address has been involved in.

Deeper operator intelligence. Knowing an address belongs to a VPN is useful. Knowing which VPN, what services that operator provides, and which other operators have also been seen running the same address is a different level of useful entirely, and that's exactly what the expanded operator section now gives you.

Smoother under load. On top of all the format changes, v3 is also simply faster and steadier at scale, with noticeably less jitter between responses when you're sending large volumes of requests.

What This Means If You're Still On v2

Nothing changes for you today, and nothing has to change for a very long time. We are committed to supporting the v2 API until 2035.

We mean that. There's no countdown clock hidden in the fine print and no plan to quietly nudge you off it before then. If v2 is doing its job for your application, keep using it. The same servers, the same reliability and the same support still backs it.

What going stable does mean is that v3 is no longer a moving target. The structure you build against today is the structure you'll be working with for the long haul, which is exactly the kind of stability you want before committing a production system to a new API version.

If you've been holding off starting a new integration until v3 settled down, or you're planning one now, this is a great time to make the move.

Getting Started

• Point your requests at the v3 endpoint. No version flag required, you'll automatically receive the latest stable release.
• Select Latest Stable Version from the version dropdown in your Customer Dashboard if you'd rather pin it explicitly.
• Read through the full API documentation for every field, flag and response type.
• Import our OpenAPI specification into Postman, Insomnia, Swagger UI or your code generator of choice.
• Take it for a spin in the test console before spending a single query against your daily allowance.

We genuinely couldn't have gotten v3 to this point without the people who used it while it was still in beta, filed the issues, asked the awkward questions and told us when something didn't sit right. Thank you, sincerely.

Here's to a stable v3, a supported v2, and another decade of keeping the internet a little more honest.

Thanks for reading and have a wonderful week!

One of the most consistently requested things from developers integrating our service into their software has been an OpenAPI specification and today we're happy to say that wait is over. We've published an OpenAPI v3.1.0 specification covering both our v3 API and our Dashboard APIs, and it's available right now from our API documentation page.

Why Now?

With our v3 API preparing to leave open beta and become our new stable API, this felt like exactly the right moment to ship the spec. We wanted it in place before v3 goes stable so that developers building integrations from day one have a machine-readable description of the API to work with rather than hand-rolling clients purely from written documentation.

It has been one of the most frequently requested things we've heard from users over the years, and we're glad we were finally able to prioritise getting it done properly. Producing a spec for an API that's still in active development is a balancing act, but we felt the timing was right. The v3 API has now gone through several substantial beta releases and its structure has settled considerably.

What's Covered?

The specification covers both major surface areas of our API offering:

The v3 API
Our new-generation proxy, VPN and threat intelligence API. This includes IP and email address checking, the full response schema (network data, location, detections, risk scores, confidence scores, operator information, detection history, attack history and more), query flags, and all status and error response formats.

The Dashboard APIs
The full suite of programmatic dashboard controls, including positive detection exporting, tag exporting, account usage and query volume exporting, custom list manipulation (add, remove, set, clear, erase), custom rule management (print, enable, disable), and CORS origin list management.

All of this is described using the OpenAPI v3.1.0 format, which is the current specification version and brings full alignment with JSON Schema, meaning you can use the spec directly with any modern tooling that supports it.

What Can You Do With It?

Having a formal OpenAPI spec opens up a lot of practical possibilities for developers:

• Generate a client library in your language of choice using tools like openapi-generator or Speakeasy. If your language isn't yet represented in our code libraries, this is the fastest path to a typed, fully featured client.
• Explore the API interactively by importing the spec into Swagger UI, Scalar, or Stoplight — useful for understanding the response schemas before you write a single line of code.
• Import it into Postman or Insomnia and have a ready-made collection of every endpoint, with example request parameters and expected response shapes already filled in.
• Validate your integration by using the spec to confirm that your code is constructing requests correctly and handling all documented response fields.
• Stay up to date — as the v3 API evolves post-beta we'll be keeping the spec in sync with the documentation, so you'll always have an authoritative reference.

Where to Find It

The spec is documented and available for download from the OpenAPI Spec section of our API documentation found here.

A Note on the v3 API Beta

For those who haven't been following the v3 beta, our v3 API is a significant overhaul of how we present data. It moves to a fully nested JSON structure, returns booleans instead of yes/no strings, always includes a rich set of detection data without requiring individual query flags, introduces proper HTTP status codes for denied and failed requests, and adds new sections like detection_history and attack_history. It also brings a confidence score alongside the risk score, giving you finer-grained control over how aggressively you act on detections.

If you're currently on v2, there's no rush. We're committed to supporting the v2 API for at least until 2035. But if you're starting a new integration, v3 is where you want to be, and the OpenAPI spec is the best place to start.

As always, if you have any feedback — on the spec, the API, or anything else — please get in touch. We do read and reply to every message. Thanks for reading and have a wonderful week!

Ten years ago, proxycheck.io opened its doors with a single purpose: give developers and website operators a fast, reliable way to detect proxy and VPN traffic. A lot has changed since then, but our purpose hasn't.

We started as a simple API, just a single page service and completely free. Today, proxycheck.io is a globally distributed, multi-region detection platform fielding billions of queries every month for customers ranging from solo developers running hobby game servers to enterprise businesses protecting their platforms at scale. This birthday post is a chance to look back at how we got here, celebrate what we've built, and share our sincere thanks towards all our customers.

The world we launched into

When proxycheck.io launched, the proxy landscape looked very different. The overwhelming majority of proxied traffic ran through free, open proxy servers — poorly maintained machines with forwarded ports, scraped from lists updated every few hours. Detection was a relatively straightforward cat-and-mouse game: collect the IPs, publish a list, update it regularly.

Ten years on, that world is gone. The rise of residential proxy networks - services that route traffic through millions of ordinary consumer devices using mobile broadband and home broadband connections - has fundamentally changed what detection means. You can't just block a datacenter range anymore. You're contending with addresses that look, to every other system, exactly like a real home user in a real city. Keeping up with that shift is perhaps the defining technical challenge of our second decade.

A timeline of the last ten years

2016 - Service launches with the v1 API

2017 - Inference engine added and honeypots

2018 - v2 API ships; bulk IP checking is added with a new API format

2019 - Risk scores, attack history & custom rules introduced

2020 - CORS support & North American infrastructure goes live

2021 - VPN operator cards; dark mode dashboard; Asian infrastructure goes live

2022 - Postcodes added to the API; HA improvements; Unified Changelog;

2023 - Timezone & currency data added to the API

2024 - New status page; device estimates and hostnames added to the API; Account Activity Log;

2025 - v3 API beta begins; confidence scores are added;

2026 - 100 times improvement in residential proxy coverage; detection history added; 10th birthday

And alongside those major features we redesigned many things, the dashboard saw lots of love, the web interface, the lookup pages, our API documentation and the site in general with our light/dark glass themes and navigation bar.

Milestones we're proud of

2019: Custom Rules We gave customers the ability to write their own logic on top of our API. Whether whitelisting cloud gaming services, blocking specific VPN operators or entire nations this feature lets you do it all. This feature that started with just 3 rules allowed per account has grown to become one of the most popular features we offer, in-fact thouands of accounts have created or imported at-least one rule each. This was such a monumental feature for us as it was extremely complicated to implement and took a massive amount of engineering effort.

2020: First servers outside Europe For the first three years, every request routed through our European infrastructure. The launch of our North American cluster was a milestone: suddenly customers in the Americas saw dramatically lower latency, and we had real geographic redundancy for the first time. This was a big monetary commitment to invest in our potential growth and acquire more customers in North America, it did pay off and we've since expanded our infrastructure there twice aswell as adding servers in Asia.

2021: VPN Operator Cards Rather than just returning "VPN: yes", we began telling customers which VPN operator controlled an address, with rich metadata they could build real logic around. The operator intelligence in our new 2026 v3 API - including cross-operator detection and specific service classification - is a direct evolution of this original idea.

The thing we've never changed

Across every API version, every server upgrade, and every pricing revision, one thing has stayed constant: our free plan. One thousand queries per day, with full access to the exact same data and detection accuracy as every paid plan. No degraded results, no watermarked data, no bait-and-switch.

We've also kept something else consistent: our pricing philosophy. When we raise prices - as we did for the first time in six years this past January - existing subscribers kept their existing rate. Loyalty is rewarded here, not penalised. The price you initially subscribed at is the price you pay until that subscription is changed or cancelled.

Thank you, truly.

None of this exists without the people who trusted proxycheck.io early - the platform operators who integrated us into their first Minecraft servers, their early WordPress blogs, their website authentication systems. The developers who wrote libraries, plugins and applications that integrated our API. The customers who sent us bug reports and feature requests. You all made this service what it is and we won't ever forget that.

Ten years. Here's to the next ten, thanks for reading and have a wonderful week.

Over the past several months we've been focusing heavily on residential proxy services. The kind of service where you pay a subscription to proxy your traffic through mainly wired residential and wireless 4G/5G internet connected devices.

The reason we've placed such a focus on these services is because of their growing prevelance, the days of free and abused proxies being the predominent type of proxy on the internet is long gone and now paid services that offer access to millions of consumer devices have taken over.

But these do present a problem for a service like our own because unlike the free proxies these don't require port-forwarding and the paid services never provide a raw IP address for you to connect through directly. Instead the addresses are masked behind gateways that are controlled by the paid service and they forward your traffic to a randomly selected IP address within their fleet of devices.

Due to this it's not uncommon to be given an IP address which is shared by many customers of the same internet service provider via technologies like CG-NAT or the address stops acting as a proxy server very quickly when it belongs to an internet service providers dynamic address pool with short lease times.

So we've been trying to tackle this issue, the main way we've gone about it is by massively increasing the number of services we access to obtain the addresses of their entire fleet while simultaneously reducing the time we list each individual address for. This has had the benefit of reducing false positives while maintaining a decent detection rate of addresses that are still acting as proxy servers.

But it hasn't been as good as we would have liked. For every hour that we reduce the time we list an IP we're giving up literally thousands of working proxies that should still remain detected. So to tackle this problem with more nuance we've added a new rules-based system to our address collector which will increase or decrease the timeframe that we list an IP based on several factors including:

1. How many times we've used the IP successfully as a proxy server.
2. How long its been since we first used the IP successfully as a proxy server.
3. How recently we used the IP as a proxy server prior to the latest detection.
4. How many unique sources provided us the same IP address.
5. Specific weights for specific proxy operators as some use more dynamic addresses than others.
6. Specific weights for specific internet service providers as some use CG-NAT or have very dynamic address pools.
7. Specific weights for different line types (Residential, Wireless, Business, Hosting etc).

This new rule based system doesn't just apply to residential proxy services with known operators, it also applies to our VPN detection and all other kinds of positive determinations that we're performing. This system is highly variable and may increase the time we display an address by as little as 0.5% or by as much as 1,000%.

The point of the system is to allow us to still expire addresses that we've only seen once or rarely very quickly while making sure that the most abused addresses don't get delisted too early.

As we mentioned above while reducing the time we display an address helped prevent false positives there have been occasions where we've seen some addresses that have clearly been abused as proxy servers for a long time (more than a month continually) get delisted early merely because we weren't given them by a residential proxy service frequently enough for them to remain listed.

In one case we had listed and then delisted an address more than 30 times leaving many hour-long gaps in its detection due to the infrequency that we were given the address combined with how soon we were delisting it. With the new system this wouldn't happen and this address in our simulations would have remained listed for the entire time period that it was being abused.

This change is live right now for all our v1, v2 and v3 API versions as this is a backend change to the amount of time we store and display positive detections and not an API specific logic change. We launched this change today after extensive testing and our hope is it will allow us to further reduce default listing times once enough data has been built up for the rules to work effectively.

Thanks for reading and have a wonderful week!

We're excited to announce a major update to our ongoing v3 API beta, released today this version introduces some major new features and enhancements, as a result we've issued a new dated version which is selectable from within Customer Dashboards, or by supplying &ver=11-February-2026 with your requests to our v3 API endpoint.

What's New

Detection History Tracking

Our API now includes detection_history, providing you with a complete timeline of an IP addresses listing status. This feature shows:

• Whether the listing is currently live or has been delisted
• Precise timestamps in ISO 8601 format indicating when entries were or will be delisted

This historical context helps you understand the lifecycle of positive detections and we have a new query flag to view historical data.

The &history=1 flag

When you provide this flag we will show you the positive detections we've had for this address no matter how long ago they were. You can also combine this with the &days= flag to restrict the history between now and a point in the past you care about.

For example if you supply &history=1&days=7 we will show you the full positive detection history of an IP over the past 7 days even if we've delisted it from our live results. Without the &history=1 flag the &days=7 may be disregarded if we've already delisted an IP due to us not being confident about the determination anymore. We may lose confidence in a listing due to its age, this is because the listings become stale and thus inaccurate unless the data is refreshed, if we've not seen an IP acting maliciously in a while it's likely safe again and thus needs to be delisted.

In the past we allowed the &days= flag to act like a history flag, but due to misuse by customers we restricted how far back it can go to no further than our delist times for the data we hold, this &history=1 flag brings back the capability to look further back beyond our delist times whilst maintaining the metadata you need regarding the addresses delisting time so you know whether we've delisted the data before you make a final decision.

Attack History & Classification

The "new" attack_history feature delivers comprehensive intelligence about recent malicious activity. I put new in quotes because this is actually a feature from our v2 API that we've brought to the v3 API. It's simpler, more standardised and thus easier to parse programmatically. For each IP address, you'll receive:

• A list of the attack types the IP has been observed partaking in
• Numbered counts showing the frequency of each attack type

Gone from the v2 API is a numbered total, you can easily do this in your own programming language so it felt redundant to include in this version. This granular attack data should enable you to assess threat severity and be more granular about the addresses you allow to access your sites and services.

Enhanced Operator Intelligence

We've significantly improved the operator information section with two key enhancements:

Specific Service Classification

We now identify the exact services provided by IP address operators as an array, which means you may receive one or more of these services in the new services section of the operator data:

• Residential proxies
• Wireless proxies
• Datacenter proxies
• Residential VPNs
• Datacenter VPNs
• Web scraping
• And more

Cross-Operator Detection and Display

The new additional_operators key reveals other operators we've observed controlling the same IP address. This multi-operator insight helps you:

• Identify IP addresses with shared infrastructure
• Detect operator networks and relationships
• Understand when an address is experiencing broad abuse

We will always put the most common operator we see as the main/primary operator with the others as additional operators. The reason we've added this section at all is because our huge increase in residential proxy detection has revealed a lot of shared infrastructure amongst these organisations.

To put it simply, they're sharing the same pool of compromised computers and we want to show that in our data so you can more easily identify addresses you should always keep blocked, the most abused ones.

We've also updated our lookup pages to show additional operators in the top operator card section.

Some API output format changes

The biggest change regarding the API format is that the operator section will now always be present for every IP but if no operator is available you'll receive an operator: null result. This is the same for our new detection_history and attack_history sections, if data doesn't exist they'll say null too.

We've done this to keep the API response consistent and to make developers aware that there may be additional data presented even if the IP they're checking right now doesn't feature it.

Getting Started

This new dated version of the API is available right now as we mentioned at the top you can select it from within the Customer Dashboard or by supplying &ver=11-February-2026 with your requests to our v3 API endpoint. Thanks for reading and have a wonderful week!

Enhanced Proxy Detection and Strengthened Security

We're excited to share two significant updates that improve both the accuracy and security of our platform.

10x Increase in Residential Proxy Detection Coverage

We've dramatically increased our residential proxy address collection, specifically we're now collecting 10 times the volume of proxy addresses per day compared to what we were doing a week ago. This substantial increase will have a direct correlation on proxy detection rates and we're not done, we intend to further increase our detection rate of residential proxies in the coming weeks as we tune the infrastructure we've built to tackle this problem.

Improved Accuracy Through Reduced Display Time

With this increased data collection rate, we're now encountering the same residential proxy addresses multiple times within a 24-hour window. This repeated observation has enabled us to make an important optimization: we've reduced the average display time of results on our API from 48 hours to 24 hours for residential proxies.

This change delivers a meaningful reduction in false positive rates. Here's why: when we observe a proxy address multiple times in quick succession, we can confidently extend its active status. Conversely, addresses that appear only once or twice and then disappear are more likely to be outliers—IP addresses that have ceased operating as proxy servers. By tightening our display window to 24 hours, we can more effectively filter out these outliers while maintaining coverage of genuinely active proxy infrastructure.

The net result is fresher, more accurate data that better reflects the current state of residential proxy networks and a reduction in the support tickets made by your customers to request their addresses be allowed to access your services.

Comprehensive Security Infrastructure Audit & Upgrades

In our ongoing commitment to protecting our platform, we've performed an internal security audit and implemented a suite of security protocols:

DNS and Email Security Enhancements

DNSSEC (Domain Name System Security Extensions): We've deployed DNSSEC to protect against DNS spoofing attacks, ensuring that users connecting to our platform are actually reaching our legitimate servers, not malicious imposters.

CAA (Certification Authority Authorization): By implementing CAA records, we've explicitly specified which certificate authorities are authorized to issue certificates for our domain, reducing the risk of fraudulent certificate issuance.

MTA-STS (Mail Transfer Agent Strict Transport Security): This protocol enforces encrypted SMTP connections for email delivery, preventing man-in-the-middle attacks on our email communications.

Enhanced SPF (Sender Policy Framework) Records: We've refined our SPF configuration to better prevent email spoofing and improve our email deliverability and authenticity.

TLS-RPT (TLS Reporting): We've enabled TLS reporting to monitor the effectiveness of our email security measures and quickly identify any delivery issues or potential security incidents.

Automatic Email Replies: Not really security related but we noticed in our audit we do not automatically reply to a customer email to let you know we received your mail and to expect a reply from us. We now send these so you can be sure your mail reached us successfully.

What This Means for You

These security enhancements work together to create multiple layers of protection for our platform and your data. From preventing domain hijacking to securing email communications, these protocols represent industry best practices in modern web security.

Looking Forward

These updates reflect our dual commitment to delivering accurate, timely threat intelligence while maintaining the highest security standards. As residential proxy networks continue to evolve, we'll continue investing in both our detection capabilities and our infrastructure security.

If you have questions about these updates or how they impact your use of our platform, please don't hesitate to reach out to our support. Thanks for reading and have a wonderful week!

Today we've deployed a new server in Singapore to double the capacity and redundancy of our Asian infrastructure. We're doing this because last month we had an ill-timed fault with our only Asian server which we weren't able to resolve for about 10 days and so we wanted to expand our Asian infrastructure so that our customers don't face higher latency if the same thing were to occur again and also if we're performing scheduled maintenance.

You may have seen in the news recently that the price of memory and to a lesser extent storage has increased in price due to demand far exceeding worldwide supply. This has had an impact on our urgency to add an extra server before the pricing became completely unreasonable, already this server while being the same specification as our other Singaporean server will cost us twice as much every month and it had a significant up-front allocation fee when in the past no fee was imposed.

In addition, while Singapore is a great place to host servers as it has great network connectivity to surrounding countries and a stable government it has some of the highest square-meter land costs in the world and as a result datacenter space is sold at an extreme premium. We are looking to pay eight times higher prices for servers in Singapore when compared to India and three times higher costs compared to Europe. So us having multiple servers there is a significant monetary investment but one we know will benefit our growing customer base.

So that's the update for today, the new server called PLUTO is live and accepting requests right now. As always, thanks for reading and have a wonderful week.

As we mentioned in this blog post on November 1st we would be increasing our prices in January 2026, and as it's the first day of January we decided to do it today. We also wanted to note that we kept large disclaimers available for two months on both our pricing page and customer dashboard, explaining how to lock in the lower prices ahead of today. This way, everyone was well-informed about the upcoming price increase and could plan accordingly.

Every price of every plan we offer has increased however the percentage of the increase differs between plans with the largest proptional increase in price focusing on our Business and Enterprise plans. For our most popular Starter plans we've increased the prices by only $1 which is effectively a 33% to 20% increase depending on the Starter plan.

This means our previous lowest plan, which has been $2.99 since January 2020, is now $3.99. We think this still offers incredible value and we've not changed any plans quantity of daily queries, custom rules, custom lists or burst tokens. Same features, same service just at a new price.

For our Pro plans we've raised the first plans price from $6.99 to $9.99 and we like the idea of seperating each of our three Pro plans by $5 instead of the previous $3.

As mentioned, the largest increase comes to our Business and Enterprise plans. The first Business plan which used to be $19.99 is now $29.99 which represents a 50% increase. Similarly, the last Buisiness plan, which was $49.99 is now $99.99, which represents a 100% increase in price. We've done this because the cost to deliver this plan (2.56 Million daily queries) is substantial and we want to be able to purchase more powerful servers to better serve the high capacity needs of our largest customers.

As we move to the Enterprise plans, the first plan has also seen a 100% increase from $99.99 to $199.99 and that's because we're sticking to a linear cost-per-query structure beginning at the 1.28 Million daily queries mark (Business plan, $49.99 per month). So for every 1.28 million daily queries, it'll cost $49.99, which is why the 5.12 Million plan is now $199.99 (4 x $49.99 essentially plus a few cents) and our largest 10.24 Million plan is now $399.99, up from $199.99. We do want to point out that we're one of the few SaaS businesses in the industry that has transparent and available enterprise pricing right on the webpage. We don't do "call us for pricing" sales tactics that lead to upselling.

Now as always, when we increase our prices, they only apply to newly started or altered plans. So the subscription you already hold will not change in price, you will continue to pay your existing lower price until you cancel your plan. We've also updated the plan section area within the Dashboard to clearly show that you're subscribed to a plan at a lower price than currently offered so it's not confusing.

We know that nobody likes price increases, we've been able to keep our prices the same since 2020 but unfortuantely the higher costs of everything, including energy, infrastructure, advertising and more, have meant we needed to increase our prices. Thankfully, we have a lot of plans, which means we can offer pricing that fits exactly what you need to save you the most amount of money and we've been able to protect our lowest cost starter plans, keeping them very competitively priced, which maintains the accessibility of our service.

And of course, we still offer our full-featured free plan that has complete access to the exact same API results as our paid plans with 1,000 daily queries. We're fully committed to our free plan and we have no plans to stop offering it or degrade it in any way.

Thanks for reading, and have a wonderful new year.