Container Apps VNet-integrated environment: ingress "Connection refused" for every app, survives full environment delete+recreate, points to internal k8se-app-webhooks-service timeout

Question

Summary

A VNet-integrated Azure Container Apps environment in East US 2 has been completely

unreachable from the outside since 2026-08-12, despite every container/replica reporting

fully healthy. We've isolated this to what looks like an internal platform control-plane

failure, not a customer-side configuration issue, and are looking for confirmation / a fix

from an Azure engineer.

Environment

Resource: Container Apps Environment (most recently dafeu2utrialcae01, resource group rg-daf-eastus2-uat-trial-app, region East US 2)
VNet-integrated: infrastructure subnet 10.5.1.0/24 in VNet trneu2uvnet01
Workload profile: Consumption only

Symptom

Every HTTP request to any app's default *.azurecontainerapps.io hostname (and to custom

domains bound via az containerapp hostname bind) returns:

HTTP 503

upstream connect error or disconnect/reset before headers. retried and the latest reset

reason: remote connection failure, transport failure reason: delayed connect error:

Connection refused

This happens even though:

az containerapp replica list shows the replica as ready=true, started=true, restartCount=0, runningState=Running
The app resource itself reports provisioningState=Succeeded, deploymentErrors=null
az containerapp exec into the "healthy" replica fails separately with Cannot attach to a container that is not running — inconsistent with the replica list's own reported state

What we've ruled out

Not one broken app — confirmed identical symptom on 3 separate Container Apps in the environment, including a brand-new app that had never been touched before.
Not one broken environment object — we deleted the entire Container Apps environment and recreated it from scratch (new static IP, new random domain-label suffix) on the same subnet, redeployed an app, and got the identical symptom immediately, on a genuinely fresh environment with a fresh replica.
Not NSG/NAT misconfiguration — the subnet's NSG has the standard required AllowContainerAppInbound rule (source *, ports 80/443, dest = subnet CIDR) plus Azure's default rules, unchanged and correct. We also tried removing the NAT Gateway entirely from the subnet (on the theory that NAT Gateway egress might interfere with the platform's own internal calls) and restarted the revision — no change, still identical 503.
Not a "shared vs. dedicated" environment thing — we have another, older, non-VNet-integrated environment in the same subscription/region that has worked reliably for months. We also have a different product's VNet-integrated environment (different VNet, same subscription/region, created months ago) that works fine right now — so VNet integration itself is not inherently broken in this subscription/region either. The only environments we've ever had trouble with are the ones created 2026-08-12 in this specific subnet/environment.

The actual clue — Azure's own platform diagnostics

The Container Apps "Diagnose and solve problems" / support-request network diagnostics panel

surfaced this platform-detected error directly:

DNS/Network Failures (1): Internal error occurred: failed calling webhook "mapp.kb.io":

failed to call webhook: Post "https://k8se-app-webhooks-service.k8se-system.svc:443/

mutate-k8se-microsoft-com-v1alpha1-app?timeout=10s": context deadline exceeded

— affected apps/jobs: cappscanary-graysea-1faab5ca

This points to the platform's own internal Kubernetes admission webhook

(k8se-app-webhooks-service, in the k8se-system namespace — Azure's internal

implementation namespace for Container Apps) timing out when trying to call itself. This is

entirely inside Azure's control plane and not something we can inspect or influence from the

customer side.

Question

Has anyone seen this specific k8se-app-webhooks-service / mapp.kb.io admission webhook

timeout before? Is this a known issue with a workaround, or does it require an internal fix

on a specific region/cluster segment? We've also submitted a formal support ticket for the

related East US 2 "Managed Environment Count" quota increase, but our support plan doesn't

appear to allow a Technical-classification ticket for the ingress issue itself — the Portal

routes us to this Q&A channel instead of a case. Happy to provide additional resource IDs,

timestamps, or further diagnostics.

Answer

The supported guidance in this scenario is to verify the self-service networking and ingress checks first, then escalate if they are clean.

Based on the described symptoms, the highest-value checks are:

Verify ingress on one affected app.
- In Azure portal: Container App > Configure > Networking > Ingress.
- Confirm ingress is enabled.
- Confirm the app is set correctly for the intended exposure model.
- Confirm Target port matches the port the application actually listens on.
- Confirm the FQDN is assigned.
- If requests return 503/502-like behavior, a mismatched target port is a documented cause.
Verify traffic is going to a healthy revision.
- In Azure portal: Container App > Configure > More > Revisions & Replicas.
- Confirm traffic routes to the intended revision and that the revision is healthy.
- CLI check:
```
     az containerapp ingress traffic show -g  -n  -o table
```
- If traffic is pinned to an older revision, set latest to 100%:
```
     az containerapp ingress traffic set -g  -n  --revision-weight latest=100
```
Check ingress configuration directly with CLI.
```
   az containerapp show -g  -n  \
     --query "{ingress:properties.configuration.ingress, latestReady:properties.latestReadyRevisionName}" -o json
```
Validate:
- ingress exists and is enabled
- targetPort matches the app listener
- transport matches the app protocol
- FQDN is present

Check HTTP logs to determine whether the failure is from the app or the platform.

In Log Analytics, query ContainerAppHTTPLogs and review ResponseCodeDetails.

CLI example:

     az monitor log-analytics query -w  \
       --analytics-query "ContainerAppHTTPLogs | where TimeGenerated > ago(1h) | where StatusCode >= 400 | project TimeGenerated, Method, Path, StatusCode, ResponseCodeDetails | take 50"

Verify VNet DNS behavior for the Container Apps environment.
- If the VNet uses custom DNS, unresolved queries must be forwarded to 168.63.129.16.
- NSG or firewall rules must not block 168.63.129.16.
- If the environment uses restricted outbound access or custom DNS, ensure required endpoints remain reachable.
If managed identity or private registry access is involved, confirm required name resolution and outbound access.
- For managed identity token acquisition, login.microsoft.com or .login.microsoft.com must be reachable.
- For private ACR, the environment must be able to resolve and connect to the registry.

If those checks are clean and the problem persists across multiple apps, a recreated environment, and healthy revisions, the documented next step is to file an Azure support request. The troubleshooting guidance explicitly says to use support when diagnostics pass but the problem persists.

References: