tech/network · 集群 B · 隧道与排障原理 · 1/6

网络隧道是什么:封装、解封装与代理隧道的通用模型

发布时间 待核实核实日期 待核实最近更新 待核实测试状态 Not Tested
Answer First · 核心结论

网络隧道是把一种网络流量装进另一种连接里传输的通用技术:入口负责封装,出口负责解封装,中间网络只看到外层连接。VPN、代理和企业内网互联都基于这一思想,差异在于封装层级、接管范围和用途。隧道必然带来额外头部开销、处理延迟和可用包大小变小,排障时需要把这些副作用考虑进去。

隧道的核心思想

隧道的核心思想只有一句话:把一个完整的数据包,当作另一个连接的“货物”运过去。入口把原始包装进新的外壳(封装),中间网络只按外壳上的地址转发,到了出口再拆掉外壳(解封装),把原始包放出来继续前进。

入口(封装)                 中间网络                出口(解封装)
┌────────────┐                                     ┌────────────┐
│ 原始包      │                                     │ 原始包      │
│ 源:A 目:X  │ ──▶ ┌──────────────────────┐ ──▶     │ 源:A 目:X  │ ──▶ 目标 X
└────────────┘     │外壳 源:入口 目:出口   │         └────────────┘
                   │ ┌────────────┐       │
                   │ │ 原始包      │       │
                   │ └────────────┘       │
                   └──────────────────────┘
                   中间网络只看到外壳

这个思想并不新,也不专属于某个领域。企业用它把不同城市的办公室连成一个内网,运营商用它在骨干网上承载多种业务,个人用它远程访问家里的设备。代理服务只是隧道众多应用中的一种。

隧道的三个组成部分

任何隧道都可以拆成三个部分:入口、传输通道和出口。理解这三部分,就能理解大多数隧道类技术的共性。

组成部分 作用 在代理场景中对应
入口 接收原始流量并封装 本地客户端与代理内核
传输通道 承载封装后的流量 本地到节点的 TCP 或 UDP 连接
出口 解封装并转发到目标 落地节点

入口和出口必须“说同一种语言”,也就是使用相同的协议和参数,否则出口无法正确解开外壳。这就是为什么订阅配置过期或协议参数不匹配时,连接会直接失败。

VPN、代理与内网互联的异同

VPN、代理和企业内网互联都使用隧道,但它们在接管范围、工作层级和用途上不同。

对比项 传统 VPN 规则型代理客户端 企业内网互联
工作层级 多为网络层 应用层或网络层(TUN) 网络层或链路层
接管范围 通常整机全部流量 可按规则分流 指定网段
分流能力 有限 规则丰富 按路由表
典型用途 远程办公、访问内网 按需访问特定服务 分支机构互联

规则型代理客户端的一个显著特点是分流:它不是把所有流量一股脑塞进隧道,而是根据域名、IP 等规则决定哪些走隧道、哪些直连。这部分原理见 分流原理。而当客户端开启 TUN 模式时,它的接管方式就接近传统 VPN 了,原理见 TUN 虚拟网卡原理。

封装层级:隧道可以承载什么

不同隧道承载的内容层级不同,这决定了它能处理哪些类型的流量。

  • 承载应用数据:例如 HTTP 代理、SOCKS 代理,入口只接收应用交给它的连接请求,转发的是应用层数据流。优点是轻量,缺点是只能处理“主动找它”的应用。
  • 承载 IP 包:例如多数 VPN 与 TUN 模式,入口接收完整的 IP 包,能处理任何协议,包括 UDP 与 ICMP。
  • 承载以太网帧:例如部分二层隧道,能让两地设备像在同一局域网里,常用于企业场景。

承载层级越低,能覆盖的流量类型越广,但封装开销和配置复杂度通常也更高。具体代理协议的差异请参考 代理协议 专题。

隧道带来的三种副作用

隧道不是免费的,它一定会带来额外的开销,排障时要把这些副作用考虑进去。

第一,路径变长。流量必须先到隧道出口,再从出口去目标。如果出口离目标很远,或者入口离你很远,总延迟就会增加。这与 跨境网络访问的基本结构 中讲到的“多段路径叠加”是同一个道理。

第二,处理开销。封装、加密、解密和解封装都需要计算资源。在性能较弱的设备上(例如部分路由器),高速传输时处理器可能成为瓶颈。

第三,可用包变小。外壳本身要占字节,原始包能用的空间就少了。如果没有正确处理,就会遇到“大包过不去”的问题,详见 MTU 与 MSS 详解。

副作用对照:
路径变长   → 延迟增加            → 选离目标近的出口
处理开销   → 高速时 CPU 占用升高  → 关注设备性能
包变小     → 大包卡住            → 检查 MTU / MSS

多层隧道叠加的风险

有些用户会在已有代理的基础上再叠加一层 VPN,或在路由器和电脑上同时开启代理,形成“隧道套隧道”。这种做法会让三种副作用成倍放大:路径更长、处理更多、可用包更小,同时排障难度大幅增加——你很难判断问题出在哪一层。

如果确有多层需求,建议:

  1. 明确每一层负责什么,避免重复接管同一流量;
  2. 先单独验证每一层都能正常工作,再叠加;
  3. 发现问题时,从最外层开始逐层关闭,定位故障层。

路由器与电脑同时开启代理的冲突,可以参考 路由器方案 专题中的说明。

从隧道视角理解常见故障

用隧道模型看常见故障,很多现象会变得容易理解:

现象 隧道视角的解释 排查方向
所有节点都连不上 入口无法与任何出口建立传输通道 本地网络、订阅是否过期、系统时间
连接立即被断开 入口与出口“语言”不匹配 更新订阅、核对协议参数
能连上但很慢 传输通道拥塞或路径过长 换节点、换时段、看路由
大文件卡住 封装后包超出路径限制 MTU / MSS
部分应用不走隧道 入口没有接管这些流量 接管方式、TUN 模式

这张表本质上就是把 分层排障法 的思路套用到隧道模型上。

合规说明与下一步

本文仅介绍隧道的通用原理和副作用,不涉及任何规避检测或监管的具体技术手段。代理服务属于第三方服务,存在运营与合规风险,请遵守所在地法律法规与平台条款,以官方发布文本为准。

理解隧道模型后,再看服务商资料中的协议和客户端字段会更有方向。你可以在 机场品牌库 查看各品牌的协议标注,或用 对比工具 并排比较。资料中协议为待核实的品牌,请以服务商最新说明为准,所有数据本站未实测。

常见问题

隧道和代理是一回事吗?

不完全是。隧道是一种通用的封装传输思想,代理是一种“替你去访问”的服务形态。很多代理在实现上使用了隧道,但隧道也广泛用于企业内网互联、远程办公等与代理无关的场景。

为什么用了隧道延迟会变高?

一是流量必须先绕到隧道出口再去目标,路径变长;二是封装、加密和解封装需要处理时间;三是额外头部让同样数据需要更多字节传输。

隧道里套隧道会怎样?

每多一层封装,就多一层头部开销和处理延迟,可用包大小也进一步缩小,更容易遇到 MTU 问题。一般不建议无必要地多层叠加。

本文会讲具体协议如何规避识别吗?

不会。本文只讲隧道的通用原理与副作用,不涉及规避检测的具体技术手段。

信息来源与更新时间

信息来源
品牌清单资料(品牌公开信息整理)
测试范围
本站未进行测速与解锁实测,所有能力描述均为资料声明或未测试状态。
发布时间
待核实
核实日期
待核实
最近更新
待核实

字段含义与数据状态见 字段说明;核查进度见 品牌动态与核查日志。