Since we last updated our API 48 hours ago we've been recording the average TTFB (Time To First Byte) of our service at our CDN (Content Delivery Network) and we've been comparing those numbers to our previous numbers leading up-to the upgrade.

What we've found is a vast difference in performance with the new code far outperforming the old code. We've made a graph below showing the numbers and then we'll go into a brief analysis.

What you're seeing above is 48 hours of queries to our API leading up-to the code change in red and 48 hours after the code change in blue. On the far left is the percentage of queries and along the bottom is the time it took that percentage of queries to be answered by our API.

So these numbers include not just the processing time on our servers but also the network overhead in the time it takes to retrieve the answer from us over the internet.

As you can see in the graph the new code is vastly outperforming the old code. Where as before we were only answering 1.76% of queries within 25ms we're now answering 23.07% of queries within 25ms.

Where before we were answering 18.47% of all queries in under 100ms we're now answering 62.64% of all queries in under 100ms. Previously we answered 59.56% of all queries in under 200ms, now we're answering 90.96% of all queries in under 200ms.

With these changes it means you can now use the API in more latency sensitive deployments. We couldn't be more thrilled with these results and we've been very excited to share the difference in performance with you.

Thanks for reading and we hope everyone had a great weekend!

At the end of April we shared with you some performance numbers for the new update to our v2 API which enhances VPN and ASN lookup speed. Today we're pleased to announce that the update is now live on our v2 endpoint.

This update has been a large undertaking as we not only focused on speed but also improving accuracy. For over a year we have been painstakingly adding VPN providers to our dataset but frankly there are thousands upon thousands of datacenters all over the world that can at a moments notice offer service to any of the thousands of VPN providers operating globally.

So we set upon a new strategy. Firstly the way we were blocking VPN's previously (blocking ASN's that served specific datacenters) was a good strategy but it had some flaws like we couldn't make exceptions for companies that use these same ASN blocks for residential or business internet access. It also meant we often gave out the incorrect provider name for a VPN service when we blocked their ASN range.

With our new VPN code launched today both of those issues have been solved. We can now block ASN's while making exceptions for specific IP Ranges or providers and we always give you the most accurate provider name for a specific IP even if they share an ASN range with another company.

Another change we've made is we're now using a new Machine Learning system for VPN detection. This is a real-time inference engine which will make determinations for all queries that have the &vpn=1 flag. This new engine has already broadened our VPN detection rate by 8% in testing when combined with our previous VPN detection methods.

The last thing we wanted to discuss is our Real-Time Inference Engine for proxy detection. With this update to v2 where we've introduced the new VPN Inference Engine we have made quite a performance breakthrough. By using enhanced math functions in the processors of our nodes combined with pre-computing computationally heavy instructions and storing their results we have been able to greatly reduce inference time from an average of 250ms to just 1.5ms. This is why we have not added a disable feature for the Inference Engine when performing VPN checks, it's simply so fast there was no need.

And that brings me to the benchmarks. In our testing with VPN, ASN and Inference checks enabled, supplying the API with 1,000 IP's in a single query it would previously take up the entire 90 second query window and only check 300 of the 1,000 IP's.

With the new code we're able to supply 10,000 IP Addresses with the same flags enabled and receive results for all 10,000 addresses within 10.5 seconds. This is a vast improvement which means you no longer need to forgo VPN, ASN or Inference Checks to get the fastest results possible. For single queries checking a single address we're seeing a consistent query time of under 6ms (after network overhead).

If you're not already using our v2 API we highly recommend the upgrade, not only is the detection for VPN's more accurate but the speed enhancements are unreal. We have ported some of this functionality back to v1 just to maintain compatibility but we cannot guarantee it will be as fast. As always all of these new features are available immediately to all customers whether you're on a paid or free plan.

Thanks for reading, we hope everyone has a great weekend.

When we launched our recent refresh of the v2 API in March we spoke about some of the things we were planning for the near future including VPN and ASN lookup speed enhancements.

Today we're ready to share with you a preview of those performance enhancements and they are quite significant. So firstly we'd like to show you how long it takes to check 100 IP Addresses under the current v2 API when checking both for VPN's and ASN's but with the Real-Time Inference Engine turned off.

Current v2 API with VPN and ASN checks enabled: 100 IP Addresses in one query

Query Time: 22.326 Seconds

And now with our new code, with the same level of accuracy.

New v2 API with VPN and ASN checks enabled: 100 IP Addresses in one query

Query Time: 0.452 Seconds

That's a dramatic improvement. But look what happens when we check 1,000 IP Addresses using the new code.

New v2 API with VPN and ASN checks enabled: 1,000 IP Addresses in one query

Query Time: 2.882 Seconds

And this is with no caching, all of these addresses were generated randomly and haven't been put through the API previously. With this kind of speed improvement it means there's no reason not to enable VPN and ASN checks any longer. We've found in testing that the previous code would take between 250ms and 350ms for both a VPN and ASN reply on a single address within a single query.

