交付:定位并修好随机故障

场景：~/diag/ 里有一处随机故障（进程/端口/解析/HTTP 之一）。 任务：自己分层定位、对症修好，让 curl 用域名访问拿到 200。改好运行 ~/check。 （判分只看你在受控容器里做

阅读更多 →

根因在HTTP层:修响应

场景：探下来根因在 HTTP 层——某路径的处理返回了 500。 任务：改 ~/diag/app.py 让说明点名的路径返回 200。改好运行 ~/check。 （判分只看你在受控容器里做出的诊断证据

阅读更多 →

根因在解析层:补记录

场景：探下来根因在解析层——域名不在 ~/diag/hosts.txt 里。 任务：补上「说明的域名 127.0.0.1」，让用域名 curl 能通。改好运行 ~/check。 （判分只看你在受控容器

阅读更多 →

根因在进程层:起服务

场景：探下来根因在进程层——服务没起，curl 连不上。 任务：把服务拉起来，让 curl 能拿到响应。改好运行 ~/check。 （判分只看你在受控容器里做出的诊断证据，全在本机 loopback，

阅读更多 →

这个域名的响应码是什么

场景：~/diag/解析.py 读 ~/diag/hosts.txt 解析。 任务：查说明点名的域名，看解析响应码（NOERROR/NXDOMAIN），到 ~/对照表.txt 里查它对应的标记。 （判

阅读更多 →

服务回的是什么状态码

场景：服务起着、端口也对，但某路径的响应码不一定是 200。 任务：用 curl 访问说明点名的路径，看状态码，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里做出的诊断证据，全在

阅读更多 →

服务实际听在哪个端口

场景：服务可能起了、但不一定在说明要求的端口上。 任务：用 ss 看它实际在哪个端口 LISTEN，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里做出的诊断证据，全在本机 loo

阅读更多 →

先探出坏在哪一层

场景：~/diag/ 里藏了一处随机故障；~/diag/诊断.sh 逐层探并打印 OK/BAD。 任务：跑它、看从底往上第一个 BAD 的层，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在

阅读更多 →

从现象认这次坏在哪层

用域名 curl 报「解析失败」，但直接用 IP curl 能拿到 200。下面判断对的是？ A. 进程起着　B. 端口在听　C. 坏在解析层　D. HTTP 层正常

阅读更多 →

无提示定位先做什么

面对一个没说哪坏的故障，最稳的第一步是【0】。 （本机受控：只有 ss / curl / 自写解析器，服务全在 127.0.0.1。）

阅读更多 →