删除Front Door私有链接后无法重新创建的解决方法咨询

问题场景 #

用Bicep创建Front Door源时，会自动向App Service发起私有链接请求，手动在UI批准后一切正常。但如果在App Service UI中删除该私有链接，再次运行Bicep部署时，无法重新创建这个私有链接。

问题原因 #

1. 硬编码状态值的错误：你在Bicep里直接写死了sharedPrivateLinkResource.status = 'Approved'，但这个状态是由App Service（私有链接的服务端）决定的，不是Front Door（客户端）能直接指定的。当你删掉App Service侧的链接后，Front Door这边的共享私有链接资源（SPLR）记录可能还处于“已批准”状态，Bicep会认为资源状态符合预期，不会发起新的请求。
2. 残留的SPLR记录：即使App Service侧删除了链接，Front Door资源里的SPLR条目可能还存在，导致Bicep判定资源已存在，不会重新创建。

解决方案 #

1. 移除硬编码的status字段 #

修改Bicep代码，删掉sharedPrivateLinkResource中的status: 'Approved'配置，让Azure自动处理状态流转。这样部署时，Front Door会重新向App Service发起私有链接请求，你可以再次在UI中批准。

修改后的代码：

resource appService 'Microsoft.Web/sites@2022-09-01' existing = {
  name: applicationName
  scope: resourceGroup(resourceGroup)
}

resource fdOrigin 'Microsoft.Cdn/profiles/originGroups/origins@2021-06-01' = {
  name: 'fd-origin'
  parent: fdOriginGroup
  properties: {
    hostName: '${applicationName}.azurewebsites.net'
    httpPort: 80
    httpsPort: 443
    originHostHeader: '${applicationName}.azurewebsites.net'
    priority: 1
    weight: 1000
    sharedPrivateLinkResource: {
      groupId: 'sites'
      privateLinkLocation: 'EastUS2'
      requestMessage: 'Created by Deployment Pipeline'
      privateLink: {
        id: appService.id
      }
    }
  }
}

2. 清理Front Door侧的残留SPLR记录（按需操作） #

如果修改代码后还是无法发起请求，说明Front Door侧的SPLR记录没清理干净。可以：

• 手动删除Front Door里对应的origin资源，再重新运行Bicep部署；
• 或者在Azure Portal的Front Door资源中，找到对应的「共享私有链接资源」条目，删除后再重新部署。

3. 可选：强制触发资源更新 #

如果需要自动化处理，可以在Bicep中添加强制更新标签，让每次部署都重新创建origin资源，触发新的私有链接请求：

resource fdOrigin 'Microsoft.Cdn/profiles/originGroups/origins@2021-06-01' = {
  name: 'fd-origin'
  parent: fdOriginGroup
  tags: {
    ForceUpdate: utcNow() // 每次部署生成新时间戳，强制更新资源
  }
  properties: {
    // 其余配置保持不变
  }
}

内容的提问来源于stack exchange，提问作者Don Chambers