【Azure 应用服务】WEBSITE_DISABLE_CROSS_STAMP_SCALE 配置的作用说明

问题描述

在排查 Azure App Service 或 Azure Function App 的 Timeout、DNS 解析失败、下游服务连接不稳定问题时，经常会遇到一个配置项：

WEBSITE_DISABLE_CROSS_STAMP_SCALE

这个配置项很容易被理解为“DNS 修复开关”或“网络问题修复开关”。但实际上，它并不是 DNS 配置，也不会直接修改 VNet 路由，更不会直接改变 Function App 的执行超时时间。

那么它的作用到底是什么呢？

简单说：

WEBSITE_DISABLE_CROSS_STAMP_SCALE 用于限制 App Service / Function App 在同一区域内跨 Stamp（Scale Unit）扩展。它的作用点在平台调度层，而不是应用运行时或 DNS 配置层。

也就是说，它更适合作为排查问题时的“隔离变量”，而不是最终修复方案。

问题分析

1）什么是 Stamp？

Azure App Service 底层运行在 Scale Unit 上，也常被称为 Stamp。一个 Azure Region 中可能存在多个 Stamp。每个 Stamp 都包含运行应用所需要的计算、存储、网络和负载均衡能力。

正常情况下，应用实例会运行在某个 Stamp 中。但为了平台容量和调度弹性，在一些场景中，应用实例可能被扩展到同一区域内的其他 Stamp 中。

示意如下：

Stamp A                          Stamp B
App Instance 1                   App Instance 4
App Instance 2   ──扩展后──>     App Instance 5
App Instance 3

这就是 Cross-Stamp Scale。

根据官方 App Service 应用设置说明：

• 默认值为 0
• 设置为 1 或 true 时，可以禁用应用在区域内的跨 Stamp 扩展
• 它控制的是实例是否可以跨 Stamp 放置，而不是应用代码逻辑

所以，WEBSITE_DISABLE_CROSS_STAMP_SCALE 的核心作用是：

限制平台不要把该应用实例扩展到当前 Stamp 之外。

2）为什么它会和 Timeout / DNS 问题联系在一起？

严格来说，它并不是 DNS 配置。但是在网络类问题排查中，它确实可能有帮助。

原因是：跨 Stamp 扩展后，实例所在的平台位置发生了变化。位置变化后，以下差异可能被放大：

所以，当问题表现为：

• 大部分请求正常，少数请求失败
• 部分实例正常，部分实例异常
• 问题出现在扩容、重启、部署或实例更替之后
• 错误表现为 DNS timeout、connect timeout、依赖服务拒绝连接

此时可以临时设置：

WEBSITE_DISABLE_CROSS_STAMP_SCALE = 1

通过限制跨 Stamp 扩展，观察问题是否消失。

如果问题消失，只能说明：跨 Stamp 调度可能触发或放大了网络差异。它并不代表根因已经修复。

真正需要继续确认的仍然是：DNS、VNet、Private Endpoint、防火墙白名单、应用连接池等配置。

配置说明

该配置改变的是：

• 平台实例放置策略
• 是否允许应用跨 Stamp 扩展

它不改变的是：

• Function 代码执行逻辑
• Function timeout / host.json
• DNS Server 设置
• VNet 路由规则
• SNAT 端口数量
• HTTP Client 连接复用
• 下游服务防火墙规则

所以，不能把它作为 DNS 或 Timeout 的直接修复方案。

适用场景

建议只在以下场景中临时启用：

1. 只有部分实例访问依赖失败
   如 SQL、Storage、Key Vault、第三方 API 等下游依赖只有部分请求超时。
   
2. 应用依赖 VNet Integration 或 Private Endpoint
   尤其是私有 DNS Zone、路由、NSG、防火墙规则较复杂时。
   
3. 需要隔离排查变量
   如果启用后问题消失，说明跨 Stamp 调度可能是触发条件之一。
   

不建议把它作为长期默认配置。因为禁用跨 Stamp 扩展会降低平台调度和扩容灵活性。对于高并发或依赖大规模自动扩展的应用，需要先评估容量影响。

Function App 场景下还需要关注什么？

如果 Function App 的 Timeout 和 DNS 有关，不应只看 WEBSITE_DISABLE_CROSS_STAMP_SCALE。

常见相关配置还有：

也就是说，如果问题是 DNS 或网络访问异常，应同时检查内容存储、VNet、DNS、路由、Private Endpoint 和下游防火墙。

配置方法

在 Azure Portal 中进入：

App Service / Function App
  -> Configuration
  -> Application settings
  -> New application setting

添加：

Name : WEBSITE_DISABLE_CROSS_STAMP_SCALE
Value: 1

保存后重启应用。

如果使用 Azure CLI，可以执行：

az functionapp config appsettings set \
  --name <function-app-name> \
  --resource-group <resource-group> \
  --settings WEBSITE_DISABLE_CROSS_STAMP_SCALE=1

Web App 可将命令中的 functionapp 替换为 webapp。

排查建议

建议按以下顺序排查，而不是一开始就启用该配置：

1. 是否所有实例都失败？
   是：优先检查应用配置、DNS、下游服务
   否：可能与实例分布或平台调度有关
2. 检查网络与依赖
   - DNS Server 是否正确
   - Private DNS Zone 是否正确链接
   - VNet Route All 是否符合预期
   - 下游防火墙是否允许必要出站路径
3. 再临时启用 WEBSITE_DISABLE_CROSS_STAMP_SCALE
   - 问题消失：继续排查跨 Stamp 带来的网络差异
   - 问题仍在：基本可以排除跨 Stamp 变量

我的建议是：可以把它理解为一个“止血带”或“排查工具”，不要一开始就把它当成最终解法。

总结

WEBSITE_DISABLE_CROSS_STAMP_SCALE 的定位可以概括为一句话：

它是一个限制 App Service / Function App 跨 Stamp 扩展的平台放置约束，用于减少实例所在平台位置差异；它不是 DNS、VNet、Timeout 或性能问题的直接修复。

如果启用后问题缓解，真正需要追问的是：

为什么跨 Stamp 实例会失败？是出站 IP、DNS、VNet、Private Endpoint，还是下游防火墙配置不完整？

找到这个答案，才是根因修复。

参考资料

• Environment variables and app settings in Azure App Service: https://learn.microsoft.com/azure/app-service/reference-app-settings
• Reliability in Azure App Service: https://learn.microsoft.com/azure/reliability/reliability-app-service
• Azure Functions app settings reference: https://learn.microsoft.com/azure/azure-functions/functions-app-settings
• Azure Functions networking options: https://learn.microsoft.com/azure/azure-functions/functions-networking-options
• Integrate your app with an Azure virtual network: https://learn.microsoft.com/azure/app-service/overview-vnet-integration
• Azure App Service inbound and outbound IPs: https://learn.microsoft.com/azure/app-service/overview-inbound-outbound-ips

当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!