This summer Chinese authorities deepened a crackdown on virtual private networks (VPNs)—tools that help internet users inside the mainland access the open, uncensored web. While not a blanket ban, the new restrictions are shifting the services out of their legal grey area and further toward a black one. In July alone, one popular made-in-China VPN abruptly ceased operations, Apple removed dozens of VPN apps from its China-facing app store, and some international hotels stopped offering VPN services as part of their in-house wifi.

Yet the government was targeting VPN usage well before the latest push. Ever since president Xi Jinping took office in 2012, activating a VPN in China has been a constant headache—speeds are slow, and connectivity frequently lapses. Especially before major political events (like this year’s upcoming party congress in October), it’s not uncommon for connections to drop immediately, or not even form at all.

In response to these difficulties, China’s tech-savvy programmers have been relying on another, lesser-known tool to access the open internet. It’s called Shadowsocks, and it’s an open-source proxy built for the specific purpose of jumping China’s Great Firewall. While the government has made efforts to curb its spread, it’s likely to remain difficult to suppress.

How is Shadowsocks different from a VPN?

To understand how Shadowsocks works, we’ll have to get a bit into the cyberweeds. Shadowsocks is based on a technique called proxying. Proxying grew popular in China during the early days of the Great Firewall—before it was truly “great.” In this setup, before connecting to the wider internet, you first connect to a computer other than your own. This other computer is called a “proxy server.” When you use a proxy, all your traffic is routed first through the proxy server, which could be located anywhere. So even if you’re in China, your proxy server in Australia can freely connect to Google, Facebook, and the like.

But the Great Firewall has since grown more powerful. Nowadays, even if you have a proxy server in Australia, the Great Firewall can identify and block traffic it doesn’t like from that server. It still knows you are requesting packets from Google—you’re just using a bit of an odd route for it. That’s where Shadowsocks comes in. It creates an encrypted connection between the Shadowsocks client on your local computer and the one running on your proxy server, using an open-source internet protocol called SOCKS5.

How is this different from a VPN? VPNs also work by rerouting and encrypting data. But most people who use them in China use one of a few large service providers. That makes it easy for the government to identify those providers and then block traffic from them. And VPNs usually rely on one of a few popular internet protocols, which tell computers how to talk to each other over the web. Chinese censors have been able to use machine learning to find “fingerprints” that identify traffic from VPNs using these protocols. These tactics don’t work so well on Shadowsocks, since it is a less centralized system.

 “Each person can configure it to look like their own thing. That way everybody’s not using the same protocol.” 

Each Shadowsocks user creates his own proxy connection, and so each looks a little different from the outside. As a result, identifying this traffic is more difficult for the Great Firewall—that is to say, through Shadowsocks, it’s very hard for the firewall to distinguish traffic heading to an innocuous music video or a financial news article from traffic heading to Google or some other site blocked in China.

Leo Weese, a Hong Kong-based privacy advocate, likens VPNs to a professional freight forwarder, and Shadowsocks to having a package shipped to a friend who then re-addresses the item to the real intended recipient before putting it back in the mail. The former method is more lucrative as a business, but easier for authorities to detect and shut down. The latter is makeshift, but way more discreet.

What’s more, tech-savvy Shadowsocks users often customize their settings, making it even harder for the Great Firewall to detect them wholesale.

“People use VPNs to set up inter-company links, to set up a secure network. It wasn’t designed for the circumvention of censorship,” says Larry Salibra, a Hong Kong-based privacy advocate. With Shadowsocks, he adds, “Each person can configure it to look like their own thing. That way everybody’s not using the same protocol.”

Calling all coders

If you’re a luddite, you’ll probably have a hard time setting up Shadowsocks. One common method to use it requires renting out a virtual private server (VPS) located outside of China and capable of running Shadowsocks. Then users must log in to the server using their computer’s terminal, and enter the Shadowsocks code. Next, using a Shadowsocks client app (there are many, both free and paid), users input the server location and password and access the server. After that, they can browse the internet freely.

