如何实现Azure Blob与App Service共用同一www域名

方案1：Azure CDN 路径分流（零SEO影响，首选方案） #

核心逻辑：不需要为www.xxx.com配置多条CNAME，仅需将该域名的唯一CNAME记录指向Azure CDN端点，通过CDN规则引擎按请求路径分流到不同后端，完全保留原有图片URL路径，对搜索引擎、用户端完全透明，无任何感知。
操作步骤：

• 调整DNS配置：删除原有www.xxx.com指向App Service的CNAME记录，将该域名唯一CNAME解析到已创建的Azure CDN端点（之前配置images子域名使用的CDN实例可直接复用，无需新建）
• CDN多源配置：在CDN后台添加两个源站
  • 默认源：类型选择App Service，填入博客使用的App Service默认域名，处理所有动态页面、非静态资源请求
  • 静态资源源：类型选择Blob存储，填入存放图片的存储账户Blob服务端点，专门处理图片请求
• 配置CDN路由规则：使用CDN标准规则集（无需额外购买高级版）新增匹配规则
  • 匹配条件：请求路径前缀匹配原有图片存放路径，比如原WordPress图片路径为/wp-content/uploads/*，重构后如果是/images/*则替换为对应路径前缀
  • 执行动作：匹配到的图片请求全部转发到Blob存储源站，其余未匹配的请求默认转发到App Service源站
• 配套缓存配置：图片路径请求设置7-30天的CDN边缘缓存，动态页面请求设置为不缓存、直接透传至App Service，不影响站点登录、评论等动态功能
  方案优势：原有图片URL完全不需要修改，不存在链接变更导致的SEO降权风险，同时整站都能获得CDN加速能力，静态图片直接从边缘节点返回，性能比原wwwroot本地存储方案更高。

方案2：App Service反向代理转发（无DNS调整成本） #

如果不想改动现有www域名的解析指向，可通过反向代理方式保持原有图片URL不变：

• 保留现有www.xxx.com指向App Service的CNAME记录不动
• 配置转发规则：可以通过两种方式实现
  • 在ASP.NET Core请求管道中添加反向代理中间件，匹配图片路径前缀的请求时，自动从Blob存储拉取对应资源返回给客户端
  • 直接使用App Service自带的URL重写模块配置规则，匹配图片路径的请求重写到Blob存储对应资源地址
• 注意：该方案下所有图片请求会先经过App Service再转发到Blob存储，会额外占用App Service的计算、带宽资源，图片访问量较高时会增加站点负载，适合中小流量博客使用。
  方案优势：完全不需要调整DNS、CDN配置，原有URL100%保留，无SEO风险。

方案3：301重定向+搜索平台适配（备选，不推荐） #

如果前两个方案都无法落地，可将原有www域名下的图片路径配置301永久重定向到images.xxx.com子域名的对应地址，同时在各大搜索引擎站长平台提交域名改版规则，传递旧URL权重。但该方案存在1-3个月的搜索权重波动期，不符合零SEO风险的要求，仅作为最后备选。

注意：DNS协议本身不支持同一主机名配置多条生效的CNAME记录，即便部分DNS服务商允许提交多条同主机名CNAME记录，实际解析时也会出现随机指向源站、SSL证书匹配失败、CDN缓存规则错乱等问题，完全不具备生产可用性，不要尝试该思路。

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