App Service refuses connections with error: “No connection could be made because the target machine actively refused it”

This post was most recently updated on December 7th, 2020.

3 min read.

This blog post describes a very specific fix to a very specific issue. In a software project that consisted of a desktop client application and some APIs hosted on Azure, we ran into an error where some connections to APIs would fail with an error like this:

No connection could be made because the target machine actively refused it.

What gives?


Imagine this: You’re connecting to an API hosted by an Azure App Service (“Web App”, if you wish) using an application or a DLL built on .NET Framework. Your code managing the connection looks something like this:

private string YourMethod()
	var httpClient = new HttpClient();

	string url = [restApiUrl];

	var response = httpClient.GetAsync(url).Result;

	if (response.IsSuccessStatusCode)
		// Omitted for clarity
		// This is where we ended up in

That’s all clean and kosher, but it still generates an error somewhat like in the title. Your stacktrace can vary GREATLY, because you might get this from multiple different calls and libraries. It is, in fact, the server responding to your request (whether that’s the server you’re aiming for, or something along the way, is pretty tough to know), but just refusing to handle it properly.

Note: Depending on the library you’re using, you could also get an Exception with a pretty generic message that’s something like “An error occurred while sending the request.


There’s plenty of different reasons why you could run into this. The target server being down, an intermediate host refusing to connect you or something like a firewall blocking your access. But sometimes, it’s something a bit more weird!

Like in our particular case: it was the minimum required TLS version causing the issue. Since we were using an older version of .NET Framework, our HttpClient didn’t support TLS versions later than 1.0.

Any new App Service deployed after 6/30/2018 has had minimum TLS version requirement set to 1.2. See below for a bit if documentation by Microsoft.

Starting June 30, all new apps in Azure App Service will be created with TLS 1.2 by default.

Although we don’t recommend it, you can select TLS 1.1 or 1.0. The update can take place through the Azure portal and Azure CLI. For details on how to make your selection, see the documentation.

Okay. So how do we go about fixing this?


2 different options here, an easy one, and a smart one :)

Let’s check out the smart one first, as that’s nice and proper.

Update to later versions of .NET

There’s a very real risk you’re not going to want to do this, but I’m going to say it anyway. Upgrade your app to use a later version of .NET Framework (or Core).

I don’t have steps for this, as each case is different. Sorry, but you’ll need to figure it out by yourself.

However, there’s always the easy option…

Enable TLS 1.0 for your Azure App Service

Well, this is definitely easy, but generally speaking not recommended. 1.2 is safer, and there’s no telling when Microsoft will disable 1.0 completely!

Anyway, for now you can follow the steps below.

Time needed: 5 minutes

How to enable TLS 1.0 for your Azure App Service?

  1. Fire up Azure Portal in your browser of choice

  2. Navigate to your Azure App Service

  3. In the left hand side navigation, find “TLS/SSL settings”

  4. Enable support for TLS 1.0

    Under “Bindings”, you can set “Minimum TLS Version” to be 1.0Azure App Service TLS/SSL Settings

  5. Save!

    If “Save” button is visible, hit it. After a minute or so, you should be good!

With that, you’re done. If your issue was caused by this configuration, whatever you’re developing should run without a hitch now! Or at least produce a different error… :)

0 0 votes
Article Rating
Notify of

Inline Feedbacks
View all comments