Azure Container Apps: Startup probe fails with PortsMismatch despite app being healthy and serving traffic

Question

Azure Container Apps: Startup probe fails with PortsMismatch despite app being healthy and serving traffic

Riccardo Ambrosini 0

Setup:

Azure Container App running Spring Boot on port 5443
Public app with HTTP ingress, targetPort: 5443
/actuator/health endpoint returning {"status":"UP"}
No traffic restrictions

Problem: Startup probe consistently fails with:

TargetPort 5443 does not match any of the listening ports: [38269 46063 24000]
Startup probe failed: dial tcp 100.100.0.208:5443: connect: connection refused
Startup probe failed: HTTP probe failed with statuscode: 503

This triggers KEDA to remove the ScaledObject and kill the container in a loop.

What was tested:

Changed targetPort and probe port across 5443, 443, 80, 8080 — same PortsMismatch on all
Tried HTTP and TCP probes against /actuator/health
Tried both HTTP and HTTPS schemes
Increased initialDelaySeconds up to 60s, failureThreshold up to 30, various periodSeconds combinations
Confirmed via netstat / ss that the app binds 0.0.0.0:5443
Verified server.port=5443 in application.yml and EXPOSE 5443 in Dockerfile

Debugging from inside the container revealed:

/proc/net/tcp shows the app listening on ports 23044/23045 (hex 5A04/5A05), not 5443. Port 23045 binds on 0.0.0.0, the rest on various 127.x.x.x addresses — all Envoy sidecar listeners.
/proc/net/nf_conntrack shows successful, completed TCP connections to dport=5443 with ASSURED state — proving Envoy's transparent NAT is correctly routing traffic to the app.
curl 127.0.0.1:5443/actuator/health from inside the container returns {"status":"UP"}.
/dev/tcp/localhost/5443 test returns OPEN.
External traffic works perfectly: https://<app-url>/actuator/info responds correctly.
iptables -t nat -L -n returns empty — redirection likely happens via nftables or a different network namespace.

Conclusion: The Envoy sidecar performs transparent port remapping. The app is bound on 5443 but Envoy intercepts and re-exposes on internal ports (23044/23045). Azure's probe infrastructure appears to validate ports by reading raw socket listeners from /proc/net/tcp, sees only Envoy's ports, and rejects the configured targetPort — despite its own sidecar being the reason for the mismatch. The app is fully healthy and serving traffic; the probe validation doesn't account for the sidecar's NAT.

Hello,

Apologies for the LLM generated description, but I have tried a lot of troubleshooting steps.
I have a springboot app hosted on Azure Container App on port 5443. The app works fine, as I can correctly query all the endpoints exposed by the controllers.
The issue is that for long running applications the container gets killed, possibly because of health probes. By sifting through system logs, it appears that the probes are misconfigured. The problem is that I have already tried several steps, as described in the message, without any luck.
I have also checked multiple times and I am sure the app is exposed on port 5443 (through docker), and the springboot server is also listening on port 5443 (application properties).

Can anyone help me out?

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

2 answers

Your answer

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 1

Siddhesh Desai 4,895 Microsoft External Staff Moderator

Hi @Riccardo Ambrosini

Thank you for reaching out to Microsoft Q&A.

The issue you are facing is not caused by an incorrect port configuration in your Spring Boot application or Docker image. Your application is correctly listening on port 5443, and this is validated by successful external access, localhost curl tests, and confirmed TCP connections. The problem occurs due to how Azure Container Apps uses an Envoy sidecar for ingress. Envoy performs transparent port remapping (NAT) and exposes the application internally on ephemeral ports, while your app still logically listens on 5443. However, the startup probe validation logic in Azure Container Apps checks raw socket listeners (for example /proc/net/tcp) and does not account for Envoy’s port remapping. As a result, it fails with a PortsMismatch error even though the application is healthy and serving traffic. This causes the startup probe to fail repeatedly, which in turn triggers KEDA to remove the ScaledObject and kill the container in a loop. This is a platform limitation/bug in Azure Container Apps startup probe validation when Envoy sidecar networking is involved.

Refer below points to resolve this issue or use as a workaround:

