网络分层模型：一次请求要经过多少层，问题又出在哪一层

分层模型不是用来背的。它真正的用处是定位问题：知道一个故障属于哪一层，就知道该改什么、不该动什么。

1. 两套模型的对应关系

OSI 七层是教学模型，实际协议栈按 TCP/IP 四层实现（RFC 1122）：

2. 封装：数据下行时每层加一个头

发送数据时，每往下一层就套一层头部：

应用数据
  → 加传输层头（端口号）      = 段
    → 加网络层头（IP 地址）    = 包
      → 加链路层头（MAC 地址） = 帧

接收端反过来逐层拆开。每一层只读自己那一层的头，不关心上层内容——这就是为什么加密的应用层数据可以穿过不认识它的中间设备。

3. 代理插在哪一层，决定它能管什么

这是分层模型在代理场景里最有用的一点：

位置越低，覆盖越广。 这解释了三个常见现象：

• HTTP 代理下游戏连不上——游戏多用 UDP，HTTP 代理管不了。
• SOCKS5 下 ping 不通——ICMP 属网络层，SOCKS5 在其之上。
• TUN 下什么都走代理——它在网络层接管，程序绕不过去。

4. 按层定位故障

遇到问题时先判断属于哪一层，能省掉大量无效尝试：

本机完全断网              → 链路层，与代理无关
能 ping 通但网页打不开     → 应用层（DNS 或 TLS）
某些程序走代理、某些不走   → 代理插入的层不够低
连接建立慢               → 传输层握手轮次 + 网络层 RTT
连上了但速度慢           → 网络层路径质量或对端容量
证书报错                 → 应用层，先查系统时间

**「证书报错先查系统时间」**这条很常被忽略：证书有效期依赖本机时钟判断，时间偏差过大会直接导致 TLS 握手失败，看起来像网络问题，实际是应用层的时间校验。

5. 一个要避免的误解

分层不代表每层都能独立优化。 上层的表现受下层制约：网络层丢包严重时，传输层再怎么优化拥塞控制也只能缓解，不能消除。

所以判断顺序应该自下而上：先确认链路和网络层没问题，再谈传输层协议选择和应用层配置。反过来做，会在错误的层上反复折腾。

该记住的

1. 分层的用处是定位，不是背诵。
2. 代理插入的层决定它能管什么——覆盖不全通常是层不够低。
3. 排查自下而上——下层不通时，优化上层没有意义。