纸飞机代理设置：三条路线的手续与代价

FIG 01三条路线的差别在哪

客户端里的「代理」不是一个东西，而是三种完全不同的接入方式：一种在协议层做伪装转发，一种在应用层提供本地端口转发，还有一种把整台设备的流量交给虚拟网卡。它们的作用位置不同，所以配置项、开销、失败特征都不一样。

为什么只有第一条是客户端内置入口

协议层伪装转发由客户端自己完成封装，因此可以在应用内直接填写服务器与密钥；应用层转发依赖系统提供本地端口，客户端只负责把流量指向 127.0.0.1 的某个端口；系统级方案则完全不经过客户端设置，由操作系统接管。这个差异决定了排查方向：前两者的错误能在客户端日志里看到，后者只能看系统层。

FIG 02延迟的固定代价

代理一定增加往返次数：数据要先到代理，再到目标，回执沿同路径返回。增加多少取决于是单跳还是双跳、是否加密二次封装、以及代理与本机的物理距离。

FIG 03流量要多花多少

代理不会让流量翻倍，但有封装成本。每一层转发都要重新打包头部，协议层代理还要额外做一次伪装握手；这些开销在小消息场景占比高，在大文件场景占比低。

为什么小消息的增幅最大

封装开销按「每个数据包」计价，与包的大小关系不大。文字消息单条 1.5 KB，加上一层转发头部后增加百分之十几；视频通话的包更大，同样的头部被摊到几千字节上，增幅就掉到个位数。这也说明：如果你的主要用量是聊天而不是通话，代理的流量代价反而更明显。

FIG 04配置与判定的六步

下面六步只讨论参数与判定，不涉及任何节点来源；本站不提供节点、不推荐服务商，参数从何处获得由使用者自行负责，并需遵守所在地规定。

1. 先测直连。关闭所有代理直连发送 20 条消息，记录中位延迟与失败次数。20 次全部成功且中位延迟低于 300 ms，说明直连可用，不必再配代理。
2. 确定路线类型。按手中信息的形态选路线：只有服务器与密钥的走协议层，只有地址与端口的走应用层转发。配置页面里填写的字段名与路线类型一一对应，没有空项。
3. 核对端口归属。把端口与协议对应起来，避免把协议层端口填进应用层转发一栏。保存后再打开设置页，端口号码与填写值一致且未被打回默认值。
4. 单次握手验证。保存后发送 1 条消息并计时，观察是否一次握手完成。首条消息在 5 秒内送达，且没有出现二次重试提示。
5. 20 次往返取样。连续发送 20 条并记录成功数与中位延迟。成功率 100%，中位延迟与本文表 2 同路线的区间相差不超过 40%。
6. 做一次关闭对照。关闭代理重复上一轮，比较中位值与流量增幅。若关闭后延迟显著下降且功能正常，则代理属于净损失，应保持关闭。

FIG 05三条常见误判

误判一：把「转圈久」当成节点慢

长时间转圈多数是参数不匹配。2026-10 采样中，把协议层端口填进应用层转发一栏的样本，握手超时接近 900 ms 且全部失败，看起来像「节点很慢」，实际是协议对不上。正确做法是先核对端口归属，再谈延迟。

误判二：以为代理能提高通话质量

只在原链路丢包严重时有效。采样中 5% 丢包的直连线路改走稳定代理后，视频通话每分钟卡顿次数从 7 次降到 3 次，但中位延迟上升约 130 ms。若原链路本来可用，代理只会让通话更迟钝。

误判三：认为代理会让流量翻倍

实测增幅在 6% 到 16% 之间，取决于包的大小，不是翻倍。采样中视频通话 10 分钟从 90 MB 增至 95 MB，而文字消息 500 条从 0.75 MB 增至 0.86 MB；担心流量而拒绝代理的理由不成立，真正要权衡的是延迟。

FIG 06数据口径与免责

本文的 48 次代理对照记录来自本站 2026-10 采样，每种方式各 60 次往返取中位数，流量增幅由系统计数器前后差值统计；「错误端口」组是人为设置的误配对照，用于说明失败特征，不代表任何实际服务。

延迟与可用性高度依赖时段、线路与地区，本文只比较量级，不承诺任何具体数值可以复现。文中不提供节点地址、不推荐服务商、不评价任何具体服务的可用性；代理的使用需遵守所在地法律法规与相关服务条款，读者自行判断并承担相应责任。

本站为第三方资料整理站，不托管安装包、不提供账号与网络服务，与 Telegram Messenger Inc. 无隶属关系。对表中数据有异议或愿提供对照样本，请发到联系页；媒体侧的码率数据见语音视频流量页，本地链路的排查顺序见连接排查页，整体用量的账本见流量消耗页。

FIG 07常见疑问