Last week we added a brand new plugin to our plugins page made by an independent developer called Sikari. The plugin allows you to integrate proxy checking from us and other providers into your Source game server.

So whether you're running a Counter Strike, Day of Defeat, Team Fortress or another SourceMod compatible game server you now have an easy way to block proxy and VPN users from from causing disruption and evading bans.

We're very thankful to Sikari for making the plugin and we're sure it will be a great benefit to all Source server operators.

Late last month just as we were shutting down for the holidays the developer of our C# example, hollow87 updated his proxycheck C# library to support our v2 API including all our latest features such as lat/long and city information.

You can check out the example here on our code examples page or here on the NuGet page for the project. Using this library you can build a very robust implementation of our API in your .net applications with very little effort.

Happy coding! 👩‍💻

Hello everyone below are the dates where live support will not be available but email based support will still be available. We will of course be monitoring our site and the API throughout the holidays and you can still make purchases and cancel a plan during the stated time periods and everything will remain fully functional.

Email support only between:
Sunday, December 23rd to Wednesday, January 2nd.

To be clear, we will only be offering email based support beginning on Sunday, December 23rd until Wednesday, January 2nd at which point normal support services which includes our web based live support chat will resume. Thanks!

As we're now just a few weeks away from the new year we thought now is a good time to go through some of the milestones from this year.

If you would like to view the specific features we added or enhanced this year we recommend taking a look at our November 2018 newsletter. It's a great read and all of the changes listed within the newsletter link to blog post entries for more detail.

This year we saw impressive growth, at one point the volume of API queries we were receiving was doubling every month and we had to upgrade not just our API but our server hardware a few times to keep up with the projected demand. We also enhanced our network infrastructure significantly by using a world-wide Virtual Private Network (VPN) through our Content Delivery Network (CDN) provider which reduced latency for customers who are the furthest away from our servers.

As we mentioned above we upgraded our API several times. In-fact we launched our v2 API in January 2018 and since then the adoption rate has been incredible, we've updated you a few times on these numbers and today we're seeing 91% of all customers using the v2 API for their queries. This is up from 72% back in July.

In addition to launching the v2 API at the start of this year we also upgraded the API several times throughout the year reducing query latency by enormous amounts. You may remember when v2 launched its main feature was the ability to check multiple IP Addresses in a single query allowing efficient batch processing.

At the time the efficiency wasn't as high as it needed to be so we could only allow 100 IP's to be checked simultaneously and that could take up-to 90 seconds in some cases with all our checks enabled. In February we raised that limit to 1,000 and then in August we raised it again to 10,000. These kinds of improvements were made possible by redesigning core parts of the API to remove bottlenecks. Today you can check 10,000 IP's in around 25 seconds.

Even while we added more data to the API including improved provider, country and ASN information, the addition of IPv6 data and most recently, city, longitude and latitude data we've been able to increase performance. In-fact we now track more datacenter providers and more proxies than ever before and we spend more machine hours than ever processing incoming queries through our inference engine and yet the API is faster today than ever before.

Going into 2019 we intend to invest even more heavily in our unique technology. We recently did an infrastructure deep dive which resulted in a large influx of questions to our support staff from people wanting to know more and we intend to follow this up with an architecture overview breaking down some of our custom tools next year, stay tuned for that.

This year we also spent a lot of time improving the tools customers have to use on our website. We improved our Dashboard API's, we improved the web interface page several times and we introduced the new threats page. We also invested heavily in the customer dashboard making it more performative, improving the appearance, adding two-factor security and other enhancements. We'll keep improving this next year too.

So that's what happened with us this year, huge growth, lots of improvements to the site and our service. We want to thank all of the customers that took the time to try our service and we're especially thankful to those of you who took the time to write to us with ideas and suggestions, that input has often been invaluable, in-fact a lot of the features listed in our November newsletter were born from ideas pitched to us directly by customers.

We hope everyone has an enjoyable festive period and a great new year. We'll be making one last blog post directly after this one for our holiday support times so make sure to check that out, apart from that you should next hear from us in January 2019!

When we added the Threats page in late August it was always our intention to create a home view where you could see live emerging threats. But we didn't quite know how we wanted it to look and what information we wanted to make available as we didn't want to give bad actors easy access to unique proxy data with which to launch malicious acts.

So we spent some time on it and decided that providing a map showing which countries the most attacks are coming from and a heavily shrunk down list of recent detections would be the best way to accomplish our goal. We'll keep working on adding more data as we feel it's appropriate but for now this is our starting point for our new threats home view.

If you've used the customer dashboard before then this view will be quite familiar to you. We've kept it simple, the map will show around 5,000 recent attacks by country with the addresses behind the attacks not displayed. Then below we will showcase 10 recent addresses that we've detected performing attacks and that also have active proxy servers running.

We hope you like the new home view, this is in addition to our specific address pages which will continue to be accessible. We've actually updated those pages with new city and specific location data which was also exposed through our v2 API update a few days ago.

Thanks for reading and we hope everyone is enjoying their weekend!

For around a 9 hour period between November 23rd and 24th all IPv6 addresses checked with our service with the VPN flag enabled were detected incorrectly as VPN's. IPv4 checks were not affected.

This was due to human error on our part when we accidentally entered in a VPN providers IPv6 range incorrectly. We have since corrected the problem and put a process in place to make sure this cannot happen again. We're very sorry to everyone affected by our mistake, we did not live up to our own expectations of high quality service in this instance.

Today we've updated our v2 API endpoint to support the exposure of city and coordinate information alongside the previous country name and country isocode information. You'll find new examples featuring this data on our API Documentation page.

We have not changed our data formatting so any software you developed against our v2 API will remain fully functional but if you go back and make some changes you can now include the City (if applicable) and Latitude and Longitude in your software if you need it.

This has been an often requested feature and we're happy to be able to provide it to everyone today. Like all API changes this is accessible to all customers whether you're using a free or paid plan.

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

Today we have updated our PHP composer library which adds support for viewing and altering your whitelist and blacklists in an easy way. Below is an example of how you would add three entries to your whitelist:

$proxycheck_options = array(
  'API_KEY' => '', // Your API Key.
  'TLS_SECURITY' => 0, // Enable or disable transport security (TLS).
  'LIST_SELECTION' => 'whitelist', // Specify the list you're accessing: whitelist or blacklist
  'LIST_ACTION' => 'add', // Specify an action: list, add, remove, set or clear.
  'LIST_ENTRIES' => array('8.8.8.8', '1.1.1.1/24', 'AS888') // Addresses, Ranges or ASN's to be added, removed or set
);

$result_array = \proxycheck\proxycheck::listing($proxycheck_options);

We have also made some changes to the whitelist/blacklist API to better support adding and removing multiple entries at once. We found that removing multiple entries at once was almost impossible before due to the way in which the search criteria was implemented, now it's much better and you should be able to remove lots of entries in a single query without any issues.

Thanks for reading and have a great day!

Over the past year we've had a few customers ask us how our service is structured, what kinds of software we use and what custom solutions we've created to run proxycheck.io. As it's coming near to the end of the year we thought now would be a good time to take you inside our software stack.

To get started lets follow a request to our API from your server to our server.

So firstly our service is entirely behind CloudFlare's Content Delivery Network (CDN). So whenever you access our website or API you're first going through CloudFlare. As illustrated your request first goes to the closest CloudFlare server to your servers physical location. This is done using IP Anycast and is entirely handled by CloudFlare.

Once your request reaches CloudFlare it then enters their Argo Virtual Private Network (VPN). This is a service CloudFlare offers (for a fee) which uses dedicated network links between CloudFlare servers to lower network latency. Essentially we use Argo as a fast and low latency on-ramp to our servers.

This is what enables us to serve customers who are the furthest away from our cluster nodes while delivering acceptable network latency.

At this point CloudFlare chooses one of our geographically separated cluster nodes to send the request to and the CloudFlare server closest to that node performs the request and returns the answer from us to you back through the Argo VPN to the CloudFlare server closest to you.

But what actually happens inside our server? Well the above illustration explains. Firstly all our cluster nodes run Windows Server. We feel that Windows offers a lot of value and performance and we've found IIS to be quite a competitive webserver offering low CPU and Memory usage while being able to handle enormous amounts of connections. That isn't to say we think NGINX isn't good, in-fact we use NGINX running on Linux for our Honeypots and even CloudFlare uses NGINX for the connections they make to us.

Second to IIS is of course wincache which you can think of as opcache for Windows. It allows us to keep compiled PHP scripts in memory and re-run them without needing to re-run the PHP interpreter. This is very important for performance. You can also store user variables, sessions and relative paths in wincache but we don't usually make use of these features and instead rely on our own memcache implementation which we will detail below.

Third and Fourth is of course PHP v7.2 and our code which is written in PHP. You may think why didn't we use something more modern such as node.js, well we feel comfortable with PHP and the latest versions have been quite incredible when it comes to performance and features. Having over a decade of experience with PHP has given us great insight into the language, its quirks, its limitations.

Above is an illustration of what happens inside our code. We've tried to outlay each step in the program loop. All of this usually happens at or under 7ms for every "full" query (meaning all flags enabled). And in the case of performing a multi-query a lot of what happens on the left is only done once. This allows the latency per IP checked to go down dramatically when you check multiple addresses in a single query.

We will elaborate on the caching system and machine learning below.

