走隧道和走转发，代理IP对数据包做的事不一样

同样是经过代理IP，走转发和走隧道时，数据包的待遇完全不同：一个被拆开改了地址再送，一个被原样装进套子整体搬运。这一篇从数据包视角把两种待遇讲清楚，看完你就知道为什么有的连接适合转发、有的必须走隧道。

转发：拆开看地址，改完再送

转发的动作可以拆成三步：代理IP收到数据包，先读包里的目标地址，把来源地址换成自己的出口地址，再按目标送出去。整个过程中，数据包是要被「打开看」的——至少要看地址部分，才能决定往哪送。

转发对数据包的改动，通常只在地址层：来源换了、目标不变，内容原样不动。这个特点决定了转发能做「地址相关」的事——换地区、换来源、按地址分流，都靠这一层改动。但代价是中间环节能看到地址信息，这是转发与生俱来的特性。

隧道：整包封装，外面套一层新壳

隧道的动作完全不同：数据包不是被拆开，而是被「整个装进一个套子」——外面套上新的传输信息，形成一个新的外层包。中间环节看到的是套子上的信息，套子里面的原始数据包原样不动，谁也看不见里面装了什么。

封装的意义在于隔离：因为原始数据包被完整包在里面，中间环节看不到内容、也改不了内容。对应到代理IP场景，HTTPS 走 CONNECT 隧道就是这个原理——先建通道，数据包在通道里整体搬运，中间环节只认外层。

从这张表能看到两种待遇的本质差别：转发是「动了地址再送」，隧道是「不拆原包直接搬」。代理IP对数据包的两种对待方式，前者为地址服务，后者为隔离服务——一个追求可控，一个追求不动，用途自然就分开了。

有人会问：那转发和隧道哪个更「安全」？要看站在哪个角度看：隧道让中间环节看不到内容，隔离性更好；转发让中间环节能处理地址，功能性更强。代理IP里没有绝对的安全，只有按场景选对动作——要隔离选隧道，要可控选转发。

实际业务里怎么对应？普通网页抓取、需要换出口地区的任务，转发够用且灵活；登录态传递、加密协议访问这类不希望内容被沿途看到的场景，隧道更合适。判断标准就一句话：你的数据包，愿意被中间环节看到地址，还是连看都不让看。

还有一个细节值得留意：转发对数据包的改动是有边界的——它只看地址层，不碰内容层；隧道则连地址都不看，纯粹整体搬运。两者对数据包的「尊重程度」不同，这也是为什么有的业务必须走隧道：内容层的完整，只有在不拆看的前提下才最有保障。

把两种待遇记牢：走转发，数据包被拆开改了地址再送；走隧道，数据包被整体装进套子搬运。代理IP对数据包做的事，决定了它能帮你解决哪类问题——想清楚数据包该被怎么对待，转发和隧道怎么选，答案自己就出来了。

最后再补一句实践提醒：判断一个代理IP连接走的是转发还是隧道，最直接的办法是看连接建立过程——有没有明显的「先建通道」阶段。有，就是隧道待遇；没有，就是转发待遇。数据包被怎么对待，决定了你的业务在连接层面是什么体验，看懂了这层，配置与排障都更有底。