Azure多容器应用拉取redis镜像报unauthorized错误如何排查

从日志可直接定位：你的私有Azure容器注册表（ACR）镜像拉取流程完全正常，失败点出在拉取公共镜像redis:latest环节——Azure App Service错误将配置的私有ACR鉴权凭据携带到Docker Hub的公共镜像拉取请求中，触发Docker Hub返回unauthorized: incorrect username or password错误，最终导致整个多容器组启动失败。前端显示的CORS错误是后端服务未正常启动的连带现象，并非CORS规则配置错误。

• 核查多容器编排配置（docker-compose.yml）中的redis镜像声明：确认redis镜像配置为image: redis:xxx（xxx为固定版本号），不存在私有仓库前缀，也未配置错误的拉取鉴权参数。禁止使用redis:latest标签，latest标签会强制平台每次启动都拉取最新manifest，触发不必要的公网镜像拉取鉴权流程。
• 核查App Service容器设置中的Docker Hub凭据残留：如果此前曾在容器设置页配置过Docker Hub账号密码，且该凭据已过期/失效，Azure拉取所有Docker Hub公共镜像时会默认携带这组失效凭据，直接触发鉴权失败。如果不需要拉取Docker Hub私有镜像，直接清空所有Docker Hub相关的凭据配置项即可。
• 核查全局Docker注册表环境变量的作用范围：确认DOCKER_REGISTRY_SERVER_URL未被配置为全局生效的路由规则——多容器场景下如果该参数被强制设为你的ACR地址，平台拉取所有镜像（包括公共镜像）都会被路由到ACR，自然无法找到redis镜像并触发鉴权错误。如果使用托管身份拉取ACR镜像，建议为ACR单独配置镜像拉取权限，不要使用全局DOCKER_REGISTRY_*环境变量做统一鉴权。
• 核查平台镜像缓存状态：如果此前实例本地已缓存过可用的redis镜像，本次拉取失败后未正常触发本地缓存回退，可在容器设置页临时切换一次镜像源、保存配置后再切回原配置，强制平台刷新容器拉取逻辑，触发本地缓存加载。
• 快速规避方案：将redis镜像同步推送到你自己的ACR实例中，修改compose配置将redis镜像地址改为你的ACR私有地址（如example.azurecr.io/redis:6-alpine），所有镜像统一走ACR鉴权拉取，完全避开Docker Hub公共拉取的鉴权问题。

注意：后端容器正常启动后，前端CORS报错会自动消失，无需单独调整CORS相关配置。

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