If you are working on an azure function with a trigger for event hub or service bus and notice this error when debugging locally, the cause is very likely that your machine or network has blocked the TCP ports 5671 and 5672. 

“Azure Service Bus or Azure Event Hubs requires the use of TLS at all times. It supports connections over TCP port 5671, whereby the TCP connection is first overlaid with TLS before entering the AMQP protocol handshake, and also supports connections over TCP port 5672 whereby the server immediately offers a mandatory upgrade of connection to TLS using the AMQP-prescribed model. The AMQP WebSockets binding creates a tunnel over TCP port 443 that is then equivalent to AMQP 5671 connections.”

https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide

Blocking ports 5671 and 5672 can also throw this error message:

“The listener for function ‘Functions.Function1’ was unable to start. Microsoft.Azure.EventHubs.Processor: Encountered error while fetching the list of EventHub PartitionIds. System.Private.CoreLib: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.”

In order to debug event hub triggers or service bus trigger locally using Visual Studio 2019/22 or VS code, create a firewall exception rule to allow ports 5671 and 5672.

Case you work in a highly secured environment where you can’t change the firewall, try adding “TransportType=AmqpWebSockets” to the end of your connection string:

The above may not work to the latest version of Microsoft.Azure.Functions.Worker.Extensions.EventHubs, (to this date, Version 5.1.0.)

For that case you can set the transport to websockets in the host.json

Still no Working?

WebSocket use Http but after all this is still not ordinary Http. Some proxies require some extra configuration to handle WebSocket (click here for example) . There is not much you can do from here. Talk to your Sysadmin, try to confirm if the proxy is blocking WebSocket and if there is no way to fix it, you will need to move on to other approaches like request a dev machine on a location that can reach Azure without proxy. I still have not had time to try Azure Dev Box but it may be a possible solution.

If you have a less restrictive proxy, you can try adding to the host.json , but before doing that, need to make sure this alternative proxy can handle websockets and the azure function need to be at least V5.x+

For any comments, feedback or questions you can also find me on twitter @brunolucasazure