1 为什么命令要先对齐失败阶段
S19 与 S20 已经把一次对外访问拆成可独立核对的阶段：名字能否解析、TCP 能否建立、TLS 身份能否通过、HTTP 是否返回预期内容。本课把这些阶段接到 Linux 上的常用观测命令。命令本身不会自动告诉你业务是否成功；只有当你先写清「已经证明什么、尚未证明什么」，输出才有明确的解释范围。
设想同事发来一句「接口挂了」。可能的证据完全不同：本机没有默认路由、对端 443 拒绝连接、证书名称不匹配、网关返回 503、或者只是偶发打到过期证书的入口。若一上来就抓包或反复刷新页面，容易把时间花在当前阶段并不需要的工具上，也容易把某一阶段的成功误写成整体恢复。值班群里最常见的空转，是3 个人同时在不同平面执行互不对照的 ping，却没有人写下取样主机与目标地址。
开始前先花大约两分钟写下两列。已证明：例如 dig 得到 198.51.100.20，本机 ss 看到到该地址 443 的 ESTAB。未证明：TLS 是否按正式域名完成校验、HTTP 状态与正文是否符合探针。然后再选下一条命令。教学上可把阶段记为 DNS → TCP → TLS → HTTP；真实环境还可能插入代理、负载均衡与安全设备，但分层提问的习惯仍然适用。两分钟看起来「慢」，却能避免 10 分钟后的方向性返工。
命令输出是观察，不是判决。ping 通只说明 ICMP 路径在某种策略下可用；ss 显示 LISTEN 只说明本机有进程绑定端口；curl 默认退出码 0 仍可能对应业务不接受的正文。同一条 Connected 日志，在「只验证 TCP」的工单里是完成条件，在「HTTPS 验收」的工单里却只是中途证据。本课使用 RFC 5737 / 3849 教学地址与 example 域名；示例不发起真实外网攻击性探测，你在自己环境执行时应替换为已授权目标，并遵守变更与抓包审批。
闭环还有一个协作含义：当你把阶段结论写进工单后，其他角色可以据此拒绝无关请求。网络工程师在看到「TLS 校验失败」时，有权要求先贴证书字段与 URL，而不是立刻去改核心路由；应用工程师在看到「SYN-SENT 持续超时」时，也不应先重启无监听变化的进程。阶段语言是跨组的礼貌与效率工具，不只是个人笔记技巧。
因此，本课训练的是「阶段 → 命令 → 证据边界」的闭环：先对齐阶段，再选择最小必要命令，最后把结论写成可交接的范围句，而不是「网络好了/坏了」的二元标签。读完后你应能在故障单里自然写出：「TCP 已建立，TLS 校验失败，HTTP 未发送」这类句子，并指出接下来该看证书字段还是该看路由。
在开始具体命令前，先约定 3 条证据纪律。第一，每条结论只覆盖其命令能够观察的范围，不向上或向下自动推广。第二，优先在与故障同一网络平面的主机取样，跨平面成功不能默认同平面成功。第三，保存原始输出摘要时同时保存命令行本身，缺了命令行的输出难以复现。把这 3 条写进个人检查清单，比记忆大量冷门参数更有用。
若一时无法判断阶段，先做最小 3 连：本机 ip route、目标名 dig +short、对业务端口的一次 nc -vz 或等价探测。3 连的目标不是证明业务健康，而是迅速排除「本机无路」「名字无解」「端口无响应」这 3 类起点问题，从而决定下一步是补地址、查解析，还是进入 curl 阶段线。
2 地址与路由：本机有什么、下一跳去哪
排障时可把本机网络状态理解成一张「出发前检查表」：没有可用地址，后面所有跨主机命令都会在起点失败；有地址但路由指向错误出口，表现会像对端无响应，实际上包可能从未进入业务平面。最后补一条时间纪律：每条关键命令的输出都应带时间戳，或至少在粘贴时手写取样时刻。网络与证书类故障常与整点轮换、缓存过期、自动化变更窗口重合；没有时间戳的「刚才还不行」无法与监控曲线对齐，阶段结论也会在交接中被下一班推翻重来。
写进已证明栏时，建议同时贴上接口名、地址 CIDR、默认经由与取样时间，方便 5 分钟后回看是否发生了 DHCP 或云平台热更新。
TCP 连不出去时，先确认本机是否具备合理的源地址与出站路由，再怀疑对端服务。常用入口是 ip addr 与 ip route（发行版若以 ifconfig/route 为主，对应关系相同，本课统一用 ip 族说明）。云主机控制台里显示的「主网卡 IP」与命名空间内看到的地址偶有延迟不一致，排障以发起连接的那一侧实际输出为准。
ip addr 列出网卡、地址与状态。假设教学机看到 eth0 上有 192.0.2.10/24，只能说明本机在该接口配置了这个地址，不能证明外网或对端主机一定能回到这里。地址缺失、网卡 DOWN、或应用绑错地址，都会在更早阶段失败。容器与虚拟机还要区分「命名空间内看到的地址」与「宿主机/云平台弹性网卡上的地址」。若 Pod 内地址是 10.244.3.15，而你在堡垒机上盯着节点的 192.0.2.10，两边的 ss 本就不是同一张表。
ip route 回答「去某个目标时下一跳是谁」。默认路由常见形态是 default via 192.0.2.1 dev eth0。没有默认路由时，访问公网地址会在本机直接失败；有默认路由也不能证明下一跳往后的路径一定通，更不能证明对端 443 上的服务健康。策略路由、多网卡、VPN 隧道会让「看起来有路由」与「业务出口网卡」不一致：例如管理网走 eth0，业务网走 eth1，应用若未绑定正确源地址，会表现为对端白名单拒绝。这时要对照应用实际绑定与云平台路由表，而不是只截一张默认路由截图。
IPv6 并存时还要确认目标族。api.example 若返回 AAAA 而环境未就绪，可能出现「解析成功但连接失败」；强制看 A 记录或检查是否应禁用该族，属于配置策略，不应被笼统写成「DNS 坏了」。链路本地与临时地址也会让不熟悉的同事误读 ip addr 输出，交接时应圈出真正用于出站的全局地址。
核对顺序建议固定：接口是否 UP → 是否有预期地址 → 到目标的路由是否存在且出口正确 → 再做跨主机探测。把「本机地址配置正确」写成已证明事项后，才能把怀疑焦点外移。反向也成立：对端服务正常时，本机路由错误仍会表现为连接失败，不能要求数据库或应用组先改配置。若变更窗口刚调整过子网或附属网卡，把变更单号写进已证明/待核列，能缩短来回追问。
3 端口与套接字：谁在听、谁连着
在微服务主机上，一次 ss -tuln 可能列出很多监听端口。先按故障单中的目标端口过滤，再看是否存在非预期的额外监听。若目标是 443，却只看到 80 与 8080，不要急着宣布「服务挂了」——可能 TLS 终止在旁路代理，本机只提供明文回端。把架构草图上的「谁终止 TLS」与 ss 对照，能少走一轮冤枉路。
确认本机网络身份之后，下一步常看套接字：谁在监听、谁已经连上。ss -tuln 列出 TCP/UDP 监听与连接的数值地址；加上 -p 可在许可环境下看到进程信息（容器权限不足时可能空白，空白不等于没有进程）。相对过时的 netstat 在部分镜像仍在，读法类似，但本课示例统一用 ss。
LISTEN 在 0.0.0.0:8080 或 [::]:8080 表示本机有进程接受该端口连接，证明范围仅限于本机监听事实。它不证明安全组、网络 ACL 或上游负载均衡已经放行，也不证明远端客户端能到达。若业务进程应监听 127.0.0.1:8080 却绑到了全网卡，暴露面会变大；若应对外却只绑回环，则对外探测会失败而本机 curl 127.0.0.1 仍成功——这是经典的「本机通、对端不通」分界。Unix 域套接字监听则根本不会出现在 TCP 端口表里，若应用配置写成「本地 socket 文件」，却有人在安全组里放行 8080，两边会各说各话。
ESTAB 连接帮助判断「已经连到哪里」。假设本机到 198.51.100.20:443 出现稳定的 ESTAB，而业务仍失败，说明 TCP 阶段大体成功，应把重点转向 TLS 与 HTTP，而不是继续加长 ping。若大量连接停在 SYN-SENT，更宜怀疑路径过滤、对端未监听或中间丢弃 SYN；若出现大量 TIME-WAIT 或连接堆积，则可能是客户端重试策略或服务端耗尽，需要结合应用指标，不能单靠再开一个终端狂敲命令。CLOSE-WAIT 堆积常指向本端应用未正确关闭，属于应用生命周期问题，网络组只看到「连接很多」容易误判为攻击或带宽不足。
读写 ss 时同时记录时间、命名空间（主机/容器/Pod）与是否使用了代理本地端口。反向代理会在本机看到到 127.0.0.1:8080 的 ESTAB，同时在另一侧看到对外 443 的 ESTAB；两张表都要，否则会把「代理到后端失败」误写成「公网进不来」。把监听证据与连接证据分开归档，避免把「进程在」写成「用户能访问」。
4 可达性与路径：ping 与 traceroute 能证明什么
ping 与 traceroute（或 tracepath）常被当作「网络通不通」的代名词，但它们默认走的是 ICMP 或 UDP 探测语义，与业务 TCP/TLS/HTTP 并不等价。理解这一点，是避免在 HTTPS 故障里反复刷 ping 的关键。
ping 198.51.100.20 成功，只说明在当前策略下 ICMP 回显大体可用；许多生产网络会限制 ICMP，此时 ping 失败并不能证明 TCP 443 不可达。反过来，ping 成功也不能证明 443 开放或证书有效。教学上把它定位为「早阶段路径直觉」，一旦进入应用排障，应尽快换成面向目标端口的探测。延迟数值同样只能当参考：公网 30ms 与 80ms 的波动很少单独构成 503 的根因。
面向端口的轻量探测可用 nc -vz 198.51.100.20 443 或发行版提供的同类工具。成功只推进到 TCP 证据；失败则停留在连接阶段，仍不要跳跃断定为「HTTP 挂了」。若 nc 显示 refused，多指对端回复了 RST 或无可接受的监听；若长时间无结果直至超时，更像路径丢弃或过滤。两者的下一步不同：refused 偏服务监听与指向；timeout 偏安全组、路由黑洞或中间设备。
traceroute 给出中间跳的线索。某跳超时很常见，可能是该跳对探测包沉默，不等于业务路径在此断裂。把 traceroute 当作假说生成器：它提示你去对照哪一段路由或哪一个安全边界，而不是直接点名「就是第 5 跳的锅」。跨公网时路径还可能不对称，往返各跳并非同一条物理路。企业内部若存在专用探测策略，应以平台提供的路径检测为准，并在交接中注明工具差异。
记录 ping/traceroute 时写明探测类型、目标、时间与是否与业务端口一致。若业务故障与 ICMP 结果冲突，以业务端口与应用层证据为准，并在交接里写清冲突本身——冲突往往比「全部失败」更有定位价值。
5 名字解析：dig 与 getent 看到的答案
当答案含多个地址时，不要只测第一个。脚本里 head -n1 取首地址的习惯，会在「第二地址异常」时造成假阴性或假阳性。教学上可对每个答案执行一次端口探测并制表：地址、探测结果、证书指纹（若已到 TLS）。这张表比口头说「DNS 轮询有问题」更能推动入口下线决策。
应用通常先解析名字再连接。S18 已讲 DNS 主线；这里只训练排障时如何快速取证，避免把解析问题误判为「链路抖动」。dig api.example A 或 dig +short api.example 向指定或默认解析器询问答案；getent hosts api.example 更接近本机 NSS 路径（可能含 files、DNS 等），有时与裸 dig 不一致。
假设 dig 得到 198.51.100.20，而故障机 getent 得到旧地址 198.51.100.30，则优先怀疑本机缓存、/etc/hosts 残留或不同解析配置，而不是先改服务端证书。若 dig 已能答、业务进程却解析失败，检查进程是否运行在不同网络命名空间、是否使用自定义解析库，或是否在连接时硬编码了 IP。Java / Node 等运行时可能有自身 DNS 缓存，操作系统侧更新后进程仍可能沿用旧答案，需要按运行时规则刷新或重启，这一步常被漏写进交接。
权威答案与递归缓存要分清：你在笔记本上 dig 到的结果，不自动等于集群节点上的结果。排障应在「真正发起连接的那台机器」上取证，或明确写明取样主机。TTL 未过期时，旧答案可以在部分节点继续存活；轮换入口后出现的「偶发连错地址」，常要用按节点分组的解析结果来解释。若使用了内网私有 Zone，公网 dig 失败而内网成功是预期现象，不能据此要求对方「开放公网解析」。
把解析证据写成：查询名、查询类型、取样主机、解析器、答案地址、时间。不要只贴一张「我这边 dig 是通的」截图覆盖所有调用方。需要对比多答案时，列出全部 A/AAAA 并标注哪个地址上的端口探测失败，这能为「半数入口异常」提供直接支持。
6 请求侧观测：curl 阶段输出如何读
当 DNS 与 TCP 线索齐备后，用 curl -v 观察请求侧阶段线。S19/S20 已强调：* Trying、* Connected、TLS 校验相关行、以及 HTTP 状态行分别对应不同证明。本课补充运维习惯：固定入口、保存完整条件、区分退出码与业务断言。浏览器开发者工具也能看状态码，但自动化取样与服务器侧排障更常依赖 curl 一类客户端，便于把命令写进可复制的交接。
定向复现常用：
curl -v --resolve api.example:443:198.51.100.20 https://api.example/health这保留 URL 中的名字（影响 SNI 与证书核对），同时把连接打到指定地址。对比「换 IP 的 URL」：后者会改变身份核对对象。若只有加 -k 才出现 HTTP 状态，结论只能写「跳过校验时应用层有响应」，不能写入正式 HTTPS 验收。把 -v 输出保存为文件时注意脱敏：Authorization 头、Cookie 与查询串中的令牌不应进共享工单。
退出码方面：默认许多 HTTP 错误状态仍返回 0；--fail 会把 4xx/5xx 变为非 0，便于脚本，但仍然替代不了正文断言。连接超时、解析失败、证书错误各有不同退出含义，交接时应同时保存 -v 日志与时间戳。连接超时类失败若与 ss 中长期 SYN-SENT 一致，可强化「路径或对端未接受」假说；若已 Connected 却在 TLS 卡住，则转向协议与证书，而不是扩大 ICMP 测试面。
把 curl 证据与前面的 ss、dig 对齐：若 Connected 成功且本机有 ESTAB，却停在证书错误，就不要回头怀疑默认路由；若卡在 Trying，则优先回到地址、路由与端口探测。阶段对齐能显著减少「同一条故障线上重复开通断检测」的空转。对需要鉴权的探针，使用专用只读账号与最小权限令牌，并在文档中写明令牌轮换方式。不要把个人长期云控制台会话 cookie 塞进共享探测脚本。若探针必须带签名头，失败时要区分「网络阶段失败」与「签名校验 401/403」，后者已进入 HTTP 语义，应按 S19 的状态码家族继续，而不是加长连接超时。
对需要跟随跳转的探针，明确是否使用 -L 以及最大跳数；一次 302 可能把你带到不同入口，阶段证据要按最终与中间分别记录。
7 常见坑：只看通断、混用特权抓包、把教学样本当地址真相
第 1 类坑是通断二元论。值班消息里的「网络不通」往往混合了解析失败、连接拒绝、超时、证书问题与 5xx。若只回「我 ping 通了」，既可能答非所问，也可能让团队过早结束排查。正确做法是回阶段句：例如「ICMP 通，TCP 443 拒绝；尚未做 TLS」。把阶段句贴进群里，比贴一张绿色大对勾截图更有协作效率。
第 2 类坑是未经授权的抓包或在错误位置抓包。tcpdump/dumpcap 能看到 SYN 是否离开网卡、是否有 SYN-ACK、是否出现 ClientHello，对卡死在 TCP/TLS 早期很有价值；但它需要权限与合规审批，且在加密负载内看不到 HTTP 正文。抓错网卡、抓到隧道内侧或只抓到回环，都会得到误导性空结果。短时、限端口、限主机的过滤器优先；抓完立刻评估是否仍需要保留完整包。教学环境可用极短窗口演示「看见 SYN、未见 SYN-ACK」；生产环境则先问是否已有平台流日志可替代。
第 3 类坑是把文档里的教学地址、示例域名或过期工单里的 IP 当成当前真相。198.51.100.0/24、api.example 只用于说明；生产以当时配置中心、云控制台或服务发现为准。同样，-k、临时关闭校验、或「先改本地 hosts」只能当受控诊断，写进验收就会把身份边界打穿。过期变更单里的 IP 被抄进新脚本，是造成「偶发连错入口」的常见人为因素。
第 4 类坑是端口与协议错配：对 80 发 HTTPS、对 443 发明文 HTTP、或健康检查打到管理端口。ss 显示端口开着，只说明有监听，不说明协议与证书名正确。偶发失败时若不按入口/节点分组，容易把「一半入口证书过期」误判为「玄学网络抖动」。还有一类混用：在错误的 VRF/命名空间执行了正确命令，输出看起来「都很健康」，却与业务平面无关。
8 案例：API 503 的分层命令复盘
复盘时保留「否定证据」同样重要。例如已证明默认路由存在、ICMP 被策略拒绝、TCP 443 成功，这 3 条合在一起，足以反驳「整网不可用」的早期假说。否定证据写进交接，能阻止下一班值班重复已完成的通断测试，把时间留给上游连接与进程状态。
场景：对外 URL https://api.example/health 约定返回 status=ok。监控显示 503 升高。取样主机为跳板机 ops-jump，已授权探测。目标是在 15 分钟内给出带阶段范围的交接，而不是先争论「到底是不是网络问题」。
第 1 步写阶段表。已证明：昨日同 URL 正常。未证明：今日失败停在哪一层。在跳板机执行 dig +short api.example 得到 198.51.100.20；getent hosts api.example 一致。DNS 暂列已证明。同步记下解析器地址，避免事后无法复现。
第 2 步 TCP。nc -vz 198.51.100.20 443 成功；ss -tp 可见到该地址的短连接。TCP 暂列已证明。若这一步失败，应停在网络/安全边界联查，而不是让应用组重启进程碰运气。
第 3 步 TLS/HTTP。
curl -v --resolve api.example:443:198.51.100.20 https://api.example/health输出含证书校验通过与 HTTP/1.1 503。结论更新为：DNS/TCP/TLS 通过，HTTP 状态不符合探针；问题转向网关、上游或应用，而不是「公网断了」。若此时有人只贴 ping 成功，应明确它不再增加信息。保存完整 URL、Resolve 映射、时间戳与响应头中的请求标识（如有），方便网关检索。
第 4 步对照。对同一入口请求 /health 与一条只读业务路径，确认是否同为 503；在应用主机上 ss -tuln 看后端 8080 是否仍在听；若后端无监听，则网关 503 与上游连接失败一致。需要短时抓包时，只在跳板机到入口的 443 上确认握手完整，避免无必要地扩大抓取范围。若后端在听但网关上游池指向旧地址，ss 与网关配置对照会比继续 tcpdump 更快。
最终交接：「2026-10-31 12:05 北美太平洋时间（与白马市本地时区一致，UTC-7）；跳板机取样；api.example→198.51.100.20；TCP/TLS OK；GET /health → 503；后端 8080 无 LISTEN。建议应用与网关组接手；网络层无证据表明默认路由或公网 ICMP 异常。」这样的句子让下一组直接知道该看进程与上游池，而不是重做一遍通断。
9 排查案例：本机通对端不通、偶发超时、证书与端口错配
若组织提供统一的拨测点，优先用拨测点复现，再在跳板机确认。拨测点失败而跳板机成功，常指向区域入口或 DNS 分流差异；两处都失败且阶段相同，则更宜按阶段深入。不要在个人笔记本、办公网出口与生产拨测点之间来回切换却不标注取样点，否则时间线无法对齐监控曲线。
案例 A：开发者本机 curl http://127.0.0.1:8080/health 返回 200，同事访问云主机公网地址失败。本机 ss 显示服务监听 127.0.0.1:8080。结论应写「仅回环可访问」，处理是按发布规范绑定或经本机反向代理对外，并核对安全组；不是让同事「再试一次网络」。若监听已是 0.0.0.0:8080 而公网仍失败，则把重点转到安全组、平台防火墙与是否绑错弹性 IP，而不是反复重启应用。
案例 B：20 次请求中约 5 次超时。按解析答案分组后发现，成功落到 198.51.100.20，超时落到 198.51.100.30；对后者 nc -vz :443 失败。修复方向是下线或修复错误入口，而不是平均加大客户端超时。把客户端超时从 3 秒改到 10 秒，只会让失败更慢，不会让错误入口恢复监听。超时滑块用于讨论等待窗口与重试间隔如何影响「用户是否判定失败」，不能把滑块数值当成根因。
案例 C：nc -vz :443 成功，但 curl https://api.example/health 报证书名不匹配；改用 IP URL 更糟。保留域名并 --resolve 后，若仍名不匹配，查入口证书与 SNI；若仅 IP URL 失败，属于预期身份核对行为。另见：误对 80 端口发 HTTPS，错误会表现成协议或握手异常，需先用 ss/探针确认端口角色。证书临近过期的入口与长期有效入口混挂时，也会呈现「有时不安全有时正常」，必须按入口指纹分组。
案例 D：容器内 dig 正常，容器外业务域名指向内部负载均衡，而测试机在 VPC 外。此时「命令都对」仍会失败，因为取样点不在同一网络位置。交接要写明取样点与目标平面（公网/内网），避免跨平面复用同一条成功证据。VPN 断开后笔记本突然「全线失败」，优先检查的是客户端路由与 DNS 后缀，而不是服务端凌晨发布。
把阶段写清楚，是为了让下一班值班不用重复已经完成的探测，把时间留给真正未证明的环节。
放进方案里
把 Linux 网络命令写进运行手册时，先规定排障入口顺序：记录故障现象与时间 → 写已证明/未证明 → 在发起连接的同一网络位置取样 → 按 DNS、TCP、TLS、HTTP 选最小命令集。默认命令清单建议包括：ip addr、ip route、ss -tuln、目标机上的 dig/getent、面向业务端口的连通探测，以及带 -v 与必要时 --resolve 的 curl。抓包列为需审批的增强步骤，写明接口、过滤表达式、最长时长与包保存位置。手册应标明「谁有权在哪类主机执行哪级命令」，避免所有人拥有无限 tcpdump。
验收与值班结论必须带阶段范围。禁止只写「网络正常/不正常」。对于 HTTPS 服务，正式验收不得以 -k 或关闭校验的结果作为通过证据。脚本化探测要同时保存退出码、状态码与关键正文断言，并区分连接超时、TLS 失败与 5xx。告警自动开单时，模板字段应预留阶段结论，防止机器人只贴一句 ping 结果。
变更与发布窗口中，预先准备对照基线：解析答案、监听端口、一跳路由、一条约定探针。回滚或放量时按同一取样点复测，避免用笔记本电脑的成功覆盖服务器命名空间里的失败。教学地址与示例域名不得进入生产配置；文档中的样例需明确标注。对多入口服务，基线表按入口列出证书指纹与最近探针状态，防止遗漏节点。
交接模板固定字段：时间（含时区）、取样主机与网络平面、目标名与地址、已执行命令摘要、各阶段结论、原始日志摘录（脱敏）、下一步责任组。偶发问题附分组统计，不用单一百分比替代入口差异。若已证明 TCP/TLS 正常，下一步责任应写应用或网关，而不是继续留在「网络待查」队列。
安全与合规：仅在授权目标上探测；不在共享频道粘贴密钥、完整证书私钥或未脱敏的抓包；临时 hosts 与调试用校验跳过必须有拆除时间。对外演练使用的教学网段与真实客户网段隔离，防止示例脚本被误跑到生产。定期用桌面推演检查手册：给定「证书名不匹配」「SYN 超时」「503」3 种卡片，值班员应能在不打开搜索引擎的情况下说出前 3 条命令与证明边界。
10 小结：观测习惯就绪，走向流量入口（C12）与数据层（S22）
Linux 网络命令的价值，在于把抽象阶段变成可复现的观察。地址与路由说明出站起点，套接字说明本机监听与连接，ping/traceroute 提供有限的路径直觉，dig/getent 固定名字答案，curl 把 TLS 与 HTTP 阶段拉进同一条时间线。先对齐阶段，再选命令，结论才写得干净。
接下来，C12 会把流量如何在入口与后端之间分配讲清楚；S22 则从应用状态进入数据库的读写与事务直觉。两门课都会继续用到本章的取样与阶段化表达：入口健康检查失败时，你要能说明失败停在连接还是应用；数据库超时时，你要能区分网络路径与连接池等待。
下一课转向 S22 数据库入门：把本章验收过的结论带进后续主题，写成可检查的方案约束。