本文定位为技术编年史，严守中立客观立场，不提供任何具体的操作指南或节点信息。如果有任何地方违反任何社区规则，随时删除。

1. 背景

本文旨在梳理一下 2010 年代初至 2026 年间，网络代理工具及其核心协议的演进历史。从早期的传统 VPN/代理，到 Shadowsocks 开创的自研加密时代，再到 V2Ray、Clash 等复杂生态的兴起。

为了确保这段历史的准确性，来源优先级如下：

1. 核心协议提案：Shadowsocks 的 SIP（Shadowsocks Improvement Proposal）提案（SIP003 插件、SIP004 AEAD）、V2Ray/Xray 的 Release Notes。
2. 社区讨论：GitHub Issue 里的技术辩论与 Commit 记录。
3. 学术研究：USENIX Security 等顶会论文（如 Wu et al. 2023）。

2. 版本里程碑时间线（2012–2026）

2012–2015：Shadowsocks 时代

• 2012-04-20：Shadowsocks Python 版发布，首个版本确立 SOCKS5 代理架构
• 2015-04：Shadowrocket 上架，成为 iOS 首个主流代理客户端
• 2015-08-21：Shadowsocks 项目归档，转向社区维护

2015–2017：代理协议井喷期

• 2015-09-18：V2Ray v0.1 (beta) 发布，引入 VMess 协议与 UUID 认证
• 2015-10：Surge 发布，iOS 代理工具鼻祖，定义规则分流标准
• 2016：WireGuard 首次发布，现代 VPN 协议
• 2017：Brook 发布，极简跨平台代理工具
• 2017-02-18：V2Ray v2.19 发布，VMess 强制防重放机制，AEAD 加密升级
• 2017–2018：Trojan 发布，HTTPS 伪装协议诞生

2018–2020：生态扩展期

• 2018：MTProxy 发布，Telegram 官方代理协议
• 2019：NaiveProxy 发布，基于 Chromium 网络栈的代理方案
• 2020-07-16：VLESS 协议提案，无状态轻量协议
• 2020：Trojan-Go 发布，Go 语言重写，支持多路复用与 CDN 中转
• 2020-03：WireGuard 进入 Linux 5.6 内核
• 2020-09-15：shadowsocks-libev v3.3.5 发布，稳定迭代与 AEAD 加密路线的延续

2022–2026：Xray 时代

• 2022-10-29：Xray-core v1.6.2 发布，XTLS Vision 优化 TLS 握手特征
• 2023-03-09：Xray-core v1.8.0 发布，REALITY 协议发布，无需自购域名
• 2023-11：Clash/CFW 项目归档，Mihomo 接手维护
• 2024-09-30：Xray-core v24.9.30 发布，XHTTP 协议整合 HTTP/3 与 XMUX

3. 早期阶段：从 VPN 到 Shadowsocks 的诞生（2012–2015）

在 2010 年代初期，OpenVPN 和 SSH Tunnel 曾是常用的工具。然而，随着网络环境监测技术的发展与 DPI 技术的应用，这些协议的稳定性逐渐下降。2012 年，Shadowsocks 的出现，开启了轻量化加密代理的新阶段。

3.1 2012-04-20：V2EX 首帖与 Python 版发布

开发者 clowwindy 在 V2EX 论坛发布帖子《发一个自用了一年多的代理工具 shadowsocks》。不同于 VPN 的复杂封装，SS 采用了极简的 SOCKS5 代理架构，配合用户自定义的加密算法（如 AES-256-CFB）。

这种设计通过减少握手特征与混淆数据流，在当时的各种网络环境中表现出了较好的适应性。

3.2 2013–2014：生态发展与配置标准化

随着 JSON 配置文件格式确立，Shadowsocks 迅速跨越了 Python 的语言限制。C# (Shadowsocks-Windows)、Android、Go、Node.js 等版本相继涌现，形成了一个庞大的开源矩阵。此时，“PAC 分流” 的概念开始普及，实现了基于域名的智能流量路由体验。

3.3 2015-08-21：项目归档与社区维护

历史转折点。原作者 clowwindy 因个人原因在 GitHub 留下 告别留言 后停止维护并删除了项目代码。这一事件促成了 SS 的社区化维护。社区接手后，shadowsocks-libev（C 语言版）与后来的 shadowsocks-rust 成为长期迭代的中流砥柱（如 2020 年 9 月 15 日发布的 v3.3.5），显示了开源社区持续维护与迭代的能力。

3.4 机制侧重：针对主动探测的优化

SS 早期主要依赖高熵（High Entropy）加密数据流。但随着 2015 年后网络环境引入了主动探测机制——即服务端可能收到伪造的探测数据包——如果服务器回应了特定格式的报错，则可能导致协议被识别。这催生了后来的 SIP004 AEAD 加密改造（AEAD，即 Authenticated Encryption with Associated Data，认证加密模式，可同时保证数据的机密性和完整性）。

4. ShadowsocksR (SSR) 的分支与发展（2016–2018）

在 Shadowsocks 进入平稳维护期时，开发者 breakwa11 发起了 ShadowsocksR（简称 SSR）分支。针对流加密协议被主动探测识别的问题，SSR 引入了 “混淆（Obfs）” 和 “协议（Protocol）” 插件，试图将流量模拟成普通的 HTTP 或 TLS 请求，以适应更复杂的网络环境。

4.1 SSR：分支发展与技术争议

• 2016-12-30：协议与混淆的标准化 - 随着 Wiki 文档的完善（Wiki Snapshot），SSR 凭借 http_simple 和 tls1.2_ticket_auth 等混淆插件，成功在部分地区改善了连接稳定性与速度。
• 2017 年 7 月下旬：项目停更与争议 - breakwa11 在 Telegram 频道发布公告宣布停止维护并删除代码，引发了社区关于协议识别性与接盘方案的广泛讨论（事件记录）。
• 2017-08-27：SSRR 的延续 - Akkariiin 发起了 ShadowsocksRR（SSRR）分支（GitHub），在原版 SSR 停止后继续维护并修复问题，确保了该技术路线的延续。

5. V2Ray 与 VMess 的里程碑（2015–2019）

Project V (V2Ray) 作为一个模块化的代理平台，自诞生起就展现了极高的野心。其核心协议 VMess 不再仅仅是一个加密管道，而是一个包含了认证、路由、多路复用的完整协议栈。

为何重要： VMess 的最大贡献在于它展示了模块化协议设计的价值。它把 TLS、WebSocket、HTTP/2 等标准传输层变成了自己的传输载体，这使得流量特征更接近正常的网页浏览（HTTPS），提高了协议的适应性。

5.1 2015-09-18：V2Ray v0.1 Beta 的降临

首个公开测试版本发布（Wikidata 记录），确立了 UUID 作为身份认证的核心（不仅防爆破，还很长）。静态路由功能让 V2Ray 具备了 “指哪打哪” 的分流能力。

5.2 2016 年初：动态端口机制

面对端口连通性问题，V2Ray 引入了 “动态端口” 功能，允许一次性开放几千个端口轮询使用。虽然配置繁琐，但在特定网络环境下，它确实是一个有效的连接方案。

5.3 2017-02-18：v2.19 强制防重放 (Anti-Replay)

这是 VMess 协议的重要特性。服务端引入了强制的时间验证，认证窗口为 UTC 当前时间前后各随机 30 秒（总计 60 秒）。确保系统时间同步是连接建立的前提。（注：文档建议误差 ≤90 秒是稳定性建议，协议硬限制是 ±30 秒窗口）。

5.4 2021-12-15：alterId 的移除

随着 VMess-AEAD 的全面实装，曾经用来辅助抗探测的 alterId 机制显得冗余。在 v1.5.1 及后续版本中，Xray 团队发出了移除 alterId 的提醒，标志着 VMess 完成了协议机制的简化与现代化改造。

