魔法学导论

这里的"魔法"不是玄学, 而是对代理网络, 加密传输, 流量分流和线路选择的一种比喻. 对初学者来说, 这些概念一开始会显得很杂: VPN, Proxy, DNS, TLS, Shadowsocks, Trojan, VLESS, Hysteria2, CN2, IPLC, TUN 模式, FakeIP 等等. 但它们其实都围绕一个核心问题:

当你的应用想访问一个目标网站时, 数据包应该怎么走, 中间经过谁, 谁能看到什么, 以及如何让这条路径更稳定, 更安全, 更可控.

这篇文档会从基本概念开始讲起. 目标不是让你背诵协议名字, 而是让你能够读懂配置, 判断常见故障, 理解不同方案的取舍.

为什么需要梯子?

"梯子"是中文互联网里对代理访问工具的俗称. 它的作用可以粗略理解成: 当你和目标网站之间的直连路径不稳定, 不可达, 被干扰, 或者需要更强的隐私保护时, 让流量先到达一个中间节点, 再由中间节点帮你访问目标网站.

一个最简化的访问链路如下:

如果不用代理, 通常是:

你的应用 -> 本地网络 -> 运营商 -> 目标网站

使用代理后, 变成:

你的应用 -> 本地代理客户端 -> 远程代理服务器 -> 目标网站

这里最重要的不是"多绕一跳", 而是这几个变化:

• 目标网站看到的访问来源通常是代理服务器, 而不是你的本地公网出口.
• 本地网络看到的是你和代理服务器之间的连接, 不直接看到你最终访问的每一个目标连接.
• 代理客户端可以根据规则决定哪些流量直连, 哪些流量走代理.
• 代理协议可以对客户端和服务器之间的流量进行加密, 认证, 混淆或伪装.

代理不是万能的. 它不能让慢服务器变快, 不能保证所有线路稳定, 也不能自动保护所有应用. 它更像一条可配置的备用路径: 走得好不好, 取决于协议, 线路, DNS, 本地网络, 远端服务器和客户端配置.

VPN vs. Proxy

VPN 和 Proxy 都可以把流量转发到另一个节点, 但它们工作的层级和使用方式不同.

可以这样理解:

• VPN 像是给电脑装了一张"虚拟网卡". 系统把很多流量都交给这张网卡, 再由 VPN 程序送到远端.
• Proxy 像是一个"代办窗口". 应用把请求交给本地代理, 本地代理再代表它去访问目标.

例如浏览器使用 HTTP/SOCKS 代理时, 浏览器知道自己正在找代理帮忙. 而 VPN 模式下, 浏览器通常不知道底层网络已经被 VPN 接管.

常见的代理使用方式:

curl -x socks5h://127.0.0.1:7891 https://example.com
curl -x http://127.0.0.1:7890 https://example.com

这里的 127.0.0.1 是本机, 7890 和 7891 是本地代理客户端监听的端口. socks5h 中的 h 表示域名解析也交给 SOCKS5 代理处理, 可以减少 DNS 泄漏.

为什么代理更适合国内环境?

这里说的"更适合"不是绝对结论, 而是很多国内用户在日常使用中更常选择代理工具, 原因主要有几个.

第一, 代理更容易做规则分流. 国内网站, 学校内网, 公司内网和延迟敏感服务通常希望直连; 只有一部分国际网站走代理. 如果整机都走 VPN, 可能会导致国内服务变慢, 内网资源访问异常, 甚至出现登录风控.

第二, 代理客户端更擅长处理复杂 DNS. 国内网络环境里, DNS 污染, DNS 泄漏, FakeIP, DoH, 分流 DNS 都很常见. 代理客户端可以根据域名规则决定 DNS 怎么解析, 连接怎么路由.

第三, 代理协议的传输层更灵活. 例如可以跑在 TCP, WebSocket, gRPC, QUIC, TLS 等不同传输方式上. 有些协议会尽量让外观接近普通 HTTPS 流量, 降低被简单特征识别的概率.

第四, 代理更适合"多节点切换". 很多客户端支持延迟测试, 自动选择, 故障转移和规则组. 这对跨境线路质量波动较大的环境很有用.

不过 VPN 仍然有自己的价值. 例如公司内网接入, 零信任网络, WireGuard 组网, 远程访问家庭网络等场景, VPN 往往更直接, 更标准, 更容易被网络管理员审计和维护.