Shadowsocks is often difficult to set up because it originated as a for-coders, by-coders tool. The software first reached the public in 2012 via Github, when a developer using the pseudonym “Clowwindy” uploaded it to the code repository. Word-of-mouth spread among other Chinese developers, as well as on Twitter, which has long been a hub for anti-firewall Chinese programmers. A community formed around Shadowsocks. Employees at some of the world’s largest tech companies—both Chinese and international—work together in their free time to maintain the software’s code. Developers have built third-party apps to run it, each touting various custom features.

 “Shadowsocks is a great invention… Until now, there’s still no evidence that it can be identified and get stopped by the Great Firewall.” 

One such developer is the creator behind Potatso, a Shadowsocks client for iOS. Based in Suzhou and employed at a US-based software company, he grew frustrated at the firewall’s block on Google and Github (the latter is blocked intermittently), both of which he relied on to code for work. He built Potatso during nights and weekends out of frustration with other Shadowsocks clients, and eventually put it in the app store.

“Shadowsocks is a great invention,” he says, asking to remain anonymous. “Until now, there’s still no evidence that it can be identified and get stopped by the Great Firewall.”

Not quite underground, not quite above ground

It’s difficult to know how many people use Shadowsocks. The developers for Potatso and Surge, another iOS client, separately told Quartz their paid apps have gathered enough downloads to make for a lucrative hobby on top of other work. But neither could estimate the popularity of the core Shadowsocks software.

Still, anecdotes suggest that the software has reached at least some people in China who aren’t professional developers. One Shadowsocks user Quartz spoke to says he relies on it to watch videos on Vimeo and YouTube. Both sites are blocked in China, but he visits regularly for his job at a production company.

Another Shadowsocks user, 25-year-old Steffie Chao, told Quartz she began using the software four years ago. While preparing to study abroad, she used a VPN to access YouTube and watch university lectures. When her VPN stopped working, she searched for an alternative and discovered Shadowsocks on a Chinese-language internet forum. She ran it on her computer using some rudimentary coding skills she picked up in a class.

At the very least, Shadowsocks is widespread enough that Chinese authorities are aware of its existence. The government has made some attempts to clip its wings. In 2015, around the time of a parade in China celebrating the 70th anniversary of WWII, Clowwindy posted a messageon Github announcing he had been visited by the police, and would have to stop working on Shadowsocks. And when Apple removed dozensof firewall-jumping apps from its Chinese-facing app store, it didn’t just target VPNs—several Shadowsocks apps were removed as well, including Potatso.

Yet Shadowsocks will continue to live on. That’s in part because the code is open-source, meaning that anyone can maintain, alter it, and release it in a different form (the source code remains on Github, it’s simply more difficult to find there than it was previously).

Should Shadowsocks give us hope for freedom on China’s internet? Yes and no.

On the one hand, it’s unlikely that any Shadowsocks app will ever become as widespread as brand-name VPNs, like VyperVPN or AnchorFree. According to Weese, the privacy advocate, Shadowsocks’s underlying technology is difficult to “scale” business-wise compared to a VPN. That means that even though Shadowsocks might be a better tool for jumping the Great Firewall, VPNs will have an advantage when it comes to reaching consumers.

Not that there’s a lot of incentive for an enterprising Chinese coder to build and promote a “mainstream,” easy-to-use Shadowsocks app. After all, if it gets popular enough in China, authorities could take notice, and there could be serious consequences (link in Chinese)—or more government effort towards figuring out how to detect and block users.

Shadowsocks might not be the “perfect weapon” to defeat the Great Firewall once and for all. But it will likely lurk in the dark for some time.


Available on GitHub to download:

Once the domain of internet security geeks, VPN (Virtual Private Networking) has gone increasingly mainstream with smart surfers looking to keep their net traffic private, and away from the prying eyes of hackers, governments or overly profit-driven ISPs.

However, remember that VPNs do have some limitations in terms of security, and when using a VPN service, one important step is to perform an IP leak test. This verifies that the VPN tunnel is enabled, and that your real IP address is successfully cloaked by the VPN.

