搜索 K
Appearance
绝大多数人把「VPN」和「代理」当成同一类东西的两种叫法,这是认知上最大的坑。它们根本不在同一层工作,性能差异、分流能力、被识别概率、兼容性表现,全部由这个层级差决定。
结论先摆在这里:
下面从物理机理开始,一层一层拆。
用 OSI 模型对齐一下就清楚了。
传统 VPN 工作在第三层(网络层)。IPsec、WireGuard、OpenVPN 的 TUN 模式,本质上都是创建一个虚拟网卡,把原始 IP 包整个吞进去,加一层外壳再发出去。客户端会改写系统路由表,把默认路由 0.0.0.0/0 指向虚拟网卡。这意味着:不管你要访问的是本地 NAS、公司 OA 还是境外站点,全部走隧道。
代理工作在第四到第七层。SOCKS5 在传输层做字节流转发,HTTP CONNECT 在应用层做隧道协商,Shadowsocks 本质是一个「加密版的 SOCKS5」,Trojan / VLESS 则是把代理握手藏进 TLS 里。代理不碰系统路由表(除非你开 TUN 模式),它只在自己这一层做一件事:判断这条连接该不该出境,该走哪条出口。
这个分歧带来三个连锁后果:
DOMAIN-SUFFIX,openai.com,PROXY 这个级别。IPsec(IKEv2):ESP 封装,NAT 穿越走 UDP 4500。优点是内核态转发,吞吐高、延迟低、移动端切换网络时重连快。缺点是协议特征极其明显,UDP 500/4500 端口 + IKE 握手报文几乎等于自报家门,在存在 DPI 的链路上存活率很低。ESP 封装开销约 50–73 字节。
WireGuard:UDP 单端口,Noise_IK 握手,ChaCha20-Poly1305 加密。代码量约 4000 行,性能是 OpenVPN 的 3–5 倍,内核态实现下千兆口轻松跑满。封装开销固定 60 字节(IPv4)。问题是包头格式固定且无填充,握手包长度可被指纹识别,2023 年之后已被主流 DPI 设备收录特征。
OpenVPN:用户态实现,TLS 握手(或静态密钥)。UDP 模式性能尚可,TCP 模式则是灾难——TCP-over-TCP 的崩溃问题:内层 TCP 超时重传,外层 TCP 也超时重传,两层退避算法互相打架,一旦链路丢包超过 2%,吞吐会雪崩式下跌。
MTU 是所有隧道的隐形杀手。隧道封装后,可用 MTU 从 1500 降到 1420–1450。如果 MTU 没调对,会出现「能打开网页、打不开图片」「SSH 能连、传大文件卡死」这类诡异现象,本质是 PMTUD 被中间设备阻断导致大包被丢弃。
Shadowsocks 的工作流可以拆成四步:
关键在于第二步的规则引擎。主流实现(Mihomo / sing-box)支持这几类规则,按顺序自上而下匹配,命中即停:
| 规则类型 | 写法示例 | 用途 |
|---|---|---|
| DOMAIN / DOMAIN-SUFFIX | DOMAIN-SUFFIX,google.com,PROXY | 精确域名分流,最常用 |
| IP-CIDR | IP-CIDR,1.1.1.1/32,PROXY | 无域名场景(DoH、直连 IP) |
| GEOIP | GEOIP,CN,DIRECT | 按国家/地区兜底 |
| PROCESS-NAME | PROCESS-NAME,Telegram.exe,PROXY | 按进程分流,解决 UWP 回环问题 |
| RULE-SET | RULE-SET,reject,REJECT | 引用远程规则集,广告拦截 |
为什么这套机制比 VPN 快? 因为它把「出境」变成一个需要被证明的必要条件。你访问 CSDN,DNS 本地解析,流量本地直达,RTT 5ms;你访问 arXiv,命中规则出境,走专线,RTT 60ms。而 VPN 是「一刀切」——访问 CSDN 也要绕地球一圈再回来,RTT 直接从 5ms 变成 200ms。
变量一:路径长度。 代理只让必要流量绕行,VPN 全量绕行。这是体感差异最大的来源,也是「为什么我开了 VPN 之后国内网站也变慢」的标准答案。
变量二:拥塞控制。 跨境链路典型特征是高带宽时延积 + 随机丢包。传统 CUBIC 把丢包等同于拥塞,一丢包就砍窗口;BBRv3 基于带宽和 RTT 建模,在高丢包链路上吞吐可以高出 3–10 倍。优秀的代理服务端会启用 BBRv3 + fq 队列,而部分老旧 VPN 网关还停留在 CUBIC。
变量三:链路类型。 这是被严重低估的一项:
< 0.1%,RTT 稳定。变量四:NAT 与二次封装。 部分 VPN 服务端在隧道出口又做一层 NAT + 用户态转发,CPU 单核跑满,10 个用户就把 1Gbps 口打爆。而代理服务端的转发路径通常更短。
反例同样成立:如果你把代理设成全局模式 + 远程 DNS,那你的代理和 VPN 在性能上已经没有本质区别,只是多了一层协议开销。
| 对比维度 | IPsec/IKEv2 | WireGuard | OpenVPN(UDP) | Shadowsocks | Trojan/VLESS |
|---|---|---|---|---|---|
| 工作层级 | L3 网络层 | L3 网络层 | L3/L4 | L4 传输层 | L7 应用层 |
| 封装开销 | 50–73 B | 60 B | 约 69 B | 约 30–40 B | TLS 头 + 约 40 B |
| 分流粒度 | 路由表/ipset,粗 | 路由表,粗 | 路由表,粗 | 域名级,极细 | 域名级,极细 |
| 是否接管整机 | 是 | 是 | 是 | 否(可 TUN) | 否(可 TUN) |
| DNS 处理 | 通常全量隧道 | 全量隧道 | 全量隧道 | 分流解析 | 分流解析 |
| DPI 抗性 | 弱 | 中(特征已收录) | 中 | 中高 | 高(伪装 TLS) |
| MTU 敏感度 | 高 | 中 | 高 | 低 | 中 |
| 千兆口典型吞吐 | 800–950 Mbps | 700–900 Mbps | 200–500 Mbps | 400–800 Mbps | 300–700 Mbps |
| 协议栈位置 | 内核 | 内核 | 用户态 | 用户态 | 用户态 |
| 最佳适用场景 | 企业内网、移动漫游 | 组网、点对点 | 兼容性兜底 | 日常分流代理 | 高审查环境 |
说明:吞吐数据基于 x86 软路由(4 核,开启硬件 AES-NI)实测区间,实际值受 CPU 单核性能、加密套件与链路质量影响极大,仅作量级参考。
轻度用户(网页 + 社交 + 学术检索):需求是「小流量、低延迟、稳定」。不需要 500Mbps 大带宽,但需要专线级别的低丢包。年付轻量套餐足够,IEPL 专线的 RTT 稳定性远胜同价位公网中转。
流媒体重度用户:4K 视频需要持续 25–40 Mbps 的稳定吞吐,且对晚高峰表现极敏感。优先看服务商的带宽冗余与超售比,而不是峰值测速数字。
跨境办公 / 内网访问:需要整机接管 + 局域网互访,WireGuard 或 Tailscale 是正解,代理协议在这里反而添乱。
游戏加速:UDP 转发 + 专线。绝对避免 TCP-over-TCP 的 OpenVPN TCP 模式,延迟抖动会毁掉一切。
Clash Verge / Mihomo(Windows / macOS):务必开启 TUN 模式而不是系统代理。系统代理只接管遵循系统代理设置的应用,大量 Electron 应用、Steam、部分游戏客户端会绕过。TUN 模式下配合 dns.enable-h3 与 respect-rules 才能彻底消除 DNS 泄漏。
sing-box(全平台):注意 route.rules 与 dns.rules 的匹配顺序和 inbound 标签。常见错误是 DNS 规则没加 inbound: dns-in,导致 DNS 查询直接走默认出站。
Shadowrocket / Surge(iOS):iOS 的内存限制很严,规则集不要超过 5000 条,否则后台会被系统杀掉。建议用精简规则集 + GEOIP,CN,DIRECT 兜底。
OpenWrt 软路由:单核性能决定加密吞吐。AES-NI 是刚需;ARMV8 路由器跑 AES-256-GCM 通常只能到 100–200 Mbps。
避坑三条硬规则:
排查思路永远是:先分层定位,再对症下药。
# 1. 定位丢包发生在哪一跳
mtr -rwzbc100 目标域名��IP
# 2. 探测 TCP 握手与 TLS 握手耗时
curl -o /dev/null -s -w "dns:%{time_namelookup} conn:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com
# 3. 端口连通性(比 ping 更有意义)
tcping -t 5 节点地址 443
# 4. 查看 TLS 证书与协商套件
openssl s_client -connect 节点地址:443 -servername 伪装域名 -tlsextdebug
# 5. 抓包看是否有明文 DNS 泄漏
tcpdump -i any -n port 53
# 6. 查看本机连接数与 TIME_WAIT 堆积
ss -s判定表:
| 现象 | 最可能原因 | 处置 |
|---|---|---|
| mtr 前三跳丢包、后续正常 | ICMP 限速,非真实丢包 | 忽略,看 TCP 层 |
| 出境跳之后持续丢包 | 公网中转拥塞 | 换专线或换节点 |
| TLS 握手 > 800ms | 线路绕行或远端负载高 | 换入口 |
| DNS 查询走 53 明文 | DNS 未走代理 | 开 fake-ip + 强制 DNS 出站 |
| 握手正常但传输卡顿 | MTU 过大导致分片丢弃 | 下调 MTU 至 1420 或 1380 |
| 小文件快、大文件断流 | TCP-over-TCP 崩溃 | 改 UDP 承载 |
延伸阅读:网络诊断命令完全手册、MTU 与 TCP 调优专题。
| 宣传话术 | 真实含义 | 识别方法 |
|---|---|---|
| 「不限流量、不限速」 | 高概率超售数十倍 | 晚高峰实测,看是否跌到白天 20% |
| 「8K 秒开」 | 单线程测速好看,多线程挤爆 | 多线程并行下载测总带宽 |
| 「Netflix 全解锁」 | 可能是 DNS 解锁,只解锁自制剧 | 用原创剧 + 第三方检测站交叉验证 |
| 「0.1x 倍率」 | 可能只是特定地域节点 | 看计费说明是否全节点适用 |
| 「免费节点」 | 存在流量嗅探与注入风险 | 抓包看是否有证书替换 |
| 「终身套餐」 | 跑路风险极高 | 查运营年限与用户口碑 |
| 「自研协议」 | 大概率是改版 SS/VMess | 抓包看握手特征 |
Q1:我用了代理,为什么 YouTube 还是卡? 先看是不是全局模式,再看节点是否走公网中转。晚高峰公网中转丢包到 10% 时,任何协议都救不了。用 mtr 确认出境后第 2–4 跳是否开始丢包。
Q2:TUN 模式和系统代理到底选哪个? TUN 接管更彻底,兼容所有应用,但配置复杂度高、可能与某些游戏反作弊冲突;系统代理轻量,但大量应用不遵守。日常推荐 TUN + 规则分流。
Q3:Shadowsocks 和 VLESS 哪个更快? 同链路下差距通常在 5% 以内,VLESS + Reality 的 TLS 头略大但抗封锁更强。不要为了 5% 的协议差异去换掉一条稳定的专线���
Q4:为什么我 ping 节点只有 30ms,实际网速却很差? ICMP 不反映 TCP 转发路径。用 tcping 和 curl -w 看真实握手与 TTFB。
Q5:DNS 泄漏有危害吗? 有。DNS 泄漏意味着你的解析请求暴露在本地网络,可能被投毒导致连接被劫持到错误 IP,也会导致 CDN 调度到远端节点。
Q6:OpenVPN 还能用吗? 能用,但仅建议用于企业内网、组网与兼容性兜底场景。跨境场景下 UDP 模式尚可,TCP 模式应完全避免。
Q7:专线一定比公网中转快吗? 不一定更快,但更稳。专线的价值在于丢包率与 RTT 抖动可控,这对视频会议、游戏、大��件传输的意义远大于峰值带宽。
结语:理解了「三层隧道 vs 七层分流」这个层级差,你就不会再被「自研协议」「黑科技加速」这类话术带偏。协议只是工具,链路才是地基,规则才是效率的来源。把这三件事分清楚,选型和排障都会变得极其简单。
#VPN与代理技术原理 #IPsec #OpenVPN #Shadowsocks #代理分流 #IEPL专线 #网络隧道 #机场推荐 #AirPick