Much like the last time we added a new node we've been looking for the right server for a while. One that offers very high IPC (instructions per clock) but also has lots of threads for handling a high volume of simultaneous connections. We believe we've found both of those qualities in our new node we're calling RHEA.

We now have four nodes in the cluster and they are spread out across three countries. And the two servers that are in the same country are hundreds of miles apart. We also have two nodes that aren't in the cluster day-to-day but can be inserted within a few seconds in the event multiple meteor strikes hit all the datacenters we use.

But we haven't only been working to add a new cluster node. Over the past month we've been optimising our post-processing inference engine which runs exclusively on STYX which was a new dedicated server we added in February. We've been able to significantly improve performance which means the server is scaling to meet our increasing daily demands.

In addition to these changes we've been working on improving our infrastructure. We've invested in an entirely new load balancing method. We setup our own nameservers and can now perform anycast DNS based geographic routing. Which means in the future when we enable this capability we will be able to direct you to one of our cluster nodes that is physically closest to you.

Although these are all under the hood changes they have taken a significant amount of capital and development time to achieve. They're not very glamorous but are important for the longevity of the proxycheck.io service. And all of it was delivered without a single second of downtime.

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

Today we've updated our contact us page with a new web form to make it faster and easier to get support. Best of all when you're logged into your account while using the new contact form we automatically receive information about your recent usage of our service so that we can assist you more quickly.

You may notice we've also included subject and a priority drop-downs. This will help us triage support queries so that customers with the greatest need will be assisted first.

But don't worry, if you prefer to send us an email yourself from your own email client you can still do that. We're also still supporting our Live Chat and iMessage contact methods.

We hope you'll check out the new improvement and perhaps give it a try the next time you need to contact us for anything. Thanks for reading and we hope everyone is having a fantastic week!

Today we've updated the threats page to include both our threat assessment risk score system and new navigation buttons to quickly traverse backwards and forwards from the currently displayed IP Address which should make the threats page much more efficient to use.

Below is a screenshot showing both changes, the new navigation buttons can be found to the top left of the map while the new risk score is displayed under the detection determination.

We hope you like these improvements and remember at the bottom right of each page you'll find our "last update" feature which lets you quickly see all the changes to the current page your viewing.

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

Today we've introduced a new feature to the v2 API endpoint which allows you to get a risk score for an IP Address. This draws on the immense volume of attack data we have combined with our knowledge of active proxy servers and virtual private networks.

{
    "status": "ok",
    "node": "PROMETHEUS",
    "140.143.90.193": {
        "asn": "AS45090",
        "provider": "Shenzhen Tencent Computer Systems Company Limited",
        "country": "China",
        "city": "Beijing",
        "latitude": 39.9288,
        "longitude": 116.3889,
        "isocode": "CN",
        "proxy": "yes",
        "type": "Compromised Server",
        "risk": 100,
        "last seen human": "56 minutes, 33 seconds ago",
        "last seen unix": "1551868636"
    },
    "query time": "0.006s"
}

Above is an example query and just below the proxy and type responses you can see a new risk score. This can range from 0 to 100 and it's a percentage value. Anything below 33% is considered a low risk while between 34% and 66% is considered a high risk and anything between 67% and 100% is considered dangerous.

We've added this score so that you can glean more information about an IP, specifically how dangerous it is on top of the proxy yes/no determination. Scores will generally be between 66% and 100% for positive detections depending on how much bad activity we're witnessing from that IP while negative detections will generally be below 10%.

To access this new feature you must supply a new flag with your queries which is &risk=1 and please remember not to rely on this score to make all your determinations, we recommend you provision your software for proxy: yes/no although you may want to fine tune your blocking based on how risky the IP has been determined to be.

Thanks for reading!

Today we have updated our warrant canary. It was meant to be updated on the 1st of January 2019 but with some internal changes that were made last year we did not get the reminder to update the warrant canary until now, apologies for the delay.

As always the warrant canary can be found here: https://proxycheck.io/canary.txt And our public key to verify the canary is still the same one from 2016 and is available here: https://proxycheck.io/pubkey.txt

Thanks and sorry for the delay!

Today we've pushed out an update to the dashboard which allows you to expand the entries listed to get detailed information including the network owner, hostname, port number, proxy type and even attack history from across our network. Below is a screenshot showing an expanded entry.

This new feature is live for all customers as of this post, we know that providing more information within the postitive detection log has been a frequently requested feature and we're happy to be able to deliver it today.

