📍 WDQWDWQD987AAAAA:216.73.217.165
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2cd70de0d519.html
📄

重庆云主机：怎样形成可复用检查清单

把重庆云主机的问题排查做成可复用检查清单，核心是从“可交付结果”倒推：先写清恢复或交付的验收标准，再列出必须收集的资料、必须执行的任务、每项任务的责任人，以及判断通过或失败的证据。清单不是故障分类表，而是一套每次都能照着走、能留下记录、能复核的流程。

先定义交付结果，再决定清单里放什么

以“重庆云主机无法通过公网访问”为例，交付结果不是“修好了”，而是可验收的状态：从指定外部网络访问指定端口，连续三次得到预期响应，且延迟、丢包在约定范围内。验收标准写不出来，清单就会变成漫无目的的尝试。

把结果拆成四类资料：

• 资源资料：实例规格、镜像、系统版本、公网与内网地址、带宽计费方式、到期时间。
• 配置资料：安全组规则、网络ACL、路由、监听端口、系统防火墙、应用配置。
• 证据资料：报错原文、时间点、客户端来源IP、抓包或连接测试结果。
• 变更资料：最近改过什么、谁改的、何时改的、是否可回滚。

按“现象—可能原因—验证动作”写检查项

清单条目要写成可执行动作，而不是结论。同一个现象往往有多种解释，未验证前只能列为可能原因。

1. 确认现象范围：是单台客户端不通，还是多个外部网络都不通；是全部端口还是单个端口。判断结果决定后续查本地网络还是查云主机侧。
2. 核对地址与端口：确认连接的是当前公网地址、协议和端口，排除复制旧地址或写错端口。
3. 查安全组与网络ACL：确认入方向规则是否放行该来源和端口。放行不等于一定可达，还要继续验证路由与主机侧。
4. 查主机内部：系统防火墙、服务监听地址是否绑定到 0.0.0.0、进程是否存活。可用 ss -lntp 一类命令查看监听状态。
5. 区分解析与连通：域名访问失败时，分别测域名解析结果和直接连 IP 的结果，判断问题在解析还是在链路。
6. 记录时间与复测：每次变更后记录时间点并复测，避免把“改完刚好恢复”误判为因果。

技术排查中，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录；这些属于内容侧检查项，不要和云主机连通性混在同一张清单里。

明确责任人与验收证据

每项任务要有唯一责任人：谁收集日志、谁改配置、谁复测、谁确认回滚点。责任人不清，清单执行时会互相等待。

验收证据建议固定为三类：

• 变更前证据：原始报错、测试结果、配置快照。
• 变更记录：改了什么、改成什么、执行人和时间。
• 变更后证据：同一测试方法的复测结果，与验收标准逐条对照。

例如假设某次排查中，安全组放行后仍不通，主机内服务只监听 127.0.0.1，那么“安全组已放行”不能作为通过依据，必须补上监听地址这一项。这里的例子仅用于说明判断方法，不代表真实项目结论。

让清单可复用的三个条件

第一，条目与具体对象绑定：重庆云主机的网络、系统、应用三层分开写，避免把“云平台配置”和“操作系统配置”混成一条。第二，每条都有判断结果：通过、不通过、待确认，不能只写“检查一下”。第三，保留版本：每次排查后把新发现的原因和有效验证动作补进清单，删除已被证伪的假设。

如果涉及 HTTPS，要单独核查证书有效期、域名匹配和链路配置；HTTPS 不保证安全无漏洞，也不保证排名。不同搜索引擎对抓取与索引的支持情况须分别核查，不要用一份清单套用所有平台。

下一步

选一个最近真实出现过的重庆云主机问题，按上面的结构写成第一版清单：先写验收标准，再补资料、任务、责任人和证据字段，然后用一次复测验证清单是否真的能走通。