6. VLESS 协议与 Xray 的分化（2020–2022）

当 TLS 逐渐成为标配，VMess 自带的加密层就显得多余了（TLS 已经加密过一次）。2020 年，以 “性能至上、轻量化” 为目标的 VLESS 协议应运而生。

6.1 VLESS：无状态的极简主义

• 2020-07-16：诞生 - 开发者 rprx 在 v2ray-core Issue #2636 中提出 VLESS 草案，并于 v4.27.0 公测。核心理念是：“我不负责加密，我只负责鉴权”。加密全权交给 TLS。
• 2020-11：Project X 成立 - 因 XTLS 许可协议讨论，rprx 创建 Project X (Xray-core)。这是一个重要节点，Xray 随后推出了 uTLS（指纹模拟）和 FakeDNS（虚假 DNS 响应，用于实现透明代理的域名嗅探）等技术，推动了协议特性的持续创新。
• 回落 (Fallback) 机制 - VLESS 的重要特性。如果探测到非认证流量，可以将流量转发到一个正常的网站。探测者看到的将是一个普通的 Web 页面或 Nginx 欢迎页。

6.2 插播：Shadowsocks-2022 的现代化补丁

2022 年 5 月，Xray v1.5.6 引入了 Shadowsocks-2022。这是对老迈 SS 协议的一次 “赛博飞升”：引入了基于时间戳的防重放机制、单一端口多用户支持以及 Session 会话层。这让 SS 在 2022 年依然能与 VLESS 等后起之秀同台竞技。

7. Trojan 协议家族：伪装的艺术（2017–2020）

在 VMess/VLESS 走"协议栈"路线的同一时期，另一个技术思路也在并行发展。与 Shadowsocks 的"加密混淆"不同，Trojan 选择了更为直接的道路：不做混淆，直接伪装成真实的 HTTPS 流量。

7.1 Trojan：模拟真实 HTTPS

• 2017–2018：协议诞生 - Trojan 的核心理念是"与其让流量看起来像随机噪声，不如让它看起来像正常的网站访问"。它直接使用标准的 TLS 协议，将代理流量隐藏在正常 HTTPS 会话中。
• 设计哲学 - Trojan 不依赖强加密或混淆，而是模拟最常见的 HTTPS 协议。由于 HTTPS 占据了现代网络流量的绝大部分，这使得 Trojan 比 Shadowsocks 等"高熵流量"方案更难被识别。
• 认证机制 - 使用密码进行认证，未通过认证的连接会被转发到预设的正常网站（类似 VLESS 的 Fallback），使得主动探测看到的是一个真实的 Web 服务。

7.2 Trojan-Go (2020)

2020 年，p4gefau1t/trojan-go 用 Go 语言重写了 Trojan，带来了诸多增强：

• 多路复用 (Mux)：基于 smux，在单个 TLS 隧道上承载多个 TCP 连接，减少握手延迟
• WebSocket 支持：可通过 CDN 中转，扩展了部署场景
• Shadowsocks 混淆插件：可使用 AEAD 对 Trojan 流量进行二次加密
• API 管理：支持 gRPC API 进行动态用户管理与流量限速

Trojan-Go 与原版 Trojan 基本兼容，但启用扩展功能后则不互通。

8. XTLS Vision 与 REALITY 的成形（2022–2023）

2022 年底，社区注意到流量识别系统针对 “TLS-in-TLS”（在 TLS 隧道内再嵌套 TLS 连接）特征的识别能力显著增强。这促使开发者意识到，需要进一步处理握手长度等微小特征以提高协议的隐蔽性与稳定性。

8.1 XTLS Vision (2022)

为了解决 TLS 握手特征问题，XTLS Vision 在 2022 年 10 月的 v1.6.2 版本中首次作为发行版提供。通过调整 TLS 握手长度与时序以提高与常见客户端（如浏览器）的行为一致性，从而改善兼容性与稳定性。

