Azure Front Door 的 deploymentStatus 长期 NotStarted 并返回 CONFIG_NOCACHE 时，核对路由、日志、传播和源站，避免盲目重建。
直接答案：Azure Front Door 的 provisioningState=Succeeded 只说明资源管理层已经接受并保存配置，不能单独证明路由已传播到边缘节点。若端点或路由长期显示 deploymentStatus=NotStarted，同时请求返回 404/504 和 x-cache: CONFIG_NOCACHE，应先保存 ARM 状态、失败请求的 UTC 时间与 x-azure-ref，再区分“门户显示异常”和“配置确实没有生效”。
先不要删除端点、反复重建路由或清空缓存。只读检查不会收费或中断服务；重建端点、切换 DNS、启用日志存储或长期并行保留旧资源可能产生费用或停机风险。
先看请求结果，不要只盯着 NotStarted
| 现场 | 优先判断 | 下一步 |
|---|---|---|
NotStarted，但默认域名和自定义域名都正常返回 | 可能是状态显示没有更新 | 保存状态，避免为“变绿”重建生产资源 |
NotStarted，返回 CONFIG_NOCACHE，源站直连 200 | 路由未匹配或配置未传播 | 核对路由关联、活动日志和传播时间 |
| Front Door 504，源站直连也超时 | 源站、网络或健康探测故障 | 先修源站可达性，不把 NotStarted 当根因 |
| Front Door 502，源站 HTTPS 可达但证书名不匹配 | 源站 TLS/SNI 配置问题 | 核对源站主机头和证书名称 |
用 CLI 保存端点、路由和源站组状态
以下命令只读取配置。先在 Azure Cloud Shell 执行，把尖括号变量替换为实际名称；输出中的订阅 ID、资源 ID和域名在公开工单或截图中需要遮挡。
az afd endpoint show \
--resource-group <资源组> \
--profile-name <Front-Door-配置文件> \
--endpoint-name <端点名> \
--query "{enabled:enabledState,provisioning:provisioningState,deployment:deploymentStatus,host:hostName}" -o json
az afd route show \
--resource-group <资源组> \
--profile-name <Front-Door-配置文件> \
--endpoint-name <端点名> \
--route-name <路由名> \
--query "{enabled:enabledState,provisioning:provisioningState,deployment:deploymentStatus,patterns:patternsToMatch,protocols:supportedProtocols,linkDefault:linkToDefaultDomain,originGroup:originGroup.id}" -o json端点和路由应为启用，路由要关联正确的源站组，并覆盖测试路径。若测试的是默认 azurefd.net 域名，linkToDefaultDomain 还要符合实际设计。CLI 显示关联缺失时先修配置；配置完整且持续不传播时再升级平台支持。
逐项核对路由是否真的能匹配请求
deploymentStatus 异常和路由配置错误可以同时存在。不要看到 NotStarted 就跳过配置核对。至少确认四项：请求协议包含 HTTP 或 HTTPS，patternsToMatch 覆盖实际路径，路由关联了正在测试的自定义域名，源站组资源 ID 指向预期环境。
例如，生产请求是 https://www.example.com/api/orders，路由只有 /static/*，即使部署状态最终成功也不会命中。默认域名能访问、自定义域名不能访问时，重点检查自定义域名是否已经关联到该路由，而不是先改源站。自定义域名尚在 Pending、证书未部署或 CNAME 未指向 Front Door 时，应转入域名验证与证书分支。
如果配置刚被自动化工具更新，先打开活动日志，确认最后一次写入来自哪个身份和哪个部署。连续执行 Terraform、Bicep、门户保存和脚本更新，会让后一项覆盖前一项，也会延长传播时间。排障期间应暂停无关的持续部署，但不要关闭正在承载流量的生产路由。
同时测试 Front Door 和源站
从同一台电脑分别访问 Front Door 默认域名、生产自定义域名和源站健康检查路径。下面命令不会写入资源：
curl -sS -D - -o /dev/null https://<端点>.azurefd.net/<健康路径>
curl -sS -D - -o /dev/null https://<自定义域名>/<健康路径>
curl -sS -D - -o /dev/null https://<源站域名>/<健康路径>保存状态码、UTC 时间、x-cache 和 x-azure-ref。源站直连 200 只能说明当前客户端能访问源站，不能证明 Front Door 的健康探测、主机头、TLS 证书名和网络路径都正确。若源站没有收到请求，而 Front Door 返回 CONFIG_NOCACHE，调查重点应放在路由匹配、配置传播和平台控制面。
检查活动日志和诊断日志
在 Azure 门户打开“Front Door 配置文件 → 活动日志”，按失败和警告筛选创建、更新、删除操作。活动日志默认记录资源管理操作；访问日志、健康探测日志和 WAF 日志默认不自动启用。
若生产故障需要继续取证，打开“监视 → 诊断设置”，把 Front Door Access Log 和 Health Probe Log 发送到 Log Analytics。日志存储与查询可能收费，先确认工作区和保留期。新建诊断设置只影响后续日志，不能补回启用前的请求。
取得失败请求的 x-azure-ref 后，用它关联访问日志。若完全没有相应访问记录，先确认诊断设置生效时间；若有边缘请求但没有源站请求，再查看路由选择、健康探测和源站 TLS。
不要用 purge、重启源站或改 DNS 代替传播诊断
Front Door 缓存清除只删除边缘缓存的对象，不会修复未关联的路由，也不会强制发布控制面配置。源站直连已经稳定返回 200 时，重启源站通常只会制造新的中断和日志噪声。只有健康探测或源站请求明确失败，才根据对应日志处理源站。
DNS 切换也不应作为第一次尝试。若自定义域名已经指向当前 Front Door，频繁改 CNAME 会叠加 DNS TTL，导致不同网络命中不同入口。必须临时绕开故障时，先确认备用入口已通过 HTTPS、主机头、登录、静态资源和写入操作的验收，再按预先记录的 TTL 切换，并保留旧值用于回退。
等待多久，什么时候提交支持请求
Microsoft 的 Front Door FAQ 说明，连续配置变更可能把总部署时间延长到约 30 分钟；缓存清除通常在 10 分钟内传播。缓存清除不会发布一条尚未传播的路由，因此不要用反复 purge 代替诊断。
超过正常传播窗口后，若端点和路由配置完整、源站直连正常、实际请求仍失败，并且问题在一次受控重试后保持不变，应停止删除重建。进入“帮助 + 支持 → 创建支持请求”，提交资源 ID、首次与最近失败的 UTC 时间、CLI 状态、失败状态码、x-cache、x-azure-ref、活动日志关联 ID，以及是否影响默认域名和自定义域名。不要提交密钥、访问令牌、连接字符串或未脱敏日志。
若门户没有显示“创建支持请求”，先确认当前身份在订阅范围拥有创建支持请求所需权限，并完成门户给出的诊断步骤。技术支持需要后台边缘遥测时，本地继续删除、重建只会改变资源 ID 和时间线，让原有证据失效。
修改、验收与回退
修改路由、源站组、主机头、TLS 或 DNS 前，先导出当前配置并保留仍可用的旧入口。生产域名切换可能造成停机；并行保留旧 Front Door 或源站可能继续计费。
- 端点和路由的资源配置读取正常，目标路由覆盖实际主机名与路径。
- 默认域名和自定义域名均返回预期状态码，不再出现
CONFIG_NOCACHE。 - 源站日志能看到 Front Door 请求，健康探测恢复。
- 从至少两个网络重复请求并记录 UTC 时间，排除单一本地缓存。
- 观察期内无持续 4xx/5xx 增长，再移除临时路由或旧入口。
若新配置扩大故障，恢复导出的路由与源站设置，并把 DNS 切回已验证入口。不要在尚未确认新入口正常时删除旧端点。
联系 Telegram 客服 