为什么坏了停在第一层
四步叠着，从最底下查起 查到坏的那步就停，上面不用查了 从底往上查，碰到第一个不通的层就停，因为【0】。 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步—
解析通但连接不通是哪层
解析查得到 IP、但端口连不上，故障定位在【0】。 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步——解析(DNS) → 连接(TCP) → 加密(TLS
从底往上第一个坏在哪
按模型，fault_step({"解析": True, "连接": False, "加密": True, "请求": True}) 交回什么？ 贯穿本节的全链路
补全:找坏在哪一步
补全 fault_step：交回当前这个不 OK 的步 s。 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步——解析(DNS) → 连接(TCP) → 加
补全:哪步更靠底
补全 deeper：交回更靠底层的那一步。 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步——解析(DNS) → 连接(TCP) → 加密(TLS) →
补全:接着查上一步
补全 next_step：这步没问题就查上一步，到请求就停。 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步——解析(DNS) → 连接(TCP) → 加
补全:四步全通吗
补全 all_ok：四步是否全通。 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步——解析(DNS) → 连接(TCP) → 加密(TLS) → 请求(H
解析层坏了怎么修
诊断出坏在「解析」层（域名查不到 IP），该做的是【0】。 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步——解析(DNS) → 连接(TCP) → 加密
连接层坏了怎么修
诊断出坏在「连接」层（端口连不上），常见的修法是【0】。 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.py）：一次访问要依次走通四步——解析(DNS) → 连接(TCP) → 加密(
补记录后能解析吗
按模型，resolvable_after({}, "api", "1.2.3.4") 交回什么？ 贯穿本节的全链路模型（判题机不联网、镜像没 dig/tcpdump，这是它的确定模型，见 spine.