But with the new code we're seeing results of between 6ms and 10ms (depending on the node answering the query) for a single address in a single query and between 2-3ms per IP when performing a multi-check. These are huge improvements and it's not just about speed we're also enabling enhanced VPN checks with this new code so that we can detect VPN's more efficiently.

We think we'll be rolling this update out later this week on our v2 API, you won't need to alter any of your client side code as the result format from the API is not being altered.

Thanks for reading and have a great week!

For some time we've been looking for a new server to add as a node within our cluster to replace ATLAS, one of our current nodes.

We added ATLAS to the cluster last year mainly as a way to get some more redundancy. The chances of three geographically separated servers going down at the same time is higher than two.

But as the queries have increased more than 10x what they were when we added ATLAS it has come time to let it go and for us to replace it with a more capable server.

Here are the specs of ATLAS, HELIOS and PROMETHEUS.

• ATLAS: Core i3, 3.3GHz, 2 Cores, 2 Threads. 8GB of RAM. - 100Mbps network
• HELIOS: Core i7, 3.4GHz, 4 Cores, 8 Threads, 16GB of RAM - 1Gbps network
• PROMETHEUS: XEON E5, 3.6GHz, 16 Cores, 32 Threads, 64GB of RAM. - 400Mbps network

As you can see ATLAS is by far the weakest node and although it served its duty by giving us the redundancy we wanted it simply couldn't keep up with some of our more demanding features such as syncing customer statistics and the inference engine. It was essentially pegged at 95% to 100% CPU load practically all day, every day.

So instead of adding a forth node and keeping ATLAS we've decided to get rid of ATLAS and replace it with a brand new node. Here is the specification of the new ZEUS node.

• ZEUS: XEON E3, 3.7GHz, 4 Cores, 8 Threads, 32GB of RAM. - 1Gbps network

The new node is online within our cluster right now and we will be removing ATLAS soon, perhaps even by the time you see this post. It has served us well and we say farewell to ATLAS!

We are still looking to add servers worldwide we may very well add a forth server later this year which is a similar specification to HELIOS or ZEUS.

Thanks for reading and have a great weekend!

Today we've introduced a new status code and message system to the v2 API. This was prompted by a user request and we felt it was a very useful feature for the API to have, standardising our errors and warnings will make the API easier to code against.

We have updated our API Documentation with the new information and below is a screenshot of that new section.

We hope you all like the change we were careful not to break compatibility with any v2 supporting clients while implementing the new status system.

Thanks!

Today Ricksterm an independent developer who made the WordPress Proxy & VPN Blocker plugin has released a major update to his plugin which adds the ability to perform checks across your entire WordPress website. Previously it supported checking and blocking only on signup, login and comment posting pages but now you can choose to enable it site-wide!

This has been a much requested feature by users and we thank him for his continued support of the plugin with frequent substantial updates. Alongside this new feature it has also gained an improved stats view with support for showing countries and a new slider which lets you adjust the detection sensitivity.

The title of this post is a common phrase you will read online when viewing forum posts within privacy minded communities. And in general it's true and has been true for as long as products have been offered for "free" to consumers.

Since we started we've had customers enquire about what we're doing with the data they send us. Specifically when they send us a customers IP Address do we correlate that with their web property and then sell that information.

For example if you operated a store that sold Guitars and you use our service for your registration or checkout system are we recording the IP Addresses you send us for proxy checking and then handing that data off to a marketing company so they can run targeted ads to your visitor for Guitar related products.

With the recent Cambridge Analytica disclosures involving Facebook we've been asked this question much more frequently than before and we thought it would be a good idea to write a blog post about our stance on this.

So the question is, do we sell your information? and the answer is no, we do not sell your information. Infact we do not make available any of the data our customers entrust with us. The only third parties we ever allow to handle your data in any way are Stripe which is our card payment processor and mailgun and both of these companies only receive the bare minimum of your personal information to perform the duties we've entrusted with them.

For Stripe that means your bank card information to perform transactions and for mailgun that means your email address. Beyond that they don't receive anything else and neither does anyone else. We simply do not make available customer information in any form even as aggregate data to any third party, period.

Now of course the question is if our free customers aren't our product how are we staying profitable? Well our business model is built around converting free customers to paid customers. We give unregistered users 100 queries per day and we give registered users 1,000 queries per day. Both for free.

Then as those customers needs grow, meaning they're regularly making over 1,000 queries per day we attempt to convert them into paying customers. We do this in a few ways, firstly the stats on the dashboard help users to determine their own query volume needs and secondly when you go over your query allotment for five days in a row we send you a single email to let you know.

Essentially a single $29.99 subscription which is our most popular paid plan right now can subsidise the usage of several hundred free users. That's part of what enables us to offer a very competitive free plan with feature parity to our paid plans.

The other part is that we designed proxycheck.io from day one to scale across multiple servers. Not just the API but every facet of our service like our website which includes the customer dashboard and web interface. As the queries hitting our API have grown we've been able to efficiently meet that increasing demand with very little waste due to the cluster.