网络概念简介

学习代理之前, 先要理解几个网络基础概念.

IP地址和端口

IP 地址用来定位网络上的一台机器或一个网络接口. 常见的是 IPv4, 例如:

93.184.216.34
192.168.1.10
127.0.0.1

也有 IPv6, 例如:

2606:2800:220:1:248:1893:25c8:1946
::1

端口用来区分同一台机器上的不同服务. 如果 IP 是一栋楼的地址, 端口就像楼里的房间号.

常见端口:

127.0.0.1 是回环地址, 表示本机. 如果代理客户端监听在 127.0.0.1:7890, 意味着只有本机程序可以连接这个代理端口. 如果监听在 0.0.0.0:7890, 则可能允许局域网其他设备连接, 这需要额外注意访问控制.

查看端口是否在监听:

lsof -i :7890

或者:

ss -lntp

TCP vs. UDP

TCP 和 UDP 是两种常见传输层协议.

TCP 像打电话. 建立连接后, 双方持续通信, 数据按顺序到达, 丢了会重传. 浏览器访问大多数 HTTPS 网站时使用 TCP.

UDP 像寄明信片. 每个数据包相对独立, 协议本身不保证顺序和重传. 但 UDP 延迟低, 灵活, 很适合游戏, 语音视频, QUIC, WireGuard, Hysteria2 等场景.

代理协议选择 TCP 或 UDP 会影响体验. TCP 在线路稳定时很可靠, 但在高丢包环境下可能因为重传和拥塞控制变慢. UDP/QUIC 类协议可以在高延迟, 高丢包环境里表现更好, 但前提是本地网络和服务器都允许 UDP 正常通过.

DNS解析

人类记域名, 机器连 IP. DNS 的作用就是把域名翻译成 IP 地址.

例如:

example.com -> 93.184.216.34

访问网站通常包含两步:

1. 问 DNS: example.com 的 IP 是多少?
2. 连接这个 IP 的 443 端口: 发起 HTTPS 请求.

可以用下面的命令查看解析结果:

dig example.com
nslookup example.com

代理场景里 DNS 很重要, 因为"域名解析在哪里发生"会影响隐私, 分流和可用性.

如果本地 DNS 被污染, 本地解析可能得到错误 IP. 如果 DNS 请求没有走代理, 即使网页流量走了代理, 本地网络仍可能知道你查询过什么域名, 这就是 DNS 泄漏的一种来源.

DNS污染和DNS泄漏

DNS 污染是指 DNS 查询过程中返回了错误的解析结果. 可以把它理解成: 你问路时, 有人抢先给了你一个错误地址.

DNS 污染可能表现为:

• 解析到不存在或错误的 IP.
• 同一个域名在不同网络环境下解析结果差异很大.
• 浏览器提示连接失败, 证书错误, 或目标地址不匹配.

DNS 泄漏是另一个问题. 它指的是你的主要访问流量走了代理, 但 DNS 查询仍然从本地网络直接发出. 这样本地 DNS 服务器或网络路径仍可能看到你查询的域名.

例如:

网页连接: 浏览器 -> 代理 -> 目标网站
DNS 查询: 浏览器/系统 -> 本地 DNS -> 运营商

这时你可能以为"全都走代理了", 但域名查询其实没有.

很多境外网站在国内并不是真正意义上的被"墙", 而是因为 DNS 污染导致解析失败. 典型的例子就是 GitHub, 国内从未正式"墙"过它, 但是持续有 DNS 污染, 导致看起来像"GitHub 被墙了".

TLS/SSL加密

TLS 是 HTTPS 使用的主要加密协议. SSL 是它的前身, 现在口语里仍有人说 SSL, 但现代系统主要使用 TLS.

TLS 做了几件事:

• 加密: 中间人不能直接看到 HTTP 内容.
• 完整性校验: 防止内容在传输途中被悄悄修改.
• 身份验证: 通过证书确认你连接的确实是目标域名对应的服务.

访问 https://example.com 时, 浏览器会和服务器进行 TLS 握手. 握手过程中, 服务器会出示证书, 浏览器验证证书链, 然后双方协商会话密钥.

不过 TLS 并不隐藏一切. 在很多场景下, 外部仍可能观察到:

• 你连接的 IP 地址.
• 连接时间, 频率, 数据包大小.
• TLS 握手的一些特征.
• 某些情况下的 SNI, 也就是你想访问的域名提示.

