Azure Hybrid Connections continuously dropping and reconnecting

Question

Azure Hybrid Connections continuously dropping and reconnecting

Brice Warembourg 20

Hi,

My company has 3 APIs hosted on Azure that reach our private network with hybrid connections. These have been working without issue for years. For the past week, the hybrid connections used to reach our network have been dropping and reconnecting hundreds of times a day on all 3 sites, or at least that is what it looks like.

When looking at the status of the connections under Networking settings on the Azure Web App dashboard, they will continuously switch between Not Connected and Connected.

The Hybrid Connections Manager on our server stays on status connected for these same connections.

Some of the errors found in various logs are as follows:

A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - The specified network name is no longer available.)

Error from Hybrid Connection Manager logging: System.Net.Sockets Error: 0 : [6860] Exception in Socket#41046487::EndReceive - 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.

I have now spent several days trying to pinpoint what could be happening but have not been successful.

kagiyama yutaka 5,410 Reputation points

2026-05-12T03:58:07.13+00:00

I think that a tiny tcpping <relay> 443 and tcpping <onprem> <port> from the HCM box is the shortest, safest way to spot the unstable hop behind the HC flaps.　　　　　　　　　　　　　　　　　　　　　　　　　　　 adding: <relay> is just the relay host shown in the HC settings, and 443 is the port HC uses to reach it.

Answer accepted by question author

Siddhesh Desai 8,210 Microsoft External Staff Moderator

Hi @Brice Warembourg

Thank you for reaching out to Microsoft Q&A.

The behavior you are experiencing is typically caused by intermittent instability in the communication path between Azure App Service, Azure Relay (Hybrid Connections), and your on‑premises endpoint. Even though the Hybrid Connection Manager (HCM) shows Connected, this only confirms that HCM has an outbound connection to Azure Relay over port 443; it does not guarantee that the full end‑to‑end TCP path (App Service → Azure Relay → backend server) is stable. Hybrid Connections rely on long‑lived outbound TLS/WebSocket connections on port 443, and any disruption in this path such as firewall/proxy interference, idle timeouts, TLS negotiation issues, or backend endpoint instability can cause frequent disconnections. Errors like “connection forcibly closed by remote host”, “pre-login handshake failed”, and socket timeouts are commonly observed when intermediate network devices terminate or reset these persistent connections. Additionally, recent infrastructure or security changes (for example, firewall rule updates, proxy changes, or TLS hardening) can introduce such behavior even if the setup was previously stable. Hybrid Connections works by brokering traffic through Azure Relay using outbound connections from both ends, so instability at any layer can result in the connection status flapping between Connected and Not Connected. [docs.azure.cn]

Refer below points to resolve this issue or this is the workaround

Verify outbound connectivity from HCM to Azure Relay

Run continuous connectivity tests from the HCM machine to ensure stable outbound access over port 443:

Test-NetConnection <namespace>.servicebus.windows.net -Port 443

If you observe intermittent failures, investigate WAN, firewall, or proxy issues as this indicates network instability.

Validate firewall/proxy configuration and avoid connection termination

Ensure that outbound HTTPS/WebSocket traffic to *.servicebus.windows.net is allowed and not intercepted. Disable SSL inspection if enabled and check for aggressive idle timeout policies, as these can terminate long‑running TCP connections required by Hybrid Connections.

Check recent changes in network, security, or OS updates

Since the issue started recently after stable operation, review any changes such as firewall rule updates, proxy modifications, TLS/cipher updates, or OS patching on the HCM host or backend servers, as these are common triggers for connection resets.

Validate backend endpoint stability from the HCM machine

Test connectivity directly from the HCM host to the backend to confirm the service is consistently reachable:

Test-NetConnection <backend-host> -Port <port>

If intermittent failures occur, the issue may be with the backend service or internal network rather than Azure.

Use Hybrid Connection Debug Utility to isolate the issue

Leverage the Hybrid Connection Debug Utility to simulate and trace traffic between App Service and your backend. This helps determine whether the issue lies in the relay path or the backend endpoint.

Validate DNS resolution and configuration

Ensure the Hybrid Connection endpoint is configured using a DNS hostname (not IP) and verify consistent resolution using tools like:

nslookup <hostname>

Hybrid Connections routing relies on DNS mapping, and inconsistencies can lead to connection failures. [docs.azure.cn]

Check for idle timeout or connection recycling in network appliances

