把没起来的服务拉起来
场景：本机服务没起，curl 报连不上（进程层坏）。 任务：用 ~/net/起服务.sh 把服务拉起来，让 curl 能拿到响应。改好运行 ~/check。 （判分只看你在受控容器里做出的诊断证据，全在本机 loopback，不碰公网。）
把配错的端口改回来
场景：服务配置里的端口和说明要求的不一致，curl 说明的端口连不上（端口层坏）。 任务：把 ~/net/端口.txt 改成说明要求的端口、重起服务，让 curl 那个端口能通。改好运行 ~/check。 （判分只看你在受控容器里做出的诊断
把缺的解析记录补上
场景：说明点名的域名不在 ~/net/hosts.txt 里，解析失败（解析层坏）。 任务：往 hosts.txt 补一条「域名 127.0.0.1」，让解析器解得出。改好运行 ~/check。 （判分只看你在受控容器里做出的诊断证据，全在
交付:让整条链路通到底
场景：进程/端口/解析里有一处坏着，curl 用域名访问不通。 任务：分层查出坏在哪、修好它，让 curl 用域名访问拿到正确响应。改好运行 ~/check。 （判分只看你在受控容器里做出的诊断证据，全在本机 loopback，不碰公网。）
无提示定位先做什么
面对一个没说哪坏的故障，最稳的第一步是【0】。 （本机受控：只有 ss / curl / 自写解析器，服务全在 127.0.0.1。）
从现象认这次坏在哪层
用域名 curl 报「解析失败」，但直接用 IP curl 能拿到 200。下面判断对的是？ A. 进程起着 B. 端口在听 C. 坏在解析层 D. HTTP 层正常
先探出坏在哪一层
场景：~/diag/ 里藏了一处随机故障；~/diag/诊断.sh 逐层探并打印 OK/BAD。 任务：跑它、看从底往上第一个 BAD 的层，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里做出的诊断证据，全在本机 lo
服务实际听在哪个端口
场景：服务可能起了、但不一定在说明要求的端口上。 任务：用 ss 看它实际在哪个端口 LISTEN，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里做出的诊断证据，全在本机 loopback，不碰公网。） （本机受控环境
服务回的是什么状态码
场景：服务起着、端口也对，但某路径的响应码不一定是 200。 任务：用 curl 访问说明点名的路径，看状态码，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里做出的诊断证据，全在本机 loopback，不碰公网。） （
这个域名的响应码是什么
场景：~/diag/解析.py 读 ~/diag/hosts.txt 解析。 任务：查说明点名的域名，看解析响应码（NOERROR/NXDOMAIN），到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里做出的诊断证据，全在