所以, 加密保护的是内容, 不等于完全隐身.

HTTP和HTTPS

HTTP 是明文网页协议. HTTPS 是 HTTP over TLS, 也就是先建立 TLS 加密通道, 再在里面传输 HTTP.

HTTP  = HTTP 明文
HTTPS = TLS 加密通道 + HTTP

代理协议经常会借用 HTTPS 的外观. 例如 Trojan, VLESS over TLS, WebSocket over TLS, gRPC over TLS 等配置, 都会让外层看起来接近普通 HTTPS 连接.

但"看起来像 HTTPS"不等于"一定无法识别". 实际网络里还会涉及证书, 域名, ALPN, SNI, TLS 指纹, HTTP 行为, 数据包时序等特征. 流量伪装的目标不是变成魔法隐身, 而是减少明显异常, 让流量更像合理的普通应用流量.

DoH和DoT

DoH 和 DoT 都是加密 DNS 的方式.

普通 DNS 通常使用 UDP 53, 明文传输. DoH/DoT 会把 DNS 查询加密, 降低被中间路径读取和篡改的概率.

但加密 DNS 也不是万能的:

• 你仍然需要信任所使用的 DNS 服务商.
• 如果网页连接不走代理, 目标 IP 和连接行为仍然可见.
• 如果代理客户端和浏览器各自使用不同 DNS 逻辑, 可能导致分流异常.

更重要的是保持 DNS 策略一致: 代理客户端负责分流时, 尽量让代理客户端统一处理 DNS, 不要让浏览器, 系统和代理客户端各走各的逻辑.

FakeIP

FakeIP 是很多代理客户端里的 DNS 模式. 它不会把域名解析成真实 IP, 而是先返回一个"假的 IP", 再在代理客户端内部记录:

198.18.0.123 -> example.com

当应用连接 198.18.0.123 时, 代理客户端知道这个连接其实对应 example.com, 于是可以继续按域名规则分流.

FakeIP 的优点是分流准确, 尤其适合 TUN 模式. 因为很多程序最终只会连接 IP, 而不告诉系统"我原本想访问哪个域名". FakeIP 让代理客户端重新掌握域名信息.

FakeIP 的常见问题是:

• 某些局域网设备, 游戏, 银行软件或企业软件不喜欢假 IP.
• 如果 FakeIP 缓存错乱, 可能出现连接到错误域名的异常.
• 需要为内网域名, 局域网地址, NTP, mDNS 等配置排除规则.

NAT和端口转发

NAT 是网络地址转换. 家里的路由器通常会让多台设备共享一个公网出口:

手机 192.168.1.20 \
电脑 192.168.1.21  -> 路由器公网 IP -> Internet
平板 192.168.1.22 /

内网设备可以主动访问外网, 因为路由器会记录连接状态. 但外网想主动访问内网设备时, 路由器不知道该转发给谁. 这时就需要端口转发.

例如你在家里电脑运行一个服务:

192.168.1.21:8080

你需要在路由器上配置:

公网 IP:8080 -> 192.168.1.21:8080

云服务器也有类似概念. 除了程序监听端口以外, 还要检查:

• 系统防火墙是否放行.
• 云厂商安全组是否放行.
• 服务是否监听在正确地址, 例如 0.0.0.0 而不是 127.0.0.1.
• 协议是 TCP 还是 UDP.

代理服务器部署失败时, 很多时候不是协议错了, 而是端口根本没有从公网打通.

国内网络环境的特殊性

国内网络环境有几个现实特点, 会影响代理体验.

第一, 跨境链路质量波动明显. 晚高峰时, 国际出口拥塞可能导致延迟升高, 丢包增加, 视频卡顿.

第二, 不同运营商之间互联质量不同. 电信, 联通, 移动, 教育网到同一海外节点的路径可能完全不同. 一个节点在电信很好, 在移动可能很差.

第三, DNS 环境复杂. 本地 DNS, 公共 DNS, DoH, 代理客户端 DNS, 浏览器内置 DNS 如果混在一起, 很容易出现"能 ping 通但网页打不开", "某些网站直连了", "规则不生效"等问题.

第四, 简单加密不等于稳定可用. 有些协议加密了内容, 但握手特征, 传输行为或端口使用仍然很明显. 这也是为什么很多现代配置会考虑 TLS, WebSocket, gRPC, QUIC, Reality, fallback, masquerade 等传输层和伪装设计.

