它是什么

先说清楚：它不是控制台里能开通、商店里能下载的某一款单独产品，而是围绕「GCP 教學常見問題與排錯技巧」整理出来的一套入门排错框架。说人话，就是一张「卡住了照着走」的检查清单，专门给刚上手、看见红字就慌的小白用的。

它管的范围很接地气：GCP 控制台点不动、Compute Engine 连不上 SSH、IAM 弹没权限、VPC 防火墙不通、Cloud Logging 翻不到记录……这几个恰恰是教学环境里最常碰、也最容易被误判成「平台坏了」的模块。

核心思路只有一句：别一上来就乱改配置，按固定顺序走一遍，先确认范围，再查权限、网络、资源状态、日志和配额，最后验证修复结果。

1. 先确认范围：先回答「哪台机器、哪个项目、哪个区出事了」。别全局乱翻，复制下面两行，先看清自己站在哪儿：

   gcloud auth list
   gcloud config get-value project

   为什么这么做：GCP 是按项目隔离的。小白最常踩的坑就是同时开了练习项目和正式项目，在 A 项目里反复改防火墙，出问题的 VM 却躺在 B 项目，改到怀疑人生也没反应；控制台刷不出来也常常只是顶部项目选错了，并不是欠费。先看账号对不对、项目对不对，再往下走最省时间。

2. 查权限（IAM）：看到 Permission denied 先别重装系统，九成是账号少绑了一个角色。
3. 查网络（VPC）：连不上就核对外部 IP 和防火墙规则，比重启更管用。
4. 查资源状态：确认 VM 不是还停在 STOPPED，或者正卡在开机中。
5. 查日志（Cloud Logging）：前面都正常，就让日志把最后一次真实报错念给你听。
6. 查配额：新建资源直接失败，多半是免费额度或该区配额用满了，不是命令写错。
7. 最后验证修复结果：改完一定重新连一次 SSH、刷新一次页面再收工。别改完就关浏览器，不然下回照样不知道是哪一步起效的。

把它想成「看病先量体温、再开药」就够了：不玄乎，不用背概念，照着顺序点一遍，零基础也能把教学里八成的小故障自己捞出来。

解决什么问题

很多人第一次用 GCP，看到红色报错就重装 VM、把防火墙改成全放行，或者反复搜索却不知道原因。这节把「GCP 教学常见问题与排错技巧」变成一张简单地图：先拿证据，再判断是哪一层出错，最后才动手修，避免越修越乱。

故障通常分几类：账号权限、项目配置没选对，常表现为「Permission denied」或找不到资源；区域选择错了，会以为 VM 消失；配额限制、计费预算用满，创建机器会失败，但镜像和服务可能没坏；Linux 系统问题多是磁盘满、服务没启动、端口没监听。混在一起判断，最容易把网络不通误当成防火墙问题，直接全开 0.0.0.0/0，既危险又常常没用。

先打开 GCP 控制台右上角的 Cloud Shell。不知道当前账号或项目时，执行下面这一条并按提示选择；它只改 Cloud Shell 本地配置，不会删除云资源：

gcloud init

接着复制这组只读命令。先只读，是因为它不会改防火墙、不会重启机器，却能回答「我是谁、在哪个项目、API 开没开、机器和规则在哪里、云日志报了什么」：

gcloud auth list
gcloud config list
gcloud projects list
gcloud services list --enabled
gcloud compute instances list
gcloud compute firewall-rules list
gcloud logging read "severity>=ERROR" --limit=20 --freshness=1d --format="table(timestamp,severity,resource.type,logName,textPayload)"

如果提示没有项目、没有权限或 API 未启用，先处理账号权限和项目配置，别急着登录 VM，也不要一路回车。小白常踩的坑是：看到「Permission denied」就去改防火墙；其实它更像 IAM 权限、服务未启用或选错项目。也别只盯一个区域，实例可能建在别处。

1. 先确认账号、项目、区域、实例状态和资源是否存在。
2. 再看防火墙规则、云日志、配额、预算与账单状态；创建失败优先查配额和预算，不要先怀疑镜像。
3. 云侧都正常，最后才进入 VM 查磁盘、内存、服务和端口。

个人站点、测试环境和小型生产服务都按这个顺序走，能把「到处试」变成「逐层排除」，更快定位方向，缩短恢复时间，也减少误删数据、误开端口的风险。

只有已经通过 SSH 进入目标 VM 后，才在 VM 窗口执行下面这组命令，分别看磁盘、内存、失败服务、监听端口和错误日志：

df -h
free -m
systemctl --failed --no-pager
sudo ss -tulnp
sudo journalctl -p err -n 30 --no-pager

最容易错的是把这组命令贴在 Cloud Shell 里：那看到的是临时机器，不是你的网站服务器。重装 VM 会丢数据和配置，应该是最后选项，不是第一反应。

怎么上手

刚出问题时别急着改配置。先去网页控制台点一遍：确认右上角选的是目标项目、区域对不对、虚拟机是不是「运行中」，以及自己有没有对应 IAM 角色。看懂后，再打开 Cloud Shell 用 gcloud 复现同一结果。为什么要两步？控制台最直观，命令却能验证「当前终端登录的账号」是否真有权限读到你看到的东西。小白最常踩的坑是：浏览器登着 A 账号，终端却挂着 B 账号，看着有机器，一跑就报 Permission denied。