Remove the startup probe (recommended workaround) Startup probes are optional in Azure Container Apps and are not required for long‑running services. Removing the startup probe avoids the faulty port validation path entirely. Keep only readiness and liveness probes pointing to /actuator/health on port 5443. This is the most reliable and production‑safe workaround.

Rely on readiness and liveness probes only Configure HTTP readiness and liveness probes against /actuator/health using the same port. These probes work correctly because they are evaluated after the Envoy sidecar routing is established and do not perform the same raw listener validation as startup probes.

Avoid HTTP‑based scaling if startup probes are required If HTTP scaling (KEDA) is enabled and startup probes are failing, KEDA will continuously remove the revision. If your application is long‑running and not request‑driven, disable HTTP scaling and set minReplicas: 1 to prevent the revision from being deleted.

Do not attempt port changes as a fix Changing targetPort, switching between HTTP/TCP probes, using 80/443/8080, increasing probe delays, or modifying Docker EXPOSE settings will not resolve this issue. The failure is caused by Envoy’s transparent port remapping and the probe validator ignoring it.

Optional: Use internal ingress with TCP probes (advanced scenario) If public ingress is not required, switching to internal ingress and using only TCP‑based readiness checks can also bypass the problematic HTTP probe validation path.

Riccardo Ambrosini 0 Reputation points

2026-04-03T15:50:23.0666667+00:00
Hi Siddhesh Desai, thanks for the insightful answer.

I turned off the startup probe and changed the scaler to be cpu-based, rather than http, but the app still times out.

Also, the readiness probe has the same issues as the startup one - I guess this is related to the issue you mentioned:

Readiness probe failed: Get "http://100.100.1.32:5443/actuator/health": dial tcp 100.100.1.32:5443: connect: connection refused

Just to add to the context:

the app is running on a standard container app environment, on a consumption plan

the app exposes an ingress on port 5443, so I cannot turn off all the probes

I tried turning off the http scaler and also tried subtituting it with a cpu-based one, without any success.

I also found out about this discussion:

https://github.com/microsoft/azure-container-apps/issues/597

Can you confirm whether the maximum timeout is actually 4 minutes for standard plans?

If you have any other troubleshooting step, I will gladly try them.

Thanks again!
Siddhesh Desai 4,895 Reputation points Microsoft External Staff Moderator

2026-04-06T11:12:12.2933333+00:00
@Riccardo Ambrosini Based on your latest findings, there are two separate but compounding platform behaviors affecting your application: (1) Envoy-based probe failures and (2) a hard ingress timeout on Azure Container Apps consumption environments. Even after disabling the startup probe and switching from HTTP‑based scaling to CPU‑based scaling, the readiness probe continues to fail with connection refused because readiness probes are evaluated through the same Envoy‑fronted ingress path. This means they are subject to the same transparent port remapping limitation that caused the startup probe to fail earlier. In other words, the application is healthy and serving traffic, but the probe infrastructure validates connectivity in a way that does not account for Envoy’s internal NAT, resulting in false negatives. Additionally, on Consumption‑based Container Apps, there is a non‑configurable 4‑minute (240 seconds) ingress idle/request timeout, which can cause requests or probe calls to fail even when the container is still running correctly. This timeout is enforced at the Envoy ingress layer and applies regardless of whether scaling is HTTP‑based or CPU‑based, which explains why changing the scaler did not resolve the issue.

Refer below points to resolve this issue or use as a workaround:

Confirm the 4‑minute ingress timeout limitation (expected behavior) Azure Container Apps consumption environments enforce a fixed 240‑second ingress idle/request timeout, and this value cannot be increased or overridden. This is explicitly confirmed by the Azure Container Apps engineering team in GitHub issue #597. If a request or probe depends on a long‑running response path, it will fail after ~4 minutes even though the container continues running. Reference: Ingress Timeout Configurable? – GitHub Issue #597 [github.com]

Understand why readiness probes fail the same way as startup probes In a public ingress scenario, readiness probes are executed via the Envoy ingress endpoint, not directly against the container’s raw listener. Because Envoy performs transparent port remapping and exposes ephemeral internal ports, the probe framework may attempt to connect to targetPort (5443) before Envoy routing is fully applied, resulting in dial tcp … connect: connection refused. This is the same underlying limitation observed with startup probes and is documented in recent Microsoft Q&A discussions. [learn.microsoft.com]

