Internal-only ingress LB returns 'Container App is stopped or does not exist' for a healthy replica (North Europe, Workload Profiles Consumption)

[julvera]

SUMMARY

From a Regional VNet-integrated Azure App Service in North Europe, all calls to a Container App configured with internal-only ingress in the same region return HTTP 404 with the body "Container App is stopped or does not exist", despite the Container App being verifiably running and its application returning 200 on direct probes. After switching the Container App to external ingress plus an IP allowlist of the App Service VNet CIDR, the exact same call succeeds. Nothing else in the path changed. This indicates the internal-only ingress load balancer is failing to route to a healthy replica.

ENVIRONMENT

Region: North Europe.
Subscription: c75b0d6c-4736-48a9-87ad-8a20215ff2af, Artfluence main.

Container App
name: clip-service
resource group: rg-artfluence-northeurope-dev
Container App Environment: cae-artfluence-northeurope-dev, Workload Profiles Consumption
FQDN: clip-service.blackdesert-d3aaefa8.northeurope.azurecontainerapps.io
Internal IP when internal-only: 10.20.0.114
Replica state during repro: Running, Ready, all probes green.

App Service, the calling client
name: app-artfluenceapi-dev-ne-01
resource group: rg-artfluence-northeurope-dev
plan: asp-artfluence-dev-ne-01, B1 tier
VNet integration: enabled, into snet-appservice-dev, 10.20.0.0/24
VNet: vnet-artfluence-northeurope-dev, 10.20.0.0/16
Same VNet as the CAE.

HOW WE PROVED THE CAE INFRA IS THE FAULT NOT THE APPLICATION

1. With clip-service set to internal-only ingress, transport Auto, external false, an HTTPS call from inside the App Service Kudu SSH console targeting the internal FQDN at path /health consistently returns HTTP 404 with body "Container App is stopped or does not exist".

2. From the same Kudu SSH console at the same instant, a direct HTTPS call to the replica IP using curl with --resolve to bind the internal FQDN to 10.20.0.114 succeeded with HTTP 200 and body status ok, device cpu. The application is healthy, the network path to the replica is open, the private DNS resolves correctly, but the CAE internal ingress load balancer at the FQDN official address is not forwarding to the replica.

3. We confirmed all of the following are NOT the cause: no Deny NSG rules touch the path. Container App probes Startup Liveness Readiness all green for over 10 minutes before the test. Application listening port confirmed as 8000 inside the container, matches ingress targetPort. Private DNS zone privatelink.northeurope.azurecontainerapps.io resolves to the CAE internal LB IP correctly. Fresh revision and fresh replica reproduce the same symptom.

4. As a control we switched clip-service to external ingress with an IP restriction of Allow 10.20.0.0/16, Deny all else. With NO OTHER CHANGE on either side, the same Kudu-side call to the external FQDN returns HTTP 200 immediately. Laptop calls correctly return HTTP 403, proving the allowlist works.

The only differing factor between the 404 stopped or does not exist error and the 200 ok response is whether the Container App ingress is internal-only or external. Traffic origin, replica, application, private DNS, VNet, and workload were all identical across both tests.

IMPACT

We had to ship the external-plus-allowlist workaround to unblock active development. Concerns:

• clip-service is reachable from any IP that can spoof being inside the /16 CIDR. We mitigate with a shared-secret CLIP_API_KEY header but defence in depth is reduced.
• It blocks our dev and prod cleanup story. Once prod needs the same access we have to either widen the allowlist further or VNet-peer prod in. Neither matches the documented Microsoft pattern of internal-only Container Apps inside a VNet reached via Regional VNet integration from App Service.

WHAT WE NEED FROM SUPPORT

1. Confirm whether this is a known issue with the internal-ingress load balancer in North Europe, or in Workload Profiles Consumption environments more generally, and if so the workaround or target fix ETA.

2. If it is not a known issue, please pull the CAE internal LB telemetry and Envoy logs for the time window 2026-05-12 around 14 UTC through 2026-05-13 around 17 UTC. We have repeat reproductions in that window and can re-run on demand.

3. Confirm that, after switching back to internal-only ingress, no action on our side, such as a specific revision spec or flag or NSG adjustment or Private DNS zone tweak, would have made the request succeed. We want to rule out misconfiguration on our end before accepting this as a platform bug.

REPRO READINESS

We can reproduce on demand by flipping clip-service ingress back to internal-only. We will keep the current external-plus-allowlist workaround in place for normal operation, and coordinate a time window with the support engineer to switch to internal-only for the repro.

CONTACT

Primary contact Julien, julien@artfluence.app Email-preferred for asynchronous back-and-forth. Happy to do screen share on demand for the repro.

[simonjj]

Thanks for the detailed write-up and clean isolation — the curl-via-replica-IP vs FQDN comparison narrows this down well to the internal LB.

To pull the CAE internal LB / Envoy telemetry for the window you mentioned, could you email acasupport@microsoft.com (subject: GitHub Issue #1714) with:

• The Container App resource URI (full ARM resource path for clip-service)
• The CAE resource URI (cae-artfluence-northeurope-dev)
• The exact UTC timestamps of 2–3 recent failing requests

Labeling as Needs: Investigation and routing to the ingress/networking team. We'll keep this open while we pull backend logs.

[julvera]

Thanks @simonjj. We've emailed acasupport@microsoft.com (subject GitHub Issue #1714) with the ARM resource URIs.

We also ran a fresh controlled reproduction on 2026-05-18: with the Container App flipped back to internal-only ingress, 3 requests from the VNet-integrated App Service to the internal /health endpoint all returned HTTP 404 "Container App is stopped or does not exist":

• 2026-05-18T08:05:23.921Z
• 2026-05-18T08:05:26.150Z
• 2026-05-18T08:05:28.400Z

Ingress was reverted to external + IP allowlist at ~08:05:42Z; a control call returned HTTP 200 at 08:06:12Z from the same client with nothing else changed. The 404 doesn't appear in our ContainerAppConsoleLogs_CL / ContainerAppSystemLogs_CL — consistent with the failure being upstream of the container, at the internal-ingress load balancer.

Minor correction to the original report: the calling subnet is 10.20.2.0/27, not 10.20.0.0/24.

Happy to re-run on demand.

[julvera]

@simonjj — friendly nudge on this one. It's been ~12 days since we emailed acasupport@microsoft.com (subject GitHub Issue #1714, sent 2026-05-18) with the ARM resource URIs and the fresh repro timestamps, and we haven't yet had a response on either the email thread or this issue.

No urgency, but a couple of questions to help us plan on our side:

1. Is there a rough ETA for when the ingress/networking team expects to come back with findings — even ballpark (days vs. weeks)?
2. In the meantime, are there alternative configurations you'd recommend trying that better match the documented "internal-only Container App reached over Regional VNet integration from App Service" pattern? Anything on our side (revision spec, transport setting, NSG/UDR tweaks, private endpoint, dedicated Workload Profile, etc.) that's known to sidestep this internal-LB routing behavior?

Happy to re-run the controlled reproduction at any time if a fresh log window would help.

Thanks!