🐛 Cloudflare Tunnel QUIC connections intermittently terminate with "timeout: no recent network activity" in Azure Container Apps

**Describe the bug**

We are running `cloudflared` as a container in an Azure Container App.

The container itself remains healthy and running, but established Cloudflare Tunnel QUIC connections intermittently terminate with:

`timeout: no recent network activity`

When this happens, `cloudflared` retries the connection and successfully registers a new QUIC connection shortly afterwards.

This causes intermittent connectivity interruptions through the tunnel.

The issue appears to affect individual QUIC connections rather than the Azure Container App/container itself. We do not see the container restarting when these connection failures occur.

**To Reproduce**

Steps to reproduce the behavior:

1. Run `cloudflared` inside an Azure Container App.
2. Configure a Cloudflare Tunnel using the default/automatic protocol selection.
3. Allow the tunnel to establish multiple QUIC connections.
4. Keep the container running and monitor the `cloudflared` logs.
5. After some time, one or more established QUIC connections intermittently terminate with `timeout: no recent network activity`.
6. `cloudflared` retries the connection and establishes a new QUIC connection.

Example log sequence:

INF Registered tunnel connection connIndex=0 protocol=quic
INF Registered tunnel connection connIndex=1 protocol=quic
INF Registered tunnel connection connIndex=2 protocol=quic

ERR failed to accept incoming stream requests error="failed to accept QUIC stream: timeout: no recent network activity"
ERR failed to run the datagram handler error="timeout: no recent network activity"
WRN failed to serve tunnel connection error="accept stream listener encountered a failure while serving"
WRN Serve tunnel error error="accept stream listener encountered a failure while serving"
INF Retrying connection in up to 1s
WRN Connection terminated error="accept stream listener encountered a failure while serving"

INF Tunnel connection curve preferences: [X25519MLKEM768 CurveID(65074) CurveP256]
INF Registered tunnel connection connIndex=0 protocol=quic

Another observed occurrence:

ERR failed to accept incoming stream requests error="failed to accept QUIC stream: timeout: no recent network activity"
ERR failed to run the datagram handler error="timeout: no recent network activity"
WRN failed to serve tunnel connection error="datagram manager encountered a failure while serving"
INF Retrying connection in up to 1s
INF Registered tunnel connection connIndex=1 protocol=quic

If it's an issue with Cloudflare Tunnel:

4. Tunnel ID: `[REDACTED]`
5. `cloudflared` config:

tunnel: [REDACTED]
credentials-file: [REDACTED]

# Other configuration omitted because it contains internal/private information.

The tunnel is running inside Azure Container Apps and uses the default/automatic protocol selection.

**Expected behavior**

Established QUIC tunnel connections should remain stable while the container remains healthy and network connectivity is available.

If a QUIC connection does encounter a network interruption, the tunnel should recover without noticeable interruption where possible.

We would also like to understand whether `timeout: no recent network activity` is expected behavior for QUIC connections running inside Azure Container Apps.

**Environment and versions**

- OS: Linux (container)
- Architecture: AMD64
- Version: latest .2026.8.2
- Platform: Azure Container Apps
- Protocol: QUIC
- Protocol selection: Default/automatic
- Base image: `gcr.io/distroless/base-debian13:nonroot-amd64`

The container remains running during the QUIC connection failures.

Multiple tunnel connections are established concurrently.

After rebuilding/redeploying the container, the built-in `cloudflared` connectivity checks reported:

+-------------------------------------------------------------------------------------+
| COMPONENT TARGET STATUS DETAILS |
+-------------------------------------------------------------------------------------+
| DNS Resolution region1.v2.argotunnel.com PASS DNS Resolved successfully |
| DNS Resolution region2.v2.argotunnel.com PASS DNS Resolved successfully |
| UDP Connectivity region1.v2.argotunnel.com PASS QUIC connection successful |
| UDP Connectivity region2.v2.argotunnel.com PASS QUIC connection successful |
| TCP Connectivity region1.v2.argotunnel.com PASS HTTP/2 connection successful |
| TCP Connectivity region2.v2.argotunnel.com PASS HTTP/2 connection successful |
| Cloudflare API api.cloudflare.com:443 PASS API is reachable |
+-------------------------------------------------------------------------------------+

SUMMARY: Environment is healthy. cloudflared will use 'quic' as primary protocol.

Therefore, DNS, UDP/QUIC, TCP/HTTP/2, and Cloudflare API connectivity are successful when the connectivity check is performed.

However, established QUIC connections can subsequently terminate with:

`timeout: no recent network activity`

**Logs and errors**

Additional examples:

WRN Serve tunnel error error="accept stream listener encountered a failure while serving"
ERR failed to accept incoming stream requests error="failed to accept QUIC stream: timeout: no recent network activity"
ERR failed to run the datagram handler error="timeout: no recent network activity"
WRN failed to serve tunnel connection error="accept stream listener encountered a failure while serving"
INF Retrying connection in up to 1s
WRN Connection terminated error="accept stream listener encountered a failure while serving"

The connection is then successfully recreated:

INF Tunnel connection curve preferences: [X25519MLKEM768 CurveID(65074) CurveP256]
INF Registered tunnel connection connIndex=0 protocol=quic

Another observed sequence:

ERR failed to accept incoming stream requests error="failed to accept QUIC stream: timeout: no recent network activity"
ERR failed to run the datagram handler error="timeout: no recent network activity"
WRN failed to serve tunnel connection error="datagram manager encountered a failure while serving"
WRN Serve tunnel error error="datagram manager encountered a failure while serving"
INF Retrying connection in up to 1s
INF Registered tunnel connection connIndex=1 protocol=quic

The same behavior has been observed on multiple connection indexes.

**Additional context**

The Azure Container App remains healthy during the failures and we do not observe a container restart associated with the QUIC disconnects.

The tunnel generally continues operating because `cloudflared` automatically reconnects, but the connection termination can cause intermittent interruptions.

The issue does not appear to be caused by an inability to establish QUIC connectivity initially. The connectivity checks successfully report QUIC connectivity to both test endpoints.

We would like to determine whether this is:

- Expected QUIC behavior
- An Azure Container Apps UDP/NAT/idle-timeout interaction
- A `cloudflared` issue
- Or a configuration issue specific to running Cloudflare Tunnel inside Azure Container Apps

We would particularly appreciate guidance on:

1. Is `timeout: no recent network activity` expected for established QUIC connections in this environment?
2. Are there known QUIC/UDP idle-timeout issues when running `cloudflared` inside Azure Container Apps?
3. Could Azure Container Apps networking, NAT, UDP idle timeouts, or another networking component cause an established QUIC connection to become inactive from `cloudflared`'s perspective?
4. Are there recommended `cloudflared` settings, keepalive settings, or timeout settings for this environment?
5. Would switching from QUIC to HTTP/2 be a recommended workaround?
6. Would running multiple `cloudflared` replicas improve availability for this type of failure?
7. Are there additional diagnostics or debug logs we should collect to identify why the QUIC connection becomes inactive?

No source file, test, or code entry point is identified. Start by reproducing the QUIC disconnect in Azure Container Apps and collecting the requested diagnostics while comparing QUIC with HTTP/2. Done means determining whether the failure is expected, caused by Azure networking, or requires a cloudflared change or documented workaround.

Written by the indexing model from the issue text.