Today we'd like to share with you a new server we've added to our family called STYX, it joins HELIOS, PROMETHEUS And HELIOS within our cluster but it has a dedicated job, inference.

Specifically, post-processing inference. See we've run into a bit of a problem, the volume of incoming traffic we're receiving is now so vast that processing all of the undetected traffic is turning into a huge burden for our main cluster nodes to handle. They have to run the API, do live inference, host the website, coalesce, process and synchronise statistics and while doing all that they also have to go through a literal mountain of addresses and figure out which ones are running proxies as part of our post-processing inference engine.

Below is an illustration showing our current system where each node handles its own incoming addresses and then simply updates the other servers about any new proxies it discovers amongst that data.

As you can see 50% of working time is spent on the API, as it should be. But 25% is spent on our post-processing inference engine. And recently this has meant we can only process 1/20th of the undetected address data we're receiving. This means if we find an IP that isn't already in our database there is only a 1 chance in 20 it will even get processed by our post-processing inference engine.

Now to fix this we've tried a lot of different things from precomputing as much data as possible and storing it on on disk, we've tried reusing inference data for common IP's (for example if two IP's are in the same subnet a lot of the prior computational work doesn't need to be done again). But all of this isn't enough because the volume of addresses being received is simply so high.

In addition to this we have a privacy commitment to our customers to only hold undetected IP information for a maximum of one hour. So we're up against the clock every time we receive an IP that needs to be examined by our inference engine.

So what is the solution? Well we've decided to invest in a new dedicated server with a lot of high performing processing cores and a lot of memory to specifically deal with this problem. We've ported our Inference Commander and Inference Engine software to this new standalone server where it can spend 100% of its time working on inference.

Below is an illustration showing how our three main nodes now have their addresses downloaded by our new server we're calling STYX before processing on its immense compute resources.

Already we've been able to move from processing only 1/20th of the addresses we're sent per day to processing 1/7th and we're confident we can increase it further until we're able to process every single address we're sent by carefully examining where the bottlenecks are and solving them. With this new server we can run it at 100% without worrying about other tasks suffering as it doesn't host our website or API, its sole purpose is inference.

The other benefit of this new server is that it frees up the main nodes to handle more customer queries, we've already seen improvements in query answer times during peak hours and that directly correlates to being able to handle more queries per second.

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

The following is an edit to this post made on the 7th of Feb 2019.

As of this update our new server is now processing 100% of all the undetected addresses we have coming in through our post-processing inference engine software. A big jump up from the 1/7th we originally quoted when this blog post was made. Over the past several days we have been tweaking and gradually increasing the volume of queries and today we have hit a more than sustainable processing threshold allowing us to process all incoming data. We're very happy with this and so we thought an update was in order :)

This is a feature we've had customers ask for and one customer in particular (you know who you are!) has been very vocal about wanting it. Today we're happy to provide attack data on our threats pages. Below is a screenshot showing what it looks like. On the far left the colour dots represent the unique properties we're monitoring that saw attack traffic from the shown IP Address. The dots are not random but generated from the unique identifier we place on each individual property. This means you can use them to discern if an IP is just attacking one thing or many different things across the web.

On the far right we're listing the kind of property that is being attacked. This may say SSH, FTP, Game or in the screenshot above, Website.

We've also grouped attacks together so we can display more unique attacks. For example if an IP is trying to brute force a login page on a website and tries hundreds of times within a short time frame those attempts will all be shown as a single entry.

This for us is a beginning point. You'll note in the top right it says BETA and that's because this is a new feature that we're still actively working on. We intend to add integration with this attack log to your dashboard's positive detection log.

Right now it doesn't display all the data we have internally. Instead we've made profiles for specific types of attacks (Vulnerability Scanning, Brute Forcing, Automated Registrations, Port Scans and so on) and we will be expanding the profiles to support more kinds of malicious traffic as time goes on. Our intention with releasing this feature is to make an attack log that is actually useful and legible that doesn't throw needless information in your face.

In the near future we will leverage this data directly into our v2 API endpoint providing you with more data about an IP Address that you can use to make better decisions on whether to block an IP Address from accessing your property. So keep an eye on our blog for future updates.

Thanks for reading and we hope everyone is having a great weekend.

Today we went live with our new pricing for 2019 and we'd very much like to discuss the new prices and our reasoning behind our pricing changes.

Firstly we want to make clear that these changes only affect new subscriptions. If you're already subscribed you won't see the price you pay change unless you cancel your subscription and start a new one.

