Improved Connectivity Types in Azure SQL Managed Instance

As part of its ongoing connectivity overhaul, Azure SQL Managed Instance is removing the last obstacles to broader use of the redirect connection type. The more performant connection type now operates only on port 1433 and provides fallback support for older TDS clients.

What are "Proxy" and "Redirect"?

Proxy and redirect are two different connectivity mechanisms that can be selected on the instance level to govern SQL client connections on managed instances' VNet-local endpoint. These mechanisms implement two separate data flows between a SQL client and the instance's underlying database engine.

When an instance's connection type is set to proxy, an internal gateway component accepts the connection and opens a new one to the primary replica. The gateway then remains involved until the client disconnects, shuttling the data back and forth between the connection from the client and the connection to the database engine – a process commonly known as proxying, hence the name.

By contrast, when an instance's connection type is set to redirect, the gateway immediately tells an incoming T-SQL client to abandon the current connection and connect to the primary replica instead. The client follows up to start talking directly to the SQL engine without the gateway in the picture. This makes the connection more resilient since it no longer breaks when the gateway undergoes a planned failover. It is also more performant since there's no unnecessary copying of the data between a pair of connections.

So, then it would be reasonable to ask...

What's stopping me from using redirect right now?

Good question! Even though it's more performant, redirect wasn't the winning choice in all scenarios until recently.

1. The client and/or its SQL driver had to understand Tabular Data Stream (TDS) version 7.4 or higher, available since SQL Server 2012 (which is when the TDS redirection handshake was introduced). Older SQL drivers have no mechanism to retarget the primary. Worse, sometimes those older drivers are baked into the client backend or executable, or are written in discontinued frameworks, or may simply not have their source code and build systems available anymore.
2. The client needed to be able to establish a connection across a broad range of ports where the primary might be listening – from 11000 through 11999. That's a thousand target ports open for inbound traffic! Not only does this number raise the hackles of conscientious InfoSec officers concerned about data exfiltration, but it also creates an additional requirement for your networking that is specific to managed instances. That's yet another service-specific deployment detail to keep track of.

Good news, though: we've removed both limitations!

1. Redirect now handles older clients as if the "proxy" connection type were set. This happens on a per-connection basis, though, so while modern SQL drivers will be redirected, any older driver will be transparently proxied. Overall, this hardens your entire fleet of clients against transient gateway disconnections and ekes out maximum performance.
2. Redirect now only requires inbound port 1433 to be open. We've changed the mechanism by which the correct replica is selected so that all replicas now listen on SQL Server's standard TDS port. Simply put, no matter which connection type is set, all managed instances now only expect inbound traffic on port 1433 – and your SQL clients' outbound traffic to managed instances will always only target that port.

So, what's changed?

In a nutshell:

• Redirect no longer requires ports 11000-11999 for inbound traffic. When the connection type is set to redirect, a connecting client is no longer redirected to a port in the 11000-11999 range. All redirection requests are now to port 1433.
• Redirect may choose to proxy a client based on its capabilities. Older (pre-TDS 7.4) SQL drivers that do not support redirection won't receive a redirect message. Instead, the gateway will proxy them transparently. Because this happens on a per-connection basis, you can have redirect as your connection type and rest assured that any legacy clients will still be able to connect. Doing so hardens your entire fleet of clients against gateway disconnections and ekes out maximum network performance.
• New managed instances default to the redirect connection type. If your deployment scripts explicitly set the connection type to proxy, that setting will be respected (see below).
• Default connection type is now replaced with redirect. If your deployment doesn't specify this value or sets it to default, then the instance will automatically adopt the redirect connection type. (It may take up to 24 hours for this change to propagate.)
• Instances with the connection type set to default prior to October 2025 are now explicitly set to proxy. Because default now evaluates to redirect, we've preserved the previous behavior to avoid confusion.
• The new redirect behavior also applies when you connect to the Business Critical tier's secondary replicas via the VNet-local endpoint.

And one thing that stays the same:

• If you use failover groups, do keep in mind that the geo-replication traffic still requires ports 11000-11999 to be open. This is a separate requirement that happens to reuse the same range of ports.

What you should do

If you're creating a new managed instance in a new subnet, you're all set; no need to reconfigure anything or open any extra ports. Your new instances will use redirect by default.

For your existing instances and deployment procedures, you may want to change the connection type from proxy to redirect. At the same time:

• Verify that your TDS drivers don't misreport their versions or provide only partial support for TDS 7.4. If your clients use the recommended versions of drivers and tools or higher, you're all set. However, we're aware that some organizations may use custom-made TDS drivers and drivers that don't exactly comply with the TDS spec. Or, you might just need additional time to validate your network settings. That's why we're keeping the explicit proxy option around.
• Double-check that your clients' network access adheres to the requirements for managed instance VNet-local endpoints. Some of the most common issues we've seen in the past include treating the instance's VNet-local endpoint as if it were a fixed IP address (it does change!) and filtering inbound traffic to allow connections on port 1433 to only the instance's current IP address or FQDN rather than the entire subnet range, as is correct (redirect can target the entire subnet via a service FQDN).

You can learn more about the new redirect behavior in our documentation on the connection types.

Let me know if you find this useful or run into issues. As always, feel free to follow up with a comment or a question and I'll get back to you as soon as possible.

Until next time, 
-Zoran