第五, 主动探测和误封都可能存在. 因此服务端暴露的端口, 证书, 回落站点, 访问行为和日志都应该认真配置. 初学者不需要一开始追求最复杂方案, 但要知道"连得上"和"设计合理"不是一回事.

第六, 国内的网络本质上是一个超大的局域网, 大规模使用 NAT, 并且存在频繁 DNS 污染和流量干扰, 导致外部可达性极差.

BGP

BGP 是互联网里不同自治系统之间交换路由信息的协议. 可以把互联网想象成很多家快递公司组成的巨大网络, BGP 负责告诉大家: 要去某个 IP 段, 应该往哪边转交.

代理线路里常说的 BGP 有两层含义:

第一层是标准互联网路由协议, 也就是 Border Gateway Protocol.

第二层是商家宣传里的"多线 BGP". 它通常表示机房接入了多个运营商或多个上游, 希望不同网络的用户都能通过较优路径到达.

需要注意, "BGP 线路"不是自动等于快. 它只表示路由层面有多线路选择能力. 实际速度还要看:

• 机房上游质量.
• 到你本地运营商的路径.
• 是否绕路.
• 晚高峰拥塞情况.
• 服务器带宽和限速策略.

常用排查工具:

ping example.com
traceroute example.com
mtr example.com

ping 看延迟和丢包, traceroute 看路径, mtr 会持续统计每一跳的表现.

CDN

CDN 是内容分发网络. 它把网站内容缓存到离用户更近的边缘节点, 让用户访问更快.

例如你访问一个图片:

没有 CDN: 你 -> 源站服务器
有 CDN:   你 -> 附近 CDN 节点 -> 必要时回源

CDN 在代理语境里常见于两类场景.

第一, 正常网站加速. 比如静态资源, 图片, 视频, 软件包下载.

第二, 流量入口伪装或转发. 某些代理配置会把流量放在 HTTPS, WebSocket, gRPC 等看起来像普通网站请求的外壳里, 再通过 CDN 转发到后端服务器.

但 CDN 不是万能遮罩. 它有明显限制:

• CDN 只支持特定端口和协议.
• UDP 类协议通常不能直接通过普通 CDN.
• 使用 CDN 会增加一层转发, 延迟可能上升.
• CDN 厂商有自己的规则和风控.
• 如果配置不合理, 反而会出现证书, Host, SNI, 路径不匹配等问题.

代理协议

代理协议决定了客户端和服务器之间怎么认证, 怎么加密, 怎么传输, 以及外观看起来像什么.

可以把代理协议拆成四层理解:

应用请求:     浏览器想访问 example.com
代理协议:     Shadowsocks / VMess / Trojan / VLESS / Hysteria2
传输外壳:     TCP / WebSocket / gRPC / QUIC / HTTP/2 / HTTP/3
安全与伪装:   TLS / Reality / obfs / masquerade / fallback

例如说"我用的是 VLESS", 但真正影响外观的可能是 VLESS + TCP + TLS, VLESS + WebSocket + TLS, VLESS + gRPC + TLS 或 VLESS + Reality. 同一个代理协议, 搭配不同传输方式, 网络特征会不同.

加密, 认证, 伪装, 混淆

这几个词经常一起出现, 但含义不同.

加密保护内容, 但不一定隐藏协议特征. 混淆和伪装可以改变外观, 但如果没有正确加密和认证, 仍然不安全.

流量伪装通常关注这些方面:

• 端口: 使用 443 更接近普通 HTTPS.
• TLS: 使用真实证书和正常握手.
• 域名: 使用合理的 SNI 和 Host.
• ALPN: 表示 HTTP/1.1, HTTP/2, HTTP/3 等应用层协议.
• 路径: WebSocket 或 HTTP 请求路径看起来像正常网站资源.
• 回落: 非代理请求能返回正常网页, 而不是直接暴露服务异常.
• 指纹: TLS 参数, 包大小, 时序行为尽量减少异常.

混淆的思路通常是"不要让第一眼就看出这是某种代理协议". 早期很多协议会在握手里暴露明显固定字节, 很容易被特征匹配. 后来的协议更倾向于借助标准 TLS, QUIC, HTTP/2, HTTP/3 等真实协议外壳.

Shadowsocks(R)

Shadowsocks 是一种轻量代理协议. 它的常见工作方式是:

应用 -> 本地 SOCKS/HTTP 代理 -> Shadowsocks 客户端 -> 加密连接 -> Shadowsocks 服务端 -> 目标网站

Shadowsocks 的核心思想是简单: 客户端和服务端共享密码和加密方法, 客户端把目标地址和数据加密后发给服务端, 服务端解密后连接目标网站.

它通常包含:

• server: 服务器地址.
• server_port: 服务器端口.
• method: 加密方法, 现代配置通常使用 AEAD 类加密.
• password: 共享密码.

概念示例:

{
  "server": "server.example.com",
  "server_port": 8388,
  "method": "2022-blake3-aes-128-gcm",
  "password": "your-password"
}

Shadowsocks 的优点:

• 协议轻量, 实现多, 资源占用低.
• 适合基本的 TCP/UDP 代理.
• 配置相对容易理解.

需要注意:

• Shadowsocks 本身不等于 HTTPS, 外观不一定像普通网站.
• 早期加密方法和插件可能已经不适合新环境.
• UDP 支持取决于客户端, 服务端和网络环境.
• 密码太弱会带来安全风险.

ShadowsocksR 是 Shadowsocks 的一个历史分支, 增加了 protocol 和 obfs 等混淆选项. 但生态较旧, 实现兼容性不如现代主流方案. 它是早期为了对抗简单特征识别, 人们在原始协议外面加了一层"包装"的产物. 现在来看这种设计思路早已过时, 因此几乎没有人再用 ShadowsocksR 了.

当然曾经 ShadowsocksR 的混淆还能用在运营商定向流量免流量的场景里, 通过协议和混淆的特征让流量看起来像某个特定应用的流量, 从而绕过流量计费. 不过那已经是历史上曾经发生过的另一件事了.

现在 Shadowsocks 的流量特征已经能被稳定识别了, 几乎已经是关键时期秒封的状态了. 在很多中转机场中你可能会看到 Shadowsocks 仍然大量使用, 看起来还很稳定. 那是因为 Shadowsocks 只用来跑从你的机器到境内中转机器的那一段, 出境仍然走专线或者其他协议.

VMess

VMess 是 V2Ray 生态里的一个代理协议. 它比 Shadowsocks 更复杂, 支持用户身份认证, 多种传输方式和路由能力.

VMess 的典型结构:

应用 -> 本地客户端 -> VMess 协议层 -> 传输层 TCP/WS/gRPC -> 远程服务端 -> 目标网站

VMess 常见字段:

• address: 服务器地址.
• port: 服务器端口.
• uuid: 用户 ID.
• security: 加密或安全设置.
• network: 传输方式, 例如 tcp, ws, grpc.
• tls: 是否使用 TLS.

VMess 的设计重点是应用层代理和身份认证. 它可以直接跑在 TCP 上, 也可以跑在 WebSocket, HTTP/2, gRPC 等传输层上. 当它和 TLS, WebSocket, CDN 搭配时, 外观可以更接近普通 HTTPS 网站访问.

优点:

• 功能丰富, 路由和传输选项多.
• 生态里有很多客户端和服务端实现.
• 适合学习"代理协议 + 传输层 + TLS"的组合概念.

缺点:

• 配置复杂, 初学者容易把 UUID, alterId, security, transport, TLS 等概念混在一起.
• 老配置和新实现之间可能有兼容性问题.
• 如果不加 TLS 或伪装, 直接裸跑的特征可能比较明显.

可以把 VMess 理解成一个"功能很多的工具箱". 工具箱本身很灵活, 但你需要知道自己拿的是哪把工具, 以及它外面套了什么传输外壳.

VMess 现在已经被社区弃用了, 全面转向 VLESS. VMess 的问题是太过于笨重, 很多新的伪装和混淆思路都没有必要在它身上实现, 维护成本太高, 并且流量特征也已经逐渐被识别了.

Trojan

Trojan 的核心思路是: 尽量把代理流量伪装成正常 HTTPS 流量.

它通常运行在 443 端口, 使用 TLS 证书. 客户端连接服务端时, 外层先进行正常 TLS 握手. 服务端会检查客户端提交的密码或认证信息:

• 如果认证正确, 服务端把连接当作代理流量处理.
• 如果认证不正确, 服务端可以回落到一个普通网站.

简化流程:

Trojan 的优点:

• 外观接近标准 HTTPS.
• 概念相对清晰: TLS + 密码认证 + 代理转发.
• 适合搭配真实域名和证书.

注意点:

• 证书必须正确, 域名和 SNI 要匹配.
• 服务器 443 端口需要能正常访问.
• 回落站点要真实可用, 否则普通访问直接报错会显得异常.
• 如果证书过期, 客户端会失败, 外观也会异常.

Trojan 很适合用来理解"流量伪装"这个概念: 它不是发明一种奇怪的外壳, 而是直接借用互联网上最常见的 HTTPS 形态.

Vless

VLESS 是 V2Ray/Xray 生态里的轻量协议. 它和 VMess 的重要区别是: VLESS 本身不负责加密内容, 它更关注用户识别和代理语义, 加密通常交给 TLS, Reality 或其他传输安全层.

可以这样理解:

VMess: 协议自身包含较多安全和认证逻辑
VLESS: 协议更轻, 安全性主要依赖外层 TLS/Reality 等

VLESS 常见组合:

VLESS + TCP + TLS
VLESS + WebSocket + TLS
VLESS + gRPC + TLS
VLESS + Reality

其中:

• TCP + TLS: 结构直接, 外观类似普通 TLS 连接.
• WebSocket + TLS: 看起来像 HTTPS 网站里的 WebSocket 通信, 可与部分 CDN 场景结合.
• gRPC + TLS: 基于 HTTP/2 的长连接, 适合一些服务化场景.
• Reality: 一种更强调握手伪装和抗探测的方案, 让连接外观更接近访问真实站点.

需要注意的是:

• VLESS 裸跑没有加密保护, 不应该把"VLESS"本身当作安全层. 几乎没有人会单跑 VLESS.
• 不同组合之间配置差异很大, 不能只看协议名.
• UUID, flow, TLS, SNI, ALPN, path, serviceName 等字段必须匹配服务端.

初学者读 VLESS 配置时, 推荐按这个顺序看:

1. 服务器地址和端口是什么?
2. 用户 ID 是什么?
3. 底层传输是 tcp, ws, grpc 还是其他?
4. 是否启用 TLS 或 Reality?
5. SNI/Host/path/serviceName 是否和服务端一致?
6. 这个节点希望直连服务器, 还是经过 CDN?

Hysteria2

Hysteria2 是基于 UDP/QUIC 思路的代理协议, 常被用于高延迟, 高丢包或跨境线路质量波动较大的环境.

传统 TCP 在丢包时会明显降速, 因为它需要保证顺序和可靠性. QUIC 基于 UDP, 把连接管理, 加密, 重传和拥塞控制放到用户态协议里, 可以更灵活地应对复杂网络.

Hysteria2 的典型特点:

• 基于 UDP, 需要网络允许 UDP 通行.
• 使用 TLS 保护连接.
• 有自己的认证机制.
• 可以根据配置进行带宽控制和拥塞控制.
• 可以配置 masquerade, 让非代理访问看起来像普通 HTTP/3 服务.

简化理解:

TCP 代理: 像一列按顺序发车的火车, 前面卡住后面也容易受影响.
QUIC/UDP: 像多个快递包裹并行送达, 上层协议自己负责整理和补发.

Hysteria2 的优点:

• 在某些高丢包线路上速度更好.
• 对移动网络, 跨境网络波动有时更友好.
• 适合大流量下载, 视频等场景.

缺点:

• UDP 可能被运营商, 校园网, 公司网络或云厂商限制.
• 配置不当容易造成带宽占用过高.
• 由于行为和普通 TCP/TLS 不同, 并不总是最隐蔽.

Hysteria2 在弱网下的表现很好, 对于直连的机器是一个很不错的选择. 但问题是运营商可以选择直接屏蔽大流量 UDP 连接 (没少干), 此时 Hysteria2 就完全无法使用了. 因此 Hysteria2 更适合用来做"备用线路", 而不是主力方案.

线路选择

协议决定"怎么说话", 线路决定"路怎么走". 同样的协议, 换一条线路, 体验可能完全不同.

选择线路时一般看以下几个方面:

• 延迟: ping 的往返时间.
• 丢包: 包是否经常丢失.
• 抖动: 延迟是否稳定.
• 带宽: 最大传输能力.
• 晚高峰表现: 真实使用中的拥塞情况.
• 到不同运营商的质量: 电信, 联通, 移动, 教育网可能不同.
• 稳定性: 是否经常断线或换路由.

直连

直连线路通常是指用户流量直接从国内出口出境, 走普通公网国际出口的线路 (例如 163 骨干网). 这种线路一般成本较低, 但是质量波动非常大, 尤其是晚高峰时段, QoS 非常差.

CN2 GIA/CN2 GT

CN2 是中国电信的下一代承载网络品牌之一. 在代理线路语境里, 常见说法有 CN2 GIA 和 CN2 GT.

非常粗略地说:

• CN2 GIA: 通常指质量更高, 国际方向更优化, 价格也更高的线路.
• CN2 GT: 通常比普通线路好一些, 但质量和保障不如 GIA.

CN2 GIA 在晚高峰的表现通常比较稳定, 有较高的 QoS 保证. 从 traceroute 上看, CN2 GIA 通常走 59.43.x.x 的 AS4134 线路, 而普通线路可能走 202.97.x.x 的 AS4134 线路.

这些名称经常被商家用于线路宣传. 需要注意:

• 不同商家的标注不一定严格.
• 入口和回程可能不是同一种线路.
• 只对电信友好不代表对移动, 联通也好.

其他两家也有自己的精品线路, 例如联通的 AS9929, 移动的 CMI. 但由于出口带宽实际上是电信一家独大, 早期联通 AS9929 还得通过电信出口, 而移动 CMI 的国际出口质量也比较一般.

IPLC/IEPL

IPLC 和 IEPL 通常指专线或类专线产品.

• IPLC: International Private Leased Circuit, 国际专线.
• IEPL: International Ethernet Private Line, 国际以太网专线.

在代理语境里, 它们通常表示用户流量先进入国内或附近的入口节点, 再通过专线传到海外出口. 这样可以绕开普通公网国际出口的拥塞, 获得更稳定的跨境体验.

典型路径:

你 -> 国内入口 -> 专线传输 -> 海外出口 -> 目标网站

优点:

• 延迟和丢包通常更稳定.
• 晚高峰表现可能更好.
• 对普通用户体验友好.

缺点:

• 成本高.
• 带宽资源有限.

实际上真正的 IPLC(由于不可抗力几乎已经绝版) 和 IEPL 的成本是极其高昂的, 目前市场上很多 IEPL 并非真正意义上的专业, 可能开一个无限流量 eSIM 也宣称自己是 IEPL.

Anycast

Anycast 是一种让多个地点使用同一个 IP 地址的路由技术. 用户访问这个 IP 时, BGP 会把请求导向网络上"看起来最近"或路由最优的节点.

常见场景:

• 公共 DNS, 例如一些全球 DNS 服务.
• CDN 边缘节点.
• DDoS 防护网络.
• 全球入口负载均衡.

Anycast 的优点:

• 用户自动接入较近节点.
• 单个节点故障时, 路由可以切到其他节点.
• 适合全球服务入口.

但在代理语境里要谨慎理解. Anycast 解决的是"入口接入"问题, 不一定解决"出口到目标网站"的问题. 如果 Anycast 把你接入了一个很近的节点, 但这个节点到目标网站的出口很差, 体验仍然可能不好.

BGP优化

BGP 优化通常指通过更好的上游, 多线接入, 智能路由或回程优化, 让不同运营商用户访问服务器时获得更好的路径.

常见宣传词包括:

• 三网优化.
• 电信 CN2.
• 联通 AS9929.
• 移动 CMI.
• 精品网.
• 高防 BGP.

这些词有参考价值, 但不能替代测试. 因为用户体验取决于完整路径:

你的网络 -> 本地运营商 -> 国际出口/专线入口 -> 服务器入口 -> 服务器出口 -> 目标网站

一个节点适合你的朋友, 不一定适合你. 你们可能使用不同运营商, 不同城市, 不同学校网络, 甚至不同晚高峰拥塞状态.

工具使用

代理工具通常由三部分组成:

• 核心: 真正负责协议, 连接, DNS, 路由的程序.
• 客户端 UI: 提供图形界面, 订阅管理, 节点切换.
• 配置: 节点信息, DNS 设置, 规则分流, TUN 设置.

常见核心包括 sing-box, Xray, Clash Meta 等. 图形客户端则是在这些核心外面包了一层界面. 不同平台上客户端名字很多, 但底层思路相似.