We talked a bit above about our custom memcache system. You may be thinking why did we roll our own when we could have used memcached or redis? - Both quite common and well developed. Well we found that in the case of memcached its use of UDP as a mechanism to withdraw cached data wasn't consistent enough under high load scenarios.

So to explain what behaviour we saw, most of the test queries we performed would be answered in under 1ms with memcached. But sometimes we would have queries that took 1 second or even 2.5 seconds. We determined this was caused by its network communication system.

For a website those kinds of one-off latency hiccups are fine but for our usage those issues would add-up fast. After testing with it for more than a month we decided to roll our own system which relies on inter-process communication similar to an RPC call. Essentially we load an interface within PHP as an extension and that allows us to store and retrieve data as needed from our custom memcache process that runs separately on each server node.

Our memcache system also has some features you'll find in redis such as being able to write out cached data to persistent storage, network updates to keep multiple instances on different servers consistent and the ability to store almost any kind of data including strings, arrays, objects and streams.

In addition to those features it can also make use of tiered storage which means it can store the most frequently touched objects in memory and keep less frequently used objects on an SSD and then even even less frequently used objects on a hard disk. We've found this approach very beneficial for our large machine learning datasets where we try to pre-process as much information as possible so that query times remain low when utilising our real-time inference engine.

Which is a great segway into how our machine learning system works. We don't want to go into too much detail about what specific machine learning framework we're using or what models we're using but we can confirm we're using an open-source library. Above are some of the intelligence gathering methods our inference engine uses in determining whether an IP is operating as a proxy or not.

And we do want to elaborate on some of these as it may not be so obvious. For example "High Volume Actioning" due to our wide visibility over many different customer properties where they make use of our API combined with our own honeypots we're able to monitor unusual and high volume actions by singular IP Addresses, this could be signing up for many different websites, posting a lot of comments on forums and blogs, clicking on a lot of ads etc - Behaviours that are on their own not unusual but when done at a high frequency within a short time frame become suspicious.

Another we wanted to elaborate on is "Vulnerable Service Discovery". A growing number of Internet of Things (IoT) devices are being turned into proxies by criminals. These range from CCTV Cameras to Routers to general "smart" devices like home automation hubs, kitchen appliances and so on.

Our system during its probing and prodding of addresses discovers a great deal of compromised devices which either can be accessed by default credentials or have a vulnerability in their firmware which has yet to be patched that can allow an attacker to setup proxy serving software on the device.

Simply having a vulnerable device available isn't going to get an IP flagged as a proxy server but it does hurt that IP's reputation and it will be weighted along with the other data we have for that IP Address when the inference engine makes its final decision.

Finally we wanted to talk about "Automated Behaviour Detection" similar to the High Volume Actioning this is where we use our wide visibility and honeypot network to observe addresses performing web crawling, spamming, automated signups, captcha solving and other activity that fits botting behaviour. As bots have become more sophisticated and actually execute javascript within headless browsers it has become harder to stop them from accessing your web properties.

So detecting this kind of automated behaviour is extremely important and our model is designed to detect all kinds of automated behaviour through wide observation of incoming queries (combined with tag mining from our customer queries) and through our own honeypot network of fake websites, blogs, forums and more.

So we hope that you enjoyed this deep dive into our software stack. Obviously some parts we've had to hold a little close to our chest as we feel they give us a competitive edge (especially with regards to our machine learning) but we think we shared enough to give you some insight into what we're doing and how.

Thanks for reading and have a great week!

As our service has been offering subscriptions for quite a while now we've come across a few instances where customers forget that they're signed up for a subscription with us or they didn't realise the payments for their subscription are taken automatically as opposed to being paid by the customer manually.

Thankfully these instances where we bill someone without their knowledge are rare and in each case we have always issued an immediate refund once the customer contacts us about the situation.

But to eliminate this problem we've decided to be proactive about it by offering upcoming payment notices. And so within the customer dashboard starting today you'll see a new email toggle (which replaces our never used promotions toggle) which allows you to activate email notices for upcoming payments.

By default all new customers will have this toggled on, if you're an existing customer you'll need to enable it yourself. Also if you're subscribed to a yearly plan we'll still send you a notice regardless of this setting because we feel it's important that customers who hold a yearly subscription get these notices due to those plans being very expensive.

We don't want anyone to forget a payment charge is coming but we know for monthly subscribers receiving two emails every month (a notice of an upcoming payment and the receipt for payment) could get annoying so we've added this email setting toggle for those users who are subscribed monthly. Of course we'll always still send you payment receipts regardless of this setting.

Below is an example of what the email looks like.

We think it conveys everything succinctly and most importantly lets you know that you can cancel your plan from the dashboard to avert the upcoming charge.

Thanks and we hope everyone had a great Halloween! 🎃