Use TCP readiness probes instead of HTTP readiness probes Where possible, configure a TCP readiness probe on the ingress port rather than an HTTP probe. TCP probes only validate that the port is accepting connections and avoid HTTP‑level routing and response validation, making them less sensitive to Envoy’s internal port mapping behavior. This is a documented best practice for Container Apps when HTTP probes cause false negatives. [azureossd.github.io]

Keep ingress enabled but minimize probe dependency Since ingress on port 5443 is required, you cannot disable all probes. The safest configuration in this scenario is:

No startup probe

TCP‑based readiness probe

Optional liveness probe with conservative thresholds This prevents KEDA or the platform from aggressively restarting or removing a healthy revision due to probe misinterpretation.

Avoid long‑running synchronous HTTP requests on Consumption plans If any endpoint (including health‑related paths indirectly triggered by initialization logic) takes close to or longer than 4 minutes, it will be terminated by the ingress layer. For long‑running operations, use asynchronous patterns (background processing, queues, jobs) or consider running the app on a Dedicated workload profile or AKS, where ingress timeouts are more flexible. This limitation is intrinsic to the Consumption plan and not probe‑related. [github.com]

When to consider Dedicated or alternative hosting If your application requires:

Long‑running HTTP requests (>4 minutes), or

Strict health probe reliability without Envoy ingress interference

then a Dedicated Container Apps workload profile or AKS is the recommended platform choice, as confirmed in multiple Azure Container Apps discussions and issues

Answer 2

The behavior matches a health probe/port configuration mismatch in Azure Container Apps rather than an issue with Spring Boot itself.

In Azure Container Apps, the platform expects:

The ingress target port to match the port where the application actually listens.
All TCP-based health probes (startup, readiness, liveness) to use that same port.

If the platform detects that the configured targetPort does not match any listening port it sees, it raises a PortsMismatch error and health probes fail, which can cause continuous restarts and scaling issues.

To stabilize the app and stop the loop:

Verify ingress target port
- In the Azure portal:
  1. Open the container app.
  2. Go to Ingress.
  3. Confirm that Target port is set to 5443 (the port where the app is configured to listen).
- If it is not, update it to 5443 and redeploy.
Align health probe ports with target port
- In the Azure portal:
  1. Go to the container app.
  2. Under Application select Containers → Health probes.
  3. Expand Startup probes, Readiness probes, and Liveness probes.
  4. For each probe, set Port to 5443 (must match the ingress target port for TCP-based probes).
  5. If using HTTP probes, ensure the path points to a valid endpoint (for example /actuator/health) and that it returns a status code between 200 and 399.
  6. Save and create a new revision.
For long startup times (for example, Java/Spring Boot):
- Increase initialDelaySeconds for startup and readiness probes to exceed the typical startup time.
- Optionally increase failureThreshold so transient delays do not cause failures.
Use diagnostics to confirm the port/probe configuration
- In the Azure portal:
  1. Open the container app.
  2. Select Diagnose and solve problems.
  3. Under Availability and Performance, open:
    - Health Probe Failures to see which probe type is failing and why.
    - Container Apps Ingress Port settings check to see if the configured targetPort matches what the platform detects.
  4. Select the latest revision in the dropdown and review the report for PortsMismatch and recommended fixes.
Confirm container startup and health behavior
- If the app takes time to start, ensure:
  - A startup probe is configured with a sufficient initialDelaySeconds.
  - Readiness and liveness probes are not firing too early (adjust periodSeconds and failureThreshold).
- If the app does not serve HTTP (not your case, but relevant generally), consider disabling external HTTP ingress or using internal ingress so that default HTTP probes are not enforced.

If, after aligning targetPort and all probe ports to 5443 and adjusting timings, diagnostics still show PortsMismatch, use the Health Probe Failures and Ingress Port settings check detectors as the authoritative view of what the platform sees and adjust configuration to match those detected ports.

References:

Share via

Azure Container Apps: Startup probe fails with PortsMismatch despite app being healthy and serving traffic

2 answers

Your answer