Azure Front Door Premium → Application Gateway via Private Link: 504 OriginTimeout after ~4s, zero traffic reaches gateway, everything shows Approved/Succeeded

We are putting Azure Front Door Premium in front of an existing Application Gateway WAF_v2 (which fronts an App Service) and want to use Private Link to the Application Gateway so we can close public ingress on the gateway later. The exact same setup works when Front Door uses the gateway's public IP as a public origin, so listener, certificate and host header are correct. With Private Link enabled nothing reaches the gateway.

SETUP

• Front Door Premium, one origin group, one origin:
  • Origin type: Custom
  • Host name = Origin host header = the listener FQDN (www.example.no)
  • HTTPS 443, certificate subject name validation enabled
  • Private link: enabled, resource = the Application Gateway, sub-resource = the IPv4 public frontend IP configuration name, region = same as the gateway
• Application Gateway WAF_v2, dual-stack (IPv4 + IPv6 public frontends). Listener for www.example.no bound to the IPv4 frontend. Public CA certificate.
• Private Link configuration on the gateway bound to the IPv4 frontend, using a dedicated subnet in the same VNet (not the gateway subnet). privateLinkServiceNetworkPolicies = Disabled, no delegation, no NAT gateway, no route table.
• Private endpoint connection on the gateway: exactly one, status Approved, matching the current origin. AFD origin shows sharedPrivateLinkResource.status = Approved.
• NSG on gateway subnet: Allow VirtualNetwork all ports in/out, Allow GatewayManager 65200-65535, Allow AzureLoadBalancer. No deny rules before these.
• No route table on either subnet. Feature EnableApplicationGatewayNetworkIsolation is NOT registered.
• Gateway provisioningState Succeeded, operationalState Running, backend healthy.

SYMPTOM

• Front Door access log: httpStatusCode 504, errorInfo = OriginTimeout, timeTaken ≈ 4 s (origin response timeout is 30 s, so this is a connect failure, not a slow origin).
• Front Door health probe log: httpStatusCode = 0 for every probe. Origin Health Percentage = 0 %.
• Application Gateway access log and WAF log: zero rows from the Private Link subnet range. The gateway never sees a packet.
• From a VM inside the VNet: curl --resolve www.example.no:443:<gateway-public-ip> https://www.example.no/ → 200 OK, TLS 1.3, full chain. Gateway itself is healthy.

WHAT WE TRIED

1. All four combinations of origin hostname/host header (listener FQDN vs public IP, host header set vs empty). No change – and as expected, IP as hostname cannot work with Private Link since certificate validation is mandatory.
2. Verified Private Link is on the IPv4 frontend (IPv6 Private Link is documented as unsupported).
3. Disabled Private Link on the origin, deleted all private endpoint connections, removed the Private Link configuration and recreated it with az network application-gateway private-link add --name <pl> --frontend-ip <ipv4-frontend> --subnet <pl-subnet-id> then re-enabled Private Link on the origin and approved again. Identical result.
4. Checked Activity Log for the RG and subscription: no Failed operations, no RequestDisallowedByPolicy, and notably NO operations at all on Microsoft.Network/privateLinkServices.
5. Only lock is CanNotDelete on the RG.

KEY OBSERVATION (see separate question, linked below)

The Private Link configuration reports Succeeded but its ipConfiguration has privateIpAddress = null and primary = null, the Private Link subnet has zero ipConfigurations allocated, and no e41f87a2<gateway>_<plname> privateLinkServices resource exists in the resource group. We suspect the NAT IP is never provisioned, but we are not sure whether this is expected customer-visible behaviour or the actual root cause.

QUESTIONS

1. Is there any additional requirement for Front Door Premium → Application Gateway Private Link beyond what is in https://learn.microsoft.com/azure/frontdoor/how-to-enable-private-link-application-gateway that could produce "Approved everywhere, zero traffic"?
2. Does a dual-stack (IPv4+IPv6) Application Gateway have any known limitation with Private Link on the IPv4 frontend?
3. Is there any customer-visible way to see the Private Link data path (NAT IP allocation, PLS state) for an Application Gateway, or to trace whether the AFD managed private endpoint's SYNs are being dropped?
4. Has anyone seen this pattern resolved by something other than a support ticket (e.g. recreating the gateway, a specific API version, a specific ordering of operations)?

We do not currently have a technical support plan on this subscription, hence asking here first. Thanks.