谷歌云优惠券渠道 谷歌云 Artifact Registry 镜像仓库鉴权失败（GCP Docker Login Error）全排查
先说结论：Artifact Registry 登录失败，通常不是 Docker 本身坏了，而是仓库地址、账号权限、Billing、凭证配置这四个环节里有一个没对上。很多人卡了半天，最后发现只是把 gcr.io 和 *.pkg.dev 混用了，或者 GCP 账号虽然能进控制台，但 Billing 没激活，拉镜像时直接 401 / 403。
如果你现在遇到的是 docker login 失败、unauthorized、denied、no basic auth credentials、403 Permission denied 这些报错，建议不要先盲目重装 Docker，先按下面顺序排查，效率会高很多。
一、先判断你卡在“哪一层”
| 报错表现 | 高概率原因 | 优先处理 |
|---|---|---|
unauthorized: Authentication required |
登录凭证无效、token 过期、命令写错 | 重新生成 access token，检查登录域名 |
denied: Permission ... |
账号没仓库权限，IAM 角色不够 | 补 Artifact Registry Reader/Writer |
no basic auth credentials |
Docker 没拿到凭证，credential helper 没配置 | 重新执行 gcloud auth configure-docker |
| 登录成功但 pull / push 失败 | 仓库区域、项目 ID、仓库名写错 | 核对镜像完整路径 |
| 控制台能进，命令行不行 | 浏览器账号和 gcloud 账号不是同一个 | 确认当前 active account |
二、最容易出错的 5 个位置，按这个顺序改
谷歌云优惠券渠道 1）仓库地址写错：这是最高频问题
Artifact Registry 的镜像地址不是随便拼的，常见格式是：
REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE:TAG
如果你还在用 gcr.io、asia.gcr.io、us.gcr.io 这类地址，要先确认你操作的到底是 Container Registry 还是 Artifact Registry。这两个系统不是一回事，很多团队迁移后最先出问题的就是这里。
2）Docker 凭证没配对
典型场景是：你已经 gcloud auth login 成功了，但 Docker 还是报认证失败。原因通常是 Docker 没有把 Artifact Registry 域名纳入凭证助手。
gcloud auth login
gcloud config set project PROJECT_ID
gcloud auth configure-docker REGION-docker.pkg.dev如果你有多个区域的仓库，别只配一个域名。比如你同时用到 asia-northeast1 和 us，就要分别确认对应域名都已经配置进 Docker。
谷歌云优惠券渠道 3）IAM 权限不够：能登录，不代表能拉/推
很多人以为能打开控制台就算有权限，其实不是。Artifact Registry 常见最小权限如下：
- 只拉镜像：
Artifact Registry Reader - 拉取和推送：
Artifact Registry Writer - 管理员级操作：
Artifact Registry Admin
如果你用的是 服务账号，还要确认服务账号本身是否被项目授权，以及是否启用了对应 API。企业环境里常见的坑是：组织策略禁止创建 key，导致本地 docker login 走不通，只能改用短期 token 或受控流水线。
4）Billing 没开通或被停用
这是新账号最容易忽略的一项。GCP 里很多资源看着“创建成功”，但 Billing 没有激活，镜像拉取会直接被限制。尤其是试用账号、刚绑卡的新账号、或者账单异常被暂停的账号，Artifact Registry 经常出现：
- 仓库能看见，拉取失败
- CI/CD 以前正常，突然全部 403
- 过了付款日后，仓库访问断掉
如果你是通过企业账号开通，还要额外确认：Billing account 是否绑定到正确项目。很多团队是账号开了、项目建了，但账单没挂上去，最后排查半天还是 Billing 侧的问题。
5）账号风控或支付验证没过
如果你是新注册 GCP 账号，登录失败有时不是技术问题，而是账号侧风控没放行。常见触发点有：
- 虚拟卡、预付卡、账单地址不一致
- 同一张卡短时间绑定多个云账号
- 频繁切换 IP、地区、浏览器环境
- 企业资料和付款主体不一致
这类问题的特征是：控制台能进，但关键操作被拦；或者 billing account 迟迟处于审核、待验证、被限制状态。对刚开通的账号来说，最好先完成实名认证、付款方式校验、联系人邮箱和电话验证，再做仓库操作。
三、按“命令行 → 权限 → 账单”三步排查，最快
- 确认当前账号：
gcloud auth list，看 active account 是否是你要用的那个。 - 确认项目：
gcloud config get-value project，很多故障就是项目切错了。 - 重新配置 Docker 凭证：
gcloud auth configure-docker REGION-docker.pkg.dev。 - 核对 IAM：当前用户或服务账号是否有 Reader / Writer 权限。
- 核对 Billing：项目是否绑定了有效账单账号，是否有欠费或暂停。
- 核对镜像完整路径：区域、项目 ID、仓库名、镜像名、tag 是否一致。
如果你在 CI/CD 里登录失败，建议再补一条：不要把本地浏览器登录凭证直接复制到流水线。生产环境更稳的做法是用服务账号和受控的短期 token，避免 token 过期导致整条发布链路中断。
四、账号购买、实名、充值和支付方式，实际要注意什么
很多人搜这个问题，表面上是 Docker 登录失败，实际上根因在账号开通阶段。对 GCP 来说，最常见的决策点不是“能不能开”，而是“开了之后能不能稳定用”。
1）自助开通 vs 企业开通
如果是个人开发测试，通常用信用卡/借记卡自助开通就够了。但如果你后面要跑镜像仓库、CI/CD、多人协作，企业开通更省事，前提是付款主体、邮箱域名、管理员权限要一次性配对好。
2）GCP 没有传统“先充值再用”的习惯
不少用户习惯按“充值余额”理解云账单，但 GCP 更常见的是绑定付款方式后自动扣费。也就是说，重点不是你充了多少，而是：
- 付款方式是否可扣款
- 账单地址是否真实一致
- 谷歌云优惠券渠道 是否触发了风控审核
- 是否设置了预算告警
如果你所在地区对国际卡支持不稳定，实际使用中比的不是“价格低一点”，而是卡能不能长期稳定通过验证。一旦卡被拒付，Artifact Registry 相关访问很容易跟着受影响。
3）企业认证别只看提交材料
企业账号常见要求不只是营业执照，还包括：公司名称拼写、账单抬头、联系人邮箱、付款主体一致性。材料一旦前后不一致，审核时间会拉长，严重时会触发二次验证。对要马上上线镜像仓库的团队来说，这个时间成本比月费本身更关键。
五、成本怎么比：别只看仓库免费额度
| 方案 | 适合谁 | 实际成本风险 | 常见问题 |
|---|---|---|---|
| 个人卡自助开通 | 测试、个人项目 | 汇率、拒付、风控概率更高 | 账单验证失败、卡被拦 |
| 企业付款账号 | 团队、生产环境 | 审批流程更长，但稳定性更好 | 权限分配、账单绑定错误 |
| 通过合规渠道代开/代付 | 不方便直接绑卡的团队 | 要看服务方是否支持账单透明、权限可控 | 后期迁移、实名归属确认 |
如果你的仓库只是放少量镜像，真正花钱的地方往往不是仓库本身，而是出网流量、跨区域访问、CI 频繁拉取。很多团队前期只看存储费，后面账单一出来，发现拉镜像的流量才是大头。所以仓库区域最好尽量靠近集群或构建机，别让镜像跨洲拉取。
六、一个真实排查思路：从“能登录”到“能稳定用”
我实际碰到过一个案例：团队在美国区创建了 Artifact Registry，开发机在亚洲，登录一直报错。第一眼看像权限问题，最后发现有三层叠加：
- 镜像地址写成了旧的
gcr.io域名 - 本地 Docker 没执行
configure-docker - 项目 Billing 绑定错了，导致 push 之后失败
这类问题最怕“改一个地方试一次”。正确做法是先把地址、账号、账单三个点一次核对完，再动手测试，不然日志会很乱。
七、FAQ：最常被问到的 5 个问题
Q1：控制台能进，为什么 Docker 还是认证失败？
A：控制台登录和仓库鉴权不是同一套检查。你需要确认当前账号、Docker 凭证助手、仓库域名都一致。
Q2：拉镜像成功，推送失败是什么原因？
A：大概率是权限不够。拉取只要 Reader，推送要 Writer 或更高权限。
Q3：新开账号为什么总要过审核？
A：新卡、新 IP、新企业资料都可能触发风控。先完成付款验证，再做高频镜像操作，成功率更高。
Q4：一定要用信用卡吗？
A：官方常见是卡支付或企业账单方式。能不能稳定通过，比“是不是某种卡”更重要。对企业用户，建议先确认账单主体和地区支持情况。
Q5：仓库访问突然失败，先看什么？
A：先看 Billing 是否停用，再看 IAM 权限有没有被回收，最后看 token 是否过期。
如果你现在正卡在 Artifact Registry 鉴权失败，最省时间的处理顺序就是：先核对仓库域名，再重配 Docker 凭证，然后查 IAM，最后查 Billing 和付款状态。大多数问题不是命令写错一行，而是账号、账单和权限没在同一个项目上对齐。