Even if this is confirmed, bear in mind that the test has been carried out at a single point in time. Any computer user knows that getting something to work once can be a challenge, but is certainly not the same as having it work day in and day out with 24/7 uptime. In other words, even the best VPN can’t be guaranteed 100% secure, and even with leak protection enabled, your IP address can be exposed, if only for brief intervals.

One common issue with a VPN connection is when the user overloads it with traffic, initiating a temporary disconnect, and then when the service reconnects, the computer does this directly, without the VPN enabled – which is known as a reconnection leak.

The other concern here is that the user is typically oblivious to this issue as the PC and the VPN appear to be functioning normally, and there is no indication of any flaw – short of repeating the IP leak test – to reveal that the user’s IP address is not hidden.

Every problem has a solution, and the fix for these VPN hiccups is known as a kill switch, and they come in two varieties. Some of the better VPN providers integrate a VPN kill switch directly into their service. This is a feature to look for when selecting a provider, as it really is a must-have these days.

When the VPN service’s software discovers that the VPN tunnel is no longer providing privacy protection, the kill switch then kicks in with the swiftness of an overloaded circuit breaker in an electrical panel, and terminates all connections to prevent the exchange of unencrypted data. Examples of VPNs that offer an integrated kill switch are NordVPNIPVanish and AirVPN, among others we highlight below.

How about if you already have a VPN that you are otherwise satisfied with, and you’ve only just realized that it doesn’t have an integrated kill switch, after paying for an annual subscription? Or perhaps your VPN software has an integrated kill switch, but you are a ‘belt and suspenders’ kind of computer user who wants a backup, just in case. Hey, we don’t blame you, and fret not, the functionality of a VPN kill switch can easily be added via a software solution that monitors the connection, and then kills it if the VPN tunnel is compromised.

Read on for some great and affordable (or even free) choices below, whether you want a standalone kill switch, or a VPN which boasts an integrated effort (or indeed both).

1. VPN Watcher

VPN Watcher is a lightweight piece of software. It’s a VPN kill switch which is available in three tiers: Free, Personal and Gold. The main difference between these options is that the paid versions check the connection more frequently, and support more simultaneous applications.

A limiting factor, as seen in the screenshot above, is that VPN Watcher supports only a half dozen VPN services directly, and otherwise requires a more labor intensive and painful manual configuration.

2. VPNetMon

VPNetMon has only one tier for its kill switch software – and the good news is that it’s a free offering. It also works with a wide variety of VPN software. While those are the points in favor of this app, disadvantages include the fact that it does take some time and tweaking to configure, and can be a little buggy. The software can support up to three VPN applications.

3. VPNCheck

VPNCheck is another lightweight piece of software, and it comes in two versions: Free and Pro. While both offer a kill switch that gets activated if the VPN crashes, only VPNCheck Pro also has a DNS Leak Fix feature. Both versions are simple apps that are easy to configure and use.

4. Comodo Firewall

Comodo Firewall is a well-known free firewall that’s popular with the open source crowd. We’ve recently reviewed the product and awarded it four stars to boot. While its primary focus is firewall duty, which the software does seriously well, it is quite robust and configurable to various other purposes.

In fact, for more advanced users willing to delve deeper into the settings, Comodo Firewall can be set up to function as a VPN kill switch. This involves going into the Global Rules menu, and setting up a series of rules that will block the IP address from being revealed. For full instructions from one VPN provider, check out nVPN’s help page.

5. LiquidVPN

LiquidVPN is a US-based provider which has been around since 2013. Amidst the many VPNs on the market these days, LiquidVPN stands out for two features. The first is that LiquidVPN claims to have a ‘zero logs DNS service’ (LiquidDNS) meaning that it doesn’t keep any of the DNS requests that users make.

The other standout element is that LiquidVPN has integrated a VPN kill switch into its software: ‘Liquid Lock’. This will allegedly stop all types of leaks, including DNS leaks, WebRTC leaks, disconnect leaks, and IPv6 leaks.

6. HideMyAss

Another VPN that has an integrated kill switch is HideMyAss, a service brought to you by AVG of antivirus fame. When TechRadar Pro reviewed this provider last year, we noted that HideMyAss benefits from a large network of servers, and it’s very easy to use (albeit not cheap).

