计算机网络排障笔记

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. 服务器返回 HTTP 响应头和响应体；
7. 浏览器继续下载 HTML、CSS、JavaScript、图片、字体等资源；
8. 浏览器解析资源并渲染页面。

不同阶段出现问题时，通常会表现出不同现象：

2. DNS：域名解析层

DNS 的主要作用是将域名转换为 IP 地址：

域名 → IP 地址

例如：

www.example.com → 93.184.216.34

2.1 DNS 过慢的表现

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

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

2.2 DNS 污染

DNS 污染是指 DNS 查询返回了错误、无效或被干扰的结果。

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

DNS 污染主要影响“域名到 IP”的解析阶段。

如果 DNS 很快返回结果，TCP 连接也能正常建立，但页面下载依然很慢，那么问题更可能出现在后续的 TCP、TLS、数据传输或浏览器阶段。

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 映射。

在 Fake IP 模式下看到：

Address: 198.18.0.60

通常表示本地 Fake IP 映射已经生效。

这类地址：

• 通常不是真实网站的公网 IP；
• 不一定表示 DNS 污染；
• 需要由本地代理工具负责后续映射和转发。

3.3 Fake IP 的价值

Fake IP 的核心价值是保留域名信息。

许多代理规则依赖域名，而不是单纯依赖目标 IP：

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

如果应用程序只连接真实 IP，代理工具可能难以确定原始访问域名。

Fake IP 可以让网络工具知道：当前连接最初来自哪个域名，从而更准确地执行分流规则。

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

网络工具常见的流量接管方式主要有两种：

系统代理
虚拟网卡 / TUN

4.1 系统代理

系统代理的典型链路：

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

优点

• 配置相对简单；
• 浏览器通常能够直接使用；
• 排查过程比较直观；
• 可以通过本地代理端口进行显式测试。

缺点

• 某些应用程序不遵循系统代理设置；
• 部分命令行工具需要单独配置代理；
• 对 UDP 流量的处理能力有限；
• 不同应用程序的代理行为可能不一致。

4.2 虚拟网卡 / TUN

TUN 模式的典型链路：

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

优点

• 流量接管能力更强；
• 对命令行工具、开发工具和桌面软件更友好；
• 可以处理更多系统级流量；
• 不依赖应用程序主动支持代理。

缺点

• 配置更加复杂；
• 容易受到路由、DNS、IPv6 和 MTU 的影响；
• 出现问题时排查难度更高；
• 可能与其他虚拟网卡、安全软件或 VPN 发生冲突。

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 表示本地程序正在监听该端口。

但需要注意：端口监听成功,只能说明本地服务已经启动,不能证明外部链路一定正常

因此，端口监听检查只能作为第一步。

后续还需要继续测试：

• DNS 是否正常；
• TCP 是否可连接；
• TLS 是否能握手；
• HTTP 是否能响应；
• 实际数据传输是否稳定。

6. 使用 curl 进行分阶段排障

curl 可以输出一次网络请求各阶段的耗时。

Windows PowerShell 示例：

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

常见指标如下：

需要注意，这些时间通常是从请求开始累计计算的。

例如：

DNS 实际耗时 ≈ time_namelookup
TCP 实际耗时 ≈ time_connect - time_namelookup
TLS 实际耗时 ≈ time_appconnect - time_connect
服务器等待时间 ≈ time_starttransfer - time_appconnect
数据下载时间 ≈ time_total - time_starttransfer

7. curl 指标

7.1 DNS 阶段较慢

典型表现：

time_namelookup 很高

可能原因：

• DNS 服务器响应缓慢；
• DNS 查询受到干扰；
• DNS 配置错误；
• 系统或浏览器 DNS 缓存异常；
• DoH 或 DoT 服务不可达；
• IPv6 DNS 路径异常。

7.2 TCP 连接较慢

典型表现：

time_connect 很高

可能原因：

• 路由绕行；
• 网络拥塞；
• 丢包；
• 目标服务器连接响应较慢；
• 中间链路不稳定；
• 防火墙丢弃或延迟处理连接请求。

7.3 TLS 握手较慢或失败

典型表现：

time_appconnect 很高
TLS handshake failed
schannel failed
connection reset

可能原因：

• TLS 握手阶段发生丢包；
• 中间链路主动重置连接；
• MTU 设置异常；
• 本地安全软件或 HTTPS 扫描功能干扰；
• 系统时间错误；
• 证书验证异常；
• 出口链路质量较差。

7.4 首字节时间较高

典型表现：

time_starttransfer 很高

可能原因：

• 目标服务器处理请求较慢；
• 中间转发链路延迟较高；
• 出口拥塞；
• 代理节点负载较高；
• 目标网站对当前出口链路不友好；
• 请求发生重定向或鉴权处理。

7.5 首字节正常，但总耗时很高

典型表现：

time_starttransfer 较低
time_total 很高

可能原因：

• 实际下载吞吐较低；
• 丢包导致 TCP 重传；
• 数据传输阶段发生拥塞；
• 响应体较大；
• MTU 或 MSS 配置异常；
• 目标服务器限速；
• 代理节点带宽不足。

这种情况应重点关注数据传输质量，而不是只检查 DNS。

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

8.1 只请求响应头

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

-I 表示只请求响应头，不下载完整响应体。

特点：

• 数据量较小；
• 适合测试目标是否可达；
• 适合检查 HTTPS 是否能够建立；
• 适合观察响应状态码和响应头；
• 无法准确反映完整页面的下载速度。

8.2 完整下载测试

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

其中：

• -L：自动跟随重定向；
• -o NUL：丢弃下载内容，只保留测试过程。

特点：

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

常见现象：

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

通常说明：

基础连接可以建立
  ↓
小规模数据传输正常
  ↓
大量数据传输阶段存在问题

此时应重点检查：

• 吞吐；
• 丢包；
• MTU；
• MSS；
• TCP 重传；
• 节点负载；
• 出口链路质量。

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

9.1 延迟

延迟表示一个数据包从发送端到接收端所需的时间，实际测试中经常关注往返时延 RTT。

延迟低 → 交互响应更快

延迟主要影响：

• 点击响应；
• 网页首屏；
• SSH；
• 远程桌面；
• 在线游戏；
• 交互式服务。

9.2 带宽

带宽表示链路理论上的最大传输能力。

例如：

100 Mbps
500 Mbps
1 Gbps

带宽高只说明理论管道较宽。

实际速度还会受到以下因素影响：

• 目标服务器性能；
• 网络拥塞；
• 协议开销；
• 代理节点负载；
• 丢包；
• TCP 拥塞控制；
• 路由质量。

9.3 吞吐

吞吐表示实际能够达到的数据传输速度。

网页、文件下载、视频加载等场景更依赖实际吞吐。

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

9.4 抖动

抖动表示延迟随时间发生波动。

例如：

100 ms → 120 ms → 800 ms → 150 ms

抖动过大可能导致：

• 视频卡顿；
• 语音断续；
• 网页加载忽快忽慢；
• 游戏延迟不稳定；
• 长连接体验较差。

9.5 丢包

丢包表示部分数据包未能成功到达目标。

丢包可能导致：

• TCP 重传；
• 下载速度下降；
• TLS 握手失败；
• 连接被重置；
• 长连接断开；
• 视频和语音质量下降。

少量持续丢包也可能显著影响 TCP 吞吐。

10.面板延迟不能代表真实速度

许多网络工具会显示节点延迟，例如：

100 ms
180 ms
250 ms

这些延迟通常来自：

• 固定测试地址；
• 连通性检测 URL；
• 小数据包请求；
• TCP 或 HTTP 探测。

它们无法完整反映：

• 目标网站的实际访问速度；
• 大文件下载吞吐；
• 链路丢包；
• TLS 稳定性；
• 高峰期拥塞；
• 节点实际负载；
• 不同网站的路由差异。

因此，更可靠的测试方式是：

对真实目标网站发起请求
  ↓
观察 start、total 和 speed_download
  ↓
重复测试多次
  ↓
比较不同节点和不同路径

11. TLS 握手

HTTPS 依赖 TLS 建立加密通信通道。

简化过程如下：

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

TLS 问题的常见表现：

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

可能原因：

• 链路丢包；
• 中间设备重置连接；
• MTU 设置异常；
• 本地安全软件进行 HTTPS 拦截；
• 系统时间错误；
• 证书链不完整；
• SNI 或域名信息异常；
• 出口转发路径质量较差。

12. MTU 与 MSS

12.1 MTU

MTU 表示单个网络层数据包允许承载的最大长度。

可以简单理解为：

每个 IP 包最多可以装多少数据

常见以太网 MTU：

1500

但在以下环境中，实际可用 MTU 可能会变小：

• 虚拟网卡；
• VPN；
• 代理隧道；
• PPPoE；
• 加密封装；
• 多层转发；
• 云网络。

12.2 MSS

MSS 表示 TCP 报文段中允许承载的最大数据长度。

在典型 IPv4 TCP 环境下：

MSS ≈ MTU - IP 头部 - TCP 头部

例如：

1500 - 20 - 20 = 1460

12.3 MTU 问题的典型表现

• 小请求正常；
• 大页面加载缓慢；
• 大文件下载失败；
• TLS 握手偶发失败；
• 网页加载到一半卡住；
• 连接被重置；
• 某些网站正常，某些网站异常。

