文章
vpn vs clash
本文目录 7
背景
因为电脑卡卡的，所以回家之后清灰换硅脂顺带重装了一下系统
然而在重配环境的时候，网络异常的卡，同样的节点在学校就用的好好的，所以进行了一下排查，顺带学习到了一些知识，主要是关于proxy和
手上有一台azure jp的服务器（公网ip），和一台sjtu内网ip的服务器
issue-server之前都是用clash把包发给jp服务器
****dddddfasafasdfasdfasdfasdfass dfadfasdfasdfasdfadsfasdfadfad
实验
设计
为了能够重回在学校的丝滑体验，我让claude做了以下的实验：
- 家里用clash verge直连jp节点
- clash + sjtuVPN
- 自建隧道，从家里开sjtu vpn
结果
| 指标 | 路径1 直连 | 路径2 VPN+校园网 | 路径3 自建隧道 |
|---|---|---|---|
| 到 jp 节点延迟 | ~119ms | 低（国内段20ms + 商业线） | ~220ms（家→校园网20 + 教育网→日本200） |
| 到 jp 节点带宽 | GitHub 0 B/s（被重置） | GitHub 7.7 MB/s | GitHub 2.4 / Cloudflare 4.6 MB/s |
| 3.8s | 0.66s | — | |
| YouTube | 失败 | HTTP 200 | — |
| 出口 IP | 20.89.213.127 | 20.89.213.127 | 20.89.213.127 |
| 判定 | ❌ 直连卡（GitHub 不可用） | ✅ 最优 | ⚠️ 优于直连、但不如路径2（废弃） |
注：三条路径最终都从日本 IP 出口（
20.89.213.127），差异完全来自”到 jp 节点的中间线路”
结论
由此得到的结论：
1. 瓶颈不在节点，在到达节点的路径上
jp 节点服务器自身出站极快（Cloudflare 180 MB/s、GitHub 9.6 MB/s）。所以快慢只取决于家里怎么到 jp
2. 路径 1 为什么卡
家庭宽带是消费级国际出口：容量小、高峰期拥堵、常被运营商对国际流量限速**/QoS**，且受 GFW 影响。实测直连 GitHub 直接被重置（0 B/s）；使用clash代理包装成的流量还是得经过家庭宽带的国际流量到达jp，这一步就是直接被运营商限流了，测出来几乎连不上
3. 路径 2 为什么快
把”国际那段”从家里的烂线路，挪到校园网的好线路上：
- 家里 → 校园网 = 国内流量（上海本地，快、稳、不堵）。
- 校园网 → 日本 = 用校园网买的商业国际专线（带宽大、对等直连、峰值不拥堵，出口 27.115.123.250 上海联通）。
- 唯一付出的代价是”多绕一跳”，但瓶颈是出口质量而非跳数——绕到畅通的线路反而快
4. 为什么”用server 打隧道慢”但”VPN 快”？
两台机器都在交大校园网，但出国际的上游线是不同的
issue-server挂在学术网段，出口是 CERNET（教育网，AS4538）- VPN 网关走商业线路（上海联通，AS17621，出口 27.115.123.250）：比教育网质量更好
关于vpn和代理
VPN(virtual private network)，虚拟专用网络
⚖️ 代理（Proxy） vs VPN
| 对比维度 | Clash（代理/Proxy） | 交大VPN（真正的VPN） |
|---|---|---|
| 英文全称 | Proxy（代理） | Virtual Private Network（虚拟专用网络） |
| 工作的层级 | 应用层（第7层） —— 只处理特定应用（浏览器、Telegram等）的流量 | 网络层（第3层） —— 处理所有流量，包括系统更新、游戏、UDP、Ping等 |
| 是否加密 | 不一定（取决于协议，如VLESS加密） | 一定加密（IPSec、OpenVPN等协议） |
| 是否分配IP | ❌ 不分配，只是转发请求 | ✅ 分配一个虚拟IP，让你成为远端网络的一员 |
| 流量范围 | 只代理配置了代理的应用（如浏览器设置了127.0.0.1:7897） | 系统全局，所有程序（包括命令行、游戏、微信）都被接管 |
| 对系统的可见性 | 应用需要主动“告诉”代理我要用你 | 操作系统层面透明，应用完全不知道VPN存在 |