# VPN 知识库 (Yalgorup) —— 全站正文

系统讲解 VPN 是什么、如何工作、有哪些协议与加密算法，以及隐私、日志、泄露防护等基础知识。中文技术百科，只讲原理，不推销产品。

本文件包含 32 个页面的完整正文，由 https://yalgorup.com/llms-full.txt 自动生成。
索引版本见 https://yalgorup.com/llms.txt

---

# VPN基础知识专题：从定义到类型的完整入门

URL: https://yalgorup.com/vpn基础/
类型: hub
专题: basics
更新: 2026-08-01
一句话回答: VPN基础知识可以拆成五个问题：它的定义是什么、数据包在隧道里经历了什么、它实际能解决哪些问题、有哪些部署形态、以及它和代理、Tor 的边界在哪。这五篇按顺序读大约需要三十分钟。

VPN基础知识入门专题：VPN是什么、它怎么工作、能用来做什么、有哪些类型，以及它和代理、Tor 的区别。五篇文章按由浅入深的顺序排列。

VPN基础 这个专题回答最前面的五个问题，也是整个站点的入口。不需要网络工程背景，按顺序读下来就能建立起完整的框架。

## 建议的阅读顺序

1. **[VPN是什么](/vpn是什么/)** —— 定义、一次连接里发生的事、三个最常见的误解。
2. **[VPN工作原理](/vpn工作原理/)** —— 虚拟网卡、路由表、封装、握手，跟着一个数据包走一遍。
3. **[VPN有什么用](/vpn用途/)** —— 七类真实场景，以及它做不到的事。
4. **[VPN类型有哪些](/vpn类型/)** —— 远程访问与站点互联，四种部署形态的取舍。
5. **[VPN和代理的区别](/vpn与代理区别/)** —— 和代理、Tor 放在一起比，边界才清楚。

## 这个专题想纠正的三件事

**「VPN 等于匿名」。** 它只处理 IP 这一个信号，Cookie、账号、浏览器指纹都不受影响。

**「加密了就安全了」。** 加密保护的是传输过程，服务器那一端依然能看到解密后的流量 —— 所以问题变成了「你信任谁」。

**「协议名字越新越好」。** 协议只是下限，客户端实现的细节（DNS、断线处理）才决定实际暴露面。

## 读完之后往哪走

- 想弄清楚各协议的差别 → [VPN协议专题](/vpn协议/)
- 关心隐私、日志和泄露 → [加密与安全专题](/vpn安全/)
- 准备实际使用与选择 → [使用与选择专题](/vpn使用/)
- 想看公开数据和图表 → [数据专题](/数据/)

### 常见问题

Q: 完全没有网络基础，能读懂这个专题吗？
A: 可以。这五篇不假设你懂 TCP/IP，涉及的术语都在正文里解释，遇到生词也可以查 VPN术语表。

Q: 读完基础专题接下来读什么？
A: 按兴趣分两条路：想知道「怎么实现的」去 协议专题，想知道「安不安全」去 加密与安全专题。

---

# VPN是什么？一篇讲清楚定义、原理与边界