8.2 REALITY (2023)

2023-03-09 v1.8.0 发布的 REALITY 带来了新的思路。它不需要用户自购域名，而是利用目标网站的证书（在 TLS 握手阶段转发给目标网站）。外部探测看到的是对微软或苹果等正常服务的访问。在学术界（如 USENIX 2023）指出传统全加密协议局限性的背景下，这成为了一种新的解决方案。

9. 2024：XHTTP 的诞生与完善

在 WebSocket 和 gRPC 因流量特征明显而在特定环境中识别率上升后，Xray 再次调整技术路线，将目光投向了更基础的 HTTP 协议本身。

9.1 2024-06-18：SplitHTTP (v1.8.16) 首发

提出了 “拆分连接” 的思路：上传和下载可以走不同的 HTTP 请求。这种设计打破了传统长连接的特征，能更好地利用 CDN 的边缘节点，同时优化了连接行为。

9.2 2024-09-30：进化为 XHTTP (v24.9.30)

在 v24.9.30 版本中，SplitHTTP 正式整合 HTTP/3 (QUIC) 支持，并引入 XMUX 控制。随后官方将其更名为 XHTTP。它高度模拟了 “标准 HTTP 浏览” 的行为：外部观测到的主要是 HTTP/3 的网页访问流量。

10. Clash 的系谱与工具生态（2018–2026）

如果说 V2Ray/Xray 专注于协议核心，那 Clash 则专注于用户体验与配置管理。它通过 YAML 配置 + 现代化 GUI，将复杂的分流规则可视化，极大降低了普通用户的使用门槛。

• 2018 年末：Clash for Windows (CFW) 诞生 - Fndroid 开发的 CFW 标志着 Windows 终于有了一个功能完善的代理客户端。随后 Fndroid 保持了高强度的开发节奏，并在 2019-09-27 的 CFW 0.7.9 版本中增加了单个节点延迟测试功能，奠定了 “分流工具” 的基础。
• 2019–2020：标准确立 - 随着 TUN Mode（系统级流量接管，支持各类应用代理）、Rule Provider（规则集动态更新）和 Fake-IP 模式（返回虚假 IP 以实现域名级别的分流判断，避免 DNS 污染）的加入，Clash 定义了现代代理客户端的 “标准动作”。
• 2023-11：项目归档与生态重组 - 2023 年 11 月，Clash Core 与 CFW 项目归档，引发社区广泛关注。但仅仅几天后，开源社区迅速集结，Mihomo (原 Clash.Meta) 接过维护重任，不仅兼容原版，还适配了多种新协议。
• 2024–2026：百花齐放 - 进入 “后 Clash 时代”，Clash Verge Rev、Clash Nyanpasu 等基于 Tauri 的现代客户端百花齐放。它们不仅界面现代化，底层更是直接集成了 Mihomo 核心，实现了开箱即用的体验。

11. Sing-box 与 UDP 新势力的崛起（2022–2025）

在 TCP 协议优化逐渐饱和时，基于 UDP/QUIC 的新协议开始涌现，试图在复杂的公网环境中寻找新的性能突破点。其中最具代表性的是 Hysteria2（基于 QUIC 的高性能代理，采用 Brutal 拥塞控制算法，专为高丢包网络优化）和 TUIC（轻量级 QUIC 代理协议，由 Rust 编写）。

11.1 Sing-box：通用平台

Sing-box 不想做 “另一个客户端”，它想做 “万能驱动”。

• 多协议统一：原生支持 VLESS, Trojan, SS-2022, Hysteria2, TUIC，甚至 WireGuard。
• 平台化：提供 SSM API 和模块化的配置体系，越来越多的 GUI（如 GUI.for.SingBox）开始直接调用它。

虽然它的 JSON 配置写起来像在写代码，但这也正是极客们的最爱。

12. 其他值得关注的工具与协议

在主流方案之外，还有一些独具特色的工具值得记录。

