补全:定位故障层
补全 fault_layer：从底往上第一个不 OK 的层。 贯穿全路线的分层模型：从底往上 LAYERS = 进程 → 端口 → 解析 → 连接 → HTTP。fault_layer(证据) 交回从底往上第一个不 OK 的层；deeper
补全:哪层更底
补全 deeper：下标小的更底层。 贯穿全路线的分层模型：从底往上 LAYERS = 进程 → 端口 → 解析 → 连接 → HTTP。fault_layer(证据) 交回从底往上第一个不 OK 的层；deeper 哪层更底、next_c
补全:查下一层
补全 next_check：查上面一层，到 HTTP 就停。 贯穿全路线的分层模型：从底往上 LAYERS = 进程 → 端口 → 解析 → 连接 → HTTP。fault_layer(证据) 交回从底往上第一个不 OK 的层；deeper
补全:五层是否全好
补全 all_ok：五层全 OK 才算好。 贯穿全路线的分层模型：从底往上 LAYERS = 进程 → 端口 → 解析 → 连接 → HTTP。fault_layer(证据) 交回从底往上第一个不 OK 的层；deeper 哪层更底、nex
真机上怎么算把故障定位对了
在受控容器里，故障定位算对的标准是【0】。 （本机受控：只有 ss / curl / 自写解析器，服务全在 127.0.0.1。）
从现象认属于哪类诊断
下面哪些属于「本机网络分层诊断」直接要做的？ A. 用 ss 看端口在不在听 B. 用 curl 看服务回什么码 C. 用解析器看域名解不解得出 D. 给机器换一块新网卡
看服务在哪个端口上听
场景：~/net/ 下起了一个本机服务；~/net/起服务.sh 已把它拉起来。 任务：用 ss 看它在哪个端口上 LISTEN，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里做出的诊断证据，全在本机 loopback
curl 拿到什么状态码
场景：本机服务对某个路径有固定响应。 任务：用 curl 访问说明点名的路径，看状态码，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里做出的诊断证据，全在本机 loopback，不碰公网。） （本机受控环境：只有 ss
这个域名解析成哪个 IP
场景：~/net/解析.py 读 ~/net/hosts.txt 当本机解析器（镜像没 dig）。 任务：用它查说明点名的域名解析成哪个 IP，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里做出的诊断证据，全在本机 l
这次故障坏在哪一层
场景：~/net/诊断.sh 会逐层探（进程/端口/解析/HTTP）并打印每层 OK 与否。 任务：跑它、看从底往上第一个不 OK 的是哪一层，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里做出的诊断证据，全在本机 l