计算机网络排障笔记：从“网络卡顿”到分层定位

0. 核心原则

网络访问看起来只是“打开一个网站”，实际包含多层过程：

域名输入
  ↓
DNS 解析
  ↓
TCP 建立连接
  ↓
TLS 握手
  ↓
HTTP 请求与响应
  ↓
数据传输
  ↓
浏览器渲染

“网络卡顿”可能发生在任意一层。排障时需要从链路上逐层定位，避免只盯着单一原因。

1. 访问一个 HTTPS 网站的完整过程

以访问：

https://www.example.com

为例，简化流程如下：

1. 浏览器获得域名：www.example.com
2. 系统查询 DNS，获得 IP 地址
3. 客户端向目标 IP 的 443 端口建立 TCP 连接
4. 双方进行 TLS 握手，建立加密通道
5. 浏览器发送 HTTP 请求
6. 服务器返回响应头和响应体
7. 浏览器下载 HTML、CSS、JS、图片等资源
8. 浏览器渲染页面

不同阶段的故障表现不同：

---

## 2. DNS：域名解析层

DNS 的作用是：

```text
域名 → IP 地址

例如：

www.example.com → 93.184.216.34

2.1 DNS 慢的典型表现

DNS 层出现问题时，常见现象包括：

• 网页打开前先等待几秒；
• 第一次打开慢，刷新后变快；
• 同一个网站时好时坏；
• nslookup 查询慢或无响应；
• 部分域名可以访问，部分域名无法访问。

2.2 DNS 污染

DNS 污染指 DNS 查询得到错误结果，例如：

查询 A 域名
  ↓
返回错误 IP / 无效 IP / 被干扰的 IP
  ↓
连接失败或访问异常

DNS 污染通常影响“域名到 IP”的阶段。 如果 DNS 很快返回，连接也能建立，但页面下载很慢，问题更可能出现在后续链路。

2.3 常见 DNS 类型

3. fake-ip 模式

一些网络代理或分流工具会使用 fake-ip 模式。

3.1 fake-ip 的工作方式

普通 DNS：

系统查询 example.com
  ↓
DNS 返回真实 IP
  ↓
系统连接真实 IP

fake-ip：

系统查询 example.com
  ↓
本地 DNS 返回一个假 IP，例如 198.18.x.x
  ↓
系统连接这个假 IP
  ↓
本地网络工具根据原始域名进行规则分流

3.2 198.18.x.x 的含义

198.18.0.0/15 常用于网络测试和本地映射场景。

在 fake-ip 模式下，看到类似：

Address: 198.18.0.60

通常表示本地 fake-ip 映射生效。

这类地址通常不代表真实网站 IP，也不代表 DNS 污染。

3.3 fake-ip 的优点

fake-ip 的核心价值是保留域名信息。

因为很多分流规则依赖域名：

example.cn → 直连
example.com → 代理
某些开发平台 → 代理
某些国内平台 → 直连

如果系统只拿到真实 IP，分流工具更难判断原始访问目标。fake-ip 可以让网络工具知道：

当前连接来自哪个域名

4. 系统代理与虚拟网卡模式

网络工具常见两种接管方式：

系统代理
虚拟网卡 / TUN

4.1 系统代理

系统代理的典型链路：

应用程序
  ↓
系统代理设置
  ↓
本地代理端口
  ↓
网络工具
  ↓
目标网站

优点：

• 配置简单；
• 浏览器通常支持；
• 排查方便；
• 可以通过本地端口测试。

缺点：

• 某些软件不遵守系统代理；
• 部分命令行工具需要单独配置；
• UDP 流量处理能力有限；
• 应用行为差异较大。

4.2 虚拟网卡 / TUN

TUN 的典型链路：

应用程序
  ↓
系统网络栈
  ↓
虚拟网卡
  ↓
网络工具接管流量
  ↓
规则分流
  ↓
目标网站

优点：

• 接管能力更强；
• 对命令行工具、开发工具、部分桌面软件更友好；
• 可以处理更多系统级流量。

缺点：

• 配置更复杂；
• 容易受到路由、DNS、IPv6、MTU 影响；
• 出错时排查难度更高。

4.3 系统代理与 TUN 的对比测试

排障时可以构造两条路径：

路径 A：应用 → TUN → 网络工具 → 目标网站
路径 B：应用 → 本地代理端口 → 网络工具 → 目标网站

判断方法：

5. 端口监听

在 Windows 中可以使用：

netstat -ano | findstr ":端口号"

查看本地端口是否监听。

示例输出：

TCP    127.0.0.1:1053    0.0.0.0:0    LISTENING
TCP    0.0.0.0:7897      0.0.0.0:0    LISTENING

LISTENING 表示本地程序正在监听该端口。

注意：

端口监听成功
  ↓
只说明本地服务已启动
  ↓
还需要继续验证外部链路是否正常

端口监听只能证明“本机服务存在”，不能证明“访问目标网站一定快”。

6. curl 排障指标

curl 可以输出网络访问各阶段耗时。

常用命令：

curl.exe -L -o NUL -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} start:%{time_starttransfer} total:%{time_total} speed:%{speed_download}`n" https://www.example.com