12.1 NaiveProxy：Chrome 的影子

NaiveProxy 由 klzgrad 开发，采用了一种独特的思路：直接使用 Chromium 的网络栈。

• 核心优势：由于直接复用 Chrome 的代码，NaiveProxy 的 TLS 指纹与真实的 Chrome 浏览器完全一致，能有效对抗 TLS 指纹识别
• 流量特征：通过 HTTP/2 多路复用来对抗流量分类，通过长度填充（Padding）来对抗长度分析
• 部署方式：服务端需要配合 Caddy + forwardproxy 模块使用，实现应用层前置（Application Fronting）
• 适用场景：在 TLS 指纹识别严格的网络环境中表现优异

12.2 Brook：极简主义的跨平台方案

Brook 由 txthinking 开发，目标是"保持简单"。

• 首发时间：约 2017 年
• 核心特点：
  • 极简配置，降低使用门槛
  • 系统级 TUN 接管，支持 TCP/UDP/IPv4/IPv6 全流量代理
  • 内置 Fake DNS 功能
  • GUI 客户端使用虚拟网卡而非 SOCKS5 代理，避免应用不走系统代理的问题
• 近期变化：移除了 Proxy 模式，全面转向 TUN 模式

12.3 WireGuard：现代 VPN 的标杆

WireGuard 由 Jason Donenfeld 于 2016 年首次发布，2020 年 3 月正式进入 Linux 5.6 内核。

• 代码精简：约 4000 行代码，相比 OpenVPN 的 10 万行代码，审计和维护成本极低
• 性能优异：使用现代密码学原语（Curve25519、ChaCha20、Poly1305 等），握手速度快
• 协议简洁：无需协商加密套件，配置简单
• 生态整合：已被 sing-box、Mihomo 等现代客户端原生支持，可作为代理链的一部分

Linus Torvalds 曾在 2018 年公开表示对 WireGuard 的喜爱：“与 OpenVPN 和 IPSec 的恐怖相比，它简直是艺术品。”

12.4 GOST：多功能隧道瑞士军刀

GOST (GO Simple Tunnel) 是一个用 Go 编写的多功能代理/隧道工具。

• 协议支持：HTTP/HTTPS/SOCKS4/SOCKS5/Shadowsocks/SSH/QUIC/KCP 等
• 核心功能：
  • 多级代理链（Proxy Chain）
  • 端口转发（TCP/UDP）
  • 透明代理
  • DNS 解析
  • 负载均衡与路由控制
• 适用场景：适合需要灵活组合多种协议、构建复杂代理拓扑的高级用户

12.5 MTProto：Telegram 的专属协议

MTProto 是 Telegram 团队开发的专有协议，MTProxy 于 2018 年推出。

• 设计目标：专为 Telegram 通信设计，优化在复杂网络环境下的连接稳定性
• 认证方式：仅使用密码认证，不转发密码到服务端
• 随机填充：为对抗基于数据包大小的识别，支持添加随机填充
• 当前状态：官方 MTProxy 仓库已多年未更新，社区有维护的 Fork 版本

13. 全平台开源客户端概览

随着开源社区的蓬勃发展，客户端生态已从单一的 Shadowsocks 衍生出适配各平台的专业工具。本章梳理截至 2026 年初仍在积极维护的主流开源项目，重点关注其内核支持与适用场景。

主流开源客户端特性速览：

• v2rayN (Windows)

  • 内核：Xray / sing-box
  • TUN 模式：支持 (sing-tun/Wintun)
  • DNS 方案：DNS 分流 + FakeIP
  • 更新状态：活跃，2026-01-09

• Clash Verge Rev

  • 内核：Mihomo
  • TUN 模式：System/Tun
  • 更新状态：活跃

• OpenClash

  • 内核：Mihomo
  • TUN 模式：Tun
  • DNS 方案：Fake-IP
  • 更新状态：活跃

• v2rayNG

  • 内核：Xray / sing-box
  • TUN 模式：Android VPN
  • 更新状态：活跃

