Container Apps internal service-to-service call times out (TCP connect timeout) despite healthy target container and correct DNS resolution

Question

Problem description

Internal HTTP calls between Container Apps in the same Managed Environment, using the short internal service name (http://appname:port), fail with a raw TCP connect() timeout - not an HTTP-level timeout. This happens even though:DNS resolves the internal name to a valid internal IP.The target container is confirmed healthy (HealthState: Healthy), stable, and has been running for hours without restarts.The exact same call pattern to a different, freshly created "hello world" test app in the same environment succeeds within ~1 second.Ingress configuration (targetPort aside) is identical between the working and failing app: external=false, transport=Auto, no IP restrictions, no client cert requirement, no custom domains.The target app's own log stream shows zero new log entries corresponding to the failed call's exact timestamp window - no incoming request is logged at all.

Environment

Azure Container Apps, Consumption workload profile, Single revision mode, Dapr disabledVNet-integrated environment (infrastructureSubnetId set to a delegated subnet), no custom domains bound, no peering involved in the current testRegion: France Central

What we've already tried

Deleted and fully recreated the entire Managed Environment and all application Container Apps from scratch, onto the same subnet as before.Verified DNS resolution succeeds to a correct internal IP for the failing hostname.Confirmed calling localhost inside the same container works fine (rules out app-level binding issues).Deployed a brand-new isolated environment on a brand-new VNet/subnet in a separate resource group - internal calls worked correctly there.After moving production onto a new VNet/subnet (matching the working isolated test): the exact same timeout reappeared immediately.Removed VNet peering entirely: no change.Restarted all application revisions: no change.Ran a clean paired test with exact UTC timestamps: a call to a fresh test app succeeded in ~10s with a real HTTP response; immediately afterward, the failing call to an existing app timed out with a Python `socket.connect()` TimeoutError (the TCP three-way handshake itself never completes - this is not an application-layer issue).

Question

Answer

Hi @JochenLeppert-3710 ,

Thank you for reaching out to Microsoft Q & A !

The combination of successful DNS resolution, a TCP connect() timeout, and no corresponding request in the target application's logs suggests that the connection is failing before it reaches the application layer. Based on the troubleshooting you've already performed, I would focus the next investigation on the Container Apps ingress/networking path rather than DNS or the application itself.

For Azure Container Apps, I recommend the following checks:

Verify the target application's ingress and target-port configuration. The configured targetPort should match the port on which the application is actually listening. Although your successful localhost test makes an application-level listener problem less likely, this is still worth validating from the Container App resource configuration. Microsoft: Troubleshoot target port settings

Confirm the internal ingress configuration. With internal app ingress, the application can be reached by other Container Apps within the same environment. Verify that the failing application has the expected ingress visibility and transport configuration. Microsoft: Azure Container Apps ingress overview

Compare the failing application with the working test application. Since both are in the same Managed Environment and the newly created application is reachable, comparing their effective ingress configuration, target port, revision/traffic configuration, and other relevant networking settings may help identify an app-specific difference.

Run the Container Apps "Diagnose and solve problems" checks. Microsoft provides networking and configuration diagnostics for Container Apps that can help identify issues affecting connectivity and ingress. Microsoft: Diagnose and solve problems for Azure Container Apps

The fact that the same caller can establish a connection to another application in the same environment, while the affected application times out during socket.connect() and records no incoming request, is particularly useful for narrowing the investigation toward the Container Apps ingress/routing path.

I would avoid concluding from these symptoms alone that there is a platform-side bug; the evidence supports investigating the ingress/networking path, but additional platform-side diagnostics would be needed to determine the underlying cause.

Please "Upvote the Answer" if this information helped you. This will help us and others in the community as well.