If Azure Firewall, load balancer, or proxy is involved, review TCP idle timeout settings. Long‑running sessions can be dropped due to timeout or maintenance operations, which can interrupt Hybrid Connections.

0 comments

1 additional answer

Your answer

kagiyama yutaka 5,410 Reputation points

2026-05-12T03:58:07.13+00:00

I think that a tiny tcpping <relay> 443 and tcpping <onprem> <port> from the HCM box is the shortest, safest way to spot the unstable hop behind the HC flaps.　　　　　　　　　　　　　　　　　　　　　　　　　　　 adding: <relay> is just the relay host shown in the HC settings, and 443 is the port HC uses to reach it.

Answer 1

The behavior described matches intermittent connectivity issues on the Hybrid Connection / Azure Relay path or between Hybrid Connection Manager (HCM) and the on‑premises endpoints. Troubleshooting should focus on network stability, firewall/proxy configuration, and end‑to‑end TCP connectivity.

Use the following steps to narrow down and remediate the issue:

Verify HCM outbound connectivity to Azure
1. On the HCM host, confirm outbound access to Azure over port 443:
  - Run Test-NetConnection <RelayNamespace>.servicebus.windows.net -Port 443.
  - If this fails intermittently, investigate WAN, firewall, or proxy issues.
2. Ensure no conflicting software is installed on the HCM host:
  - Remove BizTalk Hybrid Connection Manager or Service Bus for Windows Server if present, as they cannot coexist with HCM.
Check firewall/proxy rules for Azure Relay
1. Confirm that outbound HTTPS and WebSocket traffic over port 443 is allowed from the HCM host to Azure.
2. If the firewall or proxy supports DNS allowlisting, allow:
  - *.servicebus.windows.net.
3. If wildcard DNS rules are not supported:
  - Use the Service Bus endpoint URL shown in HCM (GUI or CLI) to identify the Relay namespace.
  - Use nslookup on that endpoint to get the stamp name.
  - Allow the namespace hostname and all gateway hostnames for that namespace (e.g., G#-prod-[stamp]-sb.servicebus.windows.net, GV#-prod-[stamp]-sb.servicebus.windows.net).
4. Avoid IP allowlists for Relay, as gateway IPs can change; use hostnames instead.
Confirm HCM health and state
1. Restart the Azure Hybrid Connection Manager Service on the HCM host to clear any bad state.
2. Monitor HCM logs after restart to see if disconnects correlate with any local errors or timeouts.
Validate on‑premises endpoint connectivity from HCM
1. Ensure the Hybrid Connection uses a DNS name (not an IP address) for the on‑premises endpoint.
2. On the HCM host:
  - Run nslookup <EndpointDNSName> and confirm it resolves exactly as configured in the Hybrid Connection.
  - Run Test-NetConnection <EndpointDNSName> -Port <Port> to verify TCP connectivity.
3. If Test-NetConnection fails or is intermittent:
  - Check internal firewalls between HCM and the SQL servers or APIs.
  - Check host‑based firewalls on the destination servers.
4. For App Service on Linux, ensure localhost is not used as the endpoint host; use the actual machine name instead.
Validate from the App Service side
1. Use the Advanced Tools (Kudu) console for each Web App:
  - Use tcpping <EndpointHost> <Port> to confirm that the app can reach the TCP endpoint (note: this confirms host:port reachability, not Hybrid Connection health itself).
  - If available, use a command‑line client (e.g., curl for HTTP endpoints) to test end‑to‑end connectivity through the Hybrid Connection.
2. Correlate times when the Azure portal shows Not Connected with HCM logs and on‑premises network logs.
Check for transient network issues
1. Because the errors indicate connections being forcibly closed or timing out, look for:
  - WAN instability between on‑premises and Azure.
  - Load balancers, IDS/IPS, or security appliances closing idle or long‑lived connections.
2. If intermittent packet loss is suspected, use tools like psping, tnc, or similar from the HCM host to the Relay namespace to measure dropped connections and latency.
Review security and access configuration
1. Ensure that no recent changes were made to Relay or Hybrid Connection configuration (keys, authorization rules, or roles) that might cause intermittent failures.
2. If Hybrid Connections were reused across apps, verify that access to the Azure Service Bus Relay is properly locked down and that only intended apps can use it.
If issues persist
- Collect HCM logs, network traces (e.g., via Wireshark) from the HCM host, and timestamps of disconnects.
- Use these artifacts when engaging Microsoft Support for deeper analysis.

References: