App Service Returns 502 Through Private Endpoint
Northwind hosts a Linux App Service plan (P1v3, three instances) with a private endpoint in subnet 10.30.2.0/24 and public access disabled. The app calls an Azure SQL database through its own private endpoint in the same VNet. Clients in the VNet reach the app over the private endpoint and get intermittent 502 Bad Gateway responses during peak load. The app also calls an external HTTPS API at api.partner.com, which now times out. Access restrictions list only the private endpoint subnet. The VNet has no custom DNS servers; the private DNS zone privatelink.azurewebsites.net is linked to the VNet. Health check shows instances healthy.
1. Explain the two distinct failures and their likely causes.
Read the worked answer
Two separate symptoms, two separate causes.
Intermittent 502s. A 502 means the front end could not get a valid response from the worker. With three healthy instances and peak-load correlation, likely causes are: (a) the app is exhausting worker resources or hitting a per-instance connection limit, causing slow responses that exceed the front-end timeout; (b) SNAT port exhaustion on outbound connections from the App Service instances to SQL, which manifests as intermittent failures under load. Check SNAT port allocation and connection pooling. A 502 is not an authorization error; do not chase access restrictions first.
External API timeout. With public access disabled and access restrictions limited to the private endpoint subnet, outbound calls to api.partner.com still leave via the App Service outbound addresses, but inbound restrictions do not block outbound. The more likely cause is that the app's outbound traffic is being routed through VNet integration that lacks a NAT gateway or route to the internet, or the partner API is blocking the App Service outbound IPs. Confirm whether VNet integration is enabled and whether a route table sends 0.0.0.0/0 to a firewall without an outbound rule permitting the destination.
2. What would you check to confirm SNAT exhaustion versus an application timeout?
Read the worked answer
SNAT exhaustion: review outbound connection counts per instance, look for many short-lived connections to SQL without pooling, and check the App Service diagnostics for SNAT port allocation warnings. Symptom pattern is failure under concurrency that recovers when load drops.
Application timeout: correlate 502 timestamps with slow dependency calls in Application Insights; if SQL query duration spikes before the 502, the app is slow rather than the network. Also compare whether failures occur on all instances or one - SNAT is per-instance, so a single hot instance points to that instance's port pool. Remediation differs: pooling and a NAT gateway for SNAT; query tuning and timeout configuration for the app.