可能过程：

数据包过大
  ↓
中间链路无法正常传输
  ↓
需要分片或发送 ICMP 通知
  ↓
通知被拦截或分片失败
  ↓
数据包被丢弃
  ↓
发生重传、卡顿或连接失败

12.4 排障思路

如果出现：

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

可以重点检查：

• TUN MTU；
• 系统网卡 MTU；
• TCP MSS；
• 链路丢包；
• 路径 MTU 发现；
• 代理隧道封装开销；
• 出口链路稳定性。

常见尝试值：

MTU 1400
MTU 1380

具体值应根据实际网络环境测试，不应盲目固定。

13. IPv6

IPv6 是新一代 IP 协议，具有长期价值。

但在排障阶段，IPv6 会增加一条额外的网络路径，因此有时可以临时关闭，以减少变量。

一种常见异常过程是：

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

可能表现为：

• 网页打开前卡顿几秒；
• 部分网站偶发失败；
• 某些应用连接缓慢；
• 同一网站表现不稳定；
• IPv4 测试正常，但默认访问异常。

排障时可以采用：

临时关闭 IPv6
  ↓
确认 IPv4 链路是否稳定
  ↓
再单独检查 IPv6 路由和 DNS
  ↓
决定是否重新启用 IPv6

关闭 IPv6 更适合作为定位问题的临时手段，不宜在未确认原因时永久关闭。

14. QUIC 与 HTTP/3

QUIC 是一种基于 UDP 的传输协议，HTTP/3 构建在 QUIC 之上。

14.1 优点

• 连接建立速度较快；
• 减少部分握手延迟；
• 支持连接迁移；
• 更适合移动网络切换；
• 避免 TCP 层的队头阻塞。

14.2 潜在问题

• 某些网络环境中的 UDP 不稳定；
• 部分代理或虚拟网卡对 UDP 支持较差；
• 防火墙可能限制 UDP；
• 节点可能没有正确转发 QUIC；
• 浏览器使用 QUIC 时可能出现卡顿。

典型现象：

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

排查方向包括：

• 浏览器是否启用了 QUIC；
• 网络工具是否支持 UDP 转发；
• TUN 模式是否正确处理 UDP；
• 浏览器安全 DNS 设置；
• 插件；
• 缓存；
• 长连接；
• 节点的 UDP 质量。

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

命令行通常只测试单个 URL。浏览器打开一个网页时，可能同时加载：

HTML
CSS
JavaScript
图片
字体
API
广告
统计脚本
CDN 资源
第三方嵌入内容

因此，浏览器的整体体验更容易受到多域名、多连接和多协议的综合影响。

16. 缓存与旧连接

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

常见缓存包括：

DNS 缓存
Fake IP 映射
路由状态
TCP 连接
TLS 会话
HTTP/2 长连接
浏览器缓存
Service Worker
代理连接池

修改配置后，如果旧状态没有被清理，测试结果可能产生干扰。

推荐流程：

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

Windows 刷新 DNS 缓存：

ipconfig /flushdns

必要时还可以重新启动相关网络工具或系统网络接口。

17. 分层排障流程

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

检查本地端口监听：

netstat -ano | findstr ":端口号"

判断：

没有 LISTENING
  ↓
本地服务未启动或端口配置错误

存在 LISTENING
  ↓
继续测试 DNS 和外部链路

第二步：确认 DNS 返回形态

使用：

nslookup example.com

可能结果：

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

第三步：测试小请求

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

主要用于检查：

目标是否可达
TCP 是否能够连接
TLS 是否能够建立
响应头是否能够返回

第四步：测试完整下载

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} speed:%{speed_download}`n" https://www.example.com

显式代理路径：

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

判断：

18. 常见现象与定位表

19. 核心经验总结

• DNS 只负责域名解析，不能代表完整网络速度。
• Fake IP 返回 198.18.x.x，通常表示本地分流映射已经生效。
• 面板延迟通常只是小规模连通性测试，不能代表真实网页体验。
• curl -I 只能说明小请求和基础连接是否可达。
• 完整下载测试更能暴露吞吐、丢包、拥塞和 MTU 问题。
• time_total 和 speed_download 比单纯延迟更接近真实使用体验。
• TLS 握手失败时，应重点检查链路稳定性、丢包、MTU 和中间转发路径。
• TUN 与系统代理属于不同接管路径，排障时应分别测试。
• 浏览器慢可能来自 QUIC、插件、缓存、安全 DNS 或多资源并发加载。
• 修改网络配置后，应重启内核、清空连接、刷新 DNS 并重启浏览器。
• 网络排障应采用分层测试和 A/B 对比，避免只凭感觉判断。
• 先定位问题层级，再修改配置，比反复更换节点和 DNS 更有效。