Another plus of HideMyAss for less tech-savvy types who don’t want to attempt to configure a kill switch is that this provider has one built directly into the software client. The firm calls it ‘Secure IP Bind,’ and it functions by forcing selected applications to only work when connected to the VPN servers. If the VPN gets interrupted, the apps will no longer work, and the IP leak is avoided.

When you create and restore a TWRP backup (as example because you tried out a custom ROM and saw that it’s not good) you’ll be greeted with:

a) A “enter PIN before boot” screen
b) A wrong lockscreen code (either PIN or Pattern) when booted to Android


  1. Simply boot into TWRP and enter your PIN (if you’ve set one) to decrypt the stroage. If you don’t have TWRP (for whatever reason) you can do so via ADB too but ONLY if you’ve connected your phone to your PC beforehand and also accepted it’s fingerprint on the phone itself.
  2. Delete (or rename) the following files inside /data/system (note that probably not all of them exist for you, simply delete those you can find):
    • password.key
    • pattern.key
    • locksettings.db-wal
    • locksettings.db-shm
    • locksettings.db
  3. Reboot the phone and (if you’ve set a PIN) enter it to decrypt the storage one more time. After that you can simply unlock your phone with a swipe.
  4. Go into Settings > Security and set your preferred unlock method again, Android will ask you if you want to set a boot-time code too. Select whatever you want here, it’s a nice security addition but can be annoying sometimes.
  5. Enjoy your phone again!

I hope this helps some people here since I was searching on how to fix this for almost an hour after restoring a backup. This is probably due to another ROM overwriting existing lockdata when you set a code there, then again you’d wipe the /data partition anyways so I have no clue why it’s still acting up like this…

Application Architecture Guidance

Practical advice, best practices, and sample applications for using .NET with microservices, Docker containers, Kubernetes, Xamarin, ASP.NET, Azure, Service Fabric, and more.

Microservices and Docker Containers

Microservices are small, modular, and independently deployable services. Docker containers (for Linux and Windows) simplify deployment and testing by bundling a service and its dependencies into a single unit, which is then run in an isolated environment.

Web Applications with ASP.NET

ASP.NET Core allows you to build high-performance, cross-platform web applications. Patterns like MVC and built-in support for Dependency Injection allow you to build applications that are easier to test and maintain.

Deploying to the Cloud with Azure

Production ready cloud applications need to be built for scalability, monitoring, management, security, resiliency, and more. The patterns covered in this guidance include example implementations for Microsoft Azure.


Mobile Applications with Xamarin

Xamarin allows you to build native Android, iOS, and Windows applications using .NET. Common patterns, such as MVVM, combined with good application layering, will maximize code sharing and result in an application that is easier to understand, test and maintain.

Taken from:

Imagine you have a set of microservices or applications that you want to publish to the world. There are several alternatives out there that you can choose from. Most of the reverse proxies were created when container technology was not around, so you have to jump through some loops to get going. As a broadly used example we will have a peek at how to configure nginx and some of its downsides. To get our hands dirty, we will have a more detailed walk-through of the modern, dynamic Traefik reverse proxy which we will use to deploy some services.

Best in class before Docker: Nginx

There is quite a number of container deployments out there that use nginx as a front end. The configuration is easy to read and write and the C style syntax gives you a cozy feeling. A simple config to deploy a service might look like this:

With this config we created a simple HTTP reverse proxy on port 80. Nginx will answer the requests by forwarding these to the upstream servers. The container with the least number of active connections will be chosen from the pool. Nice configuration. Plain and easy to read.

One thing you will encounter when you deploy nginx in a mutable container enviroment is that you can’t replace containers without at least reloading the nginx configuration although the container DNS name is still the same. Nginx will cache the IP address to the container and you have to manually take care of it. You can work around this problem in many ways but still you have to take care of it.

Don’t get me wrong: I don’t want to pick on nginx. I like it and used it a lot before I switched to Traefik as my go to solution.


