Uredi

Troubleshoot intermittent outbound connection errors in Azure App Service

Summary

This article helps you troubleshoot intermittent outbound connection errors and related performance issues in Azure App Service. It provides more information on, and troubleshooting methodologies for, exhaustion of Source Network Address Translation (SNAT) ports.

Symptoms

Applications and functions hosted on App Service might exhibit one or more of the following issues:

  • Slow response times on all or some of the instances in a service plan.
  • Intermittent 5xx or Bad Gateway errors.
  • Time-out error messages.
  • Inability to connect to external endpoints (like SQLDB, Service Fabric, or other app services).

Cause

The major cause for intermittent connection issues is hitting a limit while making new outbound connections. The limits you can hit include:

  • Transmission Control Protocol (TCP) connections: There's a limit on the number of outbound connections that you can make. The limit on outbound connections is associated with the size of the worker used.
  • SNAT ports: Outbound connections in Azure describes SNAT port restrictions and how they affect outbound connections. Azure uses source network address translation (SNAT) and load balancers (not exposed to customers) to communicate with public IP addresses. Each instance on App Service is initially given a preallocated number of 128 SNAT ports. The SNAT port limit affects opening connections to the same address and port combination. If your app creates connections to a mix of address and port combinations, you don't use up your SNAT ports. The SNAT ports are used up when you have repeated calls to the same address and port combination. Once a port is released, the port is available for reuse as needed. Azure Load Balancer reclaims SNAT ports from closed connections only after waiting for four minutes.

When applications or functions rapidly open a new connection, they can quickly exhaust their preallocated quota of 128 ports. They're then blocked until a new SNAT port becomes available, either through dynamically allocating more SNAT ports, or through reuse of a reclaimed SNAT port. If your app runs out of SNAT ports, it has intermittent outbound connectivity issues.

Troubleshooting

There are solutions that let you avoid SNAT port limitations. They include:

  • Connection pools: By pooling your connections, you avoid opening new network connections for calls to the same address and port.
  • Service endpoints: You don't have a SNAT port restriction to services secured with service endpoints.
  • Private endpoints: You don't have a SNAT port restriction to services secured with private endpoints.
  • NAT gateway: With a NAT gateway, you have 64 thousand outbound SNAT ports that are usable by the resources sending traffic through it.

To avoid SNAT port problems, prevent the creation of new connections repetitively to the same host and port. Connection pools are a way to solve SNAT port problems.

If your destination is an Azure service that supports service endpoints, you can avoid SNAT port exhaustion issues by using regional virtual network integration and service endpoints or private endpoints. When you use regional virtual network integration and place service endpoints on the integration subnet, your app outbound traffic to those services won't have outbound SNAT port restrictions. Likewise, if you use regional virtual network integration and private endpoints, you won't have any outbound SNAT port issues to that destination.

If your destination is an external endpoint outside of Azure, using a NAT gateway gives you 64 thousand outbound SNAT ports. It also gives you a dedicated outbound address that you share with no one.

If possible, improve your code to use connection pools and avoid the entire situation. It isn't always possible to change code fast enough to mitigate this situation.

For cases where you can't change your code in time, take advantage of the other solutions. The best solution to the problem is to combine all of the solutions as best you can. Try to use service endpoints and private endpoints to Azure services and the NAT gateway for the rest.

To learn more about strategies for mitigating SNAT port exhaustion, see Use SNAT for outbound connections. Of these strategies, the following are applicable to apps and functions hosted on App Service.

Use connection pooling

The following resources describe implementing connection pooling by different solution stacks.

Node

By default, Node.js doesn't keep connections alive. Resources include:

HTTP keep-alive resources include:

Java

Java Database Connectivity (JDBC) connection pooling resources include:

HTTP connection pooling resources include:

PHP

Although PHP doesn't support connection pooling, you can try using persistent database connections to your back-end server. Resources include:

Python

Python connection pooling resources include:

HTTP

HTTP connection pooling resources include:

Reuse connections

For more resources and examples on managing connections in Azure Functions, see Manage connections in Azure Functions.

Use less aggressive retry logic

For more guidance and examples, see Retry pattern.

Use keepalives to reset the outbound idle timeout

