1 为何要把网络拆成层
你在浏览器输入地址，屏幕只显示“无法访问此网站”。这句话可能来自名字查找失败、连接超时、证书校验失败，也可能来自已经收到的服务器错误。用户看到的动作相同，出问题的位置却不同。网络分层的用途，就是把这个模糊的结果拆成可以分别验证的工作，让“打不开”变成“哪项工作没有完成、证据在哪里”。
同一根网线可以承载网页、文件传输、远程登录和名字查询。线缆负责传递信号，却不知道网页标题；转发设备需要决定数据往哪里走，却不必理解登录表单。若每个应用都自行解决信号、寻址、传输和业务含义，更换网卡或接入方式就可能迫使所有应用改写。把职责分开，可以让不同部分各自变化。
分层依靠稳定接口：上层把数据交给下层，并依赖下层约定的服务；下层可以改变实现，只要继续履行约定。比如电脑从以太网切换到 Wi-Fi，浏览器通常仍能发送 HTTP 请求。变化发生在局部，应用无需知道无线信号如何发送。但“通常能用”不代表下层失效时上层还能工作；接口减少耦合，并没有消除依赖。
邮政系统提供了有限但有用的类比。信件写内容，信封标地址，运输车辆负责某段行程。换车不应要求收件人重写信件，读信人也不必知道沿途车辆型号。不过网络数据可能被拆分、重传或经过不同路径，不能继续把现实邮政的每个细节硬套进来。类比只帮助理解职责与包装，具体判断仍要依靠协议和观测。
排查时，分层还提供了“证据边界”。能看到网卡，不等于能到达远端；能到达某个 IP，不等于目标端口可用；连接成功，也不等于请求得到业务认可。每次测试只为有限的结论背书。先写清它实际验证了什么，再决定下个动作，能减少反复改 DNS、重启应用、重插网线的盲目尝试。
2 两套常用模型：TCP/IP 与 OSI 怎么对照
本课采用实用的 TCP/IP 4 层模型：链路层、网际层、传输层、应用层。由下往上看，链路层负责相邻范围内的交付，网际层负责跨网络寻址与转发，传输层把数据交给对应通信端点，应用层约定请求和响应的含义。这里的“网际层”在日常交流中也常被叫作 IP 层或网络层，听到不同叫法时要先对齐含义。
OSI 的 7 层从下往上是物理、数据链路、网络、传输、会话、表示、应用。它提供了通用讨论词汇，例如“物理链路断了”“这是传输层连接问题”。对应到本课，OSI 的物理层与数据链路层归入 TCP/IP 的链路侧，网络层对应网际层，传输层基本对应，顶部的会话、表示和应用工作归入应用侧。这个对照是学习地图，不是要求每个现实协议都严格落进唯一格子。
以普通 HTTP 经 TCP、IPv4 和以太网传输为例，应用准备 HTTP 消息，TCP 提供字节流传输，IP 负责把包送往目标网络，以太网承载当前链路上的帧。因此可写成 HTTP → TCP → IP → Ethernet。HTTPS 还包含 TLS 保护；实际使用的 HTTP 版本也会影响传输方式，本课的连接例子限定为 TCP，避免把这个例子误当成所有网页的唯一路径。
TLS 的位置尤其能说明为何不应迷信层号。它位于应用数据与 TCP 之间，讨论证书时直接说“TCP 已连接，TLS 校验失败”，比争论它属于 OSI 的哪层更能指导操作。类似地，抓到 DNS 消息时，可以说“应用层的名字解析有结果”，无需因此断言网页服务正常。
读故障单时，优先寻找职责、协议、端点和阶段。有人说“4 层通了”，应进一步确认是否指从哪台主机到哪个 IP 的哪个 TCP 端口连接成功。把 7 个名字背熟不能替代这条记录；能把含糊的层号翻译成具体探测，才是后续学习 IP、路由、端口和服务的共同基础。
3 封装与解封装：头部是怎么叠上去的
发送端的应用先产生数据。传输层增加端口等控制信息，网际层增加源 IP、目的 IP 等信息，链路层再增加当前链路交付所需的信息。这种逐层包装叫封装。上层原本关心的内容，到了下层就成为要承载的负载；下层通常无需理解负载的业务含义。这里说的“头部”是结构化控制字段，并非屏幕上可见的标题。
用 100 B 应用数据做算术练习。假设它恰好放在 1 个 TCP 段里，TCP 使用无选项的 20 B 头部，IPv4 使用无选项的 20 B 头部，以太网不带 VLAN 标签，增加 14 B 帧头和 4 B 帧尾校验。于是 TCP 段为 120 B，IP 包为 140 B，以太网帧为 158 B。这个大小无需额外填充，计算也暂不加入 TLS 等其他开销。
“约 158 B 在线上传送”在这里采用的是以太网帧口径。若计算真实介质占用，还需另计前导码、帧起始定界符及帧间隔；若启用 TCP 选项、使用 IPv6、增加隧道封装，结果也会变化。抓包工具还可能看不到帧尾，应用的 1 次写入也不保证对应 1 个包。因此这不是带宽测量公式，而是说明控制信息确实占字节。
接收方向则逐步读取外层信息。网卡及链路处理接受适用的帧，IP 处理识别包的目的地址和上层协议，TCP 再依据连接信息把字节交给对应套接字，应用最终解释请求。把不同数据分送到对应处理者叫分用。目的端口参与分用，但不能单独识别全机所有通信；同个服务端口可以同时处理来自不同客户端的多个连接。
还要区分“最终收件地址”和“当前这段行程的地址”。经过路由器时，前段链路的帧会被取下，IP 包再装进下一段链路的帧。普通路由转发不会把 HTTP 请求拆开交给网站应用，也不会让原来的以太网帧原封不动穿过所有网络。理解这点，才能解释为什么远端服务器的 MAC 通常不会出现在本机邻居表里。
4 各层各自解决什么问题（到端口为止）
链路层解决当前链路上的交付问题。在以太网中，数据组织成帧，MAC 地址帮助识别链路上的接口；交换设备可以按帧的目的 MAC 转发。这里的“本地”是链路可达范围，不是“放在同个房间”。接口关闭、线缆断开、无线接入失败，都可能让后续工作失去基础，但仅看到接口处于启用状态，也不能证明所有帧都能到达下一跳。
例如目的 IP 不在本地直连网络时，电脑可能把帧交给网关。此时帧的目的 MAC 是网关接口的 MAC，包的目的 IP 仍是远端服务器。下面的邻居条目表示本机已经保存了网关的链路地址；它没有提供远端网页状态，也不是从本机到网站的完整路径清单。
$ ip neigh show 192.0.2.1
192.0.2.1 dev eth0 lladdr 02:00:5e:10:00:01 REACHABLE网际层解决跨网络交付。IP 提供逻辑地址，主机和路由器依据路由选择下一跳，逐段把包送向目的地。路由是本机关于“从哪里发出、交给谁”的决定，不是对后续路径的担保。途中设备可能无法转发，返回方向也可能失败。后面的 S15 会具体解释地址和子网，这里先把 IP 看成跨网络选择方向的依据。
例如下面的结果说明本机计划经 eth0 把包交给 192.0.2.1，并选择 192.0.2.10 为源地址。这个查询不发送探测包；即使它正常返回，也不能据此写“远端可达”。它的价值在于及早发现出口、源地址或下一跳与预期不符。
$ ip route get 198.51.100.20
198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 1000
cache传输层把通信推进到端点。TCP 使用端口区分服务及连接，并提供有序字节流、丢失重传等机制；它不保留应用每次发送的消息边界。UDP 提供数据报传输，不直接保证交付、顺序或重传，应用可以按需求补充机制。这里先认识可靠性选择，不展开握手状态机或拥塞控制。TCP 可靠传输也不意味着服务必定接受业务请求。
例如客户端从临时端口 53124 连接服务器的 443 端口。服务器通过目的端口找到相应监听端点，TCP 又结合双方地址与端口区分连接。nc -vz 198.51.100.20 443 若报告成功，只说明本次 TCP 建连成功；它没有发送合法 HTTP 请求，也没有检查证书。端口号是惯例和配置，不能保证监听程序一定提供惯例中的服务。
应用层约定消息含义。HTTP 规定请求方法、状态码和响应内容的表达，DNS 规定名字查询与应答。它们都依赖下层承载，但各自回答不同问题：DNS 给出地址，不负责让该地址的 HTTPS 服务健康；HTTP 返回 502，则说明某个 HTTP 服务已经能向客户端报告上游错误。业务理解必须放回对应协议语境。
$ curl -I http://198.51.100.20/
HTTP/1.1 404 Not Found
Content-Type: text/html这份响应虽然不是用户想要的页面，却是有价值的成功证据：本次请求已经到达能说 HTTP 的服务并得到响应。下一步应查主机名、路径或服务配置，而不是仅凭“404 也是失败”就认定网线断了。分层允许“下层完成、上层结果不符合预期”同时成立。
5 地址与名字：MAC、IP、端口、域名各属于哪一层直觉
排查时可以用“对象、范围、用途”整理地址。MAC 标识链路接口，用于当前链路上的帧交付；IP 是跨网络使用的逻辑地址，用于包的寻址与转发；端口是传输层端点编号，用于把通信交给对应服务或连接；域名是应用使用的名字，通过 DNS 等解析机制获得地址。它们不是 4 种可以随意互换的服务器编号。
| 标识 | 本课的层次直觉 | 读故障记录时要补的问题 |
|---|---|---|
| MAC | 链路层、当前链路 | 这是本机、邻居还是网关接口？ |
| IP | 网际层、跨网络寻址 | 从哪个源地址，经哪个出口访问？ |
| 端口 | 传输层、端点分用 | 是 TCP 还是 UDP，源端口还是目的端口？ |
| 域名 | 应用层、名字解析 | 用哪个解析器，得到哪个地址？ |
例如访问 https://app.example/，浏览器需要得到 app.example 的地址，再按 HTTPS 的默认端口尝试连接。若目标是 198.51.100.20，客户端会选择本地源地址和临时源端口；若需要经过网关，链路上还要得到网关的 MAC。这个过程中，“网站叫什么”“最终包送向哪里”“当前帧先交给谁”“交给哪项服务”各有答案。
IP 的“端到端”直觉指它承担跨网络的逻辑寻址，不是说地址永远不变。NAT 可能在中途改写地址或端口，代理也可能终止连接后另建连接；后续课程再展开。现在记录观测位置即可：客户端看到的源地址，不一定就是服务器最终看到的源地址。否则拿错地址查访问规则，容易误以为规则完全没有生效。
名字解析也受上下文影响。dig 直接查询 DNS，getent hosts 使用系统配置的名字服务入口，结果可能受本地 hosts 文件及其他来源影响；浏览器还可能有自己的缓存或解析设置。本课示例统一使用 IPv4，避免把地址族差异混进主要路径。若实际返回多个地址，应记录 curl 最终尝试的地址，不能只抄 DNS 应答中的任意 1 行。
域名在解析完成后仍可能参与通信。例如 app.example 与 files.example 可以解析到同一个 IP，并共用 TCP 443。TCP 只负责建立到这个地址和端口的连接；随后客户端可在 TLS 握手中通过 SNI 指明目标名字，服务端据此选择证书等配置，HTTP 请求中的 Host 则用于选择站点。证书校验还会检查证书是否覆盖 URL 中的名字。因此，同一个 IP 上某个站点正常，不能证明另一个站点的证书与路由配置正确；直接把 URL 改成 IP，可能出现证书名称不匹配，或进入默认站点。这类失败发生在名字参与的上层处理阶段，不能据此判断 IP 转发失败。
6 用分层读一次失败：从浏览器到网线的检查顺序
面对页面打不开，默认按 DNS → TCP 建连 → TLS/HTTP → 路由与网关 → 链路与邻居检查。这个顺序先沿用户请求的关键阶段取证，再在连接失败时向下定位，并非说真实发包先完成应用层才经过链路层。若已看到网卡断开，就直接检查链路；若拿到明确的 HTTP 错误，就优先解释响应。顺序服务于缩小范围。
先确认执行环境：下面命令以 Linux 为例，实际系统需安装相应工具。记录主机、时间、网络位置以及目标协议。示例使用文档保留地址和 .example 名字，输出是教学模拟，不能照抄后期待公网返回相同结果。沿用 S6/S8 的习惯，把标准错误和退出码一起看；不能只看日志里有没有某个单词。
名字阶段可先看系统入口，再按需要查 DNS 明细。这里拿到地址，只能证明这次解析路径返回了地址，还要核对地址是否符合服务配置。getent 与 dig 的来源不同，结果有差异时先调查来源，不急着清空所有缓存。
$ getent hosts app.example
198.51.100.20 app.example
$ dig app.example A +noall +answer
app.example. 60 IN A 198.51.100.20再直接测 TCP 端口，让名字解析与端口测试暂时分开。下面是 OpenBSD 风格 nc 的示例，不同实现的参数和文字可能不同。成功意味着本次连接建立；拒绝通常说明收到了主动拒绝信号；超时只说明截止时间前没有完成，不能直接区分防火墙、路径丢包和服务静默丢弃。
$ nc -vz -w 3 198.51.100.20 443
Connection to 198.51.100.20 443 port [tcp/https] succeeded!然后用 curl 同时保留目标名字与详细阶段。--noproxy '*' 让此探测走直接连接，适用于你明确要测试直连路径的场景；企业网络若规定走代理，应另记代理路径并分别测试。下面输出依次出现 Connected、TLS 连接和 HTTP 状态，说明本次失败边界若存在，应继续向响应或业务语义寻找。
$ curl --noproxy '*' -v --connect-timeout 3 --max-time 8 https://app.example/
* Trying 198.51.100.20:443...
* Connected to app.example (198.51.100.20) port 443
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
> GET / HTTP/1.1
< HTTP/1.1 200 OK
...（正文省略）若停在 Trying 后超时，再看 ip route get 198.51.100.20 是否选择预期出口与源地址，接着查 ip neigh show 192.0.2.1。邻居为 REACHABLE 表示近期确认过可达；STALE 通常只是缓存等待重新确认，并不等于断线；持续 INCOMPLETE 或 FAILED 才提示要调查邻居解析及本地链路。必要时用 ip link show dev eth0 查看接口状态，但这些观测仍不能担保远端链路正常。
每步结束都留下“已知”和“未知”。例如“DNS 有答案，TCP 未完成，TLS 尚未开始”，比“网络不通”更利于交接。成功的探测也有边界：某刻成功、某个 IP 成功、某条直接路径成功，不能自动推广到全部客户端、全部地址或代理路径。
7 常见坑：层号教条、跨层误判、把症状当成根因
第 1 个坑是把层号当结论。“这是 3 层问题”若没有源地址、目的地址、路由或包的证据，就只是换了种说法。团队之间对层数还可能采用不同模型。直接写“本机查不到目标路由”或“目标端口 SYN 无应答”，能明确失败动作，也能告诉接手的人该去哪里验证。所谓“Layer 8”玩笑不能代替对配置和人的操作留下证据。
第 2 个坑是跨层过度推断。ping 使用 ICMP，不是对 TCP 443 的测试。IP 回应 ICMP，只能说明那次 ICMP 交换有来有回；端口策略可能另有规则。反过来，有些服务不回应 ping，HTTPS 仍能正常工作。不能把 ping 成败当成全部网络能力的总开关，更不能用它证明证书或 HTTP 路径正确。
第 3 个坑是把错误文字翻译成未经验证的原因。NXDOMAIN 表示所问名字被报告为不存在，应先核对拼写、查询环境和 DNS 配置；它不同于解析请求超时。TCP timeout 可能来自过滤或路径，也可能来自目标端静默丢弃；接口处于 DOWN 则是更靠近本地的直接线索。同样的浏览器提示，背后可以是完全不同的证据链。
第 4 个坑是把“经过某设备”当成“某设备有错”。NAT 的转换状态、过滤规则或代理路径异常，有时表现得像路由中断；仅有正确路由表不能排除这些因素。但看到中间有 NAT，也不能无证据归因给 NAT。先比较不同端口、不同来源和两端收发，再确定数据在哪个边界消失，避免对所有网络设备轮流改配置。
最后要守住测试对象。直接访问 IP 可能改变 TLS 主机名校验和 HTTP Host，测试另一条 URL 也可能命中不同服务。需要固定目标 IP 又保留原名字时，可以用 curl 的 --resolve；不要为了得到成功结果随意加 -k 跳过证书校验。排查要解释原来的失败，改变测试条件后应明确记录变更及其影响。
8 案例：同一症状，3层不同根因
下面 3 名用户都说“打不开”。把这句话当作工单标题可以，把它当作诊断结论就不够。每组证据采用不同的失败阶段，目的是决定后续测试和负责范围。日志已截断，只保留对判断有用的字段；真实记录应补齐时间、客户端和目标信息。
案例 A 的用户把 app.example 输成了 ap.example。解析器能正常返回 DNS 应答，但明确报告名字不存在；curl 随后无法获得目标地址。此时尚未对目标网站建立 TCP 连接，所以反复调 443 端口规则无法修复这个拼写错误。
$ dig ap.example A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28104
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1
...（其余省略）
$ curl --noproxy '*' https://ap.example/
curl: (6) Could not resolve host: ap.example确认用户预期名字后，改用 app.example 得到正确答案，网页也恢复。根因是输入的名字错误，失败发生在应用层的名字解析阶段。若正确名字也返回 NXDOMAIN，下一步应核对记录、查询视图与缓存，而不是把本例的结论直接搬过去。错误类型提供方向，确认原因还需要对照预期。
案例 B 的名字正确，端口测试却超时。当前只能把边界定位到 TCP 建连未完成，不能仅凭这几行区分所有可能原因。后续在服务端入口找到匹配客户端来源的丢弃计数，才把原因收敛为过滤规则。没有这项补充证据时，故障单应保留“过滤或路径待查”。
$ dig app.example A +short
198.51.100.20
$ nc -vz -w 3 198.51.100.20 443
nc: connect to 198.51.100.20 port 443 (tcp) timed out: Operation now in progress
$ echo $?
1案例 C 已经建立连接并收到 HTTP 502。客户端到返回该响应的 HTTP 端点之间，必要的网络与协议交换已经发生；现在应查网关与上游之间的连接及应用状态。502 既不保证问题一定在应用代码，也不保证上游网络正常，它只把后续调查的边界推进到了这个 HTTP 端点之后。
$ curl --noproxy '*' -sS -o /dev/null -w '%{http_code}\n' https://app.example/
502
$ echo $?
0
# 网关错误日志，已截断
2026/10/30 10:12:07 [error] connect() failed (111: Connection refused)
while connecting to upstream, upstream: "http://192.0.2.30:8080/"这里 curl 没有加 --fail，收到 HTTP 502 仍可能退出为 0；退出码表达的是工具这次传输操作的结果，不等于业务健康。检查发现上游进程未监听 8080，恢复进程后网关返回 200，才完成根因验证。这组证据把“用户打不开”落实为应用网关遇到上游端口拒绝，避免把客户端 DNS 当成修复对象。
9 排查案例：能解析域名却打不开页面
现在把流程完整走过。10:20，客户端 192.0.2.10 的用户报告：浏览 https://app.example/ 失败，但 ping 198.51.100.20 成功。服务预期在 198.51.100.20 的 TCP 443 上提供 HTTPS，客户端采用直连。以下命令和输出构成同次排查的教学证据包，地址均为文档示例；实际操作应替换为已获授权的环境。
先保留 ICMP 与 DNS 结果，避免只转述“都通”。查到的 A 记录与服务清单一致，说明本次查询获得预期 IPv4 地址。这个结论仍不涉及端口和证书，也没有验证其他客户端或浏览器自己的解析结果。
$ ping -c 2 198.51.100.20
64 bytes from 198.51.100.20: icmp_seq=1 ttl=58 time=12.1 ms
64 bytes from 198.51.100.20: icmp_seq=2 ttl=58 time=12.0 ms
--- 198.51.100.20 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss
$ dig app.example A +noall +comments +answer
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16723
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
app.example. 60 IN A 198.51.100.20再让 curl 固定到已核对的 IP，同时保留 URL 中的名字。--resolve 的映射只作用于这次 curl 调用，不修改系统 DNS。它让这次探测绕过名字解析差异，又保留后续 TLS 与 HTTP 所需的目标名字；配合直连测试，可以判断该地址上的服务是否能进入下一阶段。
$ curl --noproxy '*' --resolve app.example:443:198.51.100.20 -v --connect-timeout 3 --max-time 8 https://app.example/
* Added app.example:443:198.51.100.20 to DNS cache
* Hostname app.example was found in DNS cache
* Trying 198.51.100.20:443...
* Connection timed out after 3001 milliseconds
* Closing connection 0
curl: (28) Connection timed out after 3001 milliseconds
$ echo $?
28输出没有 Connected，也没有证书校验或 HTTP 状态。当前可确定的是 TCP 建连没有完成，TLS 与 HTTP 尚未开始。若已经 Connected 后才出现证书错误，应调查 TLS；若出现 502，应解释 HTTP 响应。本例选择的是建连超时这条路径，因此“DNS 坏了”与现有证据不符：固定地址仍能复现，且名字查询返回了预期结果。
检查本机选择与下一跳，确认没有明显的错误出口。注意路由查询只是本地决定，邻居条目只是本地链路线索；这 2 项正常不能推出远端端口已开放，也不排除返回方向上的问题。
$ ip route get 198.51.100.20
198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 1000
cache
$ ip neigh show 192.0.2.1
192.0.2.1 dev eth0 lladdr 02:00:5e:10:00:01 REACHABLE要把“疑似过滤或路径”推进为确认结论，需要知道 SYN 到了哪里。具备授权与相应权限的值班工程师，在客户端和目标服务器入口同时抓取本次探测。这里仅阅读 TCP 标志：[S] 是发起连接的 SYN，若对方接受，通常能看到返回的 SYN-ACK。抓包需要的权限不同于普通查询命令，不应把权限不足误判成网络无包。
# 客户端抓包；在另一个终端重跑上面的 curl
$ sudo tcpdump -ni eth0 -nn 'host 198.51.100.20 and tcp port 443'
10:20:11.001 IP 192.0.2.10.53124 > 198.51.100.20.443: Flags [S], seq 170001, win 64240, length 0
10:20:12.025 IP 192.0.2.10.53124 > 198.51.100.20.443: Flags [S], seq 170001, win 64240, length 0
# 目标服务器入口抓包
$ sudo tcpdump -ni eth0 -nn 'host 192.0.2.10 and tcp port 443'
10:20:11.013 IP 192.0.2.10.53124 > 198.51.100.20.443: Flags [S], seq 170001, win 64240, length 0
10:20:12.037 IP 192.0.2.10.53124 > 198.51.100.20.443: Flags [S], seq 170001, win 64240, length 0客户端的重复 SYN 解释了等待和重试；服务端也看到同批 SYN，却没有相应回复。这样已经缩小到目标主机处理或返回方向，尚不能单凭抓包宣布“防火墙”。接下来只读检查目标主机的入站规则计数，并确认服务是否监听。计数必须比较探测前后，孤立的历史累计数字不构成本次命中证据。
# 服务端：确认监听，输出已截断
$ sudo ss -lntp 'sport = :443'
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=842,fd=6))
# 服务端：同一条规则在本次探测前后的只读查询
$ sudo nft list chain inet filter input
table inet filter {
chain input {
type filter hook input priority filter; policy accept;
ip saddr 192.0.2.0/24 tcp dport 443 counter packets 40 bytes 2400 drop
}
}
# 重跑 1 次相同 curl 后，再查同一条链
$ sudo nft list chain inet filter input
table inet filter {
chain input {
type filter hook input priority filter; policy accept;
ip saddr 192.0.2.0/24 tcp dport 443 counter packets 42 bytes 2520 drop
}
}在已隔离其他匹配流量的测试窗口，计数增加的 2 个包与这次抓到的 2 个 SYN 对应。诊断因此可以写为：失败边界位于 TCP 传输层建连；目标主机按源网段和 TCP 443 匹配的入站丢弃规则阻止了连接。确认它的下一项测试是服务端抓包加规则计数对照，而非再查 DNS。该策略也解释了为什么 ICMP 能响应而 HTTPS 失败。
完成诊断后，应由规则负责人核对这是否符合访问策略。若这条访问本来就应被禁止，网络是在执行预期规则；若是误配，按变更流程修正指定规则，再重复原来的 curl，验证 Connected、TLS 校验和 HTTP 结果。不要用清空防火墙代替修复，也不要在尚未复测时写“业务已恢复”。
放进方案里
把分层方法放进网络事件记录，首先写清症状与预期：哪台客户端、什么时间、使用哪个域名和协议，用户看到什么错误，预期应该得到什么响应。记录访问是否经过代理、是否只影响特定来源、是否所有地址都失败。范围应来自实际对照测试；只查过 1 台电脑，就写这台电脑的结果，不把它扩大成全网结论。
接着写当前层次假设和支持证据，例如“解析返回预期地址，TCP 建连超时，尚未进入 TLS”。列出执行环境、完整命令、目标 IP、端口、源地址和时间窗口，保留关键输出及退出码。命令中的超时、地址固定、代理绕过等参数会改变测试条件，需要一同记录。涉及凭据或业务内容时做必要脱敏，但应保留重新执行所需的结构与字段。
单列被证伪或暂时排除的假设，并注明证据边界。“固定地址仍复现”削弱本次 DNS 原因，“本机有路由”只排除本机没有匹配路由，并没有排除沿途丢包。对尚未证实的说法使用待验证措辞，写出下项探测、执行位置和要区分的结果。例如请服务端观察是否收到 SYN，同时核对监听与过滤计数，而不是笼统地请对方检查网络。
最后记录确认原因、处置责任与复测结果。根因应指向可验证机制，恢复应以原来的访问目标和条件复测；临时绕过与正式修复分别注明。交接的验收标准是另 1 名工程师无需猜测地址、参数或时间范围，就能重复相同探测，得到可比较的证据，并看懂结论由哪些观测支持。这样事件记录既能推动当前修复，也能帮助复发时迅速找到已有的失败边界。
10 小结：走向 IP 与子网（S15）
分层模型把链路交付、跨网络转发、端点通信和应用语义拆成不同职责。封装把这些职责所需的信息带上路，解封装与分用让数据到达对应处理者。排查的关键是限定每条证据的范围，再用下项测试区分剩余假设。
读到“解析成功、ping 成功、TCP 超时”，应能指出哪些工作已被观测、哪些尚未完成；读到 HTTP 502，应能把调查推进到返回响应的服务及其上游。S15 将具体讨论 IP 地址与子网，解释主机如何判断目的地是否直连，以及为什么某些包需要先交给网关。
下一课转向 S15 IP 与子网：把本章验收过的结论带进后续主题，写成可检查的方案约束。