(403) Traffic is not from an approved private endpoint.

Hi @Dimitrios Bardis

Thank you for reaching out to Microsoft Q&A.

In Azure Functions Flex Consumption (Linux), the portal experience is different from Premium or Dedicated plans. Kudu / Advanced Tools and the in‑portal Console are not available for Flex Consumption apps. This is by design, not a misconfiguration.

That 403 from Document Intelligence (“Traffic is not from an approved private endpoint”) almost always means your Function App is still talking to the public endpoint instead of your private endpoint. Even though you’ve got a privatelink DNS zone linked and a PE in the VNet, a couple of gotchas tend to sneak in when you’re using a custom subdomain:

DNS for your custom subdomain isn’t resolving to the PE’s private IP

Your Function isn’t routing ALL outbound (including DNS) traffic into the VNet

Here’s what you can try:

Verify DNS resolution

• Spin up a quick VM (or enable SSH on your Flex container – see below) in the same VNet/subnet and run:

nslookup <your-custom-endpoint>.cognitiveservices.azure.com

• You should see the private IP of your PE. If you still get a public IP, DNS isn’t mapping correctly.

Fix your Private DNS zone for the custom domain

Because you enabled a custom subdomain, Azure doesn’t automatically populate that in the standard

privatelink.cognitiveservices.azure.com zone. You need to:

Create (or extend) a Private DNS zone that matches your custom slice – for example:

• If your endpoint is contoso-ai.document-intel.azure.com, you might need a

privatelink.document-intel.azure.com zone

In that zone, add either:

• A CNAME from contoso-ai.document-intel.azure.com → contoso-ai.privatelink.cognitiveservices.azure.com

• Or an A record pointing directly at your PE’s private IP

Link the DNS zone to your VNet.

Force all outbound + DNS traffic into the VNet

In a Flex Consumption plan you need to ensure your app actually sends DNS queries into the VNet:

App Setting WEBSITE_VNET_ROUTE_ALL = 1

If you have a custom DNS server configured on the VNet, also set

WEBSITE_DNS_SERVER = 168.63.129.16

WEBSITE_DNS_SERVER = 168.63.129.16 (Azure’s DNS) so your app picks up the private DNS zones

Enable an SSH console in your Function to validate

On Linux Flex you don’t get Kudu/Console – instead:

Add App Setting

WEBSITE_SSH_ENABLED = true

In the Azure portal, go to your Function > Development Tools > SSH and you’ll land in a shell where you can run nslookup or curl

Once your custom-domain name actually resolves to the private IP and all traffic is VNet-routed, the SDK call will flow over the PE and that 403 will disappear.

The 403 error indicates that calls are still reaching the public endpoint instead of the private endpoint, even though the private endpoint is approved. This is a DNS/routing issue between the Function App and the Document Intelligence private endpoint.

To troubleshoot and fix:

1. Verify DNS resolution from the Function App
   • Open the Function App in Azure portal.
   • Go to Tools → Kudu or Tools → Console.
   • In the console, use nameresolver.exe to see where the custom subdomain resolves:

          nameresolver.exe <your-custom-subdomain>.cognitiveservices.azure.com
     

   • If DNS resolves to a public IP instead of the private endpoint IP, the private DNS configuration is not being used by the Function App.
2. Ensure DNS is configured to resolve to the private endpoint
   • For services using Private Endpoint, DNS lookups must resolve to the private IP of the endpoint.
   • Make sure one of the following is true for the Function App’s VNet:
     1. The VNet uses Azure DNS and is linked to the private DNS zone privatelink.cognitiveservices.azure.com.
     2. If using a custom DNS server, that DNS server forwards queries for privatelink.cognitiveservices.azure.com to Azure DNS (168.63.129.16) or hosts the appropriate A records.
   • If DNS still resolves to a public IP, verify:
     • The private DNS zone exists.
     • The zone is linked to the same VNet used by the Function App integration.
     • The private endpoint has a DNS zone group configured so A records are created automatically.
3. Confirm the Function App is correctly VNet-integrated
   • The Function App must be integrated with the VNet/subnet that has access to the private endpoint and its DNS zone.
   • For Flex Consumption / Dedicated / Premium plans, VNet integration is supported; ensure the integration is active and not misconfigured.
4. Test TCP connectivity to the private endpoint
   • From the same console, use tcpping to verify network access:

          tcpping.exe <your-custom-subdomain>.cognitiveservices.azure.com 443
     

   • Successful tcpping plus correct DNS (private IP) confirms that traffic is going over the private endpoint.
5. If DNS resolves correctly but 403 persists
   • Re-check that public network access is disabled on the Document Intelligence resource and that the private endpoint is in Approved state.
   • If both Function App and Document Intelligence Studio show timeouts or 403s even with correct DNS and private endpoint, check Azure Status/Service Health and consider testing a Document Intelligence resource in another region to rule out a regional service issue.

These steps let the Function runtime “nslookup” equivalent via nameresolver.exe and confirm that the Function App is actually using the private endpoint rather than the public endpoint.

References:

• Azure Functions networking options (consumption-plan)
• Azure Functions networking options (dedicated-plan)
• Azure Functions networking options (premium-plan)
• Azure Functions networking options (container-apps)
• Microsoft Discovery FAQ