Seeing 403s being reported for GET /admin/vfs/site/wwwroot in Azure Function App

Question

Seeing 403s being reported for GET /admin/vfs/site/wwwroot in Azure Function App

yj133 40

Just trying to figure out if I've misconfigured something and maybe affecting something with the platform.

I have a .NET Azure Function App running under a Flex Consumption Plan. Under networking, I've

Enabled from select virtual networks and IP addresses
Main site
- Unmatched rule action - Deny
- Added 15 IPv4 block rules - Allow

The Function App has been setup to use OpenTelemetry with distributed tracing. The 403s for GET /admin/vfs/site/wwwroot are being reported under the requests table in Application Insights a few times across 24 hours.

Under the Function App > Diagnose and solve problems > Networking > Access Restrictions, it lists the same IP address with some error messages including:

No matching rule found. Denied by 'Deny' default action
Unauthorized clientip ()Cold start request for <function app name> site, <function app domain> hostname, 'success:200:OK' serverList, '7/27/2026 5:22:38 AM' cache expiry

These don't get reported at all in Application Insights if allow the Function App to be accessible from all networks.

Any insight or confirmation as to whether I should ignore or not would be appreciated.

Thanks!

Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-07-29T05:52:37.3+00:00

@yj133 , following up to see if the above provided information is helpful. Please let me know if you have any further queries.
Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-08-02T19:10:01.16+00:00

@yj133 ,If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.
Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-08-04T22:29:59.7733333+00:00

@yj133 , following up to see if the above provided information is helpful. Please let me know if you have any further queries.

Answer accepted by question author

Christos Panagiotidis 3,546

Your access restriction is producing the 403; OpenTelemetry only makes it visible. With the unmatched action set to Deny, Azure Functions rejects requests whose source matches none of the 15 allow rules. /admin/vfs/site/wwwroot is an administrative path, not a function route, and the diagnostic entry identifies it as cold-start-related traffic.

Correlate the timestamps in Application Insights with AppServiceIPSecAuditLogs, checking CIp, Result, CsHost, and Details. Confirm that normal triggers, cold starts, and deployments succeed and that Function logs show no startup failures. Keep the deny-by-default policy; do not add a broad Azure service-tag allowance merely to suppress telemetry. Ensure legitimate clients and deployment agents have explicit IP or virtual-network rules, and review SCM-site restrictions separately.

If invocations succeed, these isolated denials can be treated as blocked administrative probes. If they coincide with missed triggers or failed cold starts, collect the timestamps and diagnostic output and open an Azure Support case.

0 comments

2 additional answers

Your answer

Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-07-29T05:52:37.3+00:00

@yj133 , following up to see if the above provided information is helpful. Please let me know if you have any further queries.
Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-08-02T19:10:01.16+00:00

@yj133 ,If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.
Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-08-04T22:29:59.7733333+00:00

@yj133 , following up to see if the above provided information is helpful. Please let me know if you have any further queries.

Answer 1

Hi @yj133 ,

Those 403s are almost certainly coming from your Function App’s own Networking → Access Restrictions, not from OpenTelemetry or anything platform-side. The key clue is that the Access Restrictions diagnostics show messages like:

“No matching rule found. Denied by 'Deny' default action” - Requests attempting to reach /admin/vfs/site/wwwroot (a path typically associated with the Kudu/admin-side filesystem access)

The fact that you don’t see the 403s in Application Insights when you allow the Function App from all networks strongly supports that the blocked traffic is coming from an address/range that is not matching your allow rules, so it falls through to the default Deny.
What /admin/vfs/site/wwwroot likely represents

Even when you aren’t explicitly calling it, various platform components, management/diagnostic tooling, or other automated clients can attempt to access admin/Kudu-style endpoints. If those calls come from an IP that isn’t allowed, Access Restrictions will return 403.

If:

the 403s only appear occasionally (e.g., a few times across 24 hours),
they disappear when networking restrictions are opened,
and your actual function endpoints/HTTP triggers are working,

then it’s expected noise from blocked background/management traffic.

However, it’s still worth validating that the blocked traffic is not coming from something you actually rely on (e.g., APIM, health checks, monitoring agents, internal integrations).

Check whether your “real” traffic is succeeding
- Compare Application Insights for successful requests to your function endpoints vs. the /admin/vfs/site/wwwroot 403s.
Review which IPs are attempting access
- In the Function App Networking → Access Restrictions diagnostics, look closely at the specific client IP(s) being denied.
Consider allowing the specific source if it’s legitimate
- If you identify that the denied IP belongs to something you need (monitoring, a specific integration, etc.), add an appropriate allow rule.
If it’s only internal/unauthorized attempts, you can likely leave it as-is
- With the default action set to Deny, occasional 403s for admin paths are commonly consistent with “someone/thing tried, but you intentionally blocked it.”

The “these don’t get reported at all when accessible from all networks” behavior suggests the requests are still happening, but they are either:

never reaching the app when blocked (so only show up in restricted diagnostics), or
only being logged when restrictions are evaluated.

Either way, the Access Restrictions messages you pasted already confirm the denial reason.

Hope this helps!

If the resolution was helpful, kindly take a moment to click on User's image and click on Yes for was this answer helpful. And, if you have any further query do let us know.

yj133 40 Reputation points

2026-08-03T10:54:16.5033333+00:00

Thanks for the suggestions so far.

The Function App doesn't seem to have any startup issues and all functions have worked so far. I turned on Diagnostic Settings on the Function App as Christos Panagiotidis had suggested to see if I could see anything extra. It did show the client IP address, which doesn't map to the Function App itself. The IP addresses sometimes map to the AzureCloud service tag and sometimes it doesn't.
Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-08-04T01:08:00.38+00:00

Hi @yj133 ,Since your Function App is starting normally and all functions are working, this doesn't indicate a runtime issue. The diagnostics confirm that the 403s are being generated by your configured Access Restrictions (Deny default action). The client IPs may not consistently map to the AzureCloud service tag, so the IP alone isn't enough to identify the source. In the absence of any functional impact, these intermittent 403s can generally be considered expected behavior.

Please verify if the denied client IP belongs to any expected caller (such as APIM, Front Door, deployment agents, or monitoring services) and correlate the 403 timestamps with app restarts, deployments, or scale events. If the 403s remain limited to /admin/vfs/site/wwwroot and there is no functional impact to your application, they can generally be considered expected behavior due to the configured Access Restrictions.

Answer 2

kagiyama yutaka 4,915

I think the 403s come from the SCM side, and Azure Access Restrictions give 403 when no allow rule matches, so adding your IP or network under SCM → Access restrictions lines up with the behavior and keeps the app running fine.　

0 comments