• sing-box

  • 内核：自身
  • TUN 模式：Native Tun
  • DNS 方案：DNS Server
  • 更新状态：活跃

说明：上述客户端均处于活跃维护状态。完整的功能对比请参阅各项目的 README 文档。

13.1 Windows 生态

• v2rayN (活跃 / C#)
  • 内核：Xray (主), sing-box, Clash
  • 特点：经典的 “瑞士军刀”。对 Xray 新特性（如 REALITY, Vision）跟进最快。支持 Tun 模式与丰富的路由规则自定义。
• Clash Verge Rev (活跃 / Tauri)
  • 内核：Mihomo (Clash.Meta)
  • 特点：Clash for Windows 的最佳精神续作。界面现代，系统资源占用低，完美支持 Rule Providers 与脚本重写。

13.2 macOS 与 Linux 桌面

• Clash Verge Rev (活跃)
  • 平台：macOS (Intel/Silicon), Linux
  • 特点：提供跨平台一致的体验。Linux 端支持 AppImage/Deb，是桌面 Linux 用户的首选 GUI。
• v2rayA (活跃 / Web GUI)
  • 平台：Linux, Windows, macOS, Docker
  • 特点：网页控制面板。主要优势在于强大的透明代理与路由管理，非常适合 Linux 极客与家庭服务器环境。
• V2RayU / V2RayXS (一般)
  • 平台：macOS
  • 特点：传统的 Menubar 工具，适合仅需要基础 Xray 功能的用户。

13.3 OpenWrt / 路由器

• OpenClash (活跃)
  • 内核：Mihomo (Clash.Meta)
  • 特点：功能最全的 LuCI 插件。支持 Rule-Set、Fake-IP 模式及详细的 DNS 分流控制，是软路由的首选。
• PassWall / SSR Plus+ (活跃)
  • 内核：Xray, sing-box, brook 等
  • 特点：更加轻量，对 Xray 协议（VLESS, Reality）支持极好，适合性能有限的设备。

13.4 Android 移动端

• v2rayNG (活跃)
  • 内核：Xray, sing-box (插件)
  • 特点：安卓端的标杆。近期更新已支持 Hysteria2、Tuic 等新协议，界面简洁，耗电控制优秀。
• Clash Meta for Android (社区维护)
  • 内核：Mihomo
  • 特点：将 Mihomo 的强大功能带入安卓。支持完整的 YAML 配置与 Rule Provider，适合需要与 PC 端同步配置的用户。
• NekoBox for Android (社区维护)
  • 内核：sing-box
  • 特点：支持协议广泛（SS/VMess/VLESS/Trojan/Hysteria2/TUIC/WireGuard 等），界面现代。原项目已归档，社区有 Fork 版本继续维护。

13.5 iOS 移动端（付费生态）

由于 Apple 平台政策限制，iOS 缺乏完全开源且免费的代理客户端，但付费客户端生态成熟且功能强大。

• Surge (付费 / 标杆)
  • 首发：2015 年 10 月
  • 特点：iOS 代理工具的鼻祖，定义了规则分流的标准范式。支持 HTTP/SOCKS5/SS/VMess/Trojan 等协议，具备强大的脚本重写（Rewrite）和 MITM 能力。macOS 版同样优秀。
  • 地位：被誉为"代理界的 iOS"，引领了 YAML 规则配置的潮流。
• Shadowrocket (付费 / 性价比)
  • 首发：2015 年 4 月
  • 特点：俗称"小火箭"，性价比极高。支持 SS/SSR/VMess/VLESS/Trojan 等主流协议，界面简洁，配置方便。
  • 地位：iOS 平台装机量最大的代理客户端。
• Quantumult X (付费 / 功能强大)
  • 特点：功能媲美 Surge，支持脚本重写、MitM、规则分流。JavaScript 脚本生态丰富，适合需要高度定制的用户。
• Loon (付费 / 易用)
  • 特点：界面友好，上手简单。支持多种协议（SS/SSR/VMess/Trojan/VLESS/Hysteria2/WireGuard 等），适合非技术背景用户。
• Stash (付费 / Clash 规则最佳适配)
  • 特点：iOS 上对 Clash 规则集支持最完善的客户端。完美兼容 Mihomo 配置，支持 Rule Provider、脚本重写等高级功能。被评价为"iOS 上的 Clash Verge"。

13.6 跨平台 CLI 核心 (DevOps 基础)

• sing-box：通用代理平台。以高性能、低内存占用著称，原生支持 TUN 与各类新协议。配置格式为 JSON，适合容器化部署与自动化脚本。
• Xray-core：VLESS/REALITY 协议的发源地。作为 Project X 的核心，它是许多 GUI 客户端的动力源泉，适合追求最新协议特性的用户。

14. YAML & Rule Provider

统治地位：90% 以上的代理服务订阅采用 Clash YAML 格式。其可读性强，便于用户手动微调。

动态更新：Rule Provider 的引入（CFW 0.18+）让规则集与节点分离，用户可以单独更新去广告规则或流媒体规则，而不必每次重置配置文件。

14.1 兼容与转换

JSON 体系：Sing-box 采用 JSON 配置，结构严谨适合机器生成，但手写难度大。因此，“订阅转换” 工具（如 Sub-Store）成为生态刚需，负责将 YAML 订阅实时转译为 Sing-box JSON。

微迁移：随着 Mihomo 引入 listeners 等新字段，不同内核间的配置虽然大体兼容，但在高级功能（如 Sniffer、DNS 策略）上已出现方言化趋势。

15. 现代规则分流与规则集维护者（2023–2026）

随着网络环境的日益复杂，简单的 PAC 或域名白名单已无法满足需求。现代分流机制依赖于高频更新的规则集（Rule Set），并将规则细分为 Domain（域名）、IP-CIDR（IP 段）与 Classical（混合）三种行为模式。

15.1 规则类型与性能权衡

• Domain (域名/后缀/关键词)：匹配开销最小，适合作为首选规则。软路由设备建议优先使用 DOMAIN-SET 以降低内存占用。
• IP-CIDR / GeoIP：基于目标 IP 进行匹配。注意：若未开启 no-resolve，此规则会触发 DNS 解析，可能导致 DNS 泄露或性能下降。通常作为兜底规则使用。
• Classical (混合)：传统 Clash 规则格式，混合了域名和 IP。由于需要逐条加载，处理几万条记录时性能较差，现代内核（Mihomo）更推荐使用二进制的 geosite/geoip 规则集替代。

15.2 主流规则集维护者

生态中涌现了多位长期活跃的维护者，他们每日构建的数据不仅服务于 Clash，也支撑了 Sing-box、Surge 等工具的运行。

15.2.1 Loyalsoldier/v2ray-rules-dat

• 定位：V2Ray/Xray 生态的标准数据源。
• 特点：每日自动构建加强版 geoip.dat 与 geosite.dat。融合了 felixonmars 的 dnsmasq 列表、代理规则列表以及 EasyList。是绝大多数 V2Ray 客户端的默认上游。

15.2.2 MetaCubeX/meta-rules-dat

• 定位：面向 Mihomo (Clash.Meta) 的专用数据集。
• 特点：部分数据源于 blackmatrix7，但针对 Mihomo 内核进行了裁剪（Lite 版）与重组。提供了极细维度的分类（如 telegram, netflix, openai），配合 Mihomo 的 rule-set 功能可实现毫秒级匹配。

15.2.3 blackmatrix7/ios_rule_script

• 定位：“开源规则搬运工”，服务于 Surge/Loon/Clash。
• 特点：规则分类极其详尽（甚至包含特定游戏或冷门 App）。脚本与重写规则丰富，是 iOS 平台用户的首选资源库。

15.2.4 ACL4SSR

• 定位：老牌综合规则维护者。
• 特点：提供了最为广泛流传的去广告规则与 “常用国内/国外” 分组。其维护的代理规则转换版是很多订阅转换工具的默认模板。

15.3 分流判定与最佳实践

一个高效的规则系统应遵循 “先域名，后 IP” 的原则，并配合正确的 DNS 策略。

• 优先级逻辑：GEOSITE/DOMAIN (精确匹配) > RULE-SET (各类集合) > GEOIP/IP-CIDR (兜底) > MATCH (最终出口)。
• 国内直连优化：使用 geosite:cn 配合 geoip:cn。对于游戏平台，建议使用 @cn 属性（如 steam@cn）强制直连，避免 CDN 调度错误导致下载缓慢。
• DNS 分流（核心）：这是防泄漏的关键。为国内规则集指定国内 DoH（如 AliDNS），为海外规则集指定可信 DoH（如 Google DNS）。这能防止 “DNS 污染” 导致的错误 IP 匹配。
• 维护要点：软路由设备应避免使用大量 Classical 文本规则，改用 Rule Providers 引用二进制 .dat 或 .mrs 文件，不仅加载快，更新时也无需重启内核。

16. Clash 内核的差异与演进：从 Premium 到 Mihomo

Clash 的发展史是一部从 “闭源商业核心” 走向 “开源社区共建” 的历史。从最初的 Dreamacro 原版，到 Meta 的激进扩展，再到如今 Mihomo 的集大成，内核的更迭直接推动了工具生态的繁荣。

16.1 Clash Premium

Dreamacro / Closed Source

基石时代：引入了 Rule-Set 与 Rule-Provider，确立了现代分流的配置结构。其 TUN 模式让 Clash 具备了系统级流量接管能力。Script 脚本功能虽然强大，但因闭源特性，社区难以扩展。

16.2 Clash Meta

MetaCubeX / Open Source

破局者：在原版停滞时，Meta 分支通过引入 VLESS XTLS、Trojan XTLS 与 Hysteria 协议，解决了 “新协议不支持” 的痛点。同时改进了 DNS 策略与 TUN 堆栈性能。

16.3 Mihomo

MetaCubeX / Modern

新标准：Meta 的继任者。除了全面支持 Hysteria2、TUIC、WireGuard 等现代协议外，还重构了规则子系统，支持直接消费二进制规则集，成为 OpenClash、Clash Verge Rev 等主流 GUI 的默认内核。

16.4 为什么是 Mihomo？核心优势解析

• 全协议覆盖：在保留 SS/VMess/Trojan 兼容性的同时，原生支持 Reality、VLESS、Hysteria2 等网络适应性更强的新协议。
• 规则协同 (Rule Synergy)：与 meta-rules-dat 深度联动。Mihomo 可以直接加载 .mrs 或 .dat 格式的规则集，相比解析数万行 YAML 文本，内存占用降低 40% 以上，匹配速度提升显著。
• DNS 策略：引入了 nameserver-policy 与 fake-ip-filter 的高级控制。能够实现 “精确到域名的 DNS 服务器指定”，有效防止 DNS 泄露并减少连接回退（Fallback）。
• 平台适配：无论是在高性能 PC 还是低功耗的软路由（ARM/MIPS）上，Mihomo 都在持续优化资源调度。其 TProxy（透明代理）模式的稳定性已成为业界标杆。

17. 结论与未来展望

回顾这十四年的技术发展史，从 2012 年 Shadowsocks 的出现，到 2026 年 XHTTP 与 Hysteria2 的应用，技术从未停止演进。工具的形态从单一的脚本，进化为如今拥有现代化 GUI、系统级接管能力的复杂软件平台。

历史虽然不会直接提供现在的可用节点地址，但它能生动地展示技术与工具的演变逻辑。在这个过程中，变化的不仅是协议与软件，更是用户的使用习惯与网络环境的互动方式。

最后修改于 2026-01-18