执行docker pull或docker compose up时看到pull access denied，并不一定是网络故障。仓库名称写错、镜像未公开、当前用户未登录或令牌缺少读取权限，都可能让仓库拒绝请求。
先保存完整报错和镜像引用，不要把镜像名随意改成相似的公开镜像。同名仓库可能属于不同发布者。
先确认镜像引用指向哪里
核对registry/namespace/repository:tag的每一段；省略仓库地址时，Docker会按默认仓库规则解析。再到镜像发布方的仓库页面确认名称、标签与架构。
仓库不存在与无权访问可能呈现相近报错，应先核对发布者提供的准确引用。
检查登录的是哪个仓库
对私有仓库，用docker login 仓库域名登录对应的registry，再以同一用户执行拉取。仅登录Docker Hub，不会自动授予其他私有仓库权限。
凭据应保存在受控凭据存储中；不要把密码直接写入Compose文件、命令历史或工单截图。
验证授权与令牌范围
让仓库管理员核对当前账号是否被授予镜像读取权限，令牌是否过期，组织策略是否限制镜像类型。CI或自动部署要检查运行任务的服务账号，而非只检查管理员个人账号。
本机拉取成功不代表CI节点也有权限。两处可能使用不同的凭据文件和仓库身份。
按部署入口复查
先用目标主机执行精确的docker pull 完整镜像名。Compose环境再检查image:是否引用同一名称，并用docker compose config查看解析后的配置。
若同一镜像在所有环境均失败，应联系镜像提供方确认权限或标签；不要为了绕过错误而改用未经验证的镜像来源。
在独立VPS中验收
迁移部署时，可在萤光云或LightNode的隔离实例上验证仓库登录和镜像拉取，再把凭据接入生产自动化。验收标准是目标主机以实际部署身份成功拉取指定镜像。
FAQ
问：执行docker login成功，为何仍被拒绝？答：登录成功只证明身份可用，还要核对登录仓库、仓库路径、标签及该身份的读取授权。
温馨提示
温馨提示：私有仓库令牌应采用最小权限并定期轮换；不要把镜像拉取失败当作理由将内部镜像改为公开。