Secondly we've reduced the prices on two of our Starter and two of our Pro plans. So if you are on these plans you can cancel and re-subscribe to receive the new lowered pricing. The only plans we've increased in price are two of our Business plans but again this only applies to new subscriptions.

Thirdly we've reduced our discount for paying yearly from 20% to 8.44%. Which means instead of receiving just over two months discounted from a 12 month subscription you now receive the equivalent of one months free service.

So let's discuss these changes starting with the reduced prices. Prior to today we had three Starter Plans priced at $1.99, $3.99 and $5.99.

The new pricing as of today is $1.99, $3.49 and $4.99 and you still get the same volume of queries. We've done this change because we see a lot of customers bunching up around the $1.99 and $3.99 prices and very seldom do customers take the $5.99 plan. So what we've done here is make the biggest Starter plan more affordable by a dollar which keeps all of the Starter plans under $5. We're also hoping to entice users who are paying $1.99 to upgrade to the $3.49 plan as you'll get twice the queries for just $1.50 more. We still think the $1.99 plan is a great introduction price and so we're not changing it at this time.

With our Pro plans we had plans starting at $7.99, $9.99 and $14.99. By far the $9.99 plan was the most popular, users very seldom purchased the $14.99 Pro plan. So to entice more users to upgrade to Pro we've reduced the first plans price from $7.99 to $6.99 and we've reduced the $14.99 plan to $12.99. The $9.99 plan performs really well and so we've decided to keep the pricing for it the same. And of course the query volumes are the same too.

For our Business plans we have increased the prices of two plans. The prior pricing was $19.99, $24.99 and $29.99. The new pricing is $19.99, $29.99 and $39.99. We've increased the middle plan price by $5 and the last plan price by $10. We've done this because all three plans are seeing heavy use by businesses and we feel the pricing was a little lower than it should have been for what is essentially commercial use.

For Enterprises we've not made any pricing changes at this time. We feel all the Enterprise plans are performing right where they should be so for now no adjustments are needed.

The final pricing change to discuss is the annual discount. Prior to today you would receive a 20% discount if you purchased a yearly plan instead of a monthly one. We did this at the start of our subscription service mostly as a gesture of good will to our customers who had been on our prior yearly purchases model (before we had subscriptions). When we switched to subscriptions our prices did increase and we didn't want customers who had paid for a year previously to have to pay a very high renewal when their time came. We've now moved into a time where there are no more pre-paid yearly customers, every customer today is on some kind of subscription pricing tier.

So we've reduced the discount from 20% to 8.44% which as noted above is the equivalent to one month. We think this is still generous and shouldn't affect new yearly subscribers too negatively. And of course if you hold a currently active yearly subscription you will not see any changes to what you pay on your stated renewal time because all of these pricing changes including the discounts only apply to new subscriptions.

We know when services adjust pricing it can be frustrating and that's why we are not changing your active subscriptions, doing it this way keeps you in control of what you pay and you can decide whether to start a new plan or not. If you have any questions about this change or anything else on your mind please contact us we love to hear your feedback.

Thanks for reading!

Today is our first big code update of 2019 and we'd like to share with you some of the details. Over the past month we've been focusing on improving our inference engine and specifically our ability to leverage the data you send us in our engines determinations.

Each day we are sent millions of IP Addresses to check by our customers and we don't only supply you with information about the addresses, we also feed them into our inference engine in an attempt to see patterns that can identify more proxies.

For example when we see an IP Address quickly making hundreds of connections across multiple customers properties that in itself can be a red flag. And thanks to the tag system we also have a lot of insight about what pages specifically on your properties the IP Address is attempting to access.

We've taught our inference engine to understand many different kinds of customer usage so that it can identify when an IP is acting benign such as accessing a static webpage or a blog post and when it's acting malicious like making automated login and registration attempts, spamming blogs and forums or brute forcing an input field etc.

With todays update we've improved this system so that it works much better with our customers who are using our API on their game servers and at server firewalls. We've also greatly improved its understanding of different webpages so that it can identify if a page is at a high risk for automated behaviour by bots (which commonly use proxies to remain anonymous while they carry out attacks).

This update went live today because we felt the improvement in detection rate was so good that we didn't want to wait until late February when we were planning to include this in a more comprehensive update. Instead we've pushed out this change today so that you can all benefit from it now.

That's it for this update, we hope everyone is having a great first start to the year!