常见指标含义：

6.1 如何解读 curl 指标

DNS 阶段慢

time_namelookup 很高

可能原因：

• DNS 服务器慢；
• DNS 查询被干扰；
• DNS 配置错误；
• 浏览器或系统 DNS 缓存异常。

TCP 连接慢

time_connect 很高

可能原因：

• 路由绕路；
• 网络拥塞；
• 丢包；
• 目标服务器连接慢；
• 中间链路不稳定。

TLS 握手慢或失败

time_appconnect 很高
TLS handshake failed
schannel failed
connection reset

可能原因：

• TLS 握手阶段丢包；
• 链路被重置；
• MTU 异常；
• 本地安全软件干扰；
• 系统时间异常；
• 出口链路不稳定。

首字节时间高

time_starttransfer 很高

可能原因：

• 目标服务器响应慢；
• 中间转发链路慢；
• 出口拥塞；
• 目标网站对当前链路不友好。

首字节正常，总耗时很高

time_starttransfer 较低
time_total 很高

可能原因：

• 下载吞吐低；
• 丢包导致重传；
• 数据传输阶段拥塞；
• 大响应体传输慢；
• MTU 或 MSS 问题。

这种情况通常需要关注传输质量，而不是只关注 DNS。

7. curl -I 与完整下载的区别

curl -I 只请求响应头：

curl.exe -I https://www.example.com

特点：

• 数据量小；
• 适合测试连接是否可达；
• 适合测试 HTTPS 是否能建立；
• 无法反映完整页面下载速度。

完整下载测试：

curl.exe -L -o NUL https://www.example.com

特点：

• 会下载响应体；
• 更接近真实网页访问；
• 能暴露吞吐、丢包、MTU、拥塞问题。

常见现象：

curl -I 成功
curl 完整下载很慢或失败

含义：

基础连接可达
传输阶段存在问题

8. 延迟、带宽、吞吐、抖动、丢包

8.1 延迟

延迟表示一个小数据包往返所需时间。

延迟低 → 响应更灵敏

延迟主要影响：

• 点击响应；
• 网页首屏；
• SSH；
• 游戏操作；
• 交互式服务。

8.2 带宽

带宽表示理论最大传输能力。

例如：

100 Mbps
500 Mbps
1 Gbps

带宽高只代表“管道理论上更宽”，实际速度还受目标服务器、链路拥塞、协议效率、丢包影响。

8.3 吞吐

吞吐表示实际传输速度。

网页、文件下载、视频加载更依赖吞吐。

吞吐低 → 页面资源加载慢
吞吐高 → 图片、视频、代码仓库下载更快

8.4 抖动

抖动表示延迟波动。

例如：

100ms → 120ms → 800ms → 150ms

抖动大会导致：

• 视频卡顿；
• 语音断续；
• 网页加载忽快忽慢；
• 游戏延迟不稳定。

8.5 丢包

丢包表示数据包没有成功到达。

丢包会导致：

• TCP 重传；
• 下载速度下降；
• TLS 握手失败；
• 连接被重置；
• 长连接断开。

9. 为什么面板延迟不能代表真实速度

很多网络工具会显示延迟，例如：

100ms
180ms
250ms

这些延迟通常来自某个固定测试地址或连通性检测。

面板延迟无法完整反映：

• 目标网站访问速度；
• 实际下载吞吐；
• 链路丢包；
• TLS 稳定性；
• 高峰期拥塞；
• 不同网站的链路质量。

更可靠的判断方式：

对目标网站做真实请求测试
观察 start、total、speed_download
多次重复测试

10. TLS 握手

HTTPS 依赖 TLS 建立加密通道。

简化流程：

客户端发起 TLS 握手
  ↓
服务器返回证书和加密参数
  ↓
客户端验证证书
  ↓
双方协商密钥
  ↓
开始加密通信

TLS 问题常见表现：

SSL/TLS connection failed
failed to receive handshake
connection reset
schannel error

可能原因：

• 链路丢包；
• 中途连接被重置；
• MTU 设置异常；
• 本地安全软件拦截；
• 系统时间错误；
• 目标网站链路不稳定；
• 转发路径质量差。

11. MTU 与 MSS

MTU 表示单个网络包最大大小。

可以理解为：

每个包最大能装多少数据

常见以太网 MTU：

1500

在虚拟网卡、隧道、转发、加密链路中，实际可用 MTU 可能变小。

11.1 MTU 问题的典型表现

• 小请求正常；
• 大页面慢；
• 大文件下载失败；
• TLS 握手偶发失败；
• 网页加载到一半卡住；
• 连接被 reset。

原因：

包太大
  ↓
中间链路无法正常传输
  ↓
分片或丢弃
  ↓
重传、卡顿、失败

11.2 排障思路

如果出现：

curl -I 成功
完整下载慢或 TLS 失败

可以考虑检查：

• MTU；
• TUN 栈；
• 丢包；
• 出口链路稳定性。

常见测试值：

MTU 1400
MTU 1380

具体值需要结合网络环境测试。

12. IPv6

IPv6 是新一代 IP 协议。

IPv6 本身具有长期价值，但排障阶段经常建议先关闭，原因是它会增加变量。

可能情况：

系统优先尝试 IPv6
  ↓
IPv6 路由不通或质量差
  ↓
等待超时
  ↓
回退 IPv4

表现：

• 网页先卡几秒；
• 部分网站偶发失败；
• 某些应用连接慢；
• 同一网站表现不稳定。

排障建议：

先关闭 IPv6
确认 IPv4 链路稳定
再决定是否开启 IPv6

13. QUIC / HTTP/3

QUIC 是基于 UDP 的传输协议，HTTP/3 基于 QUIC。

优点：

• 连接建立快；
• 移动网络切换体验好；
• 理论上减少延迟。

潜在问题：

• 部分网络环境 UDP 不稳定；
• 某些代理或虚拟网卡对 UDP 支持不佳；
• 浏览器使用 QUIC 时可能出现网页卡顿；
• 命令行工具正常，浏览器体验异常。

典型现象：

curl 正常
浏览器慢
视频网站卡
搜索引擎加载异常

排查方向：

• 浏览器 QUIC 设置；
• 浏览器安全 DNS；
• 插件；
• 缓存；
• 长连接；
• UDP 处理能力。

14. 浏览器与命令行结果不一致

可能出现：

curl 正常
浏览器慢

常见原因：

命令行测试通常只测试单个 URL。浏览器访问一个网页时，会同时访问多个资源域名：

HTML
CSS
JS
图片
字体
API
统计脚本
CDN 资源

因此浏览器体感更容易受整体链路影响。

15. 缓存与旧连接

网络工具、系统、浏览器都会缓存状态。

常见缓存包括：

DNS 缓存
fake-ip 映射
路由状态
TCP 连接
TLS 会话
HTTP/2 长连接
浏览器缓存

改配置后，如果不清理旧状态，测试结果容易混乱。

推荐流程：

修改配置
  ↓
保存配置
  ↓
重启网络工具内核
  ↓
清空连接
  ↓
刷新系统 DNS 缓存
  ↓
关闭浏览器所有窗口
  ↓
重新打开浏览器
  ↓
重新测试

Windows 刷新 DNS 缓存：

ipconfig /flushdns

16. 分层排障流程

第一步：确认本地服务状态

检查本地端口监听：

netstat -ano | findstr ":端口号"

判断：

无 LISTENING → 本地服务未启动或端口配置错误
有 LISTENING → 继续测试外部链路

第二步：确认 DNS 形态

使用：

nslookup example.com

可能结果：

真实公网 IP → 普通 DNS 模式
198.18.x.x → fake-ip 模式
无响应 → DNS 服务或配置异常

第三步：测试小请求

curl.exe -I https://www.example.com

作用：

测试连接是否可达
测试 HTTPS 是否能建立
测试响应头是否能返回

第四步：测试完整下载

curl.exe -L -o NUL -w "start:%{time_starttransfer} total:%{time_total} speed:%{speed_download}`n" https://www.example.com

作用：

测试真实传输速度
判断吞吐、丢包、拥塞、MTU 问题

第五步：对比不同路径

如果存在 TUN 和本地代理端口，可以分别测试：

curl.exe -L -o NUL -w "TUN start:%{time_starttransfer} total:%{time_total}`n" https://www.example.com

curl.exe -x http://127.0.0.1:端口号 -L -o NUL -w "Proxy start:%{time_starttransfer} total:%{time_total}`n" https://www.example.com

判断：

17. 常见现象与定位表

18. 推荐的排障顺序

1. 确认网络工具正在运行
2. 确认本地端口监听
3. 确认 DNS 返回形态
4. 测试 curl -I 小请求
5. 测试完整下载
6. 对比 TUN 和本地代理端口
7. 查看日志中的 timeout、reset、TLS、DNS 错误
8. 清理缓存与旧连接
9. 对比不同目标网站
10. 判断 DNS、路由、MTU、浏览器、出口链路中的主要矛盾

19. 核心经验总结

• DNS 只负责域名解析，不能代表完整网速。
• fake-ip 返回 198.18.x.x 通常表示本地分流模式生效。
• 面板延迟只能代表小规模连通性测试，不能代表实际网页体验。
• curl -I 只能证明小请求可达，完整下载测试更接近真实体验。
• time_total 和 speed_download 更能反映体感速度。
• TLS 握手失败通常需要关注链路稳定性、丢包、MTU 和中间转发路径。
• TUN 和系统代理是两条不同路径，排障时需要分开测试。
• 浏览器慢可能来自 QUIC、插件、缓存、安全 DNS 或多资源加载。
• 改配置后需要重启内核、清空连接、刷新 DNS、重启浏览器。
• 网络排障应采用分层测试和 A/B 对比，避免凭感觉判断。

20. 一句话框架

先看本地服务是否启动，
再看 DNS 形态是否正常，
再看小请求是否可达，
再看完整下载是否稳定，
再对比不同接管路径，
最后定位到 DNS、路由、TLS、MTU、浏览器或出口链路。