根因在进程层:起服务
场景：探下来根因在进程层——服务没起，curl 连不上。 任务：把服务拉起来，让 curl 能拿到响应。改好运行 ~/check。 （判分只看你在受控容器里做出的诊断证据，全在本机 loopback，不碰公网。） （改状态类：改完运行 ~/
根因在解析层:补记录
场景：探下来根因在解析层——域名不在 ~/diag/hosts.txt 里。 任务：补上「说明的域名 127.0.0.1」，让用域名 curl 能通。改好运行 ~/check。 （判分只看你在受控容器里做出的诊断证据，全在本机 loopba
根因在HTTP层:修响应
场景：探下来根因在 HTTP 层——某路径的处理返回了 500。 任务：改 ~/diag/app.py 让说明点名的路径返回 200。改好运行 ~/check。 （判分只看你在受控容器里做出的诊断证据，全在本机 loopback，不碰公网。
交付:定位并修好随机故障
场景：~/diag/ 里有一处随机故障（进程/端口/解析/HTTP 之一）。 任务：自己分层定位、对症修好，让 curl 用域名访问拿到 200。改好运行 ~/check。 （判分只看你在受控容器里做出的诊断证据，全在本机 loopback
一次访问要走通哪几步
一次访问要走完四关 一关接一关，走通了才到得了 浏览器访问一个网址，底层要依次走通的是【0】。 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步——解析(D
解析这一步在做什么
一次访问要走完四关 一关接一关，走通了才到得了 全链路第一步「解析」做的是【0】。 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步——解析(DNS) →
为什么要一层层来
把访问拆成解析/连接/加密/请求四层来看，好处是【0】。 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步——解析(DNS) → 连接(TCP) → 加密(
加密是哪一步的事
HTTPS 的「加密(TLS 握手)」发生在【0】。 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步——解析(DNS) → 连接(TCP) → 加密(TL
全链路一共几步
按模型，n_steps() 交回几？ 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步——解析(DNS) → 连接(TCP) → 加密(TLS) → 请求(
补全:数链路步数
补全 n_steps：全链路一共几步（STEPS 的长度）。 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步——解析(DNS) → 连接(TCP) → 加