这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 本附录按生产排障场景组织常用命令和检查项。命令以 Linux 为主线，不同发行版、云平台和内核版本的输出可能有差异；涉及厂商能力时，以当前环境文档为准。
1. 基础信息收集
网络故障先收集事实，再建立假设。不要在未确认拓扑前直接改参数。
uname -a
cat /etc/os-release
ip -br addr
ip -d link
ip route
ip -6 route
ip neigh
ss -lntup
ss -s
ss -antp
ethtool eth0
ethtool -S eth0
ethtool -i eth0
常用组合：
ip -br addr show eth0
ip route get 10.20.30.40
ss -lntp | grep ':443'
ss -tan state established '( sport = :9000 or dport = :9000 )'
解读要点：
| 输出 | 含义 | 常见下一步 |
|---|---|---|
ip route get 命中默认路由 |
走网关 | 检查网关和安全组 |
ip neigh 为 FAILED |
邻居解析失败 | 检查 VLAN、ARP、防火墙 |
ss 只有 LISTEN，无连接 |
服务未收到请求 | 检查上游和负载均衡 |
ethtool -S 错包增长 |
链路质量问题 | 检查双工、速率、线缆和交换机 |
2. 连通性与路径诊断
ping -c 4 10.20.30.40
ping -c 4 2001:db8::1
ping -c 4 -M do -s 1472 10.20.30.40
traceroute -n 10.20.30.40
traceroute -6 -n 2001:db8::1
mtr -rwzc 100 10.20.30.40
tracepath -n 10.20.30.40
nc -vz 10.20.30.40 3306
nc -vl 0.0.0.0 9000
ping 不通不代表服务不可用，可能是 ICMP 被策略禁止。端口探测和应用层探测要分开：
nc -vz db.internal 5432
curl -v telnet://db.internal:5432
curl -v http://app.internal:8080/healthz
路径质量优先看 mtr：
mtr -rwzc 100 -i 0.2 example.com
判断要点：
| 现象 | 常见原因 | 下一步 |
|---|---|---|
| 只在某一跳丢包 | 单节点或链路异常 | 对比多源拨测 |
| 从某一跳后全部丢包 | 路径中断或策略限速 | 检查运营商或云网络 |
| 延迟阶梯异常 | 绕行、跨境、拥塞 | 结合路由和地域 |
| 丢包且 TCP 重传高 | 真实影响流量 | 看重传统计和抓包 |
3. TCP 状态速查
统计状态：
ss -ant | awk 'NR>1 {count[$1]++} END {for (s in count) print s, count[s]}'
ss -ant state time-wait | wc -l
ss -ant state close-wait | wc -l
ss -antp state close-wait
ss -antp state established
常用状态：
| 状态 | 方向 | 常见含义 |
|---|---|---|
LISTEN |
服务端 | 等待连接 |
SYN-SENT |
客户端 | 已发出 SYN，未收到 SYN-ACK |
SYN-RECV |
服务端 | 收到 SYN，等待 ACK |
ESTABLISHED |
双向 | 连接建立 |
FIN-WAIT-1 |
主动关闭 | 已发 FIN |
CLOSE-WAIT |
被动关闭 | 收到 FIN，应用未关闭 |
TIME-WAIT |
主动关闭 | 等待旧报文消散 |
LAST-ACK |
被动关闭 | 等待最后一个 ACK |
3.1 TIME_WAIT
特征：
主动关闭方大量 TIME_WAIT
端口多为本机临时端口
连接数随短连接创建速率波动
判断顺序：
先确认业务影响
-> 检查临时端口是否耗尽
-> 应用侧使用连接池和长连接
-> 客户端启用合理的连接复用
-> 扩容或调整业务模型
-> 最后评估内核参数
不建议盲目开启 tcp_tw_reuse。Linux 参数语义在不同内核版本有差异，必须先阅读当前内核文档并测试。
3.2 CLOSE_WAIT
特征：
被动关闭方堆积
对端已 FIN，本端连接保持 CLOSE_WAIT
进程 FD 往往同步增长
常见原因：
- 应用没有关闭 socket；
- 连接池归还逻辑缺失；
- 异常分支漏掉清理；
- 异步回调丢失；
- HTTP 客户端未消费完响应或未释放对象。
排查：
ss -antp state close-wait
lsof -nP -iTCP -sTCP:CLOSE-WAIT
ls -l /proc/<pid>/fd | wc -l
处理点在应用代码。重启只用于止血，根因必须回到资源关闭路径。
4. DNS 排查
dig www.example.com
dig +trace www.example.com
dig @8.8.8.8 www.example.com A
dig www.example.com AAAA
dig www.example.com CNAME
dig -x 203.0.113.10
dig +short www.example.com
dig +noall +answer www.example.com
resolvectl status
resolvectl query www.example.com
cat /etc/resolv.conf
cat /etc/hosts
sudo tcpdump -i any -nn port 53
常见问题：
| 现象 | 可能原因 | 检查 |
|---|---|---|
NXDOMAIN |
域名不存在或拼写错误 | 确认域名和权威记录 |
SERVFAIL |
DNSSEC、上游异常、递归失败 | 换 resolver、看 DNSSEC |
| 解析结果旧 | 缓存未过期 | 查看 TTL，必要时清缓存 |
| 只在某些节点错 | 本地 resolver 或 hosts 差异 | 对比 /etc/hosts |
| IPv6 解析正常但连接失败 | IPv6 路由不通 | ip -6 route 和端口探测 |
| 偶发失败 | resolver 限流或超时 | 统计失败率并抓包 |
应用侧要设置解析超时和重试，不要假设 DNS 永远可用。
5. HTTP 与 curl
curl -v http://example.com/
curl -v https://example.com/
curl -I https://example.com/
curl -o /dev/null -s https://example.com/
curl --resolve api.example.com:443:192.0.2.10 \
-v https://api.example.com/healthz
curl -x http://proxy.internal:3128 \
-v https://example.com/
curl --connect-timeout 2 --max-time 5 \
-v https://example.com/
阶段耗时：
curl -o /dev/null -s -w '\n\
dns=%{time_namelookup}\n\
connect=%{time_connect}\n\
tls=%{time_appconnect}\n\
ttfb=%{time_starttransfer}\n\
total=%{time_total}\n\
http_code=%{response_code}\n' \
https://example.com/
| 指标 | 覆盖阶段 | 主要排查 |
|---|---|---|
time_namelookup |
DNS | resolver、缓存 |
time_connect |
TCP | 路由、LB、SYN 丢包 |
time_appconnect |
TLS | 证书、协商、算法 |
time_starttransfer |
服务端首包 | 应用排队和后端耗时 |
time_total |
全请求 | 响应体和传输 |
常用状态码：
| 状态码 | 含义 | 网络排查方向 |
|---|---|---|
| 301 / 302 / 307 / 308 | 重定向 | 跳转次数、协议和路径 |
| 400 | 请求语法错误 | 客户端参数和编码 |
| 401 / 403 | 认证或授权失败 | 凭证、WAF、访问控制 |
| 404 | 资源不存在 | 路由和 upstream 路径 |
| 408 | 请求超时 | 客户端发送慢 |
| 429 | 限流 | 限流策略和重试退避 |
| 499 | 客户端主动断开 | 客户端超时、用户取消 |
| 500 / 502 / 503 / 504 | 服务端或网关错误 | upstream、容量、超时 |
6. TLS 证书排查
openssl s_client -connect example.com:443 -servername example.com
openssl s_client -connect example.com:443 -servername example.com \
-showcerts
openssl s_client -connect example.com:443 -servername example.com \
2>/dev/null | openssl x509 -noout -dates -subject -issuer
openssl x509 -in server.crt -noout -dates -subject -issuer \
-ext subjectAltName
openssl x509 -in server.crt -pubkey -noout | openssl sha256
openssl pkey -in server.key -pubout | openssl sha256
openssl verify -CAfile ca.crt server.crt
openssl s_client -connect example.com:443 -servername example.com \
-tls1_2
openssl s_client -connect example.com:443 -servername example.com \
-tls1_3
常见错误：
| 现象 | 常见原因 | 处理 |
|---|---|---|
certificate has expired |
证书过期 | 轮换并更新监控 |
hostname mismatch |
SAN 不匹配 | 补齐域名或改 SNI |
unable to get local issuer certificate |
缺中间证书或信任库问题 | 补全链 |
| 私钥不匹配 | 混用文件 | 重新绑定 |
| 旧客户端失败 | 协议或算法不兼容 | 评估兼容策略 |
| 只有 SNI 场景失败 | 未配置默认证书 | 配置默认或正确 SNI |
7. TCP 参数与重传
sysctl net.ipv4.ip_local_port_range
sysctl net.core.somaxconn
sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.ipv4.tcp_syncookies
sysctl net.ipv4.tcp_fin_timeout
sysctl net.ipv4.tcp_keepalive_time
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
ss -ti
ss -ti dst 10.20.30.40
netstat -s | grep -Ei 'retrans|listen|overflow|reset'
nstat -az | grep -Ei 'retrans|listen|drop'
关键观察：
| 指标 | 问题信号 |
|---|---|
Retrans 持续增长 |
丢包或 RTT 抖动 |
LISTEN 队列高 |
accept 积压 |
LISTEN overflow 增长 |
backlog 或应用 accept 慢 |
| SYN 重试多 | 握手阶段丢包 |
| RST 突增 | 主动拒绝、进程退出、安全策略 |
cwnd 长期偏低 |
拥塞窗口受限 |
调优必须先定位瓶颈。常见误判是把应用排队、GC 停顿、后端慢或容量不足当成网络问题。
8. MTU 与分片
ip link show eth0
ip link set dev eth0 mtu 1500
ping -c 4 -M do -s 1472 10.20.30.40
tracepath -n 10.20.30.40
ip route get 10.20.30.40
常用判断：
以太网 MTU 1500
IPv4 header 20
ICMP header 8
不分片最大 ICMP payload = 1500 - 20 - 8 = 1472
隧道、VPN、云 overlay 和容器网络可能降低有效 MTU。小包能通、大包卡住时，优先怀疑 MTU 或 PMTUD。
排查：
- 对比两端 MTU；
- 找路径最小 MTU；
- 检查 ICMP “fragmentation needed” 是否被丢弃；
- 检查 overlay 封装开销；
- 抓包看分片或卡住的字节位置。
9. NAT、conntrack 与防火墙
sudo iptables -t nat -L -n -v
sudo nft list ruleset
sudo conntrack -L
sudo conntrack -L -p tcp --state ESTABLISHED
sudo conntrack -C
sudo conntrack -S
sysctl net.netfilter.nf_conntrack_max
sysctl net.netfilter.nf_conntrack_count
dmesg | grep -i conntrack
常见问题：
| 现象 | 可能原因 |
|---|---|
| 长连接空闲后断开 | NAT 或 LB 空闲超时 |
| 并发高时新建失败 | conntrack 表满 |
| 返回包不到应用 | 会话状态或反向规则 |
| 偶发无法访问 | SNAT 端口耗尽 |
| 安全策略调整后断开 | 双向路径未同时放通 |
治理建议：
- 长连接开启应用层心跳；
- 监控 conntrack 使用率；
- 评估 NAT 网关并发和端口；
- 规则变更前记录会话影响；
- 云安全组、主机防火墙、CNI 策略分层排查。
10. 负载均衡与代理
以 Nginx 为例：
nginx -t
nginx -T
curl -v http://127.0.0.1/healthz
tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log
curl -v --resolve api.example.com:8080:10.20.30.40 \
http://api.example.com/healthz
重点日志字段：
request_time Nginx 处理请求总耗时
upstream_time upstream 响应耗时
upstream_status 后端状态码
upstream_addr 实际后端
request_length 请求大小
bytes_sent 响应大小
排障路径：
客户端
-> DNS
-> CDN / WAF
-> LB
-> Ingress / Nginx
-> upstream
-> 数据库或下游
每一跳都要能回答：
- 请求是否到达；
- 转发到哪个实例；
- 超时是多少；
- 错误码是谁产生；
- 连接是否复用；
- 是否触发健康检查摘除；
- 发布或配置是否刚变更。
11. CDN 与缓存
curl -I https://www.example.com/static/a.js
curl -H 'Cache-Control: no-cache' \
-I https://www.example.com/static/a.js
dig +short www.example.com
curl -w '%{remote_ip}\n' -o /dev/null -s https://www.example.com
重点响应头：
| Header | 含义 |
|---|---|
Cache-Control |
缓存策略 |
Age |
对象在边缘已缓存时间 |
X-Cache |
常见命中状态头，具体语义以厂商为准 |
ETag / Last-Modified |
协商缓存 |
Vary |
按请求维度区分缓存 |
CDN-Cache-Control |
部分厂商的边缘缓存策略 |
排查顺序：
- 确认用户解析到的边缘节点；
- 检查回源源站；
- 检查缓存键是否忽略或包含了错误参数；
- 检查
Vary是否导致命中率低； - 检查源站是否返回不可缓存状态；
- 检查证书和 HTTP 协议；
- 必要时刷新缓存并验证。
12. Kubernetes 与 CNI 排障
基础检查：
kubectl get nodes -o wide
kubectl get pods -o wide
kubectl describe pod <pod>
kubectl logs <pod> -c <container>
kubectl exec -it <pod> -- sh
kubectl get svc,endpoints
kubectl get endpointslice
kubectl get ingress
kubectl get networkpolicy
kubectl run net-tool --rm -it \
--image=nicolaka/netshoot -- sh
容器内探测：
ip addr
ip route
cat /etc/resolv.conf
nc -vz <service-name> <port>
curl -v http://<service-name>:<port>/healthz
分层判断：
| 测试 | 通过含义 |
|---|---|
| Pod IP 直连通 | Pod 网络基本可用 |
| Service 名称解析通 | DNS 可用 |
| Service ClusterIP 通 | 服务转发规则可用 |
| NodePort 通 | 节点转发和外部防火墙可用 |
| Ingress 域名通 | 入口控制器和证书可用 |
常见原因：
- Endpoint 为空：selector、标签、探针或 readiness 不匹配；
- DNS 失败：CoreDNS、search 域、
ndots、Service 命名空间； - NetworkPolicy 拒绝：方向、端口、命名空间选择器；
- CNI 未就绪：节点组件、网段、路由或封装异常；
- SNAT 或 masquerade 行为不符合预期；
- conntrack 表满或会话超时；
- 入口控制器配置或证书错误。
13. 抓包过滤器
sudo tcpdump -D
sudo tcpdump -i eth0 -nn
sudo tcpdump -i any -nn
sudo tcpdump -i eth0 -nn host 10.20.30.40
sudo tcpdump -i eth0 -nn port 443
sudo tcpdump -i eth0 -nn src 10.20.30.40
sudo tcpdump -i eth0 -nn dst 10.20.30.40
sudo tcpdump -i eth0 -nn \
'host 10.20.30.40 and (port 80 or port 443)'
sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0'
sudo tcpdump -i eth0 -nn \
'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn|tcp-ack'
sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0'
sudo tcpdump -i any -nn port 53
sudo tcpdump -i any -nn icmp or icmp6
sudo tcpdump -i any -nn arp
sudo tcpdump -i any -nn 'net 10.20.0.0/16'
sudo tcpdump -i eth0 -nn -s 0 \
'host 10.20.30.40 and port 443' \
-w /tmp/network.pcap
建议控制范围：
先选一个接口
-> 加 host / port / net
-> 加包数量限制 -c
-> 加快照长度限制
-> 输出到 pcap
-> 传回分析
抓包会包含敏感信息。生产操作要有审批、脱敏、保存期限和最小捕获范围。
14. 监控指标基线
基础指标：
| 类型 | 指标 |
|---|---|
| 可用性 | 成功率、错误率、拨测可用率 |
| 延迟 | DNS、TCP、TLS、TTFB、P50 / P95 / P99 |
| 容量 | 带宽、PPS、并发连接、新建连接 |
| TCP | 重传、RST、队列溢出、窗口 |
| 资源 | conntrack、网卡丢包、软中断 |
| 安全 | 拒绝数、证书剩余天数、异常流量 |
| 入口 | upstream 状态、健康检查、5xx |
告警要能回答：
- 哪个域名或服务受影响；
- 哪个地域和入口节点；
- 从什么时候开始；
- 影响多少请求；
- 是否伴随发布或配置变更；
- 下一步看哪个面板。
15. 网络事故报告模板
# 网络事故报告
## 1. 摘要
- 事故时间：
- 恢复时间：
- 影响范围：
- 影响指标：
- 当前状态：
## 2. 时间线
- 统一使用 UTC 或本地时间：
- 每个时间点写事实与证据：
- 止血动作：
- 根因确认：
## 3. 影响评估
- 请求量：
- 失败率：
- 延迟变化：
- 用户或商户影响：
- 资损评估：
## 4. 证据链
- DNS：
- 路径：
- 连接：
- 证书：
- HTTP：
- 抓包：
- 配置变更：
## 5. 根因
- 直接原因：
- 促成条件：
- 为什么监控没有提前发现：
- 为什么防护没有阻止：
## 6. 处置评估
- 做对的事：
- 延误点：
- 误判点：
- 可自动化点：
## 7. 后续行动
| 行动 | 负责人 | 截止时间 | 优先级 | 验证方式 |
|---|---|---|---|---|
## 8. 经验沉淀
- 新监控：
- 新巡检：
- 新预案：
- 架构改进：
16. 上线前检查清单
域名与入口：
[ ] DNS TTL 与切换方案已确认
[ ] 证书 SAN、证书链和有效期正确
[ ] HTTPS 策略已测试
[ ] 回源地址和备用入口明确
[ ] CDN 缓存键与刷新方案明确
超时与重试：
[ ] 连接超时、读超时、总超时分层设置
[ ] 重试只用于幂等请求
[ ] 重试有退避和抖动
[ ] 熔断和降级策略明确
[ ] 上游最大并发受限
负载与容量：
[ ] 带宽、PPS、连接数有预算
[ ] 健康检查策略正确
[ ] 摘流与恢复机制验证
[ ] 优雅停机验证
[ ] 限流阈值和排队行为明确
云原生网络：
[ ] NetworkPolicy 意图测试通过
[ ] DNS policy 和 search 域确认
[ ] CNI 网段与集群规模匹配
[ ] conntrack 容量监控
[ ] 长连接心跳和空闲超时匹配
观测与预案：
[ ] 分阶段延迟指标采集
[ ] 重传、RST、队列溢出监控
[ ] 证书过期告警
[ ] 多地域拨测
[ ] 抓包和变更审批流程
[ ] 回滚与演练记录
17. 十分钟排障路径
1. 确认影响面：哪个服务、哪个地域、多少用户
2. 确认变更：发布、证书、路由、安全组、DNS
3. 本机进程：进程在、端口监听、健康检查通过
4. 连接路径：DNS -> TCP -> TLS -> HTTP 分层探测
5. 跳过入口：直连后端，判断问题在入口还是服务
6. 查状态：SYN 积压、CLOSE_WAIT、RST、重传
7. 查路径：mtr、MTU、conntrack、防火墙
8. 看证据：访问日志、错误日志、抓包、监控
9. 止血：回滚、切流、扩容、限流、重启
10. 复盘：沉淀监控、预案和自动化检查
18. 版本差异提醒
| 主题 | 常见差异 |
|---|---|
ip / ss |
老系统可能仍以 ifconfig / netstat 为主 |
| TCP 参数 | 内核版本、发行版和默认值可能不同 |
| DNS 管理 | systemd-resolved、NetworkManager、静态配置并存 |
| 防火墙 | iptables、nftables、firewalld、云安全组语义不同 |
| CNI | overlay、路由、NetworkPolicy 实现差异较大 |
| HTTP | 网关和客户端对 HTTP/2、HTTP/3 支持不同 |
| TLS | 协议、算法、证书链和 SNI 行为受实现影响 |
| 云网络 | NAT 网关、LB、弹性网卡能力以厂商文档为准 |
遇到环境相关行为，优先使用当前环境文档和实验结果，不套用过期结论。