一、两种模式的核心定义
1.1 端口转发（透明隧道模式）
端口转发的转发单元是TCP连接。客户端通过CONNECT方法向代理请求建立到目标的TCP隧道，代理与目标建立连接后，双向原样转发字节流，不解析、不修改应用层数据。 隧道一旦建立，这条连接上的所有数据（可包含多个HTTP请求）都使用同一个出口IP，直到连接关闭。其核心特点是连接粒度转发，数据透明透传。
1.2 请求转发（应用层代理模式）
请求转发的转发单元是单个HTTP请求。代理服务器解析每个HTTP请求，以自身身份重新向目标发起请求，获取响应后返回客户端。每个请求可独立选择出口IP，也可修改请求头、增删字段。 这种模式下客户端与目标没有直接TCP连接，代理作为完整的应用层中间人。
二、两种模式的核心差异
2.1 IP轮换能力
- 端口转发：连接存续期间出口IP固定，无法在连接内切换IP，天然对应粘性会话模式；
- 请求转发：每个请求可独立分配出口IP，天然支持每次请求轮换，IP切换粒度更细。
2.2 会话保持能力
- 端口转发：天然支持会话保持，只要TCP连接不断，IP就保持不变，适合登录、多步操作等场景；
- 请求转发：难以天然保持会话，需要额外机制模拟会话连续性。
2.3 协议支持范围
- 端口转发：支持所有基于TCP的协议，HTTP、HTTPS、FTP、数据库连接等均可转发，通用性强；
- 请求转发：仅支持HTTP明文请求；HTTPS需要中间人解密才能实现请求级转发，存在安全风险，正规服务通常不采用。
2.4 请求头控制能力
- 端口转发：无法修改请求头，数据完全透传，不会引入代理相关字段；
- 请求转发：可修改、添加、删除请求头字段，可实现头部净化、字段伪装等操作。
2.5 性能开销
- 端口转发：仅做字节流转发，无应用层解析，性能开销低，延迟小；
- 请求转发：每个请求都需要解析、重建连接，应用层处理开销高。
2.6 适用场景
- 端口转发：适合需要会话保持、混合协议流量、低延迟的场景；
- 请求转发：适合高频IP轮换、无需会话、纯HTTP明文采集的场景。
三、实际场景的选型参考
3.1 高频公开数据查询场景
无需登录、仅高频查询的公开数据采集场景，优先选择请求转发模式，每个请求切换IP，降低触发风控与验证码的概率，提升采集成功率。
3.2 登录态与多步操作场景
需要登录、表单提交、多步骤流程的场景，必须使用端口转发模式，设置对应粘性时长，保持同一IP完成完整业务流程，避免IP切换导致会话失效。
3.3 多协议混合场景
业务同时包含HTTP、FTP、数据库连接等多种协议时，只能选择端口转发模式，其通用转发能力可覆盖全协议流量。
四、智能切换模式
成熟的隧道代理服务可根据协议类型与配置策略自动选择转发模式：
- HTTP明文请求+每次轮换策略，走请求转发模式；
- HTTPS请求或粘性会话策略，走端口转发模式；
- 非HTTP协议流量，强制走端口转发。 这种自动切换无需用户关注底层细节，只需配置轮换策略与粘性时长，引擎自动适配最优模式，提升整体成功率。
五、总结
端口转发是基于TCP连接的透明管道，通用性强、天然支持会话保持；请求转发是基于HTTP应用层的代理，IP切换灵活、可修改头部。两者没有绝对优劣，分别适配不同业务场景。 理解两种模式的底层差异，根据业务的协议类型、会话需求、IP轮换粒度选择对应模式，才能最大化代理的使用效果。