URL: https://yalgorup.com/vpn是什么/
类型: concept
专题: basics
更新: 2026-08-01
一句话回答: VPN是什么？VPN（Virtual Private Network，虚拟专用网络）是在公共互联网上建立的一条加密通道。你的设备先把流量加密发给 VPN 服务器，再由服务器转发到目标网站，因此本地网络看不到内容，目标网站看到的是服务器的 IP。
参考来源: RFC 4026 — Provider Provisioned Virtual Private Network Terminology (https://www.rfc-editor.org/rfc/rfc4026) | RFC 2764 — A Framework for IP Based Virtual Private Networks (https://www.rfc-editor.org/rfc/rfc2764)

VPN是什么？VPN 是在公共网络上建立的加密虚拟通道。本文解释 VPN 的定义、一次连接里发生的事、它能保护什么，以及关于 VPN 最常见的三个误解。

要回答 VPN是什么，最短的说法是：一条建在公共互联网上的加密通道。这句话已经包含了 VPN 的全部能力边界 —— 它加密传输、更换出口 IP，除此之外的功能都是这两点的衍生。下面从定义、连接过程、误解三个角度展开。

## VPN是什么：拆开这三个词

VPN 的全称是 Virtual Private Network，中文一般译作「虚拟专用网络」。三个词各有含义：

- **Virtual（虚拟）**：它不是一条真实存在的物理线路，而是在公共互联网之上「模拟」出来的。
- **Private（专用）**：通道内的数据经过加密，中间的网络设备只能看到密文。
- **Network（网络）**：连上之后，你的设备在逻辑上属于远端那个网络。

RFC 2764 在定义 IP VPN 框架时用的表述很直白：在共享的公共基础设施上，模拟出私有网络的行为特征。这句话至今仍然准确。

## 一次 VPN 连接里发生了什么

假设你打开 VPN 客户端，选了一个日本节点，然后访问某个网站：

1. 客户端与 VPN 服务器完成**握手**，双方协商出只有彼此知道的会话密钥。
2. 系统的路由表被修改，出站流量被指向一个虚拟网卡（TUN/TAP 设备）。
3. 每个 IP 数据包被加密，再塞进一个新的数据包里发出去 —— 这就是「封装」。
4. VPN 服务器解密、还原出原始数据包，用**自己的 IP** 发往目标网站。
5. 网站的回包先到 VPN 服务器，再加密回传给你。

所以对本地网络来说，它只看到「你和某个 IP 在持续交换密文」；对目标网站来说，来访者是那台 VPN 服务器。

具体的封装格式和握手过程，见 [VPN 工作原理](/vpn工作原理/)。

## VPN 改变了什么

| 环节 | 不用 VPN | 用 VPN |
|---|---|---|
| 本地 Wi-Fi / 运营商 | 能看到你访问的域名，HTTP 内容明文可见 | 只能看到你在和 VPN 服务器通信 |
| 出口 IP | 你的真实 IP | VPN 服务器的 IP |
| DNS 查询 | 通常走运营商 DNS | 通常走 VPN 提供的 DNS（前提是没有泄露） |
| 目标网站 | 看到真实 IP 与地理位置 | 看到服务器 IP 与其所在地 |
| VPN 服务商 | 不存在 | 处于能看到全部流量元数据的位置 |

最后一行是关键：VPN 并没有消灭「有人能看到你的流量」这件事，它只是把这个位置从运营商换成了服务商。

## 关于 VPN是什么 的三个常见误解

**误解一：VPN 等于匿名。**
不等于。匿名需要切断所有可关联的标识，而 VPN 只处理了 IP。浏览器指纹、Cookie、登录状态、支付信息都不受影响。想要更强的匿名性，Tor 的多跳设计才是对应工具，见 [VPN、代理与 Tor 的区别](/vpn与代理区别/)。

**误解二：VPN 能防病毒、防钓鱼。**
不能。加密的是传输过程，不是内容本身。你在 VPN 里下载的木马照样是木马。部分服务商附带的域名过滤属于额外功能，和 VPN 本身无关。

**误解三：网站是 HTTPS 了，VPN 就没用。**
HTTPS 保护的是内容，但不隐藏你访问了哪个域名（SNI、DNS 查询仍然可见），也不隐藏你的 IP。两者解决的问题不同，是叠加关系。

## 谁在用 VPN，为什么用

VPN 最早的使用者是企业。员工出差时需要访问公司内网的文件服务器，拉专线成本太高，于是有了在公网上建加密通道的方案。今天这类用法仍然存在，称为远程访问 VPN。

个人用户的动机通常是三类：在不可信的公共 Wi-Fi 上保护传输、避免出口 IP 暴露位置、或者需要以另一个地区的网络身份访问服务。这些场景在 [VPN 能用来做什么](/vpn用途/) 里有更细的拆解。

## 什么时候其实不需要 VPN

诚实地说，有些场景 VPN 帮助有限：

- 只是在家用自己的宽带浏览 HTTPS 网站 —— 收益不大，主要是隐藏 IP。
- 想彻底摆脱广告追踪 —— 换 VPN 不解决 Cookie 和指纹问题。
- 想提高「安全性」但从不更新系统、复用密码 —— 优先级排错了。

把 VPN 理解成一个「传输层的工具」，而不是万能的隐私开关，是用好它的前提。

### 常见问题

Q: VPN 和「加速器」是一回事吗？
A: 技术上多数所谓加速器就是 VPN 或代理，只是换了个面向游戏、视频场景的名字。真正的差别在于是否全局接管流量、是否加密，以及是否为特定线路做了路由优化。

Q: 用了 VPN 网站就完全看不到我是谁了吗？
A: 不会。网站看到的 IP 变了，但 Cookie、浏览器指纹、以及你自己登录的账号仍然能识别你。IP 只是众多识别信号中的一个。

Q: VPN 需要在路由器上装还是在手机上装？
A: 两种都可以。装在设备上只保护该设备，装在路由器上则保护整个局域网，代价是配置复杂、无法按应用切换。参见 VPN 的类型。

Q: VPN 会记录我访问了什么吗？
A: 取决于服务商的日志政策。技术上服务器完全有能力记录，因此日志政策和审计记录是判断一个 VPN 的关键，见 日志政策。

---

# VPN工作原理：隧道、封装与握手到底做了什么

URL: https://yalgorup.com/vpn工作原理/
类型: concept
专题: basics
更新: 2026-08-01
一句话回答: VPN工作原理可以拆成五步：客户端创建虚拟网卡并改写系统路由表，让流量先经过它；每个 IP 数据包被加密后作为「载荷」塞进一个新数据包（封装），发往 VPN 服务器；服务器解封装还原出原包并转发到目标地址。
参考来源: RFC 4303 — IP Encapsulating Security Payload (ESP) (https://www.rfc-editor.org/rfc/rfc4303) | RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 (https://www.rfc-editor.org/rfc/rfc8446) | Linux Kernel Documentation — Universal TUN/TAP device driver (https://docs.kernel.org/networking/tuntap.html)

VPN工作原理详解：从虚拟网卡、封装、路由表改写到密钥握手，逐步拆解一个数据包通过 VPN 隧道时经历的完整过程，以及 MTU、NAT 穿透这些实际问题。

理解 VPN工作原理，只需要跟着一个数据包走一遍：它从哪里进入隧道、被包了几层、密钥是怎么商量出来的、又在服务器那一端发生了什么。下面五步就是 VPN工作原理的完整链路。

## 第一步：系统里多了一块网卡

安装 VPN 客户端后，操作系统里会出现一个虚拟网络接口 —— Linux 下叫 `tun0`，Windows 上是一个虚拟适配器。它没有对应的物理硬件，但在系统看来和真网卡一样可以收发数据包。

TUN 设备处理的是 IP 层数据包，TAP 设备处理的是以太网帧。个人用的 VPN 几乎都用 TUN，因为只需要转发 IP 流量。

## 第二步：路由表被改写

有了虚拟网卡还不够，还要告诉系统「哪些流量走它」。客户端连接成功后会往路由表里插入条目，常见的做法是加两条 `0.0.0.0/1` 和 `128.0.0.0/1` 的路由 —— 它们合起来覆盖全部 IPv4 地址，且优先级高于默认路由，同时又不会把原来的默认网关整个覆盖掉。

如果只想让部分流量走隧道（分流 / split tunneling），客户端就只插入特定网段的路由。

## 第三步：封装

这是「隧道」这个比喻的技术实体。原始数据包并没有被修改，而是被**整个当作数据**，装进一个新的数据包里：

```
[新 IP 头 | 协议头 | 加密后的( 原 IP 头 | TCP/UDP 头 | 应用数据 ) ]
      ↑ 目的地是 VPN 服务器            ↑ 中间设备只看到密文
```

不同协议的外层不一样：IPsec 用 ESP 头（RFC 4303），WireGuard 用自己定义的 UDP 报文格式，OpenVPN 把加密后的内容放进 UDP 或 TCP 里。

外层包头一定会占用空间。以太网默认 MTU 是 1500 字节，封装后可用于原始载荷的空间就少了几十字节。如果不调整，超长的包要么被分片，要么被丢弃 —— 表现就是「小网页能开、大文件卡死」。

## 第四步：握手与密钥

在传数据之前，双方必须先商量出一把只有彼此知道的钥匙，而且要在一条不可信的线路上完成。

大致流程是：

1. **身份验证** —— 服务器出示证书或公钥，客户端验证它是不是自己要连的那台。
2. **密钥交换** —— 用 Diffie-Hellman 一类的算法，双方各自算出同一个共享秘密，而窃听者拿不到。现代实现普遍用椭圆曲线版本（ECDHE / Curve25519）。
3. **派生会话密钥** —— 从共享秘密派生出用于加密和校验的对称密钥。
4. **切换到对称加密** —— 之后所有数据用 AES-GCM 或 ChaCha20-Poly1305 加密，因为对称算法比非对称快几个数量级。

优秀实现还会定期更换会话密钥（rekey）。这样即便某把密钥日后被攻破，也无法解开之前录下的流量 —— 这就是**前向保密**。详见 [VPN 加密原理](/vpn加密/)。

## 第五步：服务器侧的转发

VPN 服务器收到包后解密、还原出原始 IP 包，然后做一次 NAT：把源地址换成自己的公网 IP，记录映射关系，再发往目标网站。回包按相反顺序处理。

正因为这一步，目标网站看到的永远是服务器 IP。也正因为这一步，服务器本身处于能看到全部明文流量的位置。

## VPN工作原理在现实中的两个麻烦

**NAT 穿透。** 家庭路由器和运营商 NAT 会改写端口，长时间无流量的映射会被回收，表现为连接「假死」。协议层的应对是定期发保活包，或者用 MOBIKE（RFC 4555）这类机制在地址变化后重新绑定。

**协议特征。** 封装后的流量虽然内容不可读，但报文长度、握手模式、端口号构成了可识别的特征。想要不被识别，就需要额外的伪装层，见 [混淆与伪装协议](/vpn混淆协议/)。

### 常见问题

Q: TUN 和 TAP 有什么区别？
A: TUN 工作在第三层，处理 IP 数据包，是绝大多数 VPN 的选择；TAP 工作在第二层，处理以太网帧，能承载广播和非 IP 协议，多用于需要桥接局域网的场景。

Q: 为什么连上 VPN 后有些网站打不开，但大部分正常？
A: 常见原因是 MTU 过大导致大包被分片或丢弃。握手和小请求能通过，返回大页面时就卡住。把 MTU 调低（例如 1400 或更小）通常能解决。

Q: UDP 和 TCP 承载有什么差别？
A: UDP 开销小、延迟低，是默认选择；TCP 更容易穿过限制严格的网络，但会出现 TCP-over-TCP 的重传叠加，网络一差就明显变慢。

Q: 握手失败一般是什么原因？
A: 时间不同步导致证书校验失败、UDP 端口被拦截、服务器证书过期，或者中间设备对特定协议特征做了阻断。

---

# VPN有什么用？七类真实场景与它的能力边界

URL: https://yalgorup.com/vpn用途/
类型: concept
专题: basics
更新: 2026-08-01
一句话回答: VPN有什么用，实际集中在四件事：在不可信网络上保护传输、访问只对内网开放的资源、更换出口 IP 的地理位置、以及减少本地网络对你访问行为的可见度。超出这四件事的宣传大多站不住脚。
参考来源: NIST SP 800-77 Rev.1 — Guide to IPsec VPNs (https://csrc.nist.gov/pubs/sp/800/77/r1/final) | Google Transparency Report — HTTPS encryption on the web (https://transparencyreport.google.com/https/overview)

VPN有什么用？公共 Wi-Fi 防护、远程办公、隐藏出口 IP、跨区域访问、开发调试 —— 逐条说明 VPN 用途在每个场景里究竟解决了什么，又解决不了什么。

问 VPN有什么用，答案取决于你是谁。企业 IT 的答案是远程办公，工程师的答案是访问内网环境，普通用户的答案通常是公共 Wi-Fi 与出口 IP。下面七类 VPN 用途按实际使用频率排列，每条都写清楚它的边界。

## 1. 远程访问企业内网

这是 VPN 被发明出来的原因。公司的文件服务器、数据库、内部系统只监听内网地址，员工在外面访问不到。VPN 让远程设备在逻辑上「进入」这个内网，拿到一个内网 IP。

这类部署通常是 IPsec 或 SSL VPN 网关，配合双因素认证。需要注意的是：连上之后，公司同样具备了观察这台设备流量的条件。

## 2. 在不可信网络上保护传输

机场、酒店、商场的 Wi-Fi 属于典型的不可信网络。风险有两类：同一网络下的其他人嗅探流量，以及热点本身被伪造。

HTTPS 已经解决了大部分内容层面的问题。但仍然暴露的是：

- DNS 查询（除非启用了 DoH/DoT）
- TLS 握手中的 SNI 字段，即你访问的域名
- 仍使用明文协议的老旧客户端

VPN 把这些都塞进了加密隧道里，代价是把可见性移交给服务商。

## 3. 更换出口 IP 的地理位置

服务判断你所在地区，主要依据是出口 IP 对应的地理数据库。换了服务器，判断结果就变了。

但要清楚这只影响 IP 这一个信号。已登录的账号、账号注册地、支付方式所属国家、设备语言与时区，都会继续暴露真实情况。很多服务的地区判定是多信号加权的，单换 IP 未必够。

## 4. 减少本地网络对访问行为的可见度

家庭宽带的运营商在技术上可以看到你解析了哪些域名、连接了哪些 IP。VPN 之后，它只能看到你和一个固定地址在持续通信。

这是一次信任转移，不是消除。所以服务商的 [日志政策](/vpn日志政策/) 才是这个场景里唯一值得深究的事。

## 5. 开发与运维

工程师用 VPN 的理由通常很具体：

- 访问只对特定 IP 白名单开放的测试环境
- 验证服务在不同地区的 CDN 解析结果
- 连接部署在云上私有子网中的机器
- 在本地复现异地用户遇到的网络问题

## 6. 家庭网络的远程接入

在家里的路由器或 NAS 上跑一个 VPN 服务端，出门时连回家，就能访问家里的 NAS、摄像头、打印机，而不必把这些设备直接暴露在公网上。WireGuard 因为配置简单、资源占用低，在这个场景里很常见。

## 7. 多设备统一出口

在路由器上配置 VPN，整个家庭网络共用一个出口。电视盒子、游戏机这类无法安装客户端的设备也被覆盖。代价是不能按应用分流，且路由器的加解密性能常常成为瓶颈。

## VPN有什么用之外：它做不到的事

说清楚边界比罗列好处更有价值：

| 常见宣传 | 实际情况 |
|---|---|
| 防病毒、防木马 | 无关。加密的是传输过程，不检查内容 |
| 完全匿名 | 做不到。IP 只是识别信号之一 |
| 加快网速 | 通常反而更慢，见 [VPN 与网速](/vpn速度/) |
| 防止账号被盗 | 无关。密码强度和二次验证才是对应措施 |
| 让你不被追踪广告 | 有限。Cookie 和浏览器指纹不受 IP 影响 |

### 常见问题

Q: 在咖啡店用公共 Wi-Fi，现在还需要 VPN 吗？
A: 价值比十年前小，但没有归零。HTTPS 保护了内容，但域名、DNS 查询、以及仍在用明文协议的老应用依然暴露。如果只是刷已经登录的主流网站，风险确实不高。

Q: VPN 能提高游戏或视频的网速吗？
A: 一般不能。它增加了一段绕路和加解密开销。极少数情况下，如果默认路由绕远、而 VPN 线路更直，延迟会下降，但这属于路由优化的效果，不是加密带来的。

Q: 公司发的 VPN 和商用 VPN 是一回事吗？
A: 技术同源，目的相反。公司 VPN 让你进入内网，流量和访问记录对公司可见；商用 VPN 让你出去，把可见性交给服务商。

Q: 用 VPN 可以避免被网站限流或封号吗？
A: 不可靠。风控系统同时看账号行为、设备指纹和支付信息，突然更换出口地区反而可能触发额外验证。

---

# VPN类型有哪些：远程访问、站点互联与四种部署形态

URL: https://yalgorup.com/vpn类型/
类型: concept
专题: basics
更新: 2026-08-01
一句话回答: VPN类型按用途分两类：远程访问 VPN（单个设备连入一个网络）和站点到站点 VPN（两个网络之间长期互联）。按部署形态分四种：系统客户端、浏览器扩展、路由器级和自建服务器，覆盖范围与维护成本依次不同。
参考来源: RFC 4026 — Provider Provisioned VPN Terminology (https://www.rfc-editor.org/rfc/rfc4026) | WireGuard — Quick Start (https://www.wireguard.com/quickstart/)

VPN类型分两个维度：按用途分远程访问 VPN 与站点到站点 VPN，按部署分客户端、浏览器扩展、路由器与自建服务器。每种 VPN 类型的适用场景和代价各不相同。

谈 VPN类型容易混乱，因为「类型」在两个维度上都成立：一个是用途，一个是部署形态。把这两条线分开看，剩下的选择就很清楚了。

## 按用途划分

### 远程访问 VPN

一台设备连入一个远端网络。个人用的商用 VPN、公司的办公 VPN 都属于这一类。特点是连接由客户端主动发起，用完即断。

### 站点到站点 VPN

两个固定网络之间建立长期隧道，例如总部和分公司的局域网互通。隧道建在两端的网关设备上，终端设备完全无感知，也不需要安装任何软件。

按实现方式又分为 Intranet VPN（同一组织内部）和 Extranet VPN（连接合作伙伴网络，通常只开放部分资源）。

## 按部署形态划分

### 1. 系统客户端

最常见的形态。客户端创建虚拟网卡、改写路由表，接管整机流量。

- 覆盖：全系统所有应用
- 优势：可以做分流、Kill Switch、DNS 接管
- 代价：需要系统级权限

### 2. 浏览器扩展

只作用于安装它的那个浏览器，绝大多数实现是 HTTPS 代理而非真正的 VPN 隧道。

- 覆盖：仅该浏览器
- 优势：切换快，不影响其他应用
- 代价：其他应用完全不受保护；扩展权限很大，可读取页面内容

### 3. 路由器级

在路由器固件（如 OpenWrt）里配置 VPN 客户端，所有连入这台路由器的设备共用隧道。

- 覆盖：整个局域网，包括电视、游戏机
- 优势：一次配置，设备无感
- 代价：无法按应用分流；加解密性能受限于路由器硬件

### 4. 自建服务器

在自己租的 VPS 上部署 WireGuard 或 OpenVPN 服务端。

- 覆盖：取决于客户端配置
- 优势：日志由自己掌握，成本可控
- 代价：出口 IP 独享意味着可识别性更强；服务器的安全维护、密钥轮换全部自理；机房 IP 段本身也可能被服务判定为数据中心 IP

## 一张对照表

| 形态 | 覆盖范围 | 配置难度 | 典型使用者 |
|---|---|---|---|
| 系统客户端 | 全设备 | 低 | 个人日常 |
| 浏览器扩展 | 单浏览器 | 最低 | 临时换 IP |
| 路由器 | 全局域网 | 高 | 家庭、小型办公室 |
| 自建服务器 | 自定义 | 最高 | 工程师、注重日志可控者 |
| 站点到站点 | 两个网络 | 高 | 企业 IT |

## 各种 VPN类型 该怎么选

如果只是个人日常使用，系统客户端几乎总是正确答案 —— 它覆盖全面，又保留了随时关闭的灵活性。

需要保护电视盒子、游戏机这类无法装客户端的设备时，才值得付出路由器配置的成本。

而自建的价值在于「知道服务器上到底跑了什么」，不在于更快或更安全。选择之前先看清楚代价，评估方法见 [如何评估一个 VPN](/如何选择vpn/)。

### 常见问题

Q: 浏览器里的免费 VPN 扩展算真 VPN 吗？
A: 严格说不算。它们大多是浏览器代理，只接管该浏览器的请求，其他应用照常走原网络，且扩展拥有读取页面内容的权限，风险不小。

Q: 自建 VPN 是不是比商用的更安全？
A: 在「没人替你记录日志」这点上更可控，但出口 IP 独属于你，反而更容易被关联到个人。而且服务器安全、密钥管理、系统更新都得自己负责。

Q: 家用路由器跑 VPN 速度慢是什么原因？
A: 多数家用路由器没有加解密硬件加速，主频也低。同样的线路在电脑上能跑满，在路由器上可能只有几十 Mbps。

Q: 一台设备可以同时连两个 VPN 吗？
A: 可以，通常用虚拟机或容器实现嵌套（双跳），但延迟叠加、排错困难，收益一般不值得。

---

# VPN和代理的区别在哪？与 Tor 三者的机制对比

URL: https://yalgorup.com/vpn与代理区别/
类型: concept
专题: basics
更新: 2026-08-01
一句话回答: VPN和代理的区别可以用三点概括：代理工作在应用层、只接管配置了它的那个程序、多数不加密；VPN 工作在网络层，接管整机流量并全程加密；Tor 则用三层中继换取匿名性，代价是速度极慢。
参考来源: RFC 1928 — SOCKS Protocol Version 5 (https://www.rfc-editor.org/rfc/rfc1928) | Tor Project — How Tor Works (https://community.torproject.org/onion-services/overview/)

VPN和代理的区别在哪？HTTP/SOCKS5 代理、VPN 与 Tor 在工作层级、加密范围、覆盖面和信任模型上的具体差别，以及各自适合解决什么问题。

VPN和代理的区别经常被简化成「代理不加密、VPN 加密」，这只对了一半。真正的差别有三条：作用在哪一层、加不加密、覆盖哪些流量。把 Tor 放进来一起比，三者的定位会更清楚。

## 一张表先看结论

| | HTTP/SOCKS 代理 | VPN | Tor |
|---|---|---|---|
| 工作层级 | 应用层 | 网络层 | 应用层（覆盖网络） |
| 加密 | 通常没有 | 全程加密 | 三层逐跳加密 |
| 覆盖范围 | 单个程序 | 整机 | Tor 浏览器或经配置的程序 |
| 跳数 | 1 | 1 | 3 |
| 速度 | 快 | 略有损耗 | 很慢 |
| 谁知道你是谁 | 代理服务器 | VPN 服务商 | 只有入口节点 |
| 谁知道你访问什么 | 代理服务器 | VPN 服务商 | 只有出口节点 |

## 代理：只是转一手

代理服务器代替你去请求目标资源。HTTP 代理理解 HTTP 语义，可以做缓存和内容改写；SOCKS5（RFC 1928）更底层，只负责转发 TCP/UDP 连接，不关心内容。

关键点有两个：

**只有配置了代理的程序才会走它。** 浏览器设了代理，微信、系统更新照样走原网络。这也是代理经常被误用的原因 —— 用户以为全局生效了。

**代理本身不负责加密。** 如果访问的是 HTTPS 网站，加密来自 HTTPS 而不是代理。SOCKS5 传输的数据对代理服务器和路径上的设备是什么样，取决于上层协议。

## VPN：接管整台设备

VPN 在网络层建立隧道，所有出站 IP 数据包都被加密封装。这带来了两个代理没有的特性：

- 覆盖全系统，包括那些根本没有代理设置的应用
- DNS 查询也能被接管，减少泄露面（前提是实现正确，见 [DNS 泄露](/vpn泄露/)）

代价是需要系统级权限，切换不如代理灵活。

## Tor：用多跳换匿名

Tor 的设计目标和前两者不同 —— 它要保证**没有任何一个节点同时掌握两端信息**。

流量依次经过入口节点、中间节点、出口节点，客户端为每一跳单独加密。入口节点知道你的 IP，但看不到最终目的地；出口节点知道目的地，但不知道你是谁；中间节点两头都不知道。

代价非常直接：三跳绕行，节点由志愿者运营，带宽有限，延迟通常几百毫秒起步。此外出口节点能看到未加密的内容，所以在 Tor 里访问 HTTP 网站依然危险。

## VPN和代理的区别之后：该用哪一个

- **只是想让某个程序换个出口 IP** —— 代理够用，别指望它提供隐私。
- **想让整台设备的流量都不被本地网络看到** —— VPN。
- **威胁模型里包含「不能让任何单一方关联身份与行为」** —— Tor。

一个务实的判断方法：先明确你在防谁。防同一个 Wi-Fi 下的其他人，VPN 足够；防的是掌握全局观测能力的对手，那么 VPN 的单跳架构本身就不成立，因为服务商这一个点就掌握了全部信息。

### 常见问题

Q: SOCKS5 代理有加密吗？
A: 协议本身没有。SOCKS5 只规定了如何转发连接和做身份验证，数据是否加密取决于上层协议。要加密需要在外面再套一层，例如 TLS。

Q: Tor 可以替代 VPN 吗？
A: 日常用不合适。三跳中继带来的延迟通常在数百毫秒以上，视频和游戏基本不可用。它面向的是需要强匿名的场景。

Q: VPN 和 Tor 一起用有意义吗？
A: 有特定意义但也有代价。先 VPN 后 Tor 可以让本地网络看不到你在用 Tor；顺序反过来则改变了信任假设。除非清楚自己在防谁，否则不建议叠加。

Q: 为什么有些服务能识别出我在用代理或 VPN？
A: 主要靠 IP 情报库。数据中心 IP 段、同一 IP 上异常多的并发用户、以及时区与 IP 地区不一致，都是判定信号。

---

# VPN协议总览：五种主流协议的机制与取舍

URL: https://yalgorup.com/vpn协议/
类型: hub
专题: protocols
更新: 2026-08-01
一句话回答: 值得使用的 VPN协议只有三个：WireGuard（最快、代码最简洁）、OpenVPN（最成熟、伪装能力最强）、IKEv2/IPsec（移动端切换网络最稳）。PPTP 已被攻破，L2TP 单独使用不加密，两者都不该再作为首选。
参考来源: WireGuard — Next Generation Kernel Network Tunnel (whitepaper) (https://www.wireguard.com/papers/wireguard.pdf) | RFC 7296 — Internet Key Exchange Protocol Version 2 (IKEv2) (https://www.rfc-editor.org/rfc/rfc7296) | OpenVPN Community Documentation (https://openvpn.net/community-resources/)

VPN协议怎么选？WireGuard、OpenVPN、IKEv2/IPsec、L2TP、PPTP 与 SSTP 六种 VPN 协议的加密方案、性能特征与适用场景横向对比。

VPN协议决定了连接的速度、稳定性和能不能连上，比加密算法的名字重要得多。这一页把六种主流 VPN协议放在同一张表里对比，并说明各自适合什么场景。

## 协议到底决定什么

一个 VPN协议规定三件事：

1. **怎么建立信任** —— 用证书、预共享密钥还是公钥；密钥怎么协商。
2. **怎么封装数据** —— 外层用 UDP、TCP 还是自定义格式，包头长什么样。
3. **怎么维持连接** —— 断线怎么恢复，IP 变了怎么办，多久换一次密钥。

同一家服务商切换协议，速度和稳定性会有明显差别，原因就在这三件事上。

## 五种协议横向对比

| 协议 | 出现时间 | 加密方案 | 传输 | 速度 | 现状 |
|---|---|---|---|---|---|
| WireGuard | 2016 起，2020 进入 Linux 内核 | ChaCha20-Poly1305 + Curve25519 | UDP | 最快 | 推荐 |
| OpenVPN | 2001 | 依赖 OpenSSL，通常 AES-256-GCM | UDP / TCP | 中等 | 推荐 |
| IKEv2/IPsec | 2005（RFC 4306），现为 RFC 7296 | AES-GCM / ChaCha20 | UDP 500/4500 | 快 | 推荐 |
| SSTP | 2007 | TLS | TCP 443 | 中等 | 仅 Windows 场景 |
| L2TP/IPsec | 1999（L2TP 本身不加密） | 依赖 IPsec | UDP 1701/500/4500 | 慢 | 不推荐 |
| PPTP | 1999 | MPPE + MS-CHAPv2 | TCP 1723 + GRE | 快 | 已不安全 |

## VPN协议怎么按场景选

**日常使用、追求速度** —— WireGuard。握手只需一个往返，加解密开销小，移动设备上省电优势明显。

**网络限制严格、UDP 被拦截** —— OpenVPN over TCP 443。它看起来最像普通 HTTPS 流量，穿透能力最强，代价是 TCP-over-TCP 带来的重传叠加。

**手机上频繁在 Wi-Fi 和蜂窝之间切换** —— IKEv2/IPsec。MOBIKE（RFC 4555）让连接在 IP 变化后自动重绑，不用重新握手。

**需要伪装成普通网页流量** —— 单靠协议不够，要看 [混淆与伪装协议](/vpn混淆协议/)。

## 一个常被忽略的事实

协议强度是下限，不是上限。

同样用 WireGuard，一家服务商可能把客户端的 DNS 处理做得滴水不漏，另一家可能在断线瞬间让流量裸奔。协议相同，实际暴露风险差很多。

所以看协议之外，还要看实现层面的细节：Kill Switch 是否真的生效、DNS 是否被正确接管、密钥多久轮换一次。这些在 [如何评估一个 VPN](/如何选择vpn/) 里有具体的检查清单。

### 常见问题

Q: WireGuard 和 OpenVPN 到底选哪个？
A: 追求速度和电量效率选 WireGuard；需要在限制严格的网络里连上、或者需要走 TCP 443 伪装成 HTTPS 时选 OpenVPN。多数客户端支持随时切换，可以两个都留着。

Q: 协议选对了就安全了吗？
A: 不是。协议只保证密码学层面的强度，服务商的实现（DNS 处理、密钥管理、日志策略）同样决定结果。

Q: 为什么手机上默认是 IKEv2？
A: 因为 MOBIKE 机制允许连接在 IP 地址变化时保持不断 —— 从 Wi-Fi 切到蜂窝网络时不用重连，体验最好。

Q: 还有必要了解 PPTP 吗？
A: 只需要知道一件事：它的 MS-CHAPv2 认证在 2012 年就被证明可在有限时间内破解，不应再用于任何需要保密的场景。

---

# WireGuard 是什么？现代 VPN 协议的设计与代价

URL: https://yalgorup.com/wireguard/
类型: protocol
专题: protocols
更新: 2026-08-01
一句话回答: WireGuard 是 2016 年提出的现代 VPN 协议，2020 年随 Linux 5.6 内核合入主线。它只用一套固定的现代加密算法、代码量约四千行、握手只需一个往返，因此速度和可审计性都优于上一代协议。
参考来源: WireGuard — Next Generation Kernel Network Tunnel (whitepaper, Jason A. Donenfeld) (https://www.wireguard.com/papers/wireguard.pdf) | RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols (https://www.rfc-editor.org/rfc/rfc8439) | RFC 7748 — Elliptic Curves for Security (Curve25519) (https://www.rfc-editor.org/rfc/rfc7748) | The Noise Protocol Framework (https://noiseprotocol.org/noise.html)

WireGuard 的加密套件、一次往返握手、Cryptokey Routing 机制与漫游能力，以及固定内网 IP 带来的隐私问题和厂商的应对方式。

## 它解决了什么问题

上一代协议有个共同毛病：为了兼容一切，它们支持大量可协商的算法组合。结果是配置复杂、实现庞大、历史包袱重，而每一个被保留的弱算法都是潜在的降级攻击点。

WireGuard 的思路相反 —— **不给选择**。加密套件固定为：

| 用途 | 算法 |
|---|---|
| 对称加密与认证 | ChaCha20-Poly1305（RFC 8439） |
| 密钥交换 | Curve25519（RFC 7748） |
| 哈希 | BLAKE2s（RFC 7693） |
| 密钥派生 | HKDF |

如果某个算法将来被攻破，做法是发布新版本协议，而不是在旧版本里协商替换。

## 握手：一个往返

WireGuard 的握手基于 Noise 协议框架的 `Noise_IK` 模式。客户端发起、服务端响应，一个往返完成，之后立即可以传数据。

对比 OpenVPN 的 TLS 握手需要多次往返，这个差别在高延迟线路上非常直观 —— 连接建立时间从几百毫秒降到一个 RTT。

会话密钥会定期更换。发送方在密钥使用约 120 秒后主动发起新的握手，超过约 180 秒未更新的密钥会被拒绝，从而保证前向保密。

## Cryptokey Routing

这是 WireGuard 最有特点的设计：配置文件里每个 peer 只有两样东西 —— 一个公钥，一组 `AllowedIPs`。

```ini
[Peer]
PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
AllowedIPs = 10.0.0.2/32
Endpoint = 203.0.113.10:51820
```

含义是双向的：

- **出方向** —— 目的地属于 `10.0.0.2/32` 的包，用这个公钥加密后发给它。
- **入方向** —— 用这个公钥解密出来的包，源地址必须落在 `10.0.0.2/32` 里，否则丢弃。

路由决策和身份验证被合并成了一件事，逻辑上非常干净。

## 漫游与「安静」特性

WireGuard 不维护传统意义上的连接状态。当服务端收到一个用已知密钥正确加密的包，且源地址与记录的不同，它就更新对端地址。所以手机从 Wi-Fi 切到 4G，隧道不会断，也不需要重新握手。

另一个设计是默认沉默：对于无法通过认证的数据包，服务端不回任何响应。从外部扫描的角度看，这个端口像是没开。

## 需要注意的代价

**没有内置的动态地址分配。** 原生协议里，每个 peer 的内网 IP 是配置文件写死的。自建时这没问题，但商用服务给成千上万用户分配固定内网 IP，就等于给每个账号发了一个长期标识。主流服务商的做法是在服务端再加一层 NAT，或者让内网 IP 动态化 —— 这属于厂商实现，不是协议自带。

**特征明显。** 报文头部有固定的类型字段和长度模式，DPI 设备识别 WireGuard 流量并不困难。在会主动阻断 VPN 协议的网络里，裸 WireGuard 往往连不上。

**只有 UDP。** 遇到只放行 TCP 的网络就没有办法，除非借助外部封装工具。

## 什么时候该选 WireGuard

日常使用、看视频、下载、移动设备省电 —— WireGuard 基本是最优解。

需要伪装、需要走 TCP、或者所在网络会阻断 UDP 时，[OpenVPN](/openvpn/) 仍然更合适。

### 常见问题

Q: WireGuard 支持 TCP 吗？
A: 原生只支持 UDP。需要 TCP 时要靠外层工具封装（例如 udp2raw、wstunnel），这不属于协议本身的能力。

Q: WireGuard 的固定 IP 问题严重吗？
A: 自建场景无所谓。商用场景下，如果服务商直接把内网 IP 与账号绑定并长期不变，等于留下了可关联的标识。主流服务商通过双重 NAT 或动态分配来规避，选服务时可以留意这点是否被说明。

Q: 为什么 WireGuard 连上后没有「已连接」状态？
A: 它被设计成无状态的：没有持续的会话管理，只在有数据时才发包。判断是否通了要看是否有握手记录和实际流量。

Q: 它能防止流量被识别吗？
A: 不能。WireGuard 报文有明确的格式特征，很容易被识别为 WireGuard。需要隐蔽性必须叠加混淆层，见 混淆与伪装协议。

---

# OpenVPN 详解：为什么它到今天仍然不可替代

URL: https://yalgorup.com/openvpn/
类型: protocol
专题: protocols
更新: 2026-08-01
一句话回答: OpenVPN 发布于 2001 年，用 TLS 做控制通道、用独立的数据通道传输加密载荷。它最大的优势是灵活：可以跑在 UDP 或 TCP 上、可以用 443 端口伪装成 HTTPS 流量，因此在限制严格的网络里穿透能力最强。
参考来源: OpenVPN Community Resources — Documentation (https://openvpn.net/community-resources/) | RFC 8446 — TLS 1.3 (https://www.rfc-editor.org/rfc/rfc8446) | OpenVPN Data Channel Offload (DCO) (https://openvpn.net/as-docs/dco.html)

OpenVPN 的 TLS 控制通道与数据通道结构、UDP 与 TCP 模式的区别、tls-crypt 的作用，以及 DCO 内核卸载如何改善它的性能短板。

OpenVPN 是目前仍在广泛使用的最老牌 VPN 协议之一。它的价值不在速度，而在灵活 —— 只有 OpenVPN 能同时提供 UDP/TCP 双模式、443 端口伪装和高度可定制的配置。

## 双通道结构

OpenVPN 把连接拆成两条逻辑通道：

**控制通道** 跑标准 TLS。负责验证服务器证书、验证客户端身份、协商数据通道使用的密钥和算法。这一步复用了成熟的 TLS 生态，也意味着它继承了 TLS 的安全属性和历史问题。

**数据通道** 用协商好的对称密钥加密实际流量，常见配置是 AES-256-GCM 或 ChaCha20-Poly1305。

两条通道复用同一个 UDP 或 TCP 连接。这种分离让 OpenVPN 可以在不中断传输的情况下重新协商密钥。

## UDP 与 TCP 的取舍

| | UDP 模式 | TCP 模式 |
|---|---|---|
| 延迟 | 低 | 较高 |
| 丢包处理 | 交给上层应用 | 隧道层重传 |
| 网络变差时 | 平缓退化 | 可能急剧恶化 |
| 穿透能力 | 一般 | 强，尤其 443 端口 |

TCP 模式的问题有个专门名字：**TCP meltdown**。隧道内是 TCP、隧道外也是 TCP，两层重传机制互相叠加，一旦丢包率上升，速度会掉得比想象中快得多。

所以经验法则是：能用 UDP 就用 UDP，只在连不上时才退到 TCP。

## 为什么它在受限网络里更好用

三个原因叠加：

1. **可以监听 443 端口。** 这是 HTTPS 的标准端口，在几乎所有网络里都放行。
2. **外层是 TLS。** 流量的第一印象与访问网站高度相似。
3. **`tls-crypt` 把控制通道也加密了。** 握手阶段的明文特征被消除，主动扫描时服务端也不会给出可识别的响应。

需要说明的是，这只是「不显眼」，不是真正的伪装。深度检测仍可以通过报文长度分布、时序特征做出判断。真正的伪装需要专门的混淆层，见 [混淆与伪装协议](/vpn混淆协议/)。

## 性能短板与 DCO

传统 OpenVPN 完全运行在用户空间：数据包要从内核复制到用户态、加解密、再复制回内核。这一来一回的上下文切换是它比不过 WireGuard 的主要原因。

OpenVPN 2.6 引入了 **DCO（Data Channel Offload）**：控制通道仍在用户空间，数据通道下沉到内核模块处理。在高带宽场景下改善明显。前提是客户端、服务端和操作系统三方都支持。

## 什么时候该选 OpenVPN

- 所在网络封锁 UDP，或对 VPN 协议做了主动阻断
- 需要复杂的路由策略、脚本钩子、按证书区分权限
- 设备或系统还不支持 WireGuard

如果没有这些约束，[WireGuard](/wireguard/) 在速度和省电上更划算。多数商用客户端支持一键切换，遇到连不上时换个协议试试，往往比换服务器有效。

### 常见问题

Q: OpenVPN 用 UDP 还是 TCP？
A: 默认且优先 UDP，延迟低、无重传叠加。只有在 UDP 被封锁或丢包严重时才切 TCP，代价是 TCP-over-TCP 会在网络变差时急剧退化。

Q: OpenVPN 比 WireGuard 慢多少？
A: 取决于硬件和是否启用 DCO。传统用户空间实现在高带宽下差距明显；启用 DCO 后差距大幅缩小。低带宽日常使用两者感受不出区别。

Q: tls-auth 和 tls-crypt 有什么区别？
A: tls-auth 给控制包加 HMAC 校验，能挡住扫描和 DoS，但握手内容仍可见；tls-crypt 直接加密整个控制通道，隐蔽性更好，是现在的推荐做法。

Q: .ovpn 配置文件可以随便用别人的吗？
A: 不建议。配置文件里包含证书、密钥和服务器地址，等于把信任完全交给提供者，其中可以指定 DNS、路由甚至执行脚本。

---

# IKEv2/IPsec 是什么：移动设备上最稳的 VPN 协议

URL: https://yalgorup.com/ikev2-ipsec/
类型: protocol
专题: protocols
更新: 2026-08-01
一句话回答: IKEv2 是 IPsec 体系里负责密钥协商的协议（RFC 7296），配合 ESP 完成加密封装。它最大的特点是 MOBIKE 漫游支持 —— 手机在 Wi-Fi 和蜂窝网络之间切换时连接不断，因此成为移动端的原生首选。
参考来源: RFC 7296 — Internet Key Exchange Protocol Version 2 (IKEv2) (https://www.rfc-editor.org/rfc/rfc7296) | RFC 4303 — IP Encapsulating Security Payload (ESP) (https://www.rfc-editor.org/rfc/rfc4303) | RFC 4555 — IKEv2 Mobility and Multihoming Protocol (MOBIKE) (https://www.rfc-editor.org/rfc/rfc4555) | RFC 3948 — UDP Encapsulation of IPsec ESP Packets (https://www.rfc-editor.org/rfc/rfc3948)

IKEv2 的两阶段握手、ESP 封装、NAT 穿透与 MOBIKE 漫游机制，以及为什么 iPhone 和 Windows 把它作为原生首选。

## 先分清 IPsec 里的角色

IPsec 常被当成一个协议，实际上是一组：

| 组件 | 职责 |
|---|---|
| IKEv2 | 协商密钥、验证身份、维护安全关联（SA） |
| ESP | 加密并封装数据包，提供完整性校验 |
| AH | 只做完整性校验不加密，实际很少使用 |

所以「IKEv2/IPsec」这个写法是准确的：前者管协商，后者管传输。

## 两个往返完成握手

IKEv2 的握手比 IKEv1 简洁得多：

1. **IKE_SA_INIT** —— 双方交换 Diffie-Hellman 公开值和随机数，算出共享密钥。这一步之后，后续消息全部加密。
2. **IKE_AUTH** —— 在加密信道里完成身份验证（证书、EAP 或预共享密钥），并建立第一个用于传数据的 Child SA。

之后就可以传输数据了。相比 IKEv1 主模式的六条消息，IKEv2 的往返次数和状态机复杂度都低了一个量级。

## 隧道模式与 NAT 穿透

个人 VPN 用的是**隧道模式**：整个原始 IP 包被加密，外面再套一个新的 IP 头。传输模式只加密载荷、保留原 IP 头，主要用于主机到主机的场景。

原生 ESP 是独立的 IP 协议号（50），不带端口，因此过不了 NAT。解决办法是 RFC 3948 定义的 UDP 封装：检测到路径上有 NAT 时，双方切换到 UDP 4500 端口，把 ESP 包塞进 UDP 里。

这也是为什么 IKEv2 的连接总是和 500、4500 两个端口绑定 —— 以及为什么它很容易被端口级封锁挡住。

## MOBIKE：它的杀手锏

手机的网络环境是不断变化的：出门时从家里的 Wi-Fi 切到 5G，进办公室又切回 Wi-Fi。每次切换，本地 IP 都变了。

对多数协议来说，IP 变了就意味着连接失效、需要重连。MOBIKE 的做法是：安全关联本身与 IP 地址解耦，地址变化时客户端发送一条 `UPDATE_SA_ADDRESSES` 通知，服务端更新记录，隧道继续用原来的密钥。

用户侧的感受是「切网络时视频没有卡」。这是 IKEv2 在移动端长期占优的核心原因。

## 优势与短板

**优势**

- 系统原生支持，无需第三方客户端
- 漫游稳定，断线自动恢复快
- 性能好，多数平台由内核处理加解密

**短板**

- 端口固定，容易被封锁
- 完全没有伪装能力
- 配置由系统管理，可调空间小
- 历史上出现过实现层面的漏洞（例如身份验证配置不当导致的中间人风险），依赖厂商及时更新

## 什么时候用它

手机为主、经常切换网络、且所在网络不会主动封锁 VPN 端口 —— 这是 IKEv2 最舒服的场景。

如果网络会阻断 UDP 500/4500，那么它连不上，此时应换成 [OpenVPN over TCP 443](/openvpn/) 或带混淆的方案。

### 常见问题

Q: IKEv2 和 IPsec 是同一个东西吗？
A: 不是。IPsec 是保护 IP 层通信的整套框架，IKEv2 只是其中负责协商会话密钥的部分，真正加密数据的是 ESP。

Q: 为什么 IKEv2 容易被封？
A: 它固定使用 UDP 500 和 4500 端口，端口特征太明显，限制型网络里直接封端口即可。它没有伪装能力。

Q: IKEv2 和 WireGuard 哪个更适合手机？
A: 都很适合。IKEv2 的漫游是协议内建的成熟机制，系统原生支持更好；WireGuard 更省电、握手更快，但依赖客户端实现漫游体验。

Q: L2TP/IPsec 和 IKEv2/IPsec 有什么区别？
A: 两者都用 IPsec 做加密，但 L2TP 多了一层无谓的封装，开销更大、速度更慢，且常用预共享密钥。IKEv2 在各方面都取代了它。

---

# L2TP、PPTP 与 SSTP：三种旧协议的现状与风险

URL: https://yalgorup.com/l2tp-pptp-sstp/
类型: protocol
专题: protocols
更新: 2026-08-01
一句话回答: PPTP 的 MS-CHAPv2 认证在 2012 年被证明可在有限时间内破解，不应再用于任何需要保密的场景；L2TP 自身完全不加密，必须搭配 IPsec，且双层封装带来额外开销；SSTP 能伪装成 HTTPS，但由微软私有、缺乏公开审计。
参考来源: RFC 2637 — Point-to-Point Tunneling Protocol (PPTP) (https://www.rfc-editor.org/rfc/rfc2637) | RFC 3931 — Layer Two Tunneling Protocol - Version 3 (L2TPv3) (https://www.rfc-editor.org/rfc/rfc3931) | RFC 3193 — Securing L2TP using IPsec (https://www.rfc-editor.org/rfc/rfc3193) | Microsoft — [MS-SSTP] Secure Socket Tunneling Protocol Specification (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sstp/)

PPTP 为什么在 2012 年后被视为不安全、L2TP 为什么必须搭配 IPsec、SSTP 的伪装优势与闭源代价，以及这三者今天还剩下什么用途。

## PPTP：为什么它被判了死刑

PPTP 由微软牵头，1999 年以 RFC 2637 的形式发布，是最早普及的 VPN 协议。它用 TCP 1723 建立控制连接，用 GRE 封装数据，加密依赖 MPPE，身份验证通常是 MS-CHAPv2。

问题出在认证环节。2012 年的公开研究表明，MS-CHAPv2 的握手过程可以被归约成一次 DES 密钥的穷举 —— 也就是说，只要截获握手，就能在可预期的时间内还原出凭据。相应的破解工具随后公开。

这不是「算法老旧、强度偏低」的程度，而是**认证可被离线还原**，后续的加密因此失去意义。

另外两个实际问题：

- GRE 协议不带端口，很多 NAT 环境下无法建立连接
- MPPE 使用 RC4，本身也已被弃用

结论很明确：不要用 PPTP 传输任何你不希望被读到的东西。

## L2TP：它根本不加密

L2TP（RFC 2661，第三版为 RFC 3931）的定位是「建隧道」，规范里就没有加密这回事。所以你看到的永远是 **L2TP/IPsec** 这个组合写法：L2TP 负责封装，IPsec 负责加密。

问题在开销：数据包先被 L2TP 封装一次，再被 IPsec 封装一次，包头叠加，有效载荷变小，加解密也做了两轮。同样的线路，L2TP/IPsec 通常比 IKEv2/IPsec 更慢。

还有一个常见的实现弱点：很多服务用固定的预共享密钥（PSK），且所有用户共用同一个。PSK 一旦泄露，攻击者就具备了发起中间人攻击的前提条件。

L2TP 使用 UDP 1701，配合 IPsec 时还要 500 和 4500，端口特征同样明显。

## SSTP：微软的 HTTPS 伪装

SSTP 出现在 Windows Vista SP1 时代，思路很直接：把 PPP 帧塞进 SSL/TLS 连接，走 TCP 443。

优点是真实的：443 端口几乎不会被封，流量外观接近普通 HTTPS，在限制严格的网络里往往能连上。

代价也很明确：

- **闭源。** 规范虽然公开（MS-SSTP），但实现是微软的，没有像 OpenVPN、WireGuard 那样接受过广泛的独立审计。
- **生态受限。** Windows 原生支持，其他平台要靠第三方实现。
- **TCP-over-TCP。** 和 OpenVPN TCP 模式一样的重传叠加问题。

## 三者对比

| | PPTP | L2TP/IPsec | SSTP |
|---|---|---|---|
| 加密 | MPPE/RC4，认证已被攻破 | IPsec，取决于配置 | TLS |
| 端口 | TCP 1723 + GRE | UDP 1701/500/4500 | TCP 443 |
| 速度 | 快（因为几乎没有保护） | 慢（双层封装） | 中等 |
| 穿透能力 | 差（GRE 过不了 NAT） | 一般 | 好 |
| 开源 | 是 | 是 | 否 |
| 建议 | 不要用 | 有更好选择时不要用 | 仅特定场景 |

## 今天该用什么

这三个协议出现的年代，网络环境和威胁模型都和现在不同。它们留在系统设置里主要是为了兼容老设备。

新的部署应当在 [WireGuard](/wireguard/)、[OpenVPN](/openvpn/) 和 [IKEv2/IPsec](/ikev2-ipsec/) 之间选择。如果一家服务商在 2026 年还把 PPTP 当作卖点列出来，这本身就是一个值得警惕的信号。

### 常见问题

Q: PPTP 现在还有能用的地方吗？
A: 只剩下一种：在完全不涉及敏感数据、只是需要改变出口 IP 的老设备上临时使用。任何涉及账号、支付、隐私的场景都不该用它。

Q: 为什么路由器里还保留着 PPTP 选项？
A: 兼容性遗留。老设备、老系统只支持它，厂商为了不破坏既有配置而保留，并不代表推荐。

Q: L2TP/IPsec 和 IKEv2/IPsec 差在哪？
A: 加密都靠 IPsec，但 L2TP 多套了一层封装，开销更大速度更慢，且没有 MOBIKE 漫游。IKEv2 在功能上完全覆盖它。

Q: SSTP 值得用吗？
A: 只有一种情况：设备是 Windows、网络封锁 UDP、且没有其他选择。同样的伪装效果 OpenVPN over TCP 443 也能做到，而且是开源的。

---

# VPN混淆与伪装协议：当流量特征本身成为问题

URL: https://yalgorup.com/vpn混淆协议/
类型: protocol
专题: protocols
更新: 2026-08-01
一句话回答: VPN混淆解决的是加密解决不了的问题：加密只保证内容不可读，但报文长度、握手模式、端口和时序仍构成可识别的特征。混淆协议的目标是消除这些特征 —— 要么让流量看起来完全随机，要么让它看起来就是一次普通的 HTTPS 访问。
参考来源: Tor Project — obfs4 pluggable transport specification (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs4) | How China Detects and Blocks Shadowsocks (ACM IMC 2020) (https://gfw.report/publications/imc20/en/) | RFC 8446 — TLS 1.3 (https://www.rfc-editor.org/rfc/rfc8446)

VPN混淆是什么？DPI 如何识别 VPN 流量，以及 obfs4、Shadowsocks、TLS 封装、WebSocket+CDN 等混淆协议分别通过什么手段消除特征，代价又是什么。

需要 VPN混淆的场景只有一种：隧道本身没问题，但流量的「样子」被认了出来。这一页先讲 DPI 靠什么识别，再讲两条主流的 VPN混淆技术路线各自的代价。

## DPI 是怎么认出 VPN 的

深度包检测（DPI）设备不需要解密就能做出判断，依据分三类：

**协议指纹。** 每种协议的握手包都有固定结构。WireGuard 的第一个包类型字段固定、长度固定；OpenVPN 的初始报文以特定字节开头；IKEv2 走 UDP 500 —— 这些都是明确的标识。

**统计特征。** 即便报文内容随机，包长度分布、发送节奏、上下行比例仍然带有模式。一条隧道内的视频流和真实的 HTTPS 视频流，在时序上并不完全相同。

**主动探测。** 这是最强的一类。检测方发现可疑连接后，主动去连那台服务器，发送畸形或重放的数据，观察它如何回应。学术界对 Shadowsocks 被主动探测识别的研究（IMC 2020）详细记录过这一模式：不同实现对异常输入的响应差异，本身就成了识别依据。

## 路线一：让流量看起来是随机数据

**obfs4** 是 Tor 的可插拔传输之一。它给流量加一层「看起来毫无结构」的外壳：握手用带认证的密钥交换，攻击者没有服务器公钥就无法发起有效连接（这直接抵抗主动探测），报文还会插入随机长度的填充。

**Shadowsocks** 起源于一个简单的加密 SOCKS5 代理，后来演进为使用 AEAD 加密的方案。它的流量在传输中没有可读的协议头，看上去接近随机字节。

这条路线的弱点在于：**「完全随机」本身也是一种特征**。正常互联网流量很少呈现高熵且无任何协议头的形态，统计上反而显眼。

## 路线二：让流量看起来就是 HTTPS

**TLS 封装** 是最直接的做法 —— 把 VPN 隧道整个塞进一个真实的 TLS 连接里。OpenVPN over TCP 443 就是这个思路的简化版；`stunnel` 一类工具可以给任意协议加上这层外壳。

**WebSocket + TLS + CDN。** 流量伪装成对某个域名的 WebSocket 请求，并经由 CDN 中转。此时前端看到的是访问一个正常网站的 IP，隐蔽性来自「这个地址确实还承载着大量真实流量」。

**基于真实站点的伪装。** 更新的一类方案让服务器在收到非法握手时表现得像一个普通网站 —— 攻击者主动探测时，得到的是一个正常网页，从而无法确认这是代理服务。

这条路线的代价是被绑在 TCP 上，以及多一层握手带来的延迟。

## 一张对比

| 方案 | 伪装成 | 抗主动探测 | 传输 | 主要代价 |
|---|---|---|---|---|
| obfs4 | 随机数据 | 强 | TCP | 高熵流量本身可被统计识别 |
| Shadowsocks (AEAD) | 随机数据 | 取决于实现 | TCP/UDP | 早期实现有已知的探测弱点 |
| OpenVPN TCP 443 + tls-crypt | 类 HTTPS | 中 | TCP | TCP-over-TCP 退化 |
| stunnel / TLS 封装 | HTTPS | 中 | TCP | 额外握手与开销 |
| WebSocket + TLS + CDN | 访问某网站 | 强 | TCP | 延迟高，依赖第三方 CDN |

## VPN混淆方案的实际选择

先确认问题出在哪一层。连不上有很多种原因：服务器 IP 被封、端口被封、协议被识别，或者只是线路拥堵。

- **换服务器就好了** → IP 层封锁，不需要混淆。
- **换端口就好了** → 端口封锁，用 443 即可。
- **换什么服务器都在握手阶段失败** → 协议特征被识别，这时才需要混淆。

混淆不是越多越好。每加一层都要付出延迟和带宽的代价，在不需要的网络环境里，裸 [WireGuard](/wireguard/) 永远是更快的选择。

### 常见问题

Q: 加密了为什么还能被识别出是 VPN？
A: 识别不需要读内容。WireGuard 握手包的长度是固定的，OpenVPN 的初始报文有可辨认的字节模式，IKEv2 用固定端口 —— 这些都不需要解密就能看出来。

Q: 混淆和加密是一回事吗？
A: 不是。加密解决「看不懂」，混淆解决「看不出这是什么」。两者正交，混淆层通常叠加在已加密的隧道之外。

Q: 商用 VPN 里的「隐身模式」是什么？
A: 各家叫法不同，本质多是把隧道封装进 TLS 或对报文做填充与随机化。具体实现通常不公开，效果需要在实际网络里验证。

Q: 用了混淆会慢多少？
A: 取决于方案。TLS 封装通常有一层额外握手和几十字节的包头开销；如果还被迫走 TCP，网络稍差时下降会更明显。

---

# VPN安全专题：加密、日志、泄露与断网保护

URL: https://yalgorup.com/vpn安全/
类型: hub
专题: security
更新: 2026-08-01
一句话回答: VPN安全 由三层决定：密码学（算法与密钥交换）、实现（DNS 接管、断线处理、IPv6）、运营（日志政策、审计、司法管辖）。第一层各家几乎没有差别，真正拉开距离的是后两层。

VPN安全专题总览：加密算法与密钥交换如何工作、无日志政策该怎么读、DNS 与 IPv6 泄露怎么自测、Kill Switch 怎么验证。五篇文章覆盖隐私相关的全部机制。

VPN安全 不是一个是非题。把它拆成密码学、客户端实现、服务商运营三层之后，每一层都有可以检验的具体标准 —— 这个专题就按这三层展开。

## 三层结构

**第一层：密码学。** [VPN加密原理](/vpn加密/) 解释对称与非对称加密的分工、密钥怎么在不安全的线路上协商出来、什么是前向保密。结论是：这一层各家没有实质差别。

**第二层：客户端实现。** [DNS泄露与检测](/vpn泄露/) 和 [Kill Switch](/kill-switch/) 讲的是同一件事的两面 —— 隧道之外还有没有流量在跑。这两篇给的方法你可以立刻自测。

**第三层：运营。** [VPN日志政策](/vpn日志政策/) 教你读隐私政策的措辞，[VPN安全吗](/vpn安全吗/) 把整体风险归纳成六个可回答的问题。

## 一份五分钟自测

连上 VPN 之后，依次确认：

| 检查 | 期望结果 | 出问题看这篇 |
|---|---|---|
| IPv4 出口 | 显示服务器地址 | [泄露检测](/vpn泄露/) |
| IPv6 出口 | 服务器地址或无 IPv6 | [泄露检测](/vpn泄露/) |
| DNS 服务器 | 不含本地运营商 | [泄露检测](/vpn泄露/) |
| 强杀客户端进程 | 网络立即中断 | [Kill Switch](/kill-switch/) |

## 相关专题

协议层面的取舍见 [VPN协议专题](/vpn协议/)；把这些标准合并成一份选购清单，见 [如何选择VPN](/如何选择vpn/)；公开的加密普及数据见 [数据专题](/数据/)。

### 常见问题

Q: 这个专题里最该先读哪一篇？
A: 如果只读一篇，读 泄露检测 —— 它给出的自测清单可以立刻用在你现在的连接上。

Q: 需要懂密码学才能读吗？
A: 不需要。加密那篇只解释「为什么要两种加密」「什么是前向保密」这类概念，不涉及数学推导。

---

# VPN加密原理：对称、非对称与前向保密讲明白

URL: https://yalgorup.com/vpn加密/
类型: security
专题: security
更新: 2026-08-01
一句话回答: VPN加密由两部分组成：非对称加密完成密钥交换，对称加密负责传输数据。前者解决「如何在不安全的线路上商定密钥」，后者解决「如何高效地加密大量数据」。现代实现普遍采用 AEAD 算法，加密与完整性校验一步完成。
参考来源: FIPS 197 — Advanced Encryption Standard (AES) (https://csrc.nist.gov/pubs/fips/197/final) | NIST SP 800-38D — Galois/Counter Mode (GCM) (https://csrc.nist.gov/pubs/sp/800/38/d/final) | RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols (https://www.rfc-editor.org/rfc/rfc8439) | RFC 5869 — HMAC-based Key Derivation Function (HKDF) (https://www.rfc-editor.org/rfc/rfc5869)

VPN加密原理讲明白：对称与非对称加密的分工、AES-256 与 ChaCha20-Poly1305 的区别、密钥交换如何在不安全线路上完成，以及「军用级加密」这类宣传该怎么看。

VPN加密听起来复杂，实际只有两件事：先安全地商量出一把钥匙，再用这把钥匙高效地加密流量。所有 VPN加密方案的差别，都落在这两步的具体做法上。

## 两种加密，各管一段

**对称加密**：加密和解密用同一把钥匙。速度快，适合处理大量数据，问题是双方得先有同一把钥匙。

**非对称加密**：一对公钥私钥，公钥加密的只有私钥能解。可以在公开信道上安全地建立信任，但运算慢得多，不适合加密整条流量。

VPN 的做法是把两者组合起来：先用非对称手段协商出一把临时的对称密钥，之后所有数据都用对称加密传输。这个组合在 TLS、IPsec、WireGuard 里的形式不同，思路完全一致。

## 密钥交换：在窃听下达成共识

Diffie-Hellman 解决了一个看起来矛盾的问题：两个人在被完全监听的信道上对话，最后各自得到同一个秘密，而窃听者拿不到。

原理是双方各自保留一个私有值，交换各自的公开值，再用对方的公开值和自己的私有值算出同一个结果。窃听者看到两个公开值，却无法反推。

现代实现用椭圆曲线版本（ECDHE、Curve25519），密钥更短、运算更快。

**关键在于那个 E —— ephemeral，临时的。** 每次连接生成全新的密钥对，用完丢弃。这样即使服务器的长期私钥日后泄露，攻击者也无法解开之前录制的流量，因为那些会话密钥根本没有被存储过。这就是**前向保密**。

## AEAD：加密和校验必须一起做

早期的做法是先加密、再单独算一个校验值，两步分开。顺序搞错就会出问题 —— 密码学史上有一批漏洞正是源于「先解密后校验」这个次序。

AEAD（带关联数据的认证加密）把两件事合并成一个原语。现在 VPN 里常见的两套：

| 算法组合 | 加密 | 认证 | 适合的场景 |
|---|---|---|---|
| AES-256-GCM | AES | GCM 模式内建 | 有 AES-NI 硬件加速的 x86 设备 |
| ChaCha20-Poly1305 | ChaCha20 | Poly1305 | 移动设备、路由器等无硬件加速环境 |

安全性上两者都没有已知的实用攻击。选择依据是硬件：ARM 手机和低端路由器跑 ChaCha20 常常快出一倍以上，而带 AES-NI 指令的电脑上则反过来。

## 密钥派生与轮换

协商出来的共享秘密不会被直接拿来加密。它先经过 HKDF（RFC 5869）这类密钥派生函数，产出多把用途不同的密钥 —— 发送方向一把、接收方向一把、校验一把。

好的实现还会定期更换会话密钥。WireGuard 大约每两分钟主动重新握手，OpenVPN 默认一小时重新协商一次。轮换越频繁，单把密钥一旦出问题所影响的数据量越小。

## 怎么看服务商的 VPN加密 宣传

看到「军用级 AES-256 加密」这种说法，值得追问的是后面的部分：

- 密钥交换用的是什么？有没有前向保密？
- 认证方式是证书还是共享密钥？
- 会话密钥多久轮换一次？
- 客户端是否有独立的安全审计？

算法名字本身早已不是差异点 —— 所有主流服务用的都是同一批算法。真正拉开差距的是实现细节和运营方式，见 [VPN 到底安不安全](/vpn安全吗/)。

### 常见问题

Q: AES-256 和 ChaCha20 哪个更好？
A: 安全性上都足够。有 AES-NI 硬件加速的设备上 AES-256-GCM 更快；没有硬件加速的老手机、路由器上 ChaCha20-Poly1305 明显更快，这也是它在移动端受青睐的原因。

Q: 「军用级加密」是什么意思？
A: 这是营销词汇，通常指 AES-256。AES 确实被美国政府批准用于机密信息，但这个说法不构成任何额外的技术保证。

Q: 256 位密钥比 128 位安全多少？
A: 在暴力破解层面，两者都远超现实可行的计算能力，128 位已经足够。选 256 位更多是出于对未来（包括量子计算）的保守考虑。

Q: 量子计算会让 VPN加密失效吗？
A: 对称加密受影响有限，Grover 算法只把有效强度减半，256 位仍然安全。真正受威胁的是密钥交换用的椭圆曲线算法，业界正在推进后量子密钥交换方案。

---

# VPN安全吗？把风险拆成六个具体问题

URL: https://yalgorup.com/vpn安全吗/
类型: security
专题: security
更新: 2026-08-01
一句话回答: VPN安全吗，取决于你问的是哪一层：协议层面的加密已经足够强，现实中的风险几乎全部来自实现与运营 —— 服务商能看到什么、客户端在断线时怎么处理流量、DNS 有没有泄露、以及这门生意靠什么赚钱。
参考来源: NIST SP 800-77 Rev.1 — Guide to IPsec VPNs (https://csrc.nist.gov/pubs/sp/800/77/r1/final) | CISA — Selecting and Hardening Remote Access VPN Solutions (https://www.cisa.gov/resources-tools/resources/selecting-and-hardening-remote-access-vpn-solutions)

VPN安全吗？密码学强度只是其中一环。真正决定 VPN 是否安全的是服务商可见范围、客户端实现质量、DNS 处理、断线行为、司法管辖与商业模式六个问题。

VPN安全吗 这个问题没法脱离对象回答。把它拆成六个具体问题之后，答案就变得可验证了：谁能看到什么、客户端做对了没有、日志怎么记、注册在哪、靠什么赚钱、以及你到底在防谁。

## 问题一：服务商能看到什么

先接受一个架构事实：流量必须在 VPN 服务器上解密，才能被转发到目标网站。那一刻，服务器处在和你的网络运营商完全相同的位置上。

它能看到：

- 你连接的时间、时长、流量大小
- 你访问的域名（通过 DNS 请求和 TLS SNI）
- 你的真实 IP（否则无法回包）

它看不到：HTTPS 加密后的具体内容。

所以「用 VPN 更私密」的准确表述是：**你选择了信任 VPN 服务商，而不再信任本地网络**。这个选择是否划算，取决于你更不信任谁。

## 问题二：客户端实现的质量

同样的协议，不同客户端的实际暴露面差很远。值得关注的点：

- **断线时怎么办。** 隧道意外中断，流量是被切断还是回退到原网络？后者意味着裸奔。见 [Kill Switch](/kill-switch/)。
- **DNS 谁来处理。** 系统是否仍在用运营商的 DNS？见 [泄露检测](/vpn泄露/)。
- **IPv6 处理。** 只接管 IPv4、放任 IPv6 直连，是长期存在的常见缺陷。
- **权限范围。** 客户端需要系统级权限，代码质量直接关系到整机安全。

## 问题三：日志

「无日志」有多种含义：不记录访问内容、不记录连接元数据、不记录任何东西。三者差别巨大，而多数隐私政策的措辞正好停留在模糊地带。

判断依据只有两类：**独立审计报告的全文**，以及**司法程序中被证实无数据可交的记录**。宣传语本身不构成证据。详见 [日志政策](/vpn日志政策/)。

## 问题四：司法管辖与所有权

服务商注册在哪个国家，决定了它可能被要求配合到什么程度，也决定了执法请求是否需要经过法院。

同样值得看的是所有权结构：不少品牌属于同一家母公司，几个「独立测评」网站也可能与被推荐的品牌同属一个集团。这不必然意味着造假，但在读推荐时应当知情。

## 问题五：商业模式

服务器、带宽、开发都要钱。付费服务的收入来源清楚；免费服务的成本必须从别处收回 —— 广告、数据分析、把用户设备当作出口节点，都是被记录过的做法。

这不是道德判断，而是一条实用的推理：**先问钱从哪来，再决定信不信任**。展开见 [免费 VPN 的代价](/免费vpn/)。

## 问题六：你的威胁模型

「安全吗」这个问题脱离对象无法回答。

| 你在防谁 | VPN 是否有效 |
|---|---|
| 同一 Wi-Fi 下的其他用户 | 有效 |
| 本地网络管理员 / 运营商 | 有效（可见性转移给服务商） |
| 目标网站的 IP 定位 | 有效 |
| 广告追踪与浏览器指纹 | 基本无效 |
| 有能力同时观察两端的对手 | 无效，单跳架构不成立 |
| 已获取服务商数据的对手 | 取决于服务商真实的日志情况 |

## VPN安全吗：一个务实的结论

VPN 的密码学部分几乎不是风险来源。协议久经审视，算法公开可验。

风险集中在两个更普通的地方：**客户端有没有把细节做对**，以及**你有没有理由信任这家公司**。评估方法整理在 [如何选择 VPN](/如何选择vpn/)。

### 常见问题

Q: 服务商真的能看到我访问了什么吗？
A: 技术上能。流量在服务器上被解密后才转发出去，那一刻服务器处于可观察的位置。HTTPS 保证它看不到网页内容，但域名、时间、流量大小都是可见的。

Q: 有审计报告就一定可信吗？
A: 比没有强，但要看细节：审计范围是基础设施还是仅客户端代码、是一次性还是定期、报告是否公开全文。只写「已通过审计」而不给报告的价值有限。

Q: 用 VPN 会更容易被攻击吗？
A: 隧道本身不会。但劣质客户端可能引入漏洞，某些服务在服务器上做流量改写或注入内容，这些属于服务商风险而非协议风险。

Q: 公司的 VPN 会看到我的私人流量吗？
A: 如果是全局模式，公司网关能看到你的全部出站连接。分流模式下只有指向公司资源的流量经过它。这属于合规范围内的正常能力。

---

# VPN日志政策：无日志到底意味着什么

URL: https://yalgorup.com/vpn日志政策/
类型: security
专题: security
更新: 2026-08-01
一句话回答: VPN日志分两类：记录「你何时连接、用了多少流量」的连接日志，和记录「你访问了什么」的活动日志。多数所谓无日志只承诺不保存后者。要判断真伪，看独立审计报告全文与司法案例，而不是宣传页。
参考来源: GDPR Article 5 — Principles relating to processing of personal data (https://gdpr-info.eu/art-5-gdpr/) | EFF — Who Has Your Back? (transparency report methodology) (https://www.eff.org/who-has-your-back-2019)

VPN日志政策怎么读？连接日志与活动日志的区别、隐私政策里常见的模糊措辞、独立审计能证明什么，以及内存化服务器为什么比承诺更可靠。

几乎每家服务都写着「无日志」，但 VPN日志政策的差别恰恰藏在措辞里。这一页教你怎么读这类文本：哪些字段是运营必需的，哪些例外条款值得警惕，什么才算真正的旁证。

## 两种日志，差别很大

**连接日志（metadata / connection logs）**
连接与断开时间、使用的服务器、消耗流量、并发设备数，有时还有连接来源 IP。

**活动日志（activity logs）**
访问了哪些域名、DNS 查询记录、具体的流量内容。

绝大多数「无日志」承诺针对的是第二类。第一类中的一部分是运营必需的 —— 没有会话状态就无法做设备数限制、无法排查故障、无法应对滥用。

关键因此变成：**哪些连接信息被写进了磁盘，保留多久，能否与具体账号关联。**

## 隐私政策里要盯住的措辞

读政策时，几类表达值得停下来：

- 「我们不记录**浏览活动**」 —— 只否认了活动日志，连接日志未置可否。
- 「日志在会话结束后**尽快**删除」 —— 「尽快」没有定义。
- 「为防止滥用，我们可能保留部分信息」 —— 例外条款的范围有多大？
- 「我们**不与第三方共享**」 —— 与「不收集」是两件事。
- 「聚合的**匿名**统计」 —— 匿名化到什么程度、能否重新关联？

一份写得诚实的政策，通常会明确列出保留了哪几个字段、保留多长时间，而不是只强调不保留什么。

## 审计能证明什么，不能证明什么

**能证明**：在审计发生的那段时间里，配置和流程与声明一致；代码里没有发现明显的记录逻辑。

**不能证明**：审计之后系统没有变化；也不能证明服务商在任何情况下都不会被要求配合。

因此有效的审计需要满足几个条件：审计方独立且有资质、范围覆盖服务器基础设施而不只是客户端、定期重复而非一次性、报告全文可读。

只在首页写一句「已通过第三方审计」而不给出报告和范围，信息量接近于零。

## 更硬的证据：司法记录

比审计更有说服力的，是服务商在真实的执法请求中被要求提供数据，而最终交不出任何有用记录 —— 这类案例被公开报道后，构成了对无日志声明最直接的旁证。

反过来，也有品牌在宣称无日志的同时向调查机构提供了连接记录，事后被公开。查一查有没有这类历史，是尽调里性价比最高的一步。

## 内存化服务器

一个结构性的改进：服务器不使用硬盘，操作系统从只读镜像加载到内存中运行。断电或重启，一切归零。

它的价值在于把「我们承诺不保存」变成了「保存下来在物理上没有意义」。这类部署通常被称为 RAM-only 或 diskless 基础设施。

但它同样不能防止运行期间的主动记录 —— 只是提高了事后取证的难度。

## 透明度报告与警示标语

**透明度报告** 定期披露收到多少执法请求、其中多少被拒绝或无数据可交。持续发布本身就是一种约束。

**Warrant canary（警示标语）** 是一句定期更新的声明，大意为「截至今日我们未收到过某类保密要求」。一旦停止更新，就构成暗示。这个机制在法律上有争议，参考价值有限，但仍值得留意。

## VPN日志政策：一个可操作的检查顺序

1. 打开隐私政策，找到「我们收集什么」那一节，看是否逐项列举。
2. 搜索例外条款：滥用、欺诈、法律要求各保留什么。
3. 找审计报告全文，确认范围与日期。
4. 搜索品牌名加「执法请求」「法庭」，看有没有真实案例。
5. 确认服务器是否为内存化部署，注册地在哪个法域。

这五步做完，比看十篇评测更有用。相关标准整理在 [如何评估一个 VPN](/如何选择vpn/)。

### 常见问题

Q: 完全不记录任何东西可能吗？
A: 运行中必须有状态，否则无法转发数据。可以做到的是不写入磁盘、不长期保存。区别在于「持久化」而不是「存在」。

Q: 同时在线人数上限算日志吗？
A: 算连接状态的一种。要限制设备数，服务端必须知道当前有几个会话在跑，这属于运营必需的最小信息。

Q: 审计报告要看哪几点？
A: 审计方是谁、审计范围包含哪些系统、是现场检查还是文档审查、有效期、以及报告是否公开可下载。

Q: 服务商在什么国家重要吗？
A: 重要。它决定了执法请求的门槛、是否存在强制数据保留义务、以及能否被要求保密地配合。

---

# DNS泄露、IPv6 与 WebRTC 泄露：原因、检测与修复

URL: https://yalgorup.com/vpn泄露/
类型: security
专题: security
更新: 2026-08-01
一句话回答: 常见的 VPN 泄露有四种：DNS泄露、IPv6 泄露、WebRTC 泄露和断线瞬间的流量回落。它们的共同点是隧道已建立、但部分流量或标识仍绕过了它。
参考来源: RFC 8445 — Interactive Connectivity Establishment (ICE) (https://www.rfc-editor.org/rfc/rfc8445) | RFC 8484 — DNS Queries over HTTPS (DoH) (https://www.rfc-editor.org/rfc/rfc8484) | W3C — WebRTC 1.0 Real-Time Communication Between Browsers (https://www.w3.org/TR/webrtc/)

DNS泄露、IPv6 泄露与 WebRTC 泄露的原因、检测与修复：连上 VPN 后真实信息仍然暴露的四种典型情况，每一种都有明确的成因和自测方法。

DNS泄露 是最常见、也最容易被忽略的一种 —— 隧道明明连上了，域名解析却还走着运营商的服务器。这一页按成因把四类泄露讲清楚，并给出一份可以自己跑一遍的检测清单。

## 泄露是什么意思

隧道正常建立，网站也确实看到了 VPN 服务器的 IP —— 但某一类请求走了别的路，把真实信息交了出去。这就是泄露。

它不是加密被破解，而是**流量根本没进隧道**。

## 一、DNS泄露：解析请求走了运营商

访问网站前要先把域名解析成 IP。如果这个查询发给了本地运营商的 DNS，那么即使后续流量走了隧道，运营商依然知道你解析过哪些域名。

**成因**

- 客户端没有修改系统 DNS 设置
- Windows 的「智能多宿主名称解析」会并行向多个网卡的 DNS 发查询，谁先回用谁
- 浏览器自己启用了 DoH，绕过了系统设置
- 手动配置的隧道（尤其是自建）只改了路由，没改 DNS

**检测**：连上 VPN，访问 DNS 泄露检测页面，看返回的解析服务器属于谁。

**修复**：使用会强制接管 DNS 的客户端；或在系统里把 DNS 固定为隧道内地址；Windows 上可关闭智能多宿主解析。

## 二、IPv6 泄露

这是最容易被忽略的一种。很多客户端只处理了 IPv4 路由，如果本地网络同时提供 IPv6，那么访问支持 IPv6 的网站时，流量会直接从原线路出去。

结果是：你以为在用日本节点，网站却看到了你真实的 IPv6 地址。

**检测**：连上 VPN 后访问同时显示 IPv4 与 IPv6 的检测页，两个地址都应该属于 VPN 服务器。若 IPv6 一栏显示你的本地地址，就是泄露。

**修复**：选择明确声明支持 IPv6 或会主动禁用 IPv6 的客户端；必要时在系统或路由器上关闭 IPv6。

## 三、WebRTC 泄露

WebRTC 是浏览器里做实时音视频的标准。为了打通点对点连接，它使用 ICE 框架（RFC 8445）收集本机所有可用的「候选地址」，其中包括局域网地址和通过 STUN 服务器发现的公网地址。

问题在于：网页里的 JavaScript 可以直接读取这些候选地址，**不需要真的发起通话**。于是一段脚本就能拿到你的真实 IP，哪怕全部流量都在隧道里。

现代浏览器已经做了缓解 —— 默认用 mDNS 随机主机名替代局域网地址 —— 但公网地址的暴露风险依然存在。

**检测**：使用 WebRTC 泄露测试页面，看列出的候选地址里有没有你的真实公网 IP。

**修复**：浏览器扩展限制 WebRTC；Firefox 可关闭 `media.peerconnection.enabled`；或使用会阻断非隧道流量的客户端。

## 四、断线瞬间的回落

隧道断开的那几秒，系统会把流量退回默认路由。正在下载的连接、后台同步的应用会立刻用真实 IP 继续跑。

这类泄露持续时间短，却最难察觉，因为它发生时你可能根本没在看屏幕。

对应的机制是 [Kill Switch](/kill-switch/)：在隧道不可用时直接阻断出站流量，而不是放行。

## 泄露自测清单

连上 VPN 之后，按顺序检查：

| 检查项 | 期望结果 |
|---|---|
| IPv4 出口 | VPN 服务器地址 |
| IPv6 出口 | VPN 服务器地址，或无 IPv6 |
| DNS 服务器 | 属于 VPN，不含本地运营商 |
| WebRTC 候选 | 不含真实公网 IP |
| 手动断开客户端 | 网络立即不通，而不是恢复直连 |

最后一项最值得亲手做一次：直接结束客户端进程（而不是点「断开」），然后看浏览器还能不能上网。很多 Kill Switch 只在正常断开流程里生效，在进程被强杀时并不起作用。

### 常见问题

Q: 怎么快速判断有没有 DNS 泄露？
A: 连上 VPN 后打开任意 DNS 泄露检测站点，看列出的解析服务器归属。如果出现你本地运营商的名称，就是泄露。

Q: 直接关掉 IPv6 是好办法吗？
A: 是常见且有效的临时办法，但会影响纯 IPv6 环境下的访问。更好的做法是选择明确支持 IPv6 或明确阻断 IPv6 的客户端。

Q: 浏览器要怎么处理 WebRTC？
A: Chrome 系可用扩展限制，Firefox 可在 about:config 把 media.peerconnection.enabled 设为 false。注意这会影响需要 WebRTC 的视频通话网页。

Q: 检测网站显示位置不对，是泄露吗？
A: 不一定。IP 地理库本身就有误差，尤其是新启用的机房 IP 段。只要显示的 IP 是 VPN 服务器的，就不算泄露。

---

# Kill Switch 是什么？VPN 断网保护的两种实现与验证

URL: https://yalgorup.com/kill-switch/
类型: security
专题: security
更新: 2026-08-01
一句话回答: Kill Switch（断网保护）在 VPN 隧道意外中断时阻断设备的出站流量，防止流量退回原线路暴露真实 IP。实现分两种：改写系统防火墙规则的系统级方案，和监控进程状态的应用级方案，前者可靠得多。
参考来源: Android Developers — Always-on VPN (https://developer.android.com/develop/connectivity/vpn) | Apple Platform Deployment — Always On VPN (https://support.apple.com/guide/deployment/always-on-vpn-dep7bab7e405/web)

Kill Switch 在隧道中断时阻断流量的具体做法：系统级防火墙规则与应用级监控的区别，常见的失效场景，以及怎么亲手验证它真的生效。

Kill Switch 又叫断网保护或网络锁，作用只有一个：隧道断了就切断网络，而不是悄悄回退到原线路。这一页讲它的两种实现、常见失效场景，以及怎么亲手验证 Kill Switch 是否真的生效。

## 它解决的是哪几秒钟

VPN 连接不会永远稳定。服务器重启、Wi-Fi 切换、系统休眠唤醒、线路抖动 —— 隧道随时可能断开几秒。

在这几秒里，操作系统会做一件很自然的事：把流量退回原来的默认路由。于是正在同步的网盘、正在下载的客户端、正在轮询的应用，全部用真实 IP 继续跑，而屏幕上可能什么提示都没有。

Kill Switch 的作用就是：宁可断网，也不放行。

## 两种实现方式

### 系统级（防火墙规则）

客户端在连接时向系统防火墙写入规则：只允许流量从隧道接口出去，其他接口一律拒绝。Linux 上用 nftables/iptables，Windows 上用 WFP 过滤平台，macOS 用 pf。

优点是**它不依赖客户端继续运行**。哪怕进程被强制结束、甚至崩溃，规则依然留在系统里，网络仍然是封死的。

### 应用级（进程监控）

客户端监控隧道状态，一旦发现断开，就关闭用户指定的应用程序或暂停其网络访问。

这种实现有个结构性弱点：**保护逻辑本身跑在客户端里**。客户端崩溃时，监控随之消失，流量照常放行。

## 常见的失效场景

| 场景 | 为什么会漏 |
|---|---|
| 客户端进程被强制结束 | 应用级实现失去执行主体 |
| 系统从休眠唤醒 | 网络恢复早于 VPN 重连，中间有窗口 |
| IPv6 流量 | 防火墙规则只写了 IPv4 |
| 开机到连上 VPN 之间 | 若未启用「开机即阻断」，这段时间是裸的 |
| 局域网白名单过宽 | 放行范围写得太大，等于开了口子 |

第二和第四条尤其值得注意 —— 它们发生在你还没开始用电脑的时候。

## 怎么验证 Kill Switch 真的有效

不要相信设置页面上的开关状态，动手测一次：

1. 连上 VPN，确认出口 IP 已改变。
2. 打开一个持续产生流量的东西，例如在线视频。
3. **在任务管理器里直接结束 VPN 客户端进程**（不要点「断开」按钮）。
4. 观察视频是否立刻中断、浏览器是否无法访问。

如果网络自动恢复了直连，说明这个 Kill Switch 只覆盖了正常断开的路径 —— 在最需要它的崩溃场景里并不生效。

再补一项：重启电脑，在客户端自动连接完成之前尝试打开网页。若能打开，说明开机阶段没有保护。

## 移动端的情况

**Android** 提供系统级支持：在「VPN」设置里开启「始终开启的 VPN」和「屏蔽没有 VPN 的连接」，由系统而非应用来保证，可靠性高。

**iOS** 的 Always-On VPN 主要面向受管理的设备，需要配置描述文件，个人用户通常只能依赖客户端自身的实现。

## 该不该一直开着

如果使用 VPN 的目的包含隐藏真实 IP，就应该开着 —— 否则那几秒的窗口足以让一次暴露发生，而且你不会知道。

如果只是偶尔换个出口访问某个服务，开着反而会在断线时打断所有网络活动。按用途决定，而不是默认全开。

### 常见问题

Q: 开着 Kill Switch 会影响正常上网吗？
A: 会。VPN 断开时整台设备（或指定应用）会失去网络连接，这正是它的设计意图。部分客户端提供白名单，允许局域网访问。

Q: 应用级和系统级怎么分辨？
A: 看设置里是「阻止所有流量」还是「关闭指定应用」。前者通常是防火墙级，后者只是在检测到断开后杀掉列表里的程序。

Q: 手机上有 Kill Switch 吗？
A: 有。Android 的系统设置里有「始终开启 VPN」和「阻止没有 VPN 的连接」；iOS 上通过 Always-On VPN 配置描述文件实现，个人用户可用的选项较少。

Q: 为什么开了 Kill Switch 还是泄露了？
A: 常见原因是它只覆盖 IPv4，或者只在正常断开时触发。IPv6 与进程崩溃是两个典型漏网场景。

---

# VPN怎么用、怎么选：速度、免费服务与评估标准

URL: https://yalgorup.com/vpn使用/
类型: hub
专题: usage
更新: 2026-08-01
一句话回答: VPN怎么用得舒服，取决于四个因素，按影响排序是：线路与服务器距离、协议选择、客户端实现质量，最后才是加密强度。选择服务时，日志政策、审计记录和商业模式比服务器数量更值得关注。
参考来源: NIST SP 800-77 Rev.1 — Guide to IPsec VPNs (https://csrc.nist.gov/pubs/sp/800/77/r1/final)

VPN怎么用、怎么选：它为什么会让网速变慢、免费服务的成本从哪里收回、评估一个服务该看哪些技术指标、以及合法性的基本框架。

这个板块回答的是实操问题：VPN怎么用、为什么变慢、免费的能不能用、几十家服务商该按什么标准挑。前面几个板块讲原理，这里只讲落地。

## 这个板块讲什么

前面几个板块讲的是「VPN 是什么」和「它怎么工作」。这一部分回到实际使用层面：为什么开了 VPN 网页变慢、免费的能不能用、面对几十家服务商该按什么标准判断、以及不同国家在法律上怎么对待它。

## 一个顺序建议

如果是第一次系统了解，建议按这个顺序读：

1. [VPN 会让网速变慢吗](/vpn速度/) —— 先建立对性能代价的正确预期。
2. [免费 VPN 的真实代价](/免费vpn/) —— 弄清楚免费服务的商业逻辑。
3. [如何评估一个 VPN](/如何选择vpn/) —— 一份可以直接照着核对的清单。
4. [VPN 的合法性](/vpn法律/) —— 了解所在地区的监管框架。

## 三个最常见的判断错误

**把服务器数量当作质量指标。** 数量可以靠虚拟位置堆出来，真正影响体验的是你常用地区有没有低负载的物理节点。

**把加密强度当作主要差异点。** 所有主流服务用的都是同一批算法，差别在实现细节，不在算法名字。

**忽略客户端的断线行为。** 这是最容易出问题、也最少被测试的一环，具体见 [Kill Switch](/kill-switch/)。

### 常见问题

Q: 刚开始用 VPN，最该先弄明白什么？
A: 两件事：你把信任交给了谁，以及断线时会发生什么。前者决定隐私边界，后者决定是否会意外暴露。

Q: 服务器越多越好吗？
A: 不是。有效指标是你常用地区是否有低负载的节点，以及线路质量如何。总数很容易通过虚拟位置注水。

Q: 需要每天都开着 VPN 吗？
A: 取决于用途。若目的是隐藏出口 IP，就该常开并配合 Kill Switch；若只是偶尔访问特定服务，按需开启更实际。

---

# VPN速度会变慢吗？拆解损耗的真实来源

URL: https://yalgorup.com/vpn速度/
类型: usage
专题: usage
更新: 2026-08-01
一句话回答: VPN速度确实会下降，但主要原因不是加密。真正的损耗来自物理距离带来的往返延迟、服务器与线路的拥堵、以及协议和 MTU 配置。加解密在现代 CPU 上的开销通常只有个位数百分比。
参考来源: RFC 1191 — Path MTU Discovery (https://www.rfc-editor.org/rfc/rfc1191) | RFC 8439 — ChaCha20 and Poly1305 (https://www.rfc-editor.org/rfc/rfc8439)

VPN速度为什么变慢？加密开销、路由绕行、服务器负载、协议选择与 MTU 配置分别造成多少损失，以及哪些情况下 VPN 速度反而更快。

抱怨 VPN速度 慢的人，九成遇到的是路由和负载问题，而不是加密。这一页按影响从大到小拆解五个来源，最后给出一套排查顺序。

## 先分清延迟和带宽

这是两件事，被搞混时诊断就会错。

**延迟（ping）** 是一个包往返所需的时间，由物理距离和中间跳数决定。它影响的是「点开链接后多久有反应」、游戏的手感、视频通话的同步。

**带宽（速度）** 是单位时间能传多少数据，影响下载速度和视频清晰度。

连日本节点看视频卡顿，通常是带宽问题；玩游戏手感变差，通常是延迟问题。两者的解决方向不同。

## 损耗来自哪里

### 1. 路由绕行（影响最大）

不用 VPN 时，流量走的是运营商到目标站点的相对直接路径。用了 VPN，流量必须先到服务器，再从那里出发。

如果你在东亚、服务器在欧洲、网站也在东亚，那么数据要绕地球一圈再回来。这部分损耗**无法通过任何技术手段消除**，只能通过选择更近的节点来减少。

### 2. 服务器与线路负载

一台服务器上有多少人在跑、上游带宽是多少、跨境段是否拥堵 —— 这些直接决定了你能分到多少。

同一家服务、同一个国家，换一个节点速度差几倍是很常见的。晚间高峰和凌晨的差别同样明显。

### 3. 协议与实现

| 因素 | 影响 |
|---|---|
| WireGuard vs OpenVPN | 前者握手快、加解密开销小，弱设备上差距明显 |
| UDP vs TCP | TCP 模式在丢包时因重传叠加而急剧退化 |
| 用户态 vs 内核态 | 内核态减少上下文切换，高带宽下差距显著 |

### 4. 加密开销（影响最小）

带 AES-NI 指令的处理器加解密 AES-256 的成本很低，通常不构成瓶颈。

真正的例外是没有硬件加速的设备 —— 老手机、树莓派、家用路由器。这类设备上换成 ChaCha20-Poly1305 常常能带来成倍改善，因为它是为软件实现优化的。

### 5. MTU 配置

封装增加了包头，可用载荷变小。若 MTU 没有相应调整，超长的包会被分片甚至丢弃。

典型症状很好认：**网页能打开、聊天正常，但下载和大图片卡死**。把 MTU 降到 1400 左右再测，问题往往消失。

## 什么情况下 VPN 反而更快

不常见，但确实存在：

- **默认路由绕远。** 某些运营商的国际出口路径不佳，而 VPN 线路更直。
- **运营商对特定流量限速。** 流量进了隧道后无法被识别类型，限速策略失效。
- **对端做了路由优化。** 部分服务商购买了优质线路，跨境段质量高于公网默认路径。

这些收益来自路由，不来自 VPN 本身。

## VPN速度 排查顺序

遇到「用了 VPN 特别慢」，按这个顺序试，通常前两步就能解决：

1. **换节点** —— 换成物理距离更近、负载更低的服务器。
2. **换协议** —— OpenVPN 换 WireGuard，或从 TCP 换回 UDP。
3. **调 MTU** —— 降到 1400 试试，尤其在大文件卡住时。
4. **对比基线** —— 关掉 VPN 测一次原始速度，确认瓶颈不在本地宽带。
5. **换时段** —— 高峰期的拥堵不是配置问题。

### 常见问题

Q: 用了 VPN 网速降低多少算正常？
A: 连接就近节点、线路正常时，带宽损失通常在一到两成以内。如果掉了一半以上，先怀疑服务器负载和路由，而不是加密。

Q: 为什么连远的节点 ping 值那么高？
A: 往返延迟受物理距离和中间跳数限制。跨洲连接的理论下限就是几十到一百多毫秒，任何服务都无法突破。

Q: 换协议真的能提速吗？
A: 能，尤其在移动设备上。WireGuard 的握手和加解密开销都小于 OpenVPN，弱设备上差距更明显。

Q: 下载大文件时突然卡住是什么问题？
A: 典型的 MTU 问题。大包被分片或丢弃，小请求却正常。把 MTU 调低到 1400 左右再测。

---

# 免费VPN的真实代价：钱从哪里来

URL: https://yalgorup.com/免费vpn/
类型: usage
专题: usage
更新: 2026-08-01
一句话回答: 免费VPN 不等于有问题，但它一定意味着钱来自别处。常见的四种回收方式是：展示广告、收集并转售使用数据、以限速和流量上限引导付费、以及把用户设备当作他人流量的出口节点。
参考来源: Ikram et al. — An Analysis of the Privacy and Security Risks of Android VPN Permission-enabled Apps (ACM IMC 2016) (https://dl.acm.org/doi/10.1145/2987443.2987471) | FTC — Free VPN apps and consumer privacy guidance (https://consumer.ftc.gov/articles/protect-your-phone-data)

免费VPN的真实代价：服务器与带宽成本需要被收回，常见方式包括广告与数据分析、限速引流付费、以及把用户设备当作出口节点。附有据可查的研究与案例。

判断一个 免费VPN 值不值得用，最有效的问题不是「它安全吗」，而是「它靠什么赚钱」。这一页把免费VPN 的四种商业模式摆开，风险自然就分出了层次。

## 先算一笔账

一台跑 VPN 的服务器每月要付机房费和带宽费，而 VPN 是**流量密集型**业务 —— 用户看的每一部视频，服务商都要按同样的量付一次带宽钱。再加上客户端开发、多平台维护、客服。

所以问题不是「他们为什么免费」，而是**这些成本由谁承担**。答案通常是以下四种之一。

## 方式一：广告与数据

在客户端里展示广告是最直接的。更有价值的是使用数据：访问了哪些域名、什么时段活跃、设备型号与地区。这类数据对广告行业有明确的定价。

判断方法很简单 —— 打开隐私政策，找「我们与第三方共享哪些信息」这一节。如果写着为了「改善服务」「营销合作」可以共享，那就是答案。

## 方式二：限速引流

这是最健康的一种：免费档提供有限流量或有限节点，速度和地区受限，目的是让重度用户升级付费。

这类免费档由付费业务补贴，服务商没有变卖数据的动机 —— 它的收入模型已经成立。

## 方式三：把你的设备当作出口

这是风险最高的模式。应用在你不特别留意的条款里获得授权，把你的设备变成其他用户流量的出口节点。

后果很具体：别人的请求从你的 IP 发出。如果这些请求涉及违规行为，追查到的地址是你的。

2015 年就有一起被广泛报道的案例：某款免费 VPN 将用户的闲置带宽打包成商用代理网络出售，该网络随后被用于向一个网站发起大规模请求。这一模式此后被反复讨论，也促使不少应用商店收紧了相关规则。

**检查方法**：搜索条款里有没有「peer-to-peer」「共享带宽」「idle resources」这类表述。

## 方式四：直接不做该做的事

省掉安全投入本身就是省钱。2016 年发表在 ACM IMC 上的一项研究分析了 283 款获得安卓 VPN 权限的应用，发现的问题包括：

- 相当比例的应用被安全引擎标记为含有可疑代码
- 部分应用**根本没有对流量加密**
- 大量应用未处理 IPv6，导致流量绕过隧道
- 一部分使用非透明代理，改写经过的 HTTP 流量

这项研究已经过去多年，生态有所改善，但它揭示的模式 —— 「装了 VPN 图标不等于建立了隧道」 —— 依然适用。

## 一张对照

| 模式 | 收入来源 | 主要风险 |
|---|---|---|
| 付费服务的免费档 | 付费用户补贴 | 限速、流量上限 |
| 广告支持 | 广告主 | 数据收集范围不透明 |
| 数据变现 | 转售使用数据 | 隐私目标与产品目标冲突 |
| 共享带宽 | 转售用户出口 | 你的 IP 被他人使用 |
| 无维护的免费产品 | 无 | 加密缺失、泄露、长期无更新 |

## 免费VPN 的判断标准

在决定用不用某个免费服务之前，回答三个问题：

1. **它靠什么赚钱？** —— 如果找不到答案，那答案很可能是你。
2. **它的隐私政策是否逐项列出了收集的字段？** —— 含糊的表述通常有原因。
3. **条款里有没有共享带宽的授权？** —— 有的话，风险性质完全不同。

用途也决定了容忍度。临时改一次出口 IP 看个网页，和长期承载你全部日常流量，是两种截然不同的暴露程度。评估标准见 [如何评估一个 VPN](/如何选择vpn/)。

### 常见问题

Q: 所有免费 VPN 都不能用吗？
A: 不是。由成熟付费服务提供的免费档次（限流量、限节点）风险较低，因为它的商业模式是引导升级，而不是变卖数据。

Q: 怎么判断一个免费 VPN 的收入来源？
A: 看三处：隐私政策里的数据共享条款、应用内是否有广告、以及是否存在「分享闲置带宽」一类的条款。第三条最需要警惕。

Q: 免费 VPN 为什么速度慢？
A: 免费用户共享有限的服务器资源，且通常被刻意限速以形成付费动机。这是产品设计，不是技术限制。

Q: 浏览器自带的免费代理算安全吗？
A: 它只作用于该浏览器，且由浏览器厂商运营，可信度取决于你对该厂商的信任。它不是完整的 VPN，其他应用不受保护。

---

# 如何选择VPN：一份可以逐条核对的技术清单

URL: https://yalgorup.com/如何选择vpn/
类型: usage
专题: usage
更新: 2026-08-01
一句话回答: 如何选择VPN，按六个维度核对：支持的协议、日志政策与审计证据、客户端的泄露与断线处理、服务器基础设施、注册地与所有权、以及退款条款。服务器数量和「军用级加密」这类宣传不构成有效指标。
参考来源: CISA — Selecting and Hardening Remote Access VPN Solutions (https://www.cisa.gov/resources-tools/resources/selecting-and-hardening-remote-access-vpn-solutions) | NIST SP 800-77 Rev.1 — Guide to IPsec VPNs (https://csrc.nist.gov/pubs/sp/800/77/r1/final)

如何选择VPN：抛开营销话术，从协议支持、日志与审计、客户端实现、基础设施、司法管辖和退款条款六个维度，给出可以逐条核对的评估标准。

如何选择VPN 的核心原则只有一条：只采信能验证的东西。审计报告可以读，泄露可以自己测，退款条款可以核对；而「全球最快」无法验证，也就没有参考价值。

## 维度一：协议支持

至少应当提供 WireGuard 和 OpenVPN 两种，并允许手动切换。只提供一种协议，意味着遇到网络限制时没有退路。

**加分项**：支持在 TCP 443 上运行、提供混淆选项、公开客户端源代码。

**减分项**：把 PPTP 当作卖点列出。这说明产品线多年未更新，见 [PPTP 的问题](/l2tp-pptp-sstp/)。

## 维度二：日志政策与证据

依次检查：

- 隐私政策是否**逐项列出**收集的字段，而不只是声明不记录
- 是否有独立审计报告，**报告全文能否读到**
- 审计范围是客户端代码还是整套基础设施
- 是否有公开的透明度报告
- 有没有真实的执法请求案例被报道

只写一句「严格无日志」而无任何旁证的，按未验证处理。详见 [日志政策](/vpn日志政策/)。

## 维度三：客户端实现（唯一你能亲手验的）

这一项不需要相信任何人，自己测：

| 测试 | 方法 | 期望 |
|---|---|---|
| DNS 泄露 | 连上后访问检测页 | 解析服务器不属于本地运营商 |
| IPv6 泄露 | 检测页看 IPv6 一栏 | 显示 VPN 地址或无 IPv6 |
| WebRTC 泄露 | WebRTC 测试页 | 候选地址不含真实公网 IP |
| Kill Switch | 强制结束客户端进程 | 网络立即中断 |
| 开机窗口 | 重启后立刻访问网页 | 在连上之前应无法访问 |

第四、五项最常被忽略，也最常出问题。方法见 [Kill Switch](/kill-switch/) 与 [泄露检测](/vpn泄露/)。

## 维度四：基础设施

- **自有还是租用服务器？** 租用意味着机房方在物理上可接触设备。
- **是否为内存化（RAM-only）部署？** 断电即清空，比政策承诺更硬。
- **虚拟位置的比例？** 标注为某国但实际机器在别处，会影响延迟与合规性。诚实的服务商会明确标注哪些是虚拟位置。
- **是否自营 DNS？** 用第三方公共 DNS 意味着解析记录交给了另一方。

## 维度五：司法管辖与所有权

注册地决定了它可能被要求配合到什么程度，以及是否存在强制数据保留义务。

所有权同样值得查：不少品牌属于同一家母公司，部分测评站点与被推荐品牌存在关联。这不必然说明有问题，但读推荐时应当知情。

## 维度六：付款与退款

- 退款期有多长？条件是什么（流量上限、必须联系客服）？
- 支付方式是否包含本地常用渠道？
- 自动续费如何取消，取消入口是否明显？

退款期的真正价值不是「不满意可以退」，而是**它给了你一个自费测试期**。上面维度三的五项测试全部可以在这段时间里做完。

## 低信息量指标

以下这些在对比表里出现频率极高，实际参考价值很低：

- **服务器数量 / 国家数量** —— 可通过虚拟位置任意膨胀
- **「军用级加密」** —— 所有主流服务用的是同一批算法
- **「全球最快」** —— 速度取决于你的线路和所选节点，无法泛化
- **星级评分** —— 权重与评测方法通常不公开
- **「零日志」四个字本身** —— 没有证据支撑时只是一句话

## 如何选择VPN：一个快速流程

1. 确认协议列表里有 WireGuard 和 OpenVPN。
2. 找审计报告全文，看范围与日期。
3. 查注册地和母公司。
4. 在退款期内跑完五项客户端测试。
5. 测常用节点的实际速度，晚高峰再测一次。
6. 不满意就在期限内退款。

这套流程的核心是：**把不可验证的宣传，换成可验证的测试结果**。

### 常见问题

Q: 最重要的一条标准是什么？
A: 你能不能验证它。审计报告可以读，泄露可以测，退款条款可以核对；而「全球最快」无法验证，也就没有参考价值。

Q: 需要在意服务器数量吗？
A: 基本不需要。有意义的是你常用地区是否有低负载的物理节点。虚拟位置可以让数字任意膨胀。

Q: 独立测评网站可信吗？
A: 需要留意所有权关系。部分测评站与被推荐品牌属于同一集团。判断方法是看它是否披露了利益关系，以及是否给出可复现的测试方法。

Q: 试用期该测什么？
A: 至少测四项：常用节点的实测速度、DNS 与 IPv6 泄露、强杀客户端后的断网行为、以及退款流程是否顺畅。

---

# VPN合法吗？三种监管模式与常见误解

URL: https://yalgorup.com/vpn法律/
类型: usage
专题: usage
更新: 2026-08-01
一句话回答: VPN合法吗，答案因国家而异：世界多数国家把 VPN 视为普通网络技术，企业远程办公普遍依赖它；少数国家采取许可制，要求提供跨境网络服务的经营者获得批准。无论在哪，技术本身合法都不等于用它做的事合法。
参考来源: Freedom House — Freedom on the Net (年度各国网络政策报告) (https://freedomhouse.org/report/freedom-net) | ITU — Global Cybersecurity and Regulatory Resources (https://www.itu.int/en/ITU-D/Cybersecurity/Pages/default.aspx)

VPN合法吗？各国监管大致分为完全合法、许可管理、明确禁止三类。本文说明这三种模式的差别、企业与个人的监管口径不同，以及技术合法不等于用途合法。

VPN合法吗 之所以难以一句话回答，是因为法律文本通常不单独定义 VPN，而是落在「谁可以提供跨境接入服务」和「你用它做了什么」这两个更上位的问题上。

> 本文只做技术与政策框架层面的整理，不构成法律意见。各地规定与执法实践会变化，涉及具体情况请咨询当地执业律师。

## 为什么这个问题不好一句话回答

因为「VPN」在法律文本里通常不是一个被单独定义的对象。相关规定往往落在两个更上位的概念上：

- **谁可以提供跨境网络接入服务** —— 这是电信业务经营许可的范畴
- **用它做了什么** —— 这属于内容、金融、版权等各自领域的法律

所以同一个技术，在同一个国家，企业内部使用和面向公众售卖，适用的规则可能完全不同。

## 模式一：完全合法，视为普通技术

大多数国家属于这一类，包括欧盟成员国、美国、日本、韩国、加拿大、澳大利亚等。

VPN 被当作基础网络技术：企业用它做远程办公，个人用它保护公共 Wi-Fi 上的传输，均无需特别许可。相关的监管重点反而在服务商一侧的**数据保护义务**上 —— 例如欧盟的 GDPR 对个人数据处理的要求。

需要注意的是，「使用合法」不代表「用途免责」。在这些国家用 VPN 进行版权侵权、网络攻击或欺诈，仍然按各自的法律处理。

## 模式二：许可与备案管理

一部分国家对**提供**跨境网络服务实行许可制：经营者需要获得批准，企业需要通过获批渠道办理跨境专线。

这类制度的共同特征是：

- 监管文本针对的是经营主体和接入渠道
- 企业合规使用有明确的申请路径
- 面向公众销售未经批准的跨境接入服务，属于被规范的对象

具体到某一个国家的条文、适用范围和执法实践，差异很大，且会随时间调整。查阅当地主管部门的现行规定是唯一可靠的方式。

## 模式三：明确限制或禁止

少数国家对 VPN 采取明确的限制态度，可能要求服务商接入指定系统、屏蔽特定内容，或直接禁止未经授权的使用，并设有相应罚则。

在这些法域，罚则的适用对象、力度和实际执行情况各不相同，需要具体查证。

## 三个常见误解

**误解一：VPN 在国际上是灰色技术。**
不是。它是企业 IT 的标准组件，远程办公、跨国公司内网互联都依赖它。把它整体等同于规避手段，忽略了它最主要的实际用途。

**误解二：服务商在国外，就适用国外法律。**
对使用者而言，起作用的通常是**你人在哪里**。服务商的注册地影响的是它自身面对执法请求时的处境，而不是你所处位置的法律适用。

**误解三：加密了就无从追查。**
隧道保护的是传输内容。账号信息、支付记录、设备指纹、以及服务商自身持有的数据，都是独立于加密之外的线索。

## VPN合法吗：一条通用的判断原则

把两个问题分开看：

1. **技术本身**在你所在的法域是否受限制？
2. **你打算用它做的事**，在不用 VPN 的情况下是否合法？

第二个问题的答案，不会因为加了一层加密而改变。

### 常见问题

Q: 企业用 VPN 办公有问题吗？
A: 在绝大多数国家都是合规的常规做法，也是 VPN 最初的用途。部分实行许可制的国家要求跨境专线通过获批渠道办理。

Q: 个人使用会被追究吗？
A: 取决于所在法域的具体规定与执法实践。多数许可制国家的监管重点放在经营者一侧，但这不构成任何法律意义上的保证。

Q: 出差到监管严格的国家要注意什么？
A: 当地法律适用于你所在的位置，而非你的国籍或服务商所在地。出行前应确认目的地的具体规定。

Q: 这篇文章能作为法律依据吗？
A: 不能。这里只是技术科普层面的整理，具体问题应咨询所在法域的执业律师。

---

# VPN与网络协议公开数据：图表专题

URL: https://yalgorup.com/数据/
类型: hub
专题: data
更新: 2026-08-01
一句话回答: 这个专题收录可公开核对的网络数据：Cloudflare Radar 的协议与加密普及统计、IPv6 采用率，以及各机构对 VPN 使用规模的估算。每张图表都写明来源、统计区间，二手数据会明确标注。

VPN 与网络协议的公开数据专题：HTTP 版本占比、后量子加密普及、IPv6 采用率、VPN 使用规模估算。每张图都标注来源链接与统计区间。

这个专题只放**能点开链接核对**的数字。每张图表下方都有来源、统计区间；如果是行业汇总的二手数据，会额外标一行提醒。

## 三类数据的区别

**网络测量数据**来自实际经过某个网络的请求统计，样本明确、口径固定，可信度最高 —— 本专题的协议与 IPv6 数据属于这一类。

**调查数据**来自问卷或用户面板，依赖受访者自我报告，会受样本构成影响。

**行业汇总数据**是第三方把上面两类再加工后发布的，往往找不到原始口径。VPN 使用规模的数字大多属于这一类，所以我们展示的是**区间和分歧**，不是单一数值。

## 数据怎么维护

所有数值集中在仓库的 `src/data/stats.ts` 里，每组都带 `source`、`sourceUrl`、`period` 三个字段。页面不硬编码任何数字，来源更新时改一处即可。

### 常见问题

Q: 这些数据多久更新一次？
A: 网络测量类的数据跟随来源方的发布周期，通常一年一次；行业汇总类的数字每年会被重新发布。页面上标注的统计区间就是判断新旧的依据。

Q: 为什么不给出 VPN 用户的精确人数？
A: 因为不存在可靠的精确值。各家口径差异很大，我们展示区间和分歧原因，而不是挑一个好看的数字。

Q: 图表可以引用吗？
A: 可以，请注明原始来源（图表下方的链接），而不是只写本站。

---

# 协议与加密普及数据：HTTP/3、后量子加密与拦截率

URL: https://yalgorup.com/协议普及数据/
类型: stats
专题: data
更新: 2026-08-01
一句话回答: 截至 2025 年 12 月初的全球请求中，HTTP/2 占 50%、HTTP/1.x 占 29%、HTTP/3 占 21%；后量子加密在人类发起的加密流量中的占比从年初的 29% 升到年末的 52%。数据来自 Cloudflare Radar 的网络测量。
参考来源: Cloudflare Radar 2025 Year in Review (https://blog.cloudflare.com/radar-2025-year-in-review/)

协议普及数据实测：HTTP/1.x、HTTP/2、HTTP/3 的全球请求占比，后量子加密在 2025 年的增长，以及被安全策略拦截的流量比例。数据来自 Cloudflare Radar 年度回顾。

协议普及数据 最有价值的地方在于它是**测量出来的**，不是问出来的。下面每张图都来自同一份网络测量报告，统计区间一致，可以横向对照。

## HTTP 版本：HTTP/3 已经占到五分之一

这张图对 VPN 用户有一个直接含义：**HTTP/3 依赖 UDP**。

有些网络会限制或降级 UDP 流量，结果是两件事同时发生 —— 基于 UDP 的 [WireGuard](/wireguard/) 连不上，普通网页也退回到较慢的 HTTP/2。遇到这种情况，把 VPN 换成 TCP 模式（例如 [OpenVPN over TCP 443](/openvpn/)）通常能恢复连接。

## 后量子加密：一年从 29% 到 52%

这是整份报告里增长最快的指标。它要解决的是「**现在录下、将来解密**」这一类威胁：攻击者今天把加密流量保存下来，等具备足够算力的设备出现后再回头解开。

对称加密受量子计算的影响有限，真正脆弱的是密钥交换环节 —— 这正是后量子算法优先替换的部分，原理见 [VPN加密原理](/vpn加密/)。

## 设备构成：桌面仍然过半

移动端占比逐年上升，但全球口径下桌面设备仍然过半。这个数字对 VPN 的意义在客户端选择上：移动设备更看重漫游能力和省电，因此 [IKEv2/IPsec](/ikev2-ipsec/) 和 WireGuard 在手机上的体验差别比在电脑上明显。

## 被拦截的流量

这个比例解释了另一件事：**为什么用 VPN 之后验证码变多了**。

数据中心 IP 段在风控系统里的信誉普遍低于住宅 IP，同一个出口地址上又聚集了大量用户，触发挑战的概率自然升高。这不是 VPN 出了故障，而是风控的正常反应。

## 机器人流量的来源

注意这三行**不是同一个分母**：第一行按流量来源国统计，后两行按云服务商网络统计。图表把它们放在一起是为了对照量级，不能相加成 100%。

## 数据说明

以上全部来自同一份网络测量报告，统计区间为 2025-01-01 至 2025-12-02。它反映的是流经该网络的请求，样本很大但不等于全网普查 —— 引用时应当保留这个限定。

### 常见问题

Q: 为什么 HTTP/1.x 还有 29%？
A: 大量 API 调用、老旧客户端和自动化程序仍在使用它。人类浏览器流量的新版本占比要高得多，这个数字包含了全部请求类型。

Q: 后量子加密和 VPN 有关系吗？
A: 有。它保护的是密钥交换环节，目的是防止「现在录下、将来解密」。VPN 的密钥交换面临同样的问题，见 VPN加密原理。

Q: 这些数据能代表整个互联网吗？
A: 只能代表流经该测量网络的请求。它样本很大，但不是全网普查 —— 任何单一来源的网络测量都有这个局限。

---

# IPv6普及率数据：全球采用比例与它对 VPN 的影响

URL: https://yalgorup.com/ipv6普及数据/
类型: stats
专题: data
更新: 2026-08-01
一句话回答: 在具备双栈条件的请求中，IPv6 的全球占比为 29%（较上一年提高 1 个百分点），采用率最高的是印度的 67%，同时仍有 20 个国家/地区低于 1%。这种极度不均衡正是 IPv6 泄露长期存在的原因。
参考来源: Cloudflare Radar 2025 Year in Review (https://blog.cloudflare.com/radar-2025-year-in-review/)

IPv6普及率的实测数据：全球请求中 IPv6 的占比、采用率最高的国家、以及仍低于 1% 的地区数量，并解释 IPv6 为什么是 VPN 泄露的主要来源之一。

IPv6普及率 是一个乍看和 VPN 无关、实际关系很紧的指标：**只要你的网络有 IPv6，而客户端只处理了 IPv4，隧道就漏了**。

  { label: '全球 IPv6 请求占比（2025）', value: '29%', note: '较 2024 年提高 1 个百分点' },
  { label: '采用率最高的国家', value: '67%', note: '印度' },
  { label: '占比不足 1% 的国家/地区', value: '20 个', note: '差距仍然极大' },
]} />

## 增长很慢，分布极不均衡

一年 1 个百分点的增速，意味着**双栈共存的状态还会持续很多年**。对 VPN 来说这不是好消息：需要同时正确处理两个协议栈的时间被拉长了。

## 这个数字为什么和泄露有关

假设你的客户端只在系统里插入了 IPv4 的路由：

- 访问只有 IPv4 的网站 → 走隧道，一切正常
- 访问同时支持 IPv6 的网站 → 系统优先选择 IPv6 → **直接走原线路出去**

结果是你以为在用某个海外节点，网站却看到了你真实的 IPv6 地址。检测与修复方法见 [IP、DNS 与 WebRTC 泄露](/vpn泄露/)。

## 为什么这个缺陷特别容易漏测

看上面的分布就明白了：在 IPv6 占比很低的网络里测试，可能永远触发不了这个问题 —— 因为根本没有 IPv6 流量产生。

换到一个 IPv6 普及的网络（例如移动网络），同一个客户端立刻开始泄露。**「在我这儿测过没问题」在这件事上尤其不可靠。**

## 检查清单

| 步骤 | 期望结果 |
|---|---|
| 不连 VPN，查看是否有 IPv6 地址 | 确认本地网络是否双栈 |
| 连上 VPN 后再查 | IPv6 一栏应显示服务器地址或直接不可用 |
| 换一个网络（家宽 ↔ 移动网络）重测 | 两种环境结果一致 |

第三步最容易被跳过，却是唯一能验证「客户端是真的接管了 IPv6，还是只是恰好没遇到」的方法。

### 常见问题

Q: 我怎么知道自己有没有 IPv6？
A: 访问任意一个同时显示 IPv4 与 IPv6 地址的检测页面。如果 IPv6 一栏有地址，说明本地网络提供了双栈连接。

Q: 关掉 IPv6 是不是最省事？
A: 是常见做法，也确实能消除这一类泄露，代价是纯 IPv6 环境下会连不上。更好的选择是用会同时接管两个协议栈的客户端。

Q: 为什么有的 VPN 至今不支持 IPv6？
A: 支持双栈意味着要为每个用户分配和管理 IPv6 地址、维护双份路由与防火墙规则，成本不低。部分服务因此选择直接在客户端阻断 IPv6。

---

# VPN使用数据：用户规模、市场规模与它们为什么互相矛盾

URL: https://yalgorup.com/vpn使用数据/
类型: stats
专题: data
更新: 2026-08-01
一句话回答: 公开发布的 VPN 用户规模估算集中在 16 亿到 17.5 亿之间，约占全球网民的 28.7% 到三分之一；市场规模的估算从 770 亿美元到 868 亿美元不等。这些数字全部来自行业汇总报告，口径不同，不能直接比较。
参考来源: DemandSage — VPN Statistics (https://www.demandsage.com/vpn-statistics/) | Surfshark — VPN usage trends (https://surfshark.com/blog/vpn-users)

VPN使用数据的公开估算：全球用户规模区间、市场规模口径差异、部分国家的使用率，以及这些数字为什么在不同报告里差出好几亿。

搜索 VPN使用数据 会得到一堆互相打架的数字：有说 16 亿用户的，有说 17.5 亿的；市场规模从 770 亿美元到 868 亿美元都有人写。

这一页不挑一个「最好看的」贴出来，而是把区间和**分歧的原因**讲清楚。

## 用户规模：16 亿到 17.5 亿

一亿五千万的差距，来自三个问法不同的问题：

1. **「你用过 VPN 吗？」** —— 包括装过一次就删的人，数字最大。
2. **「你上个月用过 VPN 吗？」** —— 活跃口径，中等。
3. **「你付费订阅 VPN 吗？」** —— 最小，也最接近商业意义上的用户。

多数汇总报告不写清楚自己用的是哪一种，于是它们被并排引用时就显得互相矛盾。

## 市场规模：定义差异比增长率更重要

市场规模的分歧点更具体：

- **算不算企业 VPN。** 企业远程访问网关是一门大生意，把它计入会让总额显著变大。
- **算不算硬件与集成服务。** 只算消费者订阅费，和把设备、部署、维护都算进去，差距巨大。
- **预测年份。** 图里第三条是预测，不是测量 —— 预测值不该和实测值放在同一句话里引用。

## 各国使用率

这类排行榜通常来自问卷面板，样本构成对结果影响很大：面板里年轻人和城市用户偏多，得出的使用率就会偏高。

把它当作**量级参考**是合理的，当作精确排名就不合理了。

## 怎么读这类数据

| 看到的写法 | 应该追问 |
|---|---|
| 「X 亿人使用 VPN」 | 用过一次，还是每月活跃？ |
| 「市场规模 X 亿美元」 | 含不含企业与硬件？ |
| 「X% 的网民在用」 | 分母是全球网民还是该国网民？ |
| 「预计增长到 X」 | 这是预测，谁做的，基于什么假设？ |

## 一条诚实的结论

**没有人确切知道有多少人在用 VPN。** 使用行为不需要登记，没有机构掌握全量数据，所有数字都是从问卷或市场推算出来的。

本站在其他页面里也遵循同一条原则：能核对的写清楚来源，不能核对的就说明它不能核对。选购时同样适用 —— 评估标准见 [如何选择VPN](/如何选择vpn/)。

### 常见问题

Q: 到底哪个数字是对的？
A: 都不算「对」。它们回答的是不同问题。要引用的话，请连同口径一起引用，例如「某报告口径下约 16 亿」。

Q: 为什么不用官方统计？
A: 因为不存在。VPN 使用不需要登记，没有任何机构掌握全量数据，所有数字都是推算。

Q: 使用率最高的国家为什么是这几个？
A: 通常与本地网络管制、流媒体分区、以及移动端免费应用的推广力度有关，几种因素叠加，不能只归因于一条。

---

# VPN术语表：60 个常见概念的中文解释

URL: https://yalgorup.com/vpn术语表/
类型: glossary
更新: 2026-08-01
一句话回答: 这份 VPN术语表 按「基础概念、协议、加密、隐私与泄露、网络与性能」五个主题整理，每条一句话说明，需要展开时可点进对应文章。

VPN术语表：从隧道、封装、AEAD 到 MOBIKE、DPI、RAM-only，按主题整理 60 个 VPN 术语与网络概念，每条给出一句话定义与延伸阅读。

这份 VPN术语表 收录了全站出现过的核心概念，按主题而不是按字母排列 —— 相邻的词往往属于同一个机制，连着读比单独查更容易记住。

## 基础概念

**VPN（虚拟专用网络）** — 在公共网络上建立的加密通道，用于保护传输并改变出口 IP。见 [VPN 是什么](/vpn是什么/)。

**隧道（Tunnel）** — 把一种协议的数据包装进另一种协议中传输的机制，是 VPN 的核心比喻与实体。

**封装（Encapsulation）** — 把原始数据包整体当作载荷，塞进新数据包的过程。

**TUN 设备** — 工作在第三层的虚拟网卡，处理 IP 数据包，绝大多数 VPN 使用它。

**TAP 设备** — 工作在第二层的虚拟网卡，处理以太网帧，用于需要桥接局域网的场景。

**出口 IP** — 目标网站看到的来访地址，使用 VPN 后即服务器的 IP。

**分流（Split Tunneling）** — 只让部分应用或目标网段走隧道，其余直连。

**远程访问 VPN** — 单台设备连入远端网络，个人和远程办公的常见形态。

**站点到站点 VPN** — 两个网络之间的长期隧道，终端无感知。见 [VPN 的类型](/vpn类型/)。

**虚拟位置** — 标称在某国、实际机器在别处的服务器节点。

## 协议

**WireGuard** — 2016 年提出的现代协议，加密套件固定、代码量小、握手仅一个往返。见 [WireGuard](/wireguard/)。

**OpenVPN** — 2001 年发布，基于 TLS，可走 UDP 或 TCP，伪装能力强。见 [OpenVPN](/openvpn/)。

**IKEv2** — IPsec 体系中负责密钥协商的协议（RFC 7296）。

**IPsec** — 保护 IP 层通信的框架，包含 IKE、ESP 等组件。

**ESP** — IPsec 中负责加密与封装数据包的协议（RFC 4303）。

**MOBIKE** — IKEv2 的漫游扩展（RFC 4555），IP 变化时保持连接不断。

**L2TP** — 二层隧道协议，自身不加密，需搭配 IPsec。

**PPTP** — 早期隧道协议，认证机制已被证明可破解，不应再使用。

**SSTP** — 微软的隧道协议，走 TCP 443，外观类似 HTTPS，但闭源。

**Noise 协议框架** — WireGuard 握手所基于的密码学协议构建框架。

**Cryptokey Routing** — WireGuard 把公钥与允许 IP 段绑定的机制，鉴权与路由合一。

**DCO（Data Channel Offload）** — 把 OpenVPN 数据通道下沉到内核以提升性能的机制。

## 加密

**对称加密** — 加解密用同一把密钥，速度快，用于传输数据。

**非对称加密** — 公钥私钥成对，用于身份验证与密钥协商。

**Diffie-Hellman（DH）** — 在公开信道上协商出共享密钥的算法。

**ECDHE** — 椭圆曲线版本的临时 DH，现代实现的标准做法。

**Curve25519** — 广泛使用的椭圆曲线，性能好且实现不易出错（RFC 7748）。

**AES-256** — 分组加密算法，256 位密钥（FIPS 197）。

**GCM** — AES 的一种工作模式，内建完整性校验（NIST SP 800-38D）。

**ChaCha20-Poly1305** — 流密码加认证的组合，无硬件加速时性能优于 AES（RFC 8439）。

**AEAD** — 带关联数据的认证加密，把加密与校验合并为一个原语。

**前向保密（PFS）** — 长期私钥泄露后，历史流量仍无法解密的性质。

**HKDF** — 基于 HMAC 的密钥派生函数（RFC 5869）。

**握手（Handshake）** — 建立连接时验证身份并协商密钥的过程。

**密钥轮换（Rekey）** — 定期更换会话密钥，缩小单把密钥的影响范围。

**PSK（预共享密钥）** — 事先约定的共享秘密，多用户共用时是常见弱点。

## 隐私与泄露

**无日志（No-log）** — 声称不保存用户活动记录，需以审计或司法记录佐证。见 [日志政策](/vpn日志政策/)。

**连接日志** — 连接时间、时长、流量等元数据。

**活动日志** — 访问的域名、DNS 查询等行为记录。

**RAM-only / 内存化** — 服务器不使用硬盘，断电即清空全部状态。

**独立审计** — 第三方对代码或基础设施的检查，需关注范围与日期。

**透明度报告** — 定期披露收到的执法请求数量与处理结果。

**Warrant Canary** — 定期更新的声明，停止更新即构成暗示。

**DNS 泄露** — 域名解析请求绕过隧道，暴露访问的域名。见 [泄露检测](/vpn泄露/)。

**IPv6 泄露** — 客户端只接管 IPv4，IPv6 流量直连造成暴露。

**WebRTC 泄露** — 浏览器通过 ICE 暴露本地或公网 IP。

**ICE** — WebRTC 用于收集候选地址、建立点对点连接的框架（RFC 8445）。

**Kill Switch（断网保护）** — 隧道中断时阻断出站流量。见 [Kill Switch](/kill-switch/)。

**Always-on VPN** — 系统级的常连接模式，Android 与受管 iOS 设备支持。

**浏览器指纹** — 通过浏览器特征组合识别用户的技术，不受 IP 变化影响。

## 网络与性能

**MTU** — 单个数据包的最大传输单元，封装后需相应下调。

**Path MTU Discovery** — 探测路径上最小 MTU 的机制（RFC 1191）。

**延迟（RTT）** — 数据包往返一次的时间，受物理距离与跳数限制。

**带宽** — 单位时间可传输的数据量。

**丢包率** — 传输中丢失数据包的比例，影响 TCP 模式尤其明显。

**NAT** — 网络地址转换，VPN 服务器借此把多个用户映射到一个公网 IP。

**NAT-T** — IPsec 的 NAT 穿透机制，用 UDP 4500 封装 ESP（RFC 3948）。

**TCP-over-TCP** — 隧道内外都是 TCP 时重传叠加导致的性能退化。

**DPI（深度包检测）** — 通过特征分析识别流量类型的技术。

**主动探测** — 检测方主动连接可疑服务器以确认其性质的手段。

**混淆（Obfuscation）** — 消除流量可识别特征的技术，见 [混淆与伪装协议](/vpn混淆协议/)。

**obfs4** — Tor 的可插拔传输之一，使流量呈现为随机数据并抵抗主动探测。

**Shadowsocks** — 使用 AEAD 加密的代理协议，流量无明显协议头。

**SNI** — TLS 握手中明文携带的服务器名称，是域名可见性的来源之一。

**DoH / DoT** — 通过 HTTPS 或 TLS 加密 DNS 查询的方案（RFC 8484 等）。

**AES-NI** — 处理器中的 AES 硬件加速指令集。

### 常见问题

Q: 这些术语需要全部记住吗？
A: 不需要。理解隧道、封装、对称/非对称加密、前向保密、泄露这几个核心概念，其余在遇到时查即可。

Q: 有推荐的阅读顺序吗？
A: 建议先读基础概念一节，再按需要跳到协议或加密部分。完整的入门路径见 VPN 是什么。

---

# 关于本站

URL: https://yalgorup.com/about/
类型: page
更新: 2026-08-01

Yalgorup（VPN知识库）是一个中文技术百科，只解释 VPN 的原理、协议与隐私机制。本页说明内容原则、编辑方式与利益披露。

## 这是什么站

**Yalgorup / VPN知识库** 是一个中文技术资料站，专注解释一件事：VPN 这项技术到底是怎么回事。

数据包在隧道里经历了什么、WireGuard 和 OpenVPN 差在哪、加密算法保护的是什么、日志政策的措辞意味着什么 —— 这些问题在中文网络上要么被讲得过于简略，要么被夹在购买推荐里一带而过。这个站点想把它们单独讲清楚。

## 内容原则

**只写能核实的内容。** 涉及协议行为的部分，尽可能引用 RFC、官方文档或公开的学术研究，并在文末列出来源，方便读者自己去查。

**不编造测试数据。** 我们不会给出没有真实测量依据的速度数字、评分或「实测结论」。当某个结论依赖具体环境时，会说明这一点。

**写清楚边界。** 一项技术做不到什么，往往比它能做什么更重要。关于 VPN 的多数误解，都源于对边界的模糊描述。

**保持中立。** 讲协议就讲协议，不在技术文章里夹带产品推荐。

## 目前不做什么

截至本页更新时，本站：

- 没有任何广告
- 没有联盟推广链接
- 不销售任何产品或服务
- 不使用第三方追踪脚本（详见 [隐私政策](/privacy/)）

如果将来引入任何形式的商业合作，我们会在页面上明确标注，并单独设立披露页面。在那之前，这里的内容不受任何商业关系影响。

## 内容怎么写出来的

文章由编辑部撰写，主要参考来源包括：

- IETF 的 RFC 文档（协议行为的权威定义）
- 各协议项目的官方文档与白皮书
- NIST、CISA 等机构公开的技术指南
- 经过同行评审的学术论文

涉及具体数字或结论时，我们会标注出处和年份 —— 网络安全领域的结论有时效性，五年前成立的判断今天未必成立。

## 纠错

技术文档难免出错。如果你发现事实性错误、过时信息或表述不清的地方，欢迎通过 [联系方式](/contact/) 告诉我们。指出具体位置和你认为正确的说法，会让处理更快。

## 免责

本站内容用于技术学习与参考，不构成法律建议，也不构成对任何产品的推荐或担保。详见 [免责声明](/免责声明/)。

---

# 联系方式

URL: https://yalgorup.com/contact/
类型: page
更新: 2026-08-01

内容纠错、事实核实、内容建议或合作咨询的联系方式。

## 邮箱

**hello@yalgorup.com**

这是本站唯一的联系渠道。我们没有客服电话，也没有在线聊天。

## 写邮件时请注明

为了让处理更快，建议在邮件里包含：

**内容纠错** —— 页面链接、具体段落、你认为正确的说法，以及可参考的出处。有出处的纠错我们会优先处理。

**内容建议** —— 你希望看到哪个主题被展开、目前哪部分讲得不够清楚。

**引用与转载** —— 说明使用范围与出处标注方式。

**其他咨询** —— 请直接说明来意。

## 我们不提供的

- 针对具体产品的选购建议
- 技术支持与故障排查（我们不销售任何服务）
- 法律咨询

关于本站的定位和内容原则，见 [关于本站](/about/)。

---

# 隐私政策

URL: https://yalgorup.com/privacy/
类型: page
更新: 2026-08-01

本站收集哪些信息、不收集哪些信息，以及托管服务商在技术上会处理的数据。

## 简短版本

本站是一个静态网站，不需要注册、不设账号、不使用第三方追踪脚本，也不投放广告。我们没有主动收集任何可识别个人身份的信息。

## 本站不做的事

- 不设置用于追踪的 Cookie
- 不加载广告网络或社交媒体追踪代码
- 不要求注册、不收集邮箱（除非你主动写邮件给我们）
- 不销售或共享任何用户数据

## 托管方会处理什么

本站托管在 Cloudflare Pages 上。和所有网站一样，服务器在响应请求时会处理一些技术性信息，用于内容分发和防止滥用：

- 请求的 IP 地址
- 浏览器 User-Agent 与语言设置
- 访问的页面路径与时间
- Referer（从哪个页面跳转过来）

这些数据由托管服务商按其自身政策处理，我们不会主动导出、留存或与其他信息关联。

## 你主动提供的信息

如果你通过 [联系方式](/contact/) 给我们写邮件，那么你的邮箱地址和邮件内容会保留在邮箱服务里，用于回复你的问题。我们不会把它用于其他用途，也不会加入任何邮件列表。

## 外部链接

文章中的参考资料链接指向外部网站（RFC 文档、官方文档、学术论文等）。点击后你将离开本站，对方网站的隐私实践由其自行决定，本站不承担责任。

## 统计与广告

截至本页更新时，本站**没有部署**访问统计工具，也没有任何广告或推广链接。

如果将来引入网站统计，我们会在本页更新说明所使用的工具、收集范围以及是否可选择退出；如果引入任何形式的商业合作，也会在相关页面明确标注。

## 变更

本政策如有修改，会更新本页并调整页面日期。重大变更会在首页说明。

## 联系

隐私相关问题请发送至 **hello@yalgorup.com**。

---

# 免责声明

URL: https://yalgorup.com/免责声明/
类型: page
更新: 2026-08-01

本站内容的性质、适用范围与责任限制说明。

## 内容性质

本站内容用于**技术学习与参考**，属于科普与资料整理，不构成：

- 法律建议
- 安全咨询意见
- 对任何产品或服务的推荐、担保或背书

涉及各地法律法规的部分，只是框架层面的整理。法规与执法实践会随时间变化，具体问题应咨询所在法域的执业律师。

## 准确性

我们在写作时尽可能引用一手来源（RFC、官方文档、公开研究），并在文末列出出处。即便如此：

- 技术标准会更新，文中描述可能滞后于最新版本
- 引用的研究有明确的时间与样本范围，结论不应无条件外推
- 难免存在疏漏与错误

发现问题欢迎通过 [联系方式](/contact/) 指出。

## 使用风险

你如何使用本站提供的信息，由你自行判断并承担相应后果。配置网络设备、修改系统设置、选择网络服务都可能带来风险，本站不对由此产生的任何直接或间接损失负责。

## 合规使用

本站讨论的是技术原理。使用任何网络技术都应遵守你所在地区的法律法规，以及相关服务的用户协议。技术本身的合法性，不等于用它所做行为的合法性。

## 外部链接

参考资料中的外部链接仅为方便查证，本站不对其内容、可用性或其隐私实践负责。

## 商业关系披露

截至本页更新时，本站没有任何广告、联盟推广链接或商业合作。若将来发生变化，我们会在相关页面标注，并设立独立的披露页面。

## 变更

本声明如有修改，会更新本页内容与日期。