For implementing keepalives for Node.js apps, see My node application is making excessive outbound calls.

More guidance specific to App Service

Further App Service-specific guidance includes:

  • A load test should simulate real-world data in a steady feeding speed. Testing apps and functions under real-world stress can identify and resolve SNAT port exhaustion issues ahead of time.
  • Ensure that the back-end services can return responses quickly. For troubleshooting performance issues with Azure SQL Database, review Troubleshoot Azure SQL Database performance issues with Intelligent Insights.
  • Scale out the App Service plan to more instances. For more information on scaling, see Scale an app in Azure App Service. Each worker instance in an app service plan is allocated a number of SNAT ports. If you spread your usage across more instances, you might get the SNAT port usage per instance below the recommended limit of 100 outbound connections, per unique remote endpoint.
  • Consider moving to App Service Environment, where you're allotted a single outbound IP address, and the limits for connections and SNAT ports are higher. In an App Service Environment, the number of SNAT ports per instance is based on the Azure load balancer preallocation table. For example, an App Service Environment with 1-50 worker instances has 1,024 preallocated ports per instance, while an App Service Environment with 51-100 worker instances has 512 preallocated ports per instance.

Avoiding the outbound TCP limits is easier to solve, as the limits are set by the size of your worker. You can see the limits in Sandbox Cross VM Numerical Limits - TCP Connections.

Limit name Description Small (A1) Medium (A2) Large (A3) Isolated tier (App Service Environment)
Connections Number of connections across entire VM 1920 3968 8064 16,000

To avoid outbound TCP limits, either increase the size of your workers, or scale out horizontally.

Diagnose outbound connection limits in App Service

Knowing the two types of outbound connection limits and what your app does makes it easier to troubleshoot. If you know that your app makes many calls to the same storage account, you might suspect a SNAT limit. If your app creates many calls to endpoints all over the internet, you might be reaching the virtual machine (VM) limit.

If you don't know the application behavior enough to determine the cause quickly, there are tools and techniques available in App Service to help with that determination.

Find SNAT port allocation information

Use App Service Diagnostics to find SNAT port allocation information, and observe the SNAT ports allocation metric of an App Service site. To find SNAT port allocation information, see the following steps:

  1. To access App Service diagnostics, go to your App Service web app or App Service Environment in the Azure portal. In the sidebar menu, select Diagnose and solve problems.
  2. Select Availability and Performance category.
  3. Select the SNAT Port Exhaustion tile in the list of available tiles under the category. Keep it below 128.

If you can't determine this using the previous steps, open a support ticket.

Because SNAT port usage isn't available as a metric, you can't autoscale based on SNAT port usage or configure autoscale based on the SNAT ports allocation metric.

TCP connections and SNAT ports

TCP connections and SNAT ports aren't directly related. The Diagnose and Solve Problems management page of any App Service app includes a TCP connections usage detector. Search for the phrase TCP connections to find it.

Be aware of the following points when using the TCP connections usage detector:

  • SNAT ports are only used for external network flows, while the total TCP connections includes local loopback connections.
  • Different flows can share SNAT ports if the flows differ in protocol, IP address, or port. The TCP connections metric counts every TCP connection.
  • The TCP connections limit happens at the worker instance level. Azure outbound load balancing doesn't use the TCP connections metric for SNAT port limiting.
  • You can find the TCP connections limits in Sandbox Cross VM Numerical Limits - TCP Connections.
  • Existing TCP sessions fail when new outbound TCP sessions are added from an App Service source port. Either use a single IP or reconfigure backend pool members to avoid conflicts.
Limit name Description Small (A1) Medium (A2) Large (A3) Isolated tier (App Service Environment)
Connections Number of connections across entire VM 1920 3968 8064 16,000

WebJobs and database connections

If SNAT ports are exhausted and WebJobs can't connect to a SQL Server database, no metric shows how many connections each individual web application process opens. To find the problematic WebJob, move several WebJobs to another App Service plan to see if the situation improves or if an issue remains in one of the plans. Repeat the process until you find the problematic WebJob.

References

Third-party contact disclaimer

Microsoft provides third-party contact information to help you find additional information about this topic. This contact information may change without notice. Microsoft does not guarantee the accuracy of third-party contact information.