# 先确认项目和账号，再列机器、已启用 API 与最近日志
gcloud config list
gcloud compute instances list
gcloud services list --enabled
gcloud logging read "resource.type=gce_instance" --limit=20 --format="table(timestamp, textPayload)"

接着按五步固定顺序查，别跳步也别凭感觉猜：

1. 服务与 API 是否启用：上面若没看到 compute.googleapis.com，后面全白搭。坑：新项目默认关着不少 API，创建时弹的启用提示容易被顺手点掉。
2. 防火墙与路由是否放行：核对规则绑的「目标标签」和来源 IP。坑：只放了 22 能 SSH，忘了放 80/443，网页就打不开；或改了规则却没给机器打标签，规则压根没生效。
3. SSH 密钥与用户是否正确：坑：以为默认都是 root，其实镜像不同可能是 ubuntu 或 gcp-user，用户名输错会一直提示密钥被拒。
4. 日志是否报错：先看云平台日志，再进机器看系统日志和本地连通性。坑：只看状态「运行中」就以为服务没事，其实进程早崩了。
5. 配额或账单是否受限：去「结算」「配额」页看欠费或 CPU/IP 满没满。坑：免费额度到期后机器起不来，界面只给一句含糊失败，不翻账单根本找不到原因。

进到虚拟机后，用这两条把第四步查到底，可直接复制：

# 看最近系统报错，并测本机端口到底有没有在听
sudo journalctl -xe --no-pager | tail -n 30
curl -I http://127.0.0.1:80

最后一条规矩最要紧：每次只改一个变量。比如先只加一条防火墙规则，别顺手又改标签又重启。改完立刻记下命令、时间和截图，然后用刚才完全相同的路径复测（同样的 list、同样的 curl）。为什么？一次改三处，就算好了也不知道是哪处救回来的；不按原路径复测，可能只是缓存碰巧通了，过两分钟又挂。慢一点，反而排得最快。

与替代方案对比

和只查官方文档相比，这里按“登录不了、部署失败、403、配额不足、日志空白”等故障现象给路径。官方文档像字典，准是准，但第一次看到红字时，你常不知道该翻 IAM、配额还是日志；先按现象走，再回文档核对，第一次遇到报错的小白更不迷路。

和盲目搜索、群聊提问或直接提交工单相比，先凑齐“五件套”，别人不用反复追问，沟通效率更高：

1. 项目 ID：不是项目名称，形如 my-shop-123；不确定就看项目列表。
2. 资源名：实例、服务、存储桶要抄完整，能带区域就带区域。
3. 报错原文：复制整段文字或完整截图，别只写“失败了”、别截掉错误码。
4. 日志时间：写清发生时间和时区，最好同时记 UTC，免得查错时间段。
5. 复现步骤：按 1、2、3 写“从哪页点了什么、期望什么、实际什么”。

和只依赖控制台点击相比，控制台更适合直观查看状态、颜色和单条日志；但换项目、换账号、找历史容易点错。gcloud 更适合批量确认、复制同一条命令给同事、留存输出证据。用已登录的 Cloud Shell 整段贴下面命令，不用改；看到 === 项目 ID === 就是在分段查项目，把终端输出全选复制即可留档。

gcloud auth list --format="table(account,status)"
gcloud config list --format=json
gcloud projects list --format="table(projectId,name,projectNumber)"
gcloud projects list --format="value(projectId)" | while read -r p; do
  echo "=== $p ==="
  gcloud services list --enabled --project="$p" --format="table(config.name,state)"
  gcloud logging read "severity>=ERROR" --freshness=1h --limit=20 --project="$p" --format="table(timestamp,severity,logName,textPayload,protoPayload.status.message)"
done

小白坑：项目 ID 不是项目名称；日志时间别只写“刚才”；报错别只截半张图。若提示 API 未启用、没权限或没默认项目，先存下原文，别为了“让命令变绿”乱开服务、乱切项目、重启生产资源；没查到日志也可能是时间段或权限不对，这本身就是线索。

和一键脚本或重启相比，清单式排错没那么“爽”，但能避免掩盖根因：重启可能让服务暂时恢复，却把 IAM、配额、账单、区域问题盖住，还冲掉现场。每步记“做了什么、看到什么、结论是什么”，方便贴进工单、交给同事、沉淀成团队清单；下次同样报错，照着走就行。

最佳实践

常见问题（FAQ）

GCP 新手最常遇到哪类报错？

多是权限不足、API 未启用、配额受限、防火墙未放行和账单异常，先按这五类排查。

SSH 连不上 VM 要先查什么？

先查 VM 状态、外部 IP、防火墙规则、SSH 密钥和项目权限，再看系统日志。

为什么控制台能看，gcloud 却报错？

通常是项目切换、账号权限、区域参数或 API 未启用，先核对当前配置和认证账号。

需要一开始就开工单吗？

不必，先准备报错原文、时间、项目 ID、资源名和复现步骤，仍无法定位再提交工单。

如何避免删错资源？

用标签、IAM 最小权限、删除保护、快照和变更记录，删除前确认项目与资源名。