为了灵活自如地实用工具, 要先掌握这几个问题:

1. 本地代理端口是多少?
2. 当前使用的是哪个节点?
3. DNS 由谁处理?
4. 哪些网站直连, 哪些网站走代理?
5. 当前是系统代理, 浏览器代理, 还是 TUN 模式?
6. 出问题时日志在哪里看?

代理工具

代理客户端通常会在本机开启一个或多个监听端口:

假设你的客户端监听:

HTTP:  127.0.0.1:7890
SOCKS: 127.0.0.1:7891

可以这样测试:

curl -x http://127.0.0.1:7890 https://example.com
curl -x socks5h://127.0.0.1:7891 https://example.com

如果你想知道当前出口 IP:

curl -x socks5h://127.0.0.1:7891 https://api.ipify.org

如果直连和代理结果不同, 说明代理端口大概率生效:

curl https://api.ipify.org
curl -x socks5h://127.0.0.1:7891 https://api.ipify.org

规则分流

规则分流是代理工具最重要的能力之一. 它决定一个连接应该直连, 走哪个代理, 还是拒绝.

常见规则类型:

示例:

rules:
  - DOMAIN-SUFFIX,edu.cn,DIRECT
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-KEYWORD,google,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

这组规则的意思是:

• edu.cn 后缀域名直连.
• github.com 走代理.
• 域名中包含 google 的走代理.
• 局域网 IP 直连.
• 中国大陆 IP 直连.
• 其他没有匹配到的流量走代理.

规则通常按顺序匹配, 第一条命中的规则生效. 因此顺序很重要. 如果把 MATCH,PROXY 放到最前面, 后面的规则就永远没有机会执行.

常见分流策略:

国内直连, 国外代理:
  CN 域名/IP -> DIRECT
  其他 -> PROXY

白名单模式:
  只有指定域名 -> PROXY
  其他 -> DIRECT

黑名单模式:
  指定域名 -> PROXY
  其他 -> DIRECT

全局代理:
  所有流量 -> PROXY

初学者建议从"国内直连, 其他代理"开始, 再根据实际需要手动添加规则. 不要一开始就追求极复杂规则集, 否则出了问题很难判断是 DNS, 节点, 还是规则本身的问题.

规则分流和 DNS 是绑定的. 如果连接阶段只剩 IP, 客户端可能无法知道原始域名, 域名规则就失效. 这就是 FakeIP 和 TUN 模式经常一起出现的原因.

TUN模式

TUN 模式会创建一个虚拟网卡, 让系统把更多网络流量交给代理客户端处理. 它比普通系统代理更底层, 因此可以接管那些不支持 HTTP/SOCKS 代理的应用.

普通系统代理:

支持代理的应用 -> HTTP/SOCKS 代理端口 -> 代理客户端
不支持代理的应用 -> 直接联网

TUN 模式:

应用 -> 系统路由 -> 虚拟网卡 TUN -> 代理客户端 -> 直连或代理

TUN 的优点:

• 可以代理不支持系统代理的程序.
• 对命令行工具, 游戏, Electron 应用更有效.
• 可以结合 FakeIP 做更准确的域名分流.
• 更接近 VPN 的整机接管体验.

TUN 的缺点:

• 需要较高权限, 因为要创建虚拟网卡和改路由.
• 配置不当会导致断网, DNS 异常, 内网访问失败.
• 某些系统安全软件, 校园网客户端, 企业 VPN 可能与 TUN 冲突.
• 对局域网, 打印机, NAS, SSH 内网连接要设置排除规则.

适合开启 TUN 的场景:

• 某个应用不支持手动设置代理.
• 命令行工具不想逐个配置 HTTP_PROXY, HTTPS_PROXY.
• 需要更完整地处理 DNS 和 UDP.
• 希望游戏, 开发工具, 包管理器都按规则分流.

命令行工具也可以不用 TUN, 直接设置环境变量:

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7891

绝大多数情况下只要规则配置合理, 软件代理设置正确就够了, 用不上 TUN 模式.

取消代理:

unset HTTP_PROXY
unset HTTPS_PROXY
unset ALL_PROXY

很多工具会读取这些环境变量, 例如 curl, git, pip, npm 等. 但极少程序还是不遵守它们的, 这时 TUN 模式就可以派上用场.