Azure Front Door遇Azure Function停止403错误时未自动故障转移

问题现象 #

• 双区域部署Azure Function作为Front Door后端，正常运行时50%负载均衡策略生效符合预期
• 手动停止主区域Function后，流量未全部切换至次区域，客户端持续收到The web app is stopped的403错误响应，自动故障转移未触发
• 相同配置下替换为Web App作为后端时，停止单区域实例可正常触发全量切流，故障转移逻辑生效
• 当前配置参考截图：
  

根本原因 #

核心差异来自Azure App Service/Function平台停止实例时返回的状态码，和Front Door默认健康判定规则的匹配逻辑：

1. Azure Front Door 后端健康探测默认判定逻辑：仅当后端返回指定范围的错误状态码（默认包含400、408、411、413、414、415、417、500、502、503、504等）时，才会将后端标记为不健康，从负载均衡池中摘除触发故障转移；其余状态码（包括403）默认被判定为后端正常返回的合法响应，不会触发故障摘除。
2. 手动停止Web App实例时，App Service平台前端层直接返回503 Service Unavailable响应，该状态码在默认不健康状态码范围内，因此可以正常触发故障转移。
3. 手动停止Azure Function实例时，平台返回的是403 Forbidden响应（即用户看到的停止提示页），该状态码不在Front Door默认的不健康状态码列表中，因此Front Door会持续认为该后端健康，继续向其转发流量，导致客户端收到403错误。

修复配置步骤 #

按照以下顺序调整Front Door后端池配置即可修复问题：

1. 补充不健康状态码范围
   进入Front Door对应后端池的健康探测配置页，在「判定为不健康的状态码」配置项中，新增403状态码。如果业务上没有自定义403响应的需求，也可以直接将所有4xx、5xx状态码全部纳入不健康判定范围，避免其他平台级错误导致的漏判。
2. 替换为专用健康探测路径
   不要使用默认的/作为健康探测路径，为两个区域的Function分别新增一个无业务逻辑的HTTP触发健康检查端点（例如路径为/api/health），端点逻辑仅需在Function正常运行时返回200状态码即可。将Front Door健康探测的路径修改为该专用端点，避免根路径无路由、权限校验等问题导致的健康状态误判。
3. 调整健康探测阈值
   可根据业务对故障切换时长的要求，将连续探测失败次数阈值设置为2-3次，探测间隔设置为10-30秒，平衡故障切换速度和网络波动导致的误切概率。默认配置下配置完成后，故障发生后30-90秒即可完成全量切流。
4. 生效验证
   配置修改后等待5-10分钟待Front Door全球节点配置同步完成，手动停止主区域Function，连续访问Front Door入口地址，确认不再返回403停止页面、所有流量均路由至次区域Function；重新启动主区域Function，待健康探测连续通过阈值后，流量会自动恢复为双区域50%负载均衡的状态。

内容的提问来源于stack exchange，提问作者vishnu prajapati