There’s a more modern reverse proxy around that is able to handle dynamic container environments: Traefik. It is a small application written in GO tailored to the new challenges. You can use it as a frontend in a variety of environments. The simpler ones are Docker and Docker Swarm, the more complex ones are Apache Mesos or Kubernetes. You can even read metadata from directory services like etcdor Consul.

Back to our application we want to deploy. Let’s imagine we have a set of services that are described in a Docker Compose file. We can wire up our services and deploy these. Here we can have a look at a simple configuration:

This configuration will start the whoami test image that will allow us to see our requests in a kind of echo chamber. You can start it with docker-compose up and call it with your browser. How can we deploy it on a specific virtual host? Let’s extend the configuration a bit by adding Docker labels.

This is the configuration needed for Traefik to deploy our service at http://whoami.server.test . Pretty straightforward.

When you followed the example closely you might ask where Traefik is involved and you are right. Next we need to spin Traefik itself up:

The config above takes care of starting Traefik and will connect to the hosting Docker daemon to retrieve the needed metadata. It will scan for Docker containers that are marked with labels and will publish the services accordingly. The connection is kept so that changes will be reflected without any delay.

Both services are wired together using a Docker network called call webgateway that is prefixed by the project name. If no project name is specified, the name is inferred from the directory name where the compose file is located.

You can find more configuration options on the documentation site: This takes you straight to a backend configuration part. Below that there is a list of Docker labels that can be used to further configure the publishing of the services. Currently we just used traefik.backend and traefik.frontend.rule in the sample above but you can find more.

Once Traefik and the service are up you can connect to the service and test the deployment. Make sure you first start Traefik in this example because the config provides the network the services can connect to.

Have a look at the built in dashboard by pointing your browser to: http://localhost:8080/

Here you can see what services are deployed and how these are configured. You see that our service is available as whoami.server.test. But since we don’t have a DNS record pointing from this name to our localhost, we need to manually set the Host header and call the localhost.

Once you have entered the command, you can see the request that is being sent to Traefik and the response that will be returned. The result will look similar to:


To fully enjoy the power of Traefik, you need to take care of the DNS records of your deployments. But this is a one time setup, so don’t worry about it too much. One deployment we run at a customer consists of two DNS records per host. One is an A record pointing to the IP Address of the host. And the other is a CNAME record that catches all virtual hosts below this one and forwards it to the A entry. This is a simple way to locate our services.

Just a little example to show you the setup:

This will allow us to reach our server as server.test and whatever.server.test, youwant.server.test. When you access the site with your favorite tool like a REST service, httpie or a browser, the client will forward the target host in an HTTP header called Host. Traefik will find the right container based on this header to forward the request to.

One advantage of using virtual hosts is that you don’t need to take extra care of redirects in your web application. We ran into problems when using relative paths for deployments because nobody thought about that being an option. Once you have your environment set up, you can deploy the services as you like.

Scaling out

Deploying a single container is easy and we could achieve it without any great effort. But what about scaling out? What part of the config do I have to change? The simple answer is: You don’t have to change your config. Just spin up more containers and that’s it. In our simple example:

This command will spin up four containers that will get added to the load balancer instantly. You can verify it by hitting the endpoint repeatedly and see the container name change and by having a look at the dashboard that is located on port 8080.

Sticky Sessions

Clearly I would strive for a stateless application backend that can be scaled independently and without any restrictions regarding the service endpoint.

Sometimes you don’t have the freedom because you are running a session-based application that doesn’t distribute the sessions in a cluster of servers. Or – if you think more of REST services – you heavily use caching of resources and you want your sessions pinned to a specific container. No matter why you want your clients to be pinned to a specific Docker container, there is an easy configuration switch to handle it:

This will check for a session cookie with a specific backend as a value. If the cookie is present and the backend is up, the request will be forwarded there. If the backend is down, another is chosen.

Be sure to use the upcoming 1.4 version for this feature or my patched Docker image (marcopaga/traefik: if you want to use this feature. Before these versions, the cookie path wasn’t specified so that clients tended to drop the cookie once in a while depending on the request path.