With some of our competitors infrastructure we've seen them place free customers on one server and paid customers on another server. We've also seen competitors setup single dedicated servers just for single paid customers. While that sounds very premium on the surface, the reality is that's increasing the chance of failure and it's very inefficient business wise as you will have under-utilised resources which you have to pay for regardless of that servers actual usage, it also makes their premium plans exceedingly and in some cases outrageously pricey. Essentially you pay more, but you get less.

Our custom cluster architecture has allowed us to maximise our resource use so that all of our customers benefit equally from the increased performance and redundancy that adding more servers to the cluster brings while keeping our costs low as we don't have to keep paying for under-utilised servers. All of that means we can offer our generous free plans while respecting all of our customers privacy.

When companies sell their customers data while also having paid plans we call that double dipping. Frankly we think the privacy situation globally right now is in a very poor state and we don't want to be a part of the problem. We have welcomed the GDPR (General Data Protection Regulation) because for too long internet companies have been operating like it's the wild west when it comes to user privacy and user data ownership rights.

We hope this blog post has informed you on our stance, we have no plans to make available customer data to third parties, frankly we don't want to know who your website visitors are or what your website does. All we're interested in is making the best Proxy and VPN detection API at the lowest possible cost and we can certainly do that without invading anyones privacy.

Thanks for reading and have a great week!

On January 1st 2018 we introduced our v2 API which was the first new version of our API since we started in April 2016. Sure we'd re-coded v1 quite significantly several times since we launched but the v2 rewrite changed everything. It really was a from the ground up re-implementation of our API with almost no shared code between v1 and v2 due to the main feature we wanted to implement which was the ability to check multiple IP's with a single query, a feature we call multi-checking.

I'm pleased to say that since the launch we have seen quite a high degree of registered users utilising the new API. In-fact 46.37% of all registered users are now making use of the v2 API and as of right now 79.54% of all queries made today by registered users were to the v2 API endpoint. Our largest customers are the fastest movers in this regard and have jumped onto the v2 endpoint very quickly.

For a new product that's only just over three months old that's incredible adoption and it means we're getting our messages out to our customers and they are trusting us to make the right decisions with a product they rely on every day.

When it comes to unregistered users the adoption rate is quite a bit lower, only 11.56% of unregistered users that performed any query to the API today did so to our v2 endpoint. We expect this because many of these users are using 3rd-party software solutions that are still using the older v1 API and these users have not configured the software and so have not got an API key yet.

We're still two years away from us ending support for v1 so these numbers are incredibly encouraging to us. The third-party software that has implemented our v1 API will likely get updated or replaced before then but we're leaning towards creating a simple redirect endpoint at v1 which will forward queries to the v2 endpoint and translate the queries back into a v1 format. This won't take much effort from us and guarantee no one gets left behind, we know sometimes people implement an API and then forget about it and we don't want to leave anyone unprotected.

So that's the update we wanted to share, the high adoption rate among our registered customers has been a great win for us and with the new v2 specific features we launched in March it has only accelerated the adoption rate. We don't poll users for their satisfaction of our service but many like to write in and tell us anyway and I'm pleased to say the satisfaction rate is incredibly high, we've been able to provide a stable service whilst responding to new feature requests from our customers.

We love to hear from all of you, if you have a new feature idea, found a bug or just want to tell us what you think of the service please get in touch and let us know!

Since we added the dashboard we've had various requests from users to add two-factor authentication which is where you use an application local to you (such as on your computer or phone) to generate a one-time password which can be used in conjunction with your normal password to authenticate your logins.

The added security is obvious, if an attacker compromises both your API key and password they would still need to gain physical access to the device you run your authenticator on. Most people choose to use a mobile phone based authenticator for this reason.

So today we've enabled two-factor authentication for all accounts whether you're on our free or paid tiers you can benefit from the extra security two-factor provides. Below is a screenshot showing the new user interface within your dashboard for the feature.

We hope you like the apperance of the feature, we wanted to make sure it looks clean while being easy to understand and use. As the image informs you we're not limiting the feature to a specific authenticator. You're free to use any TOTP compatible authenticator which includes Googles, Authy, 1Password and more.

Thanks for reading and we hope everyone is having a great week!

Over the past couple of days we've been updating the stats tab on the Dashboard. Yesterday we added by customer request a country display to the recent detections section as shown below. We also added support for country information to the JSON output feature.

Today we've added a very neat looking interactive geographic heat map which shows the countries your positive detections are originating from. We're using maxmind's geoip data for this feature. This means we download their IP to Country database and do the IP Address lookups on our own server.

This is different to where we obtain our country/asn information for our main API and we are using maxmind here for speed so the graph can load very quickly. Below is an image of the map you'll find within your dashboard as of this post.

We hope you enjoy the new additions to the dashboard, these changes are the result of direct customer feedback.