摘要：你可能有过这样的体验——同样的目标网站，换一个代理节点速度天差地别。这背后的原因往往不是服务器配置的差异，而是网络路由的差异。BGP（边界网关协议）决定了互联网流量的传输路径，Anycast（任播）让同一个 IP 地址在全球多个位置同时服务。理解这两个概念，能帮助你理解为什么某些线路特别快，以及如何挑选更好的节点。

互联网是怎么传输数据的

在了解 BGP 之前，先简单回顾一下互联网的基本结构。

互联网不是一个统一的网络，而是由成千上万个独立网络互相连接组成的。每个独立网络被称为一个 AS（Autonomous System，自治系统），每个 AS 都有一个唯一的编号（ASN）。

举几个例子：

当你从北京家中访问一台位于洛杉矶的服务器时，你的数据包不是直飞过去的——它需要在多个 AS 之间”接力传递”。从你的家庭宽带（运营商的接入网）→ 运营商的骨干网 → 国际出口 → 海底光缆 → 美国的骨干网 → 目标服务器所在的网络。

这个”接力”过程中，数据包在每个 AS 之间的”传递方式”就是由 BGP 决定的。

BGP 是什么

BGP（Border Gateway Protocol，边界网关协议）是互联网的核心路由协议。它的作用简单来说就是：告诉每个网络，如何到达其他网络。

BGP 的工作方式

每个 AS 通过 BGP 向邻居 AS 宣告（announce）自己管理的 IP 地址范围。这些宣告会在 AS 之间传播，最终形成一张全球性的路由表。

假设你在电信网络（AS4134）中，要访问 Google（AS15169）的服务器：

1

你的电脑 → AS4134 (中国电信) → AS ??? → AS ??? → AS15169 (Google)

中间经过哪些 AS，由 BGP 决定。BGP 会根据以下因素选择路径：

1. AS 路径长度：经过的 AS 数量越少，路径通常越短
2. 路由策略：运营商会配置各种策略偏好，比如优先使用成本更低的路径
3. 商业关系：AS 之间存在不同的商业关系（对等互联、上游购买、下游客户），这些关系影响路由选择
4. 网络拥塞：某些路径拥塞时，流量可能被引导到其他路径

AS 路径（AS Path）

AS Path 是 BGP 中最重要的属性之一。它记录了数据包到达目标需要经过的所有 AS。例如：

1

AS4134 → AS4837 → AS6939 → AS15169

这条路径表示：从中国电信出发，经过中国联通（可能在某个交换中心互联），然后到 Hurricane Electric（HE，美国的一个大型网络），最后到 Google。

AS Path 越短，通常延迟越低。但这不是绝对的——一条经过 3 个 AS 但物理距离很长的路径，可能比一条经过 5 个 AS 但物理距离短的路径更慢。

为什么 BGP 路由对代理很重要

BGP 路由直接决定了你使用代理时的实际网络体验：

延迟（Latency）：好的路由意味着更少的中间跳转和更短的物理距离，延迟更低。

带宽（Throughput）：不同路径的可用带宽不同。拥挤的路径会降低实际吞吐量。

稳定性（Stability）：频繁变化的路由会导致连接不稳定，甚至出现丢包。

丢包率（Packet Loss）：某些路径（特别是高峰期的国际出口）丢包率很高。

一个非常现实的例子：同样是从北京到洛杉矶的 VPS，使用中国电信 163 骨干网（AS4134）的路由可能延迟 200ms+ 且高峰期丢包严重；而使用中国电信 CN2 GIA（AS4809）的路由可能延迟只有 150ms 且几乎不丢包。两台 VPS 可能物理上在同一个数据中心，但网络体验天差地别。

BGP 优化线路

在代理领域，”优质线路”通常指的是有 BGP 优化的网络路径。以下是最常见的几种。

CN2 GIA（全球互联网接入）

CN2 GIA 是中国电信的高端国际线路，属于 AS4809。它的特点是：

• 双向 CN2：去程和回程都走 CN2 网络，不绕路
• 低延迟：中美之间延迟通常在 130-160ms
• 低丢包：即使在高峰期也能保持极低的丢包率
• 价格昂贵：CN2 GIA 的 VPS 价格远高于普通线路

CN2 GIA 之所以好，核心原因是它的 BGP 路由经过精心优化——流量走的是电信的精品骨干网，避开了拥挤的 163 骨干网。

CUII（中国联通精品网）

AS9929 是中国联通的精品网络（CUII），类似于电信的 CN2 GIA。对联通用户来说，CUII 线路提供了更好的国际出口体验。

CMI（中国移动国际）

AS58453 是中国移动的国际出口。CMI 线路在近年来有较大改善，某些目的地的表现甚至优于 CN2。

如何判断 VPS 使用的线路

使用 traceroute（或 Windows 上的 tracert）可以查看数据包的路由路径：

1

traceroute -I your-server-ip

或者使用更好用的 mtr（结合了 ping 和 traceroute 的功能）：

1

mtr your-server-ip

在 traceroute 的结果中，关注以下 IP 段可以判断走的是什么线路：

如果去程（从你到服务器）走的全是 59.43 开头的 IP，说明你走的是 CN2 线路。

Anycast 是什么

理解了 BGP 之后，Anycast 就很好理解了。

在正常的互联网通信中，一个 IP 地址对应一台服务器——这叫做 Unicast（单播）。无论你在世界哪个角落访问这个 IP，数据包都会被路由到同一台服务器。

Anycast（任播） 则完全不同：同一个 IP 地址在全球多个位置同时被宣告。当你访问一个 Anycast IP 时，BGP 会自动将你的流量路由到离你最近的那个位置。

用一个比喻来理解：

• Unicast 像是只有一家总店的餐厅——无论你住在哪里，想吃就得去总店
• Anycast 像是连锁餐厅——每个城市都有分店，你自然会去离你最近的那家

Anycast 的工作原理

Anycast 的实现依赖于 BGP。假设一个服务在全球 10 个位置部署了服务器，这 10 个位置的路由器都通过 BGP 向外宣告同一段 IP 地址。

1
2
3
4

美国西海岸数据中心 → BGP 宣告: 1.2.3.0/24
欧洲法兰克福数据中心 → BGP 宣告: 1.2.3.0/24
亚太新加坡数据中心 → BGP 宣告: 1.2.3.0/24
...

当北京的用户访问 1.2.3.1 时，BGP 路由系统会发现到 1.2.3.0/24 有多条路径，然后选择 AS 路径最短（通常也是物理距离最近）的那条——大概率是新加坡的数据中心。而当纽约的用户访问同一个 IP 时，流量会被路由到美国西海岸的数据中心。

所有这一切对用户来说是透明的——他们访问的是同一个 IP 地址，但实际响应来自不同的物理服务器。

Cloudflare：Anycast 的典型案例

Cloudflare 是 Anycast 技术的最大规模应用者之一。Cloudflare 在全球 300 多个城市部署了数据中心，所有数据中心都通过 BGP 宣告相同的 IP 地址。

当你使用 Cloudflare 的 DNS 服务（1.1.1.1）时，你的请求会被自动路由到离你最近的 Cloudflare 数据中心。在中国大陆，这通常是香港、日本或新加坡的节点。

这就是为什么 Cloudflare 的 DNS 在全球范围内都能提供很低的延迟——不是因为某一台服务器特别快，而是因为在你附近总有一台服务器在响应。

Anycast 的优势

1. 低延迟：用户总是连接到最近的服务器
2. 高可用：某个数据中心故障时，流量自动切换到下一个最近的位置
3. DDoS 防护：攻击流量会被分散到全球各个位置，不会集中打击单一服务器
4. 简单部署：客户端不需要做任何特殊配置，IP 地址始终不变

Anycast 的局限

1. TCP 长连接不友好：如果 BGP 路由发生变化，可能导致已建立的 TCP 连接断开（因为流量被路由到了不同的服务器）
2. 无法精确控制：你不能选择连接到哪个位置，完全由 BGP 路由决定
3. 部署成本高：需要在全球多个位置部署服务器，且需要自己的 AS 和 IP 段

代理服务如何利用 BGP 和 Anycast

理解了 BGP 和 Anycast 之后，让我们看看代理服务是如何利用这些概念的。

BGP 优化：选择更好的上游

高质量的 VPS 提供商会通过 BGP 优化来提供更好的网络路径。具体做法包括：

多线接入（Multi-homed）：VPS 连接多个上游网络提供商，通过 BGP 选择最优路径。例如，一台位于洛杉矶的 VPS 可能同时接入了 Cogent、NTT 和 PCCW 三家上游，对于来自中国的流量，BGP 会选择经过 PCCW（太平洋方向优化）的路径。

BGP 社区（BGP Communities）：运营商通过 BGP 社区属性来标记和控制路由策略。高端 VPS 提供商可能提供 BGP 社区控制功能，允许用户自定义路由策略。

直接互联（Peering）：在互联网交换点（IXP）直接互联，减少中间跳转。这是为什么某些 VPS 在特定地区表现特别好的原因——它们与当地的运营商有直接互联关系。

中转/IPLC 的 BGP 原理

中转节点（relay）的核心思路是利用 BGP 路由优化来改善整体路径。一般的工作方式是：

1. 在中国境内部署一台服务器（入口节点），连接到优质骨干网
2. 入口节点通过优化的线路（如 CN2 GIA、IPLC 专线等）连接到海外服务器（出口节点）
3. 用户连接入口节点，流量通过优化路径到达出口节点，再访问目标网站

这实际上是在 BGP 无法优化的路径上，通过额外的网络跳转来”绕开”拥塞。

CDN 与 Anycast 的结合

一些高端机场服务使用类似 CDN 的架构——在全球多个位置部署入口节点，使用 Anycast 或智能 DNS 将用户引导到最近的入口。这种架构能提供更一致的用户体验，但成本也相应更高。

如何利用这些知识选择更好的节点

查看路由路径

使用 traceroute 或 mtr 查看从你到代理服务器的路由路径。关注以下几点：

1. 经过的 AS 数量：越少通常越好
2. 是否走优质线路：查看是否经过 CN2（59.43.x.x）等优质骨干网
3. 是否有明显绕路：比如从北京到东京，如果路由先绕到美国再回来，那就是绕路了
4. 高延迟跳：如果某一跳的延迟突然增加了 100ms 以上，说明那里是瓶颈

选择合适的机房位置

对于中国大陆用户，以下机房位置通常有较好的网络表现：

• 香港：物理距离近，延迟低，是最受欢迎的节点位置
• 日本东京：延迟适中，与中国运营商的互联质量通常不错
• 新加坡：对南方用户较友好
• 美国西海岸（洛杉矶/圣何塞）：CN2 GIA 线路表现优秀
• 韩国首尔：延迟低，但带宽通常较小

关注线路标识

机场和 VPS 提供商通常会标注线路类型：

• CN2 GIA：最优质的电信国际线路，三网优化
• CN2 GT：CN2 的普通版，去程走 CN2 但回程可能走 163
• BGP 优化：多线接入，自动选择最优路径
• IPLC/IEPL：国际专线，不经过公共互联网，最稳定但最贵
• 普通线路：走运营商默认的 BGP 路由，高峰期可能拥塞

理解”三网优化”

“三网优化”指的是对中国电信、联通、移动三大运营商都进行了路由优化。普通的 VPS 可能只对某一家运营商的路由较好，而三网优化的节点通过 BGP 多线接入，保证三家运营商的用户都有不错的体验。

用 traceroute 读懂路由

traceroute 是诊断网络路径最重要的工具。以下是一个简化的阅读指南。

基本用法

1
2
3
4
5
6
7
8

# Linux / macOS
traceroute -I your-server-ip

# Windows
tracert your-server-ip

# 更好的选择：mtr（需要安装）
mtr your-server-ip

解读输出

1
2
3
4
5
6
7

1  192.168.1.1     1.2ms   ← 你的路由器
2  100.64.0.1      5.3ms   ← 运营商接入网
3  202.97.33.1    10.2ms   ← 163 骨干网（电信）
4  202.97.90.1    35.6ms   ← 163 骨干网国际出口
5  218.30.54.1   160.2ms   ← 跨太平洋海底光缆
6  69.174.14.1   155.8ms   ← 美国骨干网
7  104.16.88.1   158.3ms   ← 目标服务器

关注点：

• 第 3-4 跳：如果 IP 是 59.43.x.x 说明走的 CN2，202.97.x.x 说明走的 163 普通骨干
• 延迟突增的位置：第 4→5 跳延迟从 35ms 跳到 160ms，这是跨洋传输造成的，属于正常
• 星号（*）：表示该跳未响应 ICMP，不一定是问题——很多路由器配置为不回应 traceroute
• 延迟波动：如果某一跳的延迟在多次测试中波动很大，说明该节点可能拥塞

常见问题（FAQ）

Q1：BGP 优化对普通用户有多大影响？

影响很大。同一台服务器，走 CN2 GIA 和走 163 普通线路的体验可能完全不同。好的 BGP 路由能将延迟降低 30-50%，高峰期丢包率降低 90% 以上。对于代理用户来说，选择 BGP 优化的线路是提升体验最有效的方式之一。

Q2：为什么我 traceroute 时某些跳显示星号？

很多路由器配置为不回应 ICMP traceroute 请求（出于安全考虑），这不代表网络有问题。关注起点和终点的延迟即可。

Q3：Anycast 会导致代理连接不稳定吗？

理论上存在这种可能——如果 BGP 路由在连接过程中发生变化，TCP 连接可能被路由到不同的服务器导致断开。但在实际使用中，BGP 路由变化不会非常频繁，这种情况比较少见。

Q4：CN2 GIA 和 IPLC 哪个更好？

IPLC（国际私有租用线路）是专线，不走公共互联网，理论上最稳定。CN2 GIA 走的仍然是公共网络，但路径经过优化。在大多数情况下 CN2 GIA 已经够用，IPLC 价格贵很多但边际收益有限，适合对延迟和稳定性要求极高的场景。

Q5：如何知道我当前走的是什么线路？

使用 mtr 或 traceroute 查看路由路径，根据中间节点的 IP 地址判断走的是哪个运营商的哪条线路。也可以使用 ipip.net 等在线 traceroute 工具。

Q6：BGP 路由会随时间变化吗？

会。BGP 路由受到网络状况、运营商策略等多种因素影响，可能在不同时段走不同的路径。这也是为什么同一个节点在白天和晚上高峰期的速度可能差别很大。

外部链接

• bgp.tools — BGP 和 ASN 信息查询
• ipip.net 路由追踪 — 在线 traceroute 工具
• Hurricane Electric BGP Toolkit — 详细的 BGP 数据
• PeeringDB — 互联网交换点和对等互联信息
• Cloudflare 网络地图 — Anycast 部署示例

理解 BGP 和 Anycast 不需要成为网络工程师，但掌握这些基础知识能帮助你做出更好的节点选择，并理解为什么某些线路的价格差异如此之大。

摘要：每一个公网 IP 地址都属于一个自治系统（AS），每个 AS 都有一个唯一编号（ASN）。通过查询 ASN，你可以知道一个 IP 的所有者是谁——是大型云服务商的数据中心，还是面向普通用户的 ISP。这个信息直接关系到节点的流媒体解锁能力、被封锁风险和长期稳定性。本文介绍 ASN 的基础概念、查询方法和实际应用。

什么是 AS 和 ASN

互联网的组织方式

互联网不是一台超级路由器连接着全球所有的电脑。它是由数万个独立管理的网络拼接在一起的——就像全球的铁路系统由各国的铁路公司分别运营，但列车可以在它们之间跨越和换乘。

每一个独立管理的网络被称为一个 自治系统（Autonomous System，AS）。一个 AS 由一个组织运营，拥有一组 IP 地址和一套统一的路由策略。这个组织可以是一家电信运营商（如中国电信）、一家云服务商（如 AWS）、一所大学、一个政府机构，甚至一家大型企业。

每个 AS 都有一个全球唯一的编号，叫做 ASN（Autonomous System Number）。ASN 由 IANA 统一分配，再通过五大 RIR（地区互联网注册机构）分发给各组织。

常见的 ASN 示例

一些你可能经常遇到的 ASN：

AS 之间如何通信

不同的 AS 之间通过 BGP（Border Gateway Protocol，边界网关协议） 交换路由信息。你可以把 BGP 理解为”AS 之间的通讯协议”——每个 AS 通过 BGP 告诉邻居”我有哪些 IP 段，你如果要到达这些 IP，可以把流量发给我”。

当你从中国访问一个美国网站时，数据包可能经过多个 AS 的”接力”：中国电信（AS4134）→ 某个过境 AS → 美国某 ISP → 目标服务器所在的 AS。BGP 协议负责在这些 AS 之间找到最优路径。

这些 BGP 路由信息是公开可查的，这也是各种 ASN 查询工具能够工作的基础。

ASN 能告诉你什么

查到一个 IP 的 ASN 之后，你能获得以下关键信息：

IP 的所有者

ASN 直接对应一个注册组织的名称。通过组织名称，你可以快速判断这个 IP 属于谁。比如看到 AS16509，你立刻知道这个 IP 来自 AWS；看到 AS7922，你知道这是 Comcast 的 IP。

IP 的类型：数据中心还是 ISP

这是代理场景中最关键的一个判断。

数据中心（Hosting）IP 属于云服务商或托管服务商的 AS。它们的特征是：大量 IP 被用于服务器托管，而非终端用户上网。流媒体平台和 AI 服务会将数据中心 IP 标记为高风险，因为从数据中心发出的请求大概率来自代理/VPN 而非真实用户。

ISP（互联网服务提供商）IP 属于面向终端用户提供接入服务的运营商的 AS。ISP 的 IP 被认为更”干净”，因为它们通常分配给家庭或企业用户使用。当流媒体平台看到来自 Comcast 或 NTT 的 IP 时，它会倾向于认为这是一个正常用户。

关于 IP 类型对解锁的影响，可以参考 什么是原生 IP、广播 IP、住宅 IP。

IP 的地理归属

ASN 信息通常包含注册组织的所在国家/地区。结合 GeoIP 数据库的查询结果，你可以判断一个 IP 是否是”原生 IP”——即 IP 的 ASN 归属国家与服务器的物理位置一致。

IP 的网络规模和声誉

一个 AS 管理的 IP 数量、它与多少其他 AS 有 BGP 连接（peer）、它的上游 AS 是谁——这些信息可以帮助你判断这个网络的规模和可靠性。一个大型 ISP 的 AS 通常有大量的 peer 连接，网络覆盖广泛；一个小型 VPS 提供商的 AS 可能只有几个上游连接。

如何查询 ASN

ipinfo.io

网址：https://ipinfo.io/

ipinfo.io 是最常用的 IP 信息查询工具之一。它不仅提供 ASN 信息，还标注 IP 的使用类型（ISP / Hosting / Business / Education）、地理位置、隐私相关标记（是否为 VPN/代理/Tor 出口）等。

使用方法非常简单。在浏览器中直接访问 https://ipinfo.io/IP地址 即可查看结果：

1

https://ipinfo.io/203.0.113.1

你也可以在命令行中使用：

1

curl ipinfo.io/203.0.113.1

返回的 JSON 数据中，关键字段包括：

• org：所属组织和 ASN（如 “AS16509 Amazon.com, Inc.”）
• city / region / country：地理位置
• company.type：组织类型（isp / hosting / business / education）

ipinfo.io 的免费版本每月有查询次数限制，但对于偶尔查几个 IP 来说完全够用。

bgp.tools

网址：https://bgp.tools/

bgp.tools 是一个专注于 BGP 和 ASN 分析的工具，信息深度超过 ipinfo.io。它特别适合需要了解 AS 的路由关系、上下游连接、前缀公告等技术细节的用户。

在首页的搜索框中输入 IP 地址或 ASN 编号，你可以看到：

• AS 的基本信息（名称、国家、注册日期）
• 该 AS 公告的所有 IP 前缀列表
• 该 AS 的上游 / 下游 / peer AS 列表
• 前缀的路由路径和历史变化

对于代理用户来说，bgp.tools 的价值在于：你可以查看一个 AS 的所有前缀，判断它是一个大型 ISP（拥有大量前缀和 peer）还是一个小型托管商（只有几个前缀和有限的上游）。

bgpview.io

网址：https://bgpview.io/

bgpview.io 和 bgp.tools 功能类似，但界面更加直观友好。它提供了 AS 关系的可视化图表，可以帮助你更直观地理解一个 AS 在互联网拓扑中的位置。

搜索方式同样简单——输入 IP 地址、ASN 编号或组织名称即可。返回结果包括：

• AS 的详细注册信息
• 前缀列表和路由状态
• AS 之间的连接关系图
• Whois 原始数据

其他工具

• ipapi.is：提供 IP 类型检测（datacenter/residential/VPN/proxy），对代理用户非常实用
• whoer.net：综合隐私检测，可以查看你当前的出口 IP、DNS 泄漏、WebRTC 泄漏等
• ipleak.net：专注于隐私泄漏检测

如何解读查询结果

判断 IP 是数据中心还是 ISP

拿到 ASN 查询结果后，核心判断逻辑很简单：看组织名称和类型。

如果组织名称中包含以下关键词，大概率是数据中心 / 云服务商：

• Amazon / AWS / EC2
• Google Cloud / GCP
• Microsoft Azure
• DigitalOcean
• Vultr / Choopa / The Constant Company
• OVH / OVHcloud
• Hetzner
• Linode / Akamai Connected Cloud
• Bandwagon Host / IT7 Networks（搬瓦工）
• CloudInnovation（DMIT）

如果组织名称中包含以下关键词，通常是 ISP：

• Telecom / 电信 / Telekom
• Broadband / 宽带
• Communications
• Cable
• Mobile / 移动
• 特定国家的知名 ISP 名称（Comcast、NTT、KDDI、PCCW、SingTel 等）

ipinfo.io 等工具通常会直接在结果中标注 type: isp 或 type: hosting，省去了你自己判断的步骤。

数据中心 IP 意味着什么

如果你的代理节点使用的是数据中心 IP（比如来自 AWS、Vultr、Hetzner 的 IP），这意味着：

流媒体解锁大概率受限。 Netflix、Disney+、HBO Max 等主流平台都会将数据中心 IP 列入黑名单。即使这个 IP 目前还没被封，由于数据中心 IP 段已经被系统性标记，解锁能力本身就很脆弱。

AI 服务可能受限。 ChatGPT、Claude 等 AI 服务也会检测数据中心 IP。从数据中心 IP 访问可能触发验证、限制功能或直接拒绝服务。

IP 更容易被”连坐”。 数据中心的 IP 段被大量代理和 VPN 服务共用，一个 IP 被平台标记后，同段的其他 IP 也可能受到牵连。

ISP IP 意味着什么

如果节点使用的是 ISP 的 IP（如 Comcast、NTT、PCCW 的 IP），情况通常好得多：

流媒体解锁成功率高。 平台倾向于将 ISP IP 视为正常用户，除非该特定 IP 有大量异常使用记录。

AI 服务限制少。 ISP IP 通常不会触发数据中心检测。

但成本更高。 ISP IP 获取难度大，价格远高于数据中心 IP。这也是为什么提供”原生 IP”或”住宅 IP”节点的机场价格往往更贵。

什么是”干净 IP”

在代理社区中，”干净 IP”是一个非常常见的术语。它的含义是：

一个没有被流媒体平台、AI 服务或 IP 信誉数据库标记为代理/VPN 的 IP 地址。

“干净”的反面是”脏”——一个”脏 IP”已经被一个或多个平台列入黑名单，无法用于解锁服务。

判断一个 IP 是否”干净”的方法：

1. 用上述工具查询 ASN 和类型。 如果是数据中心 IP，先天就不太”干净”。
2. 直接测试解锁。 连接该节点后访问 Netflix/Disney+/ChatGPT 等服务，看是否被拦截。
3. 使用专门的检测工具。 如 ipapi.is 可以检测一个 IP 是否被标记为 VPN/代理。
4. 查看 IP 信誉评分。 ipinfo.io 的 privacy 检测可以显示一个 IP 是否被标记为 VPN、代理或 Tor 出口。

需要注意的是，”干净”是一个相对和动态的概念：

• 一个 IP 可能在 Netflix 上”干净”但在 Disney+ 上”脏”——不同平台使用不同的黑名单。
• 一个 IP 今天”干净”，明天可能被封——因为被大量用户共用或被扫描检测到。
• 一个曾经”脏”的 IP 也可能随时间推移逐渐”变干净”——如果长期没有被代理使用，平台可能会解除标记。

实际应用示例

场景一：评估一个新机场

你订阅了一个新机场，想知道它的节点质量。连上一个日本节点后，先查一下出口 IP：

1

curl ipinfo.io

如果返回结果显示：

1

org: AS20473 The Constant Company, LLC

你就知道这是 Vultr 的数据中心 IP。解锁能力一般，Netflix 日本大概率不行（除非这个特定 IP 碰巧还没被封）。

如果返回结果显示：

1

org: AS2516 KDDI Corporation

这是日本 KDDI 的 ISP IP——原生日本 IP，解锁能力强，品质相对较高。

场景二：排查解锁失败

你的美国节点之前能看 Netflix，突然不行了。查一下出口 IP 的 ASN：

如果 ASN 属于某个云服务商，大概率是这个 IP 段被 Netflix 新加入了黑名单。你可以尝试切换到同机场的其他美国节点（可能使用不同 IP 段），或者联系机场客服反馈。

如果 ASN 属于 ISP，那可能是特定 IP 因为被过多用户共用而被标记。这种情况下，机场运营者可能需要轮换 IP 地址。

场景三：选择机场时的参考

当你对比多个机场时，可以分别试用后检查它们的节点 IP 归属。一个使用 ISP IP（特别是本地 ISP IP）的机场，在解锁能力和稳定性上通常优于使用便宜云服务商 IP 的机场——虽然价格也会更高。

这并不意味着数据中心 IP 的节点完全没有价值。对于单纯的翻墙上网（不需要解锁流媒体或 AI 服务），数据中心 IP 完全够用。但如果你的核心需求是流媒体解锁或 AI 服务访问，IP 质量就是一个需要重点关注的因素。

常见的数据中心 ASN

以下是代理场景中最常遇到的数据中心 ASN。如果你查询到节点 IP 属于这些 AS，说明它是数据中心 IP：

常见的 ISP ASN

以下是各地区常见的 ISP ASN。节点使用这些 AS 的 IP 通常意味着更好的解锁能力：

常见问题

一个 IP 可以属于多个 AS 吗？

通常不会。一个 IP 前缀在某一时刻只由一个 AS 公告。但在特殊情况下（如 anycast 服务），同一个 IP 前缀可能从多个物理位置的路由器公告，不过它们仍然属于同一个 AS。

ASN 查询的结果会变化吗？

会。IP 地址可以在不同组织之间转让，AS 也可以变更自己公告的前缀。一个 IP 今天属于 AS-A，几个月后可能被转让给 AS-B。但在代理场景中，这种变化通常不会频繁发生。

为什么有些节点的 IP 查不到 ASN？

极少数情况下，某些 IP 可能没有被任何 AS 公告（属于未使用或保留的地址段），或者查询工具的数据库更新有延迟。这种情况下，可以换一个查询工具试试。

数据中心 IP 完全没法解锁吗？

不是绝对的。某些数据中心的特定 IP 段可能尚未被平台标记，仍然可以解锁。但这种”可用”状态通常不稳定——随时可能被封。相比之下，ISP IP 的解锁持久性要好得多。此外，一些机场运营者通过技术手段（如 DNS 解锁）配合数据中心 IP 实现解锁，具体原理可以参考 DNS 解锁与原生解锁的区别。

查 ASN 对普通用户有用吗？

如果你只是日常翻墙浏览网页，不需要关心 ASN。但如果你重视流媒体解锁、AI 服务访问或节点稳定性，了解 ASN 的基础知识可以帮助你更理性地选择机场和评估节点质量——不被宣传话术迷惑，用数据说话。

摘要：Clash 生态经历了开源、闭源、删库、fork 等戏剧性事件。本文梳理 Clash 系列的演变历史，解释各个分支的关系，帮助你理解当前应该使用哪个版本。

Clash 的诞生与繁荣

2018 至 2019 年间，开发者 Dreamacro 用 Go 语言创建了 Clash——一个基于规则的代理客户端。它的出现彻底改变了中文代理社区的格局。

在 Clash 之前，代理客户端的配置方式大多是图形界面点选或 JSON 手写，灵活性和可读性都有限。Clash 引入了 YAML 配置文件这一设计，让配置变得既直观又强大。一份 YAML 文件就能定义所有的代理节点、分流规则、DNS 设置和策略组——而且可读、可版本控制、可复用。

Clash 带来的核心创新包括：

• YAML 配置格式：结构清晰、易于维护，对比 JSON 大幅降低了配置门槛。
• 代理组（Proxy Groups）：支持自动选择、负载均衡、故障转移等策略，节点管理从”选一个用”变成了”设好策略自动选”。
• 规则分流系统：通过 DOMAIN、GEOIP、IP-CIDR 等规则类型，精确控制每一条连接走代理还是直连。
• 混合代理模式：同时支持 HTTP 代理、SOCKS5 代理和透明代理，一个客户端满足所有场景。
• rule-provider：将规则集独立托管，客户端自动拉取更新，不需要每次手动修改配置文件。
• RESTful API：提供外部控制接口，让 Web UI 和第三方工具能远程管理 Clash。

凭借这些设计，Clash 迅速成为中文代理社区最主流的框架。它的成功不仅在于自身，还在于催生了一整个生态——基于 Clash 的图形化客户端、规则集、配置模板、订阅转换服务遍地开花。

两个版本：Clash 与 Clash Premium

Clash 在早期就分化为两个版本：

• Clash（开源版）：核心功能完整，代码开源在 GitHub，社区可以审计和贡献。
• Clash Premium（闭源版）：在开源版基础上增加了高级功能，以二进制形式分发，不开放源码。

Clash Premium 增加的关键特性包括 TUN 模式（在系统层面接管所有流量，不仅限于配置了代理的应用）、rule-provider（早期只有 Premium 版支持）、Script 脚本支持（用 Python/JS 编写自定义分流逻辑）。

这种”核心开源 + 高级功能闭源”的模式在当时并不罕见，Clash Premium 的功能确实强大，但闭源也为后来的变故埋下了隐患：一旦作者停止维护，社区无法接手闭源部分的代码。

2023 年 11 月：大删库事件

2023 年 11 月，Dreamacro 突然删除了 GitHub 上的 Clash 仓库。不仅仅是 Clash 核心——几乎在同一时间，基于 Clash 的多个重要项目也纷纷下线：

• Clash for Windows（最流行的 Windows 端图形化客户端）宣布停止维护。
• Clash for Android 归档。
• 一系列相关工具和文档也被清理。

这在中文代理社区引发了强烈震动。Clash 彼时已经是事实上的”基础设施”级项目，无数用户的日常上网依赖它，无数机场的配置格式围绕它构建。

关于删库的原因，Dreamacro 本人没有做详细公开说明。社区的普遍推测包括：

• 监管压力：Clash for Windows 的开发者据传受到了约谈或警告，引发连锁反应。
• 个人决定：长期维护开源项目的压力和风险积累。
• 法律风险规避：主动下架以避免潜在的法律责任。

无论真实原因是什么，这次事件产生了两个关键结果：

1. 原版 Clash 和 Clash Premium 彻底停止了更新。 没有新功能、没有 bug 修复、没有协议适配。
2. 社区 fork 成为唯一的延续路径。 幸运的是，Clash 的开源版本在删库前就已经被大量 fork，而且最重要的 fork——Clash Meta——在删库之前就已经是一个成熟的、独立发展的项目。

当前的 Clash 家族

Clash Premium：已停止维护

Clash Premium 作为原版闭源增强版，曾是功能最完整的 Clash 内核。它支持 TUN 模式、rule-provider、Script 脚本等高级功能，在很长一段时间内是高级用户和机场配置的首选内核。

但由于闭源且已停更，Clash Premium 存在以下问题：

• 不再有安全更新：已知的漏洞不会被修复。
• 不支持新协议：VLESS、Reality、Hysteria2 等 2023 年后成为主流的协议完全不被支持。
• 无法获取新版本：官方分发渠道已关闭，网上流传的版本来源不明，存在安全隐患。

如果你还在使用 Clash Premium，强烈建议尽快迁移到 mihomo。 迁移成本几乎为零——mihomo 完全兼容 Clash Premium 的配置格式。

Clash Meta 到 mihomo：核心继承者

mihomo（原名 Clash.Meta）是当前 Clash 生态最重要的项目，也是事实上的”Clash 正统继承者”。

这个项目由 MetaCubeX 团队维护，创建时间早于删库事件。最初，它作为 Clash 的一个增强 fork 存在，目标是添加原版 Clash 和 Clash Premium 都不支持的新协议和新功能。

在删库事件后，Clash.Meta 更名为 mihomo——这个看似随意的名字背后是出于法律和安全考量的慎重决定。与”Clash”品牌脱钩，可以降低项目因名称关联而受到波及的风险。

mihomo 的定位非常明确：在完全兼容 Clash 配置格式的前提下，持续跟进最新的代理协议和技术。

目前 mihomo 活跃维护，更新频率高，新协议的支持通常在协议发布后很快跟进。它已经取代了原版 Clash 和 Clash Premium 的位置，成为绝大多数 Clash 系客户端的底层内核。

GitHub 地址：MetaCubeX/mihomo

其他值得关注的分支

除了 mihomo，Clash 删库后还出现了一些其他 fork 和衍生项目。但从活跃度、功能完整度和社区采用度来看，mihomo 是压倒性的主流选择，其他项目的影响力相对有限。MetaCubeX 团队同时还维护 metacubexd（一个现代化的 Clash Web Dashboard）等配套工具，形成了完整的生态。

基于 mihomo 的客户端

mihomo 本身是一个命令行内核。大多数用户通过图形化客户端来使用它——这些客户端内置或调用 mihomo 核心，提供界面操作。

Clash Verge Rev（桌面端首选）

• 平台：Windows / macOS / Linux
• 技术栈：Tauri（Rust + Web 前端）
• 定位：当前桌面端最推荐的 Clash 系客户端

Clash Verge Rev 是原 Clash Verge 项目的社区继承版本。原版 Clash Verge 在大删库事件后也停止了更新，社区随后 fork 并继续维护，命名为 Clash Verge Rev（Rev 即 Revival/Revised 之意）。

它的优势在于：

• 界面现代：比起老旧的 Clash for Windows，UI 设计更加清爽。
• 内存占用低：得益于 Tauri 框架（Rust 后端），相比 Electron 方案内存占用显著更小。
• 功能完整：支持 mihomo 的全部功能，包括 TUN 模式、规则集管理、节点测速等。
• 更新活跃：社区持续维护，跟进 mihomo 的新版本。

GitHub 地址：clash-verge-rev/clash-verge-rev

OpenClash（路由器端首选）

• 平台：OpenWrt
• 定位：路由器级别的代理解决方案，全家设备无需单独安装客户端

OpenClash 是 OpenWrt 路由器上最流行的代理插件。它通过 LuCI Web 界面提供管理能力，支持 mihomo 内核，可以在路由器层面为整个局域网提供透明代理。

对于家庭用户来说，在路由器上运行 OpenClash 意味着所有连接到这个路由器的设备——手机、平板、电视、游戏机——都自动通过代理上网，无需逐一安装和配置客户端。

Clash Meta for Android（Android 端）

• 平台：Android
• 定位：Android 上的 mihomo 图形化客户端

采用 Material Design 界面风格，功能覆盖 mihomo 的主要特性。支持导入订阅链接、管理规则集、切换节点和代理模式。对于 Android 用户来说，是比较直接的 Clash 系选择。

不过需要注意，Android 端目前也有 sing-box 等替代方案正在快速发展。

Stash（iOS 端）

• 平台：iOS / macOS
• 定位：兼容 Clash 配置格式的商业客户端

Stash 是一款付费应用（App Store 上架），不直接使用 mihomo 内核，而是使用自己的实现。但它兼容 Clash YAML 配置格式，这意味着你为 Clash/mihomo 编写的配置文件可以直接导入 Stash 使用。

对于 iOS 用户来说，Stash 和 Shadowrocket 是两个主要选择。Stash 更偏向”Clash 生态”，Shadowrocket 则更通用。

mihomo 相比原版 Clash 的改进

mihomo 不仅仅是”接手维护”，它在功能上已经远远超越了原版 Clash Premium。以下是关键差异：

几个特别值得说明的改进：

• VLESS + Reality：这是目前抗检测能力最强的协议组合之一。mihomo 对其的支持意味着你可以在 Clash 配置体系下直接使用最先进的协议，不需要切换到其他内核。详见 VLESS + Reality 深度解析。
• Hysteria2 和 TUIC：这两个基于 QUIC（UDP）的协议在高延迟、高丢包网络下有显著优势。原版 Clash 完全没有 UDP 代理协议的支持，mihomo 填补了这个空白。
• Sub-Rule（子规则）：允许在规则匹配后进一步细分处理逻辑，配置灵活度大幅提升。

配置兼容性

从 Clash Premium 迁移到 mihomo，配置兼容性是大多数用户最关心的问题。好消息是：mihomo 对 Clash Premium 配置格式保持了高度向后兼容。

具体来说：

• 标准 Clash YAML 配置文件可以直接被 mihomo 解析和使用，几乎不需要任何修改。
• rule-provider、proxy-provider 等 Clash Premium 引入的功能在 mihomo 中完全支持。
• 代理组策略（url-test、fallback、load-balance 等）的语法和行为与原版一致。
• DNS 配置的格式和逻辑兼容。

新功能方面，mihomo 使用了扩展的 YAML 语法来支持原版 Clash 不存在的协议和特性。例如，添加一个 VLESS + Reality 节点的写法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

proxies:
  - name: "vless-reality"
    type: vless
    server: your.server.com
    port: 443
    uuid: your-uuid
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: www.microsoft.com
    reality-opts:
      public-key: your-public-key
      short-id: your-short-id

这些扩展语法不会影响已有的 Clash 配置——你的旧配置依然正常工作，只是在需要使用新协议时才会用到新语法。

订阅转换方面，主流的订阅转换服务（如 subconverter）都已支持输出 mihomo 兼容格式。大多数机场的订阅链接也已经默认适配 mihomo。如果你的机场订阅链接直接能用，不需要做任何转换。

常见问题

Q：现在搜”Clash”搜到的是什么版本？

如果你在搜索引擎中搜索”Clash 代理”或”Clash 下载”，搜到的几乎都是基于 mihomo 的产品——Clash Verge Rev、OpenClash、Clash Meta for Android 等。原版 Clash 和 Clash Premium 的下载链接已经不存在了。在 2024 年之后的语境下，”Clash”这个词实际上已经等同于”mihomo 生态”。

Q：我的 Clash 配置文件还能用吗？

如果你的配置是标准的 Clash YAML 格式，几乎 100% 可以直接在 mihomo 下使用。直接导入即可。唯一可能需要调整的情况是：你的配置中使用了 Clash Premium 的 Script 功能（用 Python 脚本自定义分流逻辑），这个功能在 mihomo 中的实现方式有所不同。

Q：Clash Verge 和 Clash Verge Rev 什么关系？

Clash Verge 是原版客户端，由 zzzgydi 开发。在删库事件后，原版 Clash Verge 也停止了更新。Clash Verge Rev 是社区基于原版的 fork，由新的维护团队继续开发。两者的界面和交互非常相似，但 Rev 版本修复了旧版的 bug、跟进了 mihomo 的新功能、改善了性能和稳定性。推荐使用 Rev 版本。

Q：还有必要用 Clash 系吗？Sing-box 不是更新？

这是一个好问题。sing-box 确实是更新的代理框架，架构设计更现代，性能也有一定优势。但 Clash 系（mihomo）的核心优势在两个方面：

1. 规则系统的成熟度：Clash 的 rule-provider 生态已经非常完善，社区维护着大量成熟的规则集（Loyalsoldier、MetaCubeX、ACL4SSR 等），覆盖了绝大多数分流场景。这些规则集经过多年迭代，准确性高、维护频繁。
2. 社区生态的庞大：配置模板、教程文档、问题解答——围绕 Clash/mihomo 的社区资源极其丰富。遇到问题时，搜索到解决方案的概率远高于 sing-box。

对于大多数用户来说，Clash Verge Rev（mihomo 内核）仍然是上手最快、维护成本最低的选择。如果你对 sing-box 有兴趣，可以参考 Sing-box 使用指南 和 Sing-box TUN vs Clash Verge TUN：实际体验对比。

Q：mihomo 的名字为什么这么奇怪？

mihomo 这个名字并没有特别深的含义。项目更名的主要目的是与”Clash”品牌脱钩，降低因品牌名称关联而带来的法律和安全风险。名字本身不重要——重要的是它是目前最活跃、功能最完整的 Clash 兼容内核。

Q：我是新用户，应该从哪个客户端开始？

根据你的平台选择：

• Windows / macOS / Linux：Clash Verge Rev。下载安装后导入订阅链接即可使用。
• Android：Clash Meta for Android 或 v2rayNG。
• iOS：Stash（付费，兼容 Clash 配置）或 Shadowrocket（付费，更通用）。
• 路由器（OpenWrt）：OpenClash。

如果你是第一次使用代理，建议先阅读 第一次使用代理：从零开始的配置指南。

总结

Clash 的故事是开源社区韧性的一个缩影。原始项目虽然消失了，但它的设计理念和配置生态通过 mihomo 延续了下来，并且在功能上走得更远。

当前的 Clash 生态简单明了：

• 内核：mihomo（MetaCubeX/mihomo）——唯一活跃维护的 Clash 兼容内核。
• 桌面客户端：Clash Verge Rev——最推荐的跨平台图形化客户端。
• 路由器：OpenClash——OpenWrt 上的首选方案。
• 配置格式：Clash YAML——经过 mihomo 扩展，支持所有现代协议。

如果你曾经用过 Clash，你的知识和配置仍然有效。如果你是新用户，直接从 mihomo 生态开始即可。无论哪种情况，Clash 的规则系统和配置哲学在代理工具领域仍然是最成熟、最易用的方案之一。

摘要：rule-provider 是 Clash（mihomo）中管理分流规则的核心机制。它允许你从外部加载和自动更新规则列表，而不用在配置文件中手写成百上千条规则。本文详解 rule-provider 的工作原理、配置方法和常用规则集推荐。

为什么需要 rule-provider

一个能用的代理配置，分流规则是核心。你需要告诉客户端：哪些流量走代理、哪些直连、哪些应该屏蔽。

如果不使用 rule-provider，你的配置文件里会写满这样的内容：

1
2
3
4
5
6
7
8
9
10

rules:
  - DOMAIN-SUFFIX,google.com,Proxy
  - DOMAIN-SUFFIX,googleapis.com,Proxy
  - DOMAIN-SUFFIX,youtube.com,Proxy
  - DOMAIN-SUFFIX,twitter.com,Proxy
  - DOMAIN-SUFFIX,facebook.com,Proxy
  # ... 还有几千条
  - IP-CIDR,91.108.0.0/16,Proxy
  - IP-CIDR,149.154.0.0/16,Proxy
  # ... 还有几百条 IP 段

这种做法有三个严重问题：

1. 配置文件膨胀。一套完整的分流规则通常包含数千条记录——GFW 屏蔽的域名、国内直连的域名和 IP 段、广告域名、各种流媒体的域名。全部写在主配置文件中，文件大小动辄几百 KB，打开编辑都很困难。

2. 无法自动更新。GFW 的屏蔽列表不是固定的，新的域名不断被封锁，旧的 IP 段可能被释放。广告域名的变化更加频繁。如果规则写死在配置文件里，你需要手动追踪这些变化并逐条更新，这在实际操作中几乎不可能做到。

3. 维护成本极高。当你想调整分流策略时——比如把 Netflix 从通用代理组移到专门的流媒体组——你需要在几千条规则中找到所有相关条目并逐一修改。

rule-provider 的思路和浏览器的广告拦截器完全一样：你不用自己编写拦截规则，只需要订阅别人维护的规则列表。 列表的维护者会持续更新内容，你的客户端定期拉取最新版本，始终保持规则的时效性。

rule-provider 的工作原理

rule-provider 的运行逻辑分为三个阶段：

加载阶段：Clash 启动时，读取配置文件中 rule-providers 段的定义。对于每个 provider，根据 type 字段决定加载方式——http 类型会从指定 URL 下载规则文件，file 类型会从本地路径读取文件。下载的文件会缓存到 path 指定的本地路径。

更新阶段：对于 http 类型的 provider，Clash 会按照 interval 字段设定的时间间隔（单位为秒）重新下载规则文件。如果下载失败（比如网络不可用），Clash 会继续使用上一次成功下载的缓存文件，不会中断服务。

匹配阶段：当有流量进入时，Clash 按照 rules 段的顺序逐条匹配。遇到 RULE-SET 类型的规则时，Clash 会在对应的 rule-provider 加载的规则列表中查找匹配项。如果找到匹配，按照 RULE-SET 指定的策略组处理；如果没有匹配，继续检查下一条规则。

规则文件格式：rule-provider 支持三种格式：

• text：纯文本格式，每行一条规则，最直观也最通用
• yaml：YAML 格式，规则包裹在 payload 字段中
• mrs：mihomo 专有的二进制格式，加载速度最快，但只有 mihomo 内核支持

配置方法

基本语法

rule-provider 的配置分为两部分：先在 rule-providers 段定义规则集，再在 rules 段中引用它们。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

rule-providers:
  google:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/google.txt"
    path: ./ruleset/google.txt
    interval: 86400
    format: text

  cn-cidr:
    type: http
    behavior: ipcidr
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/cncidr.txt"
    path: ./ruleset/cncidr.txt
    interval: 86400
    format: text

rules:
  - RULE-SET,google,Proxy
  - RULE-SET,cn-cidr,DIRECT
  - MATCH,Proxy

参数详解

每个 rule-provider 包含以下参数：

type – 加载方式

• http：从远程 URL 下载规则文件。适合使用公共维护的规则集。
• file：从本地文件路径读取。适合自定义规则或网络受限环境。

behavior – 规则行为类型

这是最容易混淆的参数，决定了规则文件内容的解析方式。三种取值对应三种不同的文件格式要求：

• domain：文件中每一行是一个域名，Clash 自动按 DOMAIN-SUFFIX 逻辑匹配。
• ipcidr：文件中每一行是一个 IP CIDR 段。
• classical：文件中每一行是完整的规则语法（包含规则类型前缀）。

url – 远程下载地址

规则文件的 URL。仅在 type: http 时需要。建议使用 CDN 加速地址（如 jsdelivr）以提高下载成功率。

path – 本地缓存路径

下载的规则文件在本地的存储路径。即使是 http 类型也需要指定，用于缓存下载的文件。路径相对于 Clash 的配置目录。

interval – 更新间隔

自动更新的时间间隔，单位为秒。86400 表示每 24 小时更新一次。设为 0 则不自动更新。

format – 文件格式

• text：纯文本，每行一条规则，最常用。
• yaml：YAML 格式，规则在 payload 列表中。
• mrs：mihomo 的二进制格式，解析速度最快。

behavior 类型详细说明

三种 behavior 的区别是新手最容易踩坑的地方。文件内容格式必须和 behavior 声明严格对应，否则 Clash 无法正确解析。

domain behavior：

文件内容只包含域名，不需要规则类型前缀：

1
2
3
4

google.com
googleapis.com
youtube.com
gstatic.com

Clash 会自动将这些域名按 DOMAIN-SUFFIX 逻辑匹配。也就是说，google.com 会匹配 google.com 本身以及 mail.google.com、docs.google.com 等所有子域名。

在 rules 中引用时直接写 RULE-SET,google,Proxy，不需要再指定匹配类型。

ipcidr behavior：

文件内容只包含 IP CIDR 段：

1
2

91.108.0.0/16
149.154.0.0/16

引用方式与 domain 相同。当流量的目标 IP 落在这些 CIDR 范围内时，规则命中。

classical behavior：

文件内容包含完整的规则语法，支持混合多种规则类型：

1
2
3
4

DOMAIN-SUFFIX,google.com
DOMAIN-KEYWORD,youtube
IP-CIDR,91.108.0.0/16,no-resolve
DOMAIN,api.openai.com

classical 是最灵活的 behavior，因为一个文件中可以同时包含域名规则、IP 规则、关键词规则等。代价是解析速度略慢于 domain 和 ipcidr，因为 Clash 需要逐行解析规则类型前缀。

选择建议：如果规则文件只包含域名，用 domain；只包含 IP 段，用 ipcidr；包含混合类型，用 classical。公共规则集的文档通常会标明应该使用哪种 behavior。

在规则中引用 rule-provider

定义好 rule-provider 后，在 rules 段中通过 RULE-SET 关键字引用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

rules:
  # 广告拦截
  - RULE-SET,reject,REJECT
  # 私有地址直连
  - RULE-SET,private,DIRECT
  # 具体服务 → 专用策略组
  - RULE-SET,openai,AI
  - RULE-SET,google,Proxy
  - RULE-SET,apple,Apple
  - RULE-SET,netflix,Streaming
  - RULE-SET,telegram,Telegram
  # 国内流量直连
  - RULE-SET,cn-domain,DIRECT
  - RULE-SET,cn-cidr,DIRECT
  - GEOIP,CN,DIRECT
  # 兜底
  - MATCH,Proxy

规则的匹配顺序至关重要：Clash 从上到下逐条匹配，第一条命中的规则生效。 因此：

• 把 REJECT（广告拦截）放在最前面，确保广告域名不会被后面的规则放行
• 具体服务的规则放在通用规则前面，避免被更宽泛的规则覆盖
• GEOIP 和 MATCH 放在最后作为兜底

常用规则集推荐

Loyalsoldier/clash-rules

目前最流行的 Clash 规则集项目，社区维护活跃，覆盖全面。

规则分类：

URL 基础路径：https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/

格式：text

适合人群：大多数用户。规则分类清晰，文件格式统一，文档完善。

MetaCubeX/meta-rules-dat

mihomo（Clash Meta）官方维护的规则数据集，提供 MRS 二进制格式。

特点：

• 提供 MRS 格式的规则文件，加载速度显著快于文本格式。在规则数量较大时（数万条），MRS 格式的解析时间可以比 text 格式快数倍。
• 规则数据来源于 v2fly/domain-list-community 和 Loyalsoldier/geoip 等上游项目，覆盖全面。
• 同时提供 GeoSite 和 GeoIP 数据，可以搭配 GEOSITE 和 GEOIP 规则使用。

适合人群：使用 mihomo 内核的用户。如果你的客户端是 Clash Verge Rev、Clash Nyanpasu 等基于 mihomo 的软件，优先考虑这个项目以获得最佳加载性能。

ACL4SSR

历史悠久的规则项目，最大的特点是提供了预制的完整配置文件，包括 rule-provider 定义和 rules 段，开箱即用。

特点：

• 规则分类非常细致，对流媒体服务有详细拆分：Netflix、Disney+、HBO、Amazon Prime Video、Spotify 等各有独立规则文件。
• 提供适用于不同机场订阅转换服务的配置模板。
• 社区讨论活跃，遇到问题容易找到解决方案。

适合人群：需要对每个流媒体服务单独配置路由策略的用户。比如你想让 Netflix 走美国节点、Disney+ 走新加坡节点，ACL4SSR 的细粒度分类会很方便。

完整配置示例

以下是一套可以直接使用或在此基础上修改的完整配置。包含广告拦截、国内直连、常用海外服务分组、流媒体、AI 服务和 Telegram 的独立路由。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153

# ==================== 规则集定义 ====================
rule-providers:
  # 广告拦截
  reject:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/reject.txt"
    path: ./ruleset/reject.txt
    interval: 43200
    format: text

  # 私有网络
  private:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/private.txt"
    path: ./ruleset/private.txt
    interval: 86400
    format: text

  # 国内直连域名
  cn-domain:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/direct.txt"
    path: ./ruleset/direct.txt
    interval: 86400
    format: text

  # 国内 IP 段
  cn-cidr:
    type: http
    behavior: ipcidr
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/cncidr.txt"
    path: ./ruleset/cncidr.txt
    interval: 86400
    format: text

  # Google 服务
  google:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/google.txt"
    path: ./ruleset/google.txt
    interval: 86400
    format: text

  # Apple 服务
  apple:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/apple.txt"
    path: ./ruleset/apple.txt
    interval: 86400
    format: text

  # iCloud
  icloud:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/icloud.txt"
    path: ./ruleset/icloud.txt
    interval: 86400
    format: text

  # Telegram IP 段
  telegram-cidr:
    type: http
    behavior: ipcidr
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/telegramcidr.txt"
    path: ./ruleset/telegramcidr.txt
    interval: 86400
    format: text

  # 流媒体 - Netflix
  netflix:
    type: http
    behavior: classical
    url: "https://cdn.jsdelivr.net/gh/ACL4SSR/ACL4SSR@master/Clash/Providers/Ruleset/Netflix.yaml"
    path: ./ruleset/netflix.yaml
    interval: 86400

  # 流媒体 - Disney+
  disney:
    type: http
    behavior: classical
    url: "https://cdn.jsdelivr.net/gh/ACL4SSR/ACL4SSR@master/Clash/Providers/Ruleset/DisneyPlus.yaml"
    path: ./ruleset/disney.yaml
    interval: 86400

  # AI 服务 (OpenAI, Claude 等)
  ai-services:
    type: file
    behavior: classical
    path: ./ruleset/ai-services.txt
    format: text

  # GFW 列表
  gfw:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/gfw.txt"
    path: ./ruleset/gfw.txt
    interval: 86400
    format: text

  # 需要代理的域名
  proxy-domain:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/proxy.txt"
    path: ./ruleset/proxy.txt
    interval: 86400
    format: text

# ==================== 分流规则 ====================
rules:
  # 1. 广告拦截 - 最高优先级
  - RULE-SET,reject,REJECT

  # 2. 私有地址和局域网 - 必须直连
  - RULE-SET,private,DIRECT

  # 3. AI 服务 - 单独分组，方便切换节点地区
  - RULE-SET,ai-services,AI

  # 4. 流媒体 - 单独分组，走专用解锁节点
  - RULE-SET,netflix,Streaming
  - RULE-SET,disney,Streaming

  # 5. Telegram - 基于 IP 段匹配
  - RULE-SET,telegram-cidr,Telegram

  # 6. Google 服务
  - RULE-SET,google,Proxy

  # 7. Apple 服务 - 国内 CDN 可直连，部分服务需要代理
  - RULE-SET,apple,Apple
  - RULE-SET,icloud,Apple

  # 8. 国内域名和 IP - 直连
  - RULE-SET,cn-domain,DIRECT
  - RULE-SET,cn-cidr,DIRECT

  # 9. GFW 列表和通用代理域名
  - RULE-SET,gfw,Proxy
  - RULE-SET,proxy-domain,Proxy

  # 10. GeoIP 兜底 - 中国 IP 直连
  - GEOIP,CN,DIRECT

  # 11. 最终兜底 - 未匹配的流量走代理
  - MATCH,Proxy

上面的配置中，ai-services 使用了 type: file，你需要手动创建这个文件。示例内容如下（保存为 ./ruleset/ai-services.txt）：

1
2
3
4
5
6
7
8
9
10
11
12
13

DOMAIN-SUFFIX,openai.com
DOMAIN-SUFFIX,ai.com
DOMAIN-SUFFIX,chatgpt.com
DOMAIN-SUFFIX,oaistatic.com
DOMAIN-SUFFIX,oaiusercontent.com
DOMAIN-SUFFIX,anthropic.com
DOMAIN-SUFFIX,claude.ai
DOMAIN-SUFFIX,googleapis.com
DOMAIN-SUFFIX,gemini.google.com
DOMAIN-SUFFIX,bard.google.com
DOMAIN-SUFFIX,deepmind.google
DOMAIN-SUFFIX,copilot.microsoft.com
DOMAIN-SUFFIX,perplexity.ai

配置中引用了 AI、Streaming、Telegram、Apple 等策略组名称，你需要在 proxy-groups 段中定义这些组。这些组的具体节点配置取决于你的代理服务提供商。

自定义规则集

公共规则集覆盖了绝大多数场景，但总有一些个性化需求需要自定义规则。

创建自定义规则文件

以公司内网域名直连为例，创建一个文本文件 company.txt：

1
2
3
4
5

internal.mycompany.com
gitlab.mycompany.com
jira.mycompany.com
wiki.mycompany.com
vpn.mycompany.com

在配置中引用

如果是本地文件：

1
2
3
4
5
6
7
8
9
10

rule-providers:
  company:
    type: file
    behavior: domain
    path: ./ruleset/company.txt
    format: text

rules:
  - RULE-SET,company,DIRECT
  # ... 其他规则

如果你把文件托管到 GitHub 或自己的服务器：

1
2
3
4
5
6
7
8

rule-providers:
  company:
    type: http
    behavior: domain
    url: "https://raw.githubusercontent.com/yourname/rules/main/company.txt"
    path: ./ruleset/company.txt
    interval: 86400
    format: text

实际应用场景

游戏加速：某些游戏的服务器 IP 需要走特定节点以获得最低延迟。创建一个 gaming.txt，使用 ipcidr behavior，将游戏服务器 IP 段路由到延迟最低的节点组。

开发工具：GitHub、npm、Docker Hub 等开发相关服务的域名，集中到一个规则文件中，路由到稳定性最好的节点。

内容过滤：除了使用公共的广告拦截规则，你可以创建自己的屏蔽列表，把不想看到的域名加入其中，使用 REJECT 策略。

常见问题

Q: rule-provider 下载失败怎么办？

这是最常见的”先有鸡还是先有蛋”问题：你需要代理才能下载规则文件，但规则文件还没下载完成时代理无法正常工作。

解决方法：

1. 使用 CDN 地址：jsdelivr（cdn.jsdelivr.net）、ghproxy（ghproxy.com）等 CDN 在国内通常可以直接访问，避免直接访问 GitHub raw 域名。
2. 手动下载：先通过其他方式（比如已经能翻墙的手机）下载规则文件，放到 path 指定的本地路径，并将 type 改为 file。
3. 初始启动配置：第一次使用时，先用一个精简的配置（不包含 rule-provider，只有几条基本规则）连上代理，然后再切换到包含 rule-provider 的完整配置。
4. 机场提供的配置：很多机场的订阅链接已经内置了 rule-provider 配置，且使用可达的 CDN 地址，直接导入即可。

Q: 规则集多久更新一次合适？

取决于规则集的类型：

• 广告拦截规则（reject）：建议 12 小时（43200 秒）。广告域名变化较快，更频繁的更新可以保持更好的拦截效果。
• 常规分流规则（direct、proxy、gfw 等）：24 小时（86400 秒）足够。这类规则的变化频率较低。
• IP 段规则（cncidr、telegramcidr 等）：24-72 小时都可以。IP 段的分配变化很慢。
• 自定义规则（本地文件）：设为 0 即可，由你手动维护。

不建议将 interval 设得过小（比如每小时更新一次）。频繁下载不仅浪费带宽，还可能触发 CDN 的速率限制，导致下载失败。

Q: domain 和 classical behavior 选哪个？

优先用 domain 或 ipcidr，原因是：

1. 解析速度更快：domain 和 ipcidr behavior 的规则文件格式简单，Clash 可以将它们高效地加载到内存中的哈希表或前缀树结构中，查询复杂度接近 O(1)。而 classical behavior 包含多种规则类型，需要逐条线性匹配，效率较低。
2. 文件更小：domain 文件每行只有一个域名，不需要 DOMAIN-SUFFIX, 前缀，文件体积更小，下载更快。
3. 不容易出错：格式简单意味着手动编辑时不容易写错。

必须用 classical 的场景：规则文件中混合了不同类型的规则（域名 + IP + 关键字），或者规则来源只提供 classical 格式。ACL4SSR 项目的部分规则文件就是 classical 格式。

Q: 规则集之间冲突了怎么办？

规则冲突的本质是：同一个域名或 IP 出现在多个 rule-provider 的规则列表中，而这些 rule-provider 对应不同的策略组。

Clash 的处理方式是 先匹配先生效（first match wins）。rules 段中排在前面的 RULE-SET 优先级更高。

典型冲突场景和解决方法：

• youtube.com 同时出现在 google.txt 和 proxy.txt 中。如果你在 rules 里先写了 RULE-SET,google,Proxy，再写 RULE-SET,proxy-domain,Proxy，YouTube 会命中 Google 的规则。两者策略相同时没有实际影响；如果策略不同，调整 rules 中的顺序即可。
• Netflix 域名同时出现在 netflix 规则集和通用 proxy-domain 规则集中。把 RULE-SET,netflix,Streaming 放在 RULE-SET,proxy-domain,Proxy 前面，Netflix 就会走 Streaming 组而非通用 Proxy 组。

排查方法：在 Clash 的日志或连接面板中查看特定域名命中了哪条规则。Clash Verge Rev 的”连接”页面会显示每个连接匹配的规则名称和策略组，方便排查冲突。更多配置细节可以参考 Clash Wiki。

Q: 使用 MRS 格式有什么注意事项？

MRS（Meta Rule Set）是 mihomo 引入的二进制规则格式，加载速度最快，但有以下限制：

• 只有 mihomo 内核支持，原版 Clash Premium 和其他内核无法使用。
• 无法直接用文本编辑器查看或编辑文件内容。
• 需要使用 mihomo 提供的工具将文本规则编译为 MRS 格式。

如果你使用的客户端基于 mihomo 内核（Clash Verge Rev、Clash Nyanpasu 等），且规则集数量较多、总条目数达到数万条级别，切换到 MRS 格式可以显著减少启动时的规则加载时间。对于规则条目较少的情况，text 格式已经足够快，差异可以忽略。

Q: 能同时使用 GEOSITE/GEOIP 和 rule-provider 吗？

可以，两者并不冲突。GEOSITE 和 GEOIP 是 Clash 内置的规则类型，使用预编译的数据库进行匹配；RULE-SET 则引用外部的 rule-provider 文件。

实际配置中，常见的搭配方式是：用 rule-provider 处理需要精细控制的服务（Netflix、Telegram、AI 等），用 GEOIP,CN,DIRECT 作为中国 IP 的兜底规则。两者各司其职，互相补充。

摘要: V2Ray、Xray、Sing-box 是当前最主流的三个代理内核。它们之间存在继承和分化关系——Xray 从 V2Ray 分裂而来，Sing-box 则是受其启发后从零构建的新生代。本文梳理它们的历史渊源、技术架构差异和各自的适用场景，帮助你理解”内核”这一层在整个代理体系中扮演的角色。

什么是”代理内核”

在讨论 V2Ray、Xray、Sing-box 之前，有必要澄清一个基础概念：内核（core）是代理软件的底层引擎，负责协议解析、流量路由、加解密等核心功能。你在手机或电脑上使用的 v2rayN、NekoBox、Clash Verge 等工具，它们本身只是图形界面（GUI），真正干活的是背后集成的内核。

换句话说，选择客户端时你其实在间接选择内核。理解内核之间的差异，有助于判断一个客户端的协议支持范围、性能上限和未来的可持续性。

一段简短的历史

V2Ray 的诞生

V2Ray 项目诞生于 2015-2016 年前后，创建者使用化名”Victoria Raymond”（V2Ray 之名即源于此）。项目的初始目标并非发明某个单一协议，而是构建一个通用的代理平台——一个可以承载多种协议的框架。

V2Ray 引入了 VMess 协议，这是它的原生协议，采用 UUID 认证和自定义加密方案。在当时的环境下，VMess 相比传统的 SOCKS/HTTP 代理和早期 Shadowsocks 提供了更强的安全性保障。V2Ray 还设计了灵活的路由系统、多种传输方式（WebSocket、gRPC、HTTP/2 等），这些架构理念深刻影响了后来的所有代理项目。

2019 年左右，Victoria Raymond 逐步淡出项目。此后，V2Ray 由社区组织 V2Fly 接手维护，仓库名为 v2fly/v2ray-core。V2Fly 团队在维护期间保持了项目的基本稳定，但开发节奏明显放缓，新功能的推进速度远不及审查技术的演进速度。

Xray 的分裂

2020 年末，开发者 RPRX 围绕 XTLS 技术与 V2Fly 团队产生了许可证分歧。XTLS 是一项重要的性能优化技术，能够在 TLS 代理场景下避免对 TLS 内层数据的重复加密，显著降低延迟和 CPU 开销。这一分歧最终导致 RPRX fork 了 v2ray-core，创建了 Xray-core（隶属 Project X 组织）。

Xray 并非简单的换皮分支。它在 V2Ray 的基础上带来了一系列关键技术突破：

• VLESS 协议：比 VMess 更轻量的协议设计，去掉了 VMess 冗余的加密层（依赖外层 TLS 提供安全性），降低了协议头部开销
• XTLS（Vision）：避免 TLS-in-TLS 的双重加密问题，在保持安全性的前提下大幅提升转发性能
• Reality：2023 年推出的反检测技术，无需域名和证书即可实现 TLS 伪装，将代理流量伪装成访问真实网站的 TLS 1.3 连接，是目前抗主动探测能力最强的方案之一
• XHTTP 和 XMUX：基于 HTTP 的新传输方式及其多路复用扩展，为 CDN 中转等场景提供更灵活的选择

截至 2026 年，Xray-core 的开发活跃度远超 v2ray-core，是协议创新的主要推动力量。在服务端部署领域，Xray 占据绝对主导地位。

Sing-box 的崛起

Sing-box 走了一条完全不同的路。它的作者 nekohasekai（SagerNet 系列客户端的开发者）没有选择 fork V2Ray 或 Xray，而是从零开始用 Go 语言重新编写了一个全新的代理内核。

这个决策背后的逻辑是：V2Ray 的代码架构经过多年迭代已经变得臃肿，历史包袱沉重，模块间耦合度高，很难在其基础上做大规模的结构优化。与其在旧地基上修补，不如重新打地基。

Sing-box 的设计哲学是”通用代理平台“——不绑定某个特定协议阵营，而是尽可能广泛地支持各种协议。它同时支持 Xray 生态的 VLESS+Reality 和独立协议如 Hysteria2、TUIC，还提供了类似 Clash 的强大规则路由系统。

Sing-box 的增长势头很快。截至 2026 年，多个主流客户端（NekoBox、Hiddify、Clash Verge Rev 等）已将 sing-box 作为默认或可选内核。它在移动端（Android/iOS）的表现尤为突出，因为其现代化的架构在资源受限的移动设备上有更好的内存管理和电池效率。

技术对比

几个值得注意的要点：

1. v2ray-core 已基本停止实质性开发。最近的更新以依赖升级和小修复为主，没有新协议和新功能的推进。选择它等同于选择一个不再演进的平台。

2. Xray 和 Sing-box 在协议覆盖上高度重叠，但侧重点不同。Xray 更专注于自有协议栈的创新（Reality、XHTTP），Sing-box 更专注于跨协议兼容和路由功能。

3. 性能差异在实际使用中通常不是瓶颈。三个内核在同一协议下的吞吐量差异通常在 5-15% 以内，真正的性能瓶颈几乎总是在网络链路本身——你的线路质量、运营商的国际出口带宽、目标服务器的距离和负载，这些因素的影响远大于内核差异。

配置格式差异

三个内核都使用 JSON 作为配置文件格式，但结构完全不同。以下用”连接一个 VLESS+Reality 节点”为例，展示各自的出站（outbound）配置方式。

v2ray-core / xray-core 格式

v2ray-core 和 xray-core 共享相同的配置结构（Xray 在此基础上扩展了 Reality 等字段）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

{
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "uuid-here",
                "encryption": "none",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "www.microsoft.com",
          "fingerprint": "chrome",
          "shortId": "abcd1234",
          "publicKey": "public-key-here"
        }
      }
    }
  ]
}

配置的核心逻辑是：protocol 指定协议类型，settings 定义服务器和用户信息，streamSettings 定义传输层和安全层参数。这种嵌套结构沿用了 V2Ray 早期的设计。

sing-box 格式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

{
  "outbounds": [
    {
      "type": "vless",
      "tag": "proxy",
      "server": "example.com",
      "server_port": 443,
      "uuid": "uuid-here",
      "flow": "xtls-rprx-vision",
      "tls": {
        "enabled": true,
        "server_name": "www.microsoft.com",
        "utls": {
          "enabled": true,
          "fingerprint": "chrome"
        },
        "reality": {
          "enabled": true,
          "public_key": "public-key-here",
          "short_id": "abcd1234"
        }
      }
    }
  ]
}

Sing-box 的配置结构更加扁平化：服务器地址、端口、UUID 直接作为出站对象的顶层字段，没有 v2ray 那种 vnext > users 的多层嵌套。TLS 和 Reality 参数统一归入 tls 对象。整体可读性更好，编写出错的概率更低。

关键区别总结

• v2ray/xray：配置层级深（protocol > settings > vnext > users），传输层参数独立在 streamSettings 中，历史兼容性好但结构冗余
• sing-box：配置扁平化，字段命名使用 snake_case 而非 camelCase，TLS/传输参数整合在出站对象内部，语义更清晰

对于普通用户来说，这些差异很少需要手动处理——现代客户端通过分享链接（URI）或订阅自动生成配置。但如果你需要手写或调试配置，sing-box 的格式显然对人类更友好。

我应该选哪个

v2ray-core：已不推荐

2026 年，基本没有选择 v2ray-core 的理由。它不支持 Reality、XTLS Vision、XHTTP 等现代协议特性，维护处于半停滞状态，安全更新也不及时。唯一合理的使用场景是你正在维护一个遗留系统，且迁移成本过高。

如果你还在使用基于 v2ray-core 的部署，强烈建议迁移到 Xray 或 Sing-box。Xray 的迁移路径最简单，因为它兼容 v2ray 的配置格式。

xray-core：协议创新的前沿

选择 Xray 的理由：

• 你需要 Reality 的完整实现和最新特性（Xray 是 Reality 的原生发源地）
• 你需要 XHTTP/XMUX 传输方式来实现 CDN 中转等高级部署
• 你使用 v2rayN（Windows）、V2RayNG（Android）等以 Xray 为默认内核的客户端
• 你在服务端部署中需要最完整的协议选项
• 你已有 v2ray 格式的配置，希望无缝升级

Xray 是目前服务端部署最成熟的选择，社区经验积累最丰富，配置教程和问题排查资源最多。

sing-box：现代化的全能选手

选择 Sing-box 的理由：

• 你想要强大的路由和分流功能（按域名、IP、进程、规则集灵活分流）
• 你使用 NekoBox、Hiddify、Clash Verge Rev 等以 sing-box 为内核的客户端
• 你需要在移动端获得更好的性能和电池表现
• 你需要 Hysteria2 或 TUIC 等基于 QUIC 的协议（sing-box 原生支持，Xray 不支持）
• 你希望配置文件更易读、更现代化

一个重要提醒

大多数用户不需要直接选择内核。 你选择的是客户端，内核是客户端内置的。v2rayN 内置 Xray，NekoBox 内置 Sing-box，Clash Verge Rev 使用 Mihomo（另一个内核）——你只需要选一个好用的客户端，内核的事交给客户端开发者去处理。

只有当你需要在服务端部署代理服务、手动编写配置、或在客户端之间做深度技术对比时，理解内核差异才真正重要。

它们之间的关系图

1
2
3
4
5
6
7
8
9
10
11
12

v2ray-core (2015)
    │
    ├──fork──→ xray-core (2020)
    │            ├── VLESS 协议优化
    │            ├── XTLS Vision 性能加速
    │            ├── Reality 反检测 (2023)
    │            └── XHTTP / XMUX 传输方式
    │
    └──inspired──→ sing-box (2022)
                    ├── 全新代码库，零历史包袱
                    ├── 多协议兼容（含 Hysteria2、TUIC）
                    └── 类 Clash 规则路由系统

Xray 和 V2Ray 之间是代码级的继承关系（fork），配置格式保持兼容。Sing-box 和 V2Ray 之间是理念上的继承关系（inspired），代码和配置完全独立。

三者之间并非零和竞争。Xray 的协议创新（如 Reality）被 sing-box 跟进支持，sing-box 的路由设计也在影响其他项目的发展方向。这种良性的技术竞争推动了整个代理生态的进步。

常见问题

三者可以互相替换吗？

大部分场景下可以。如果你的服务端使用标准协议（比如 VLESS+Reality+Vision），无论客户端使用 Xray 还是 Sing-box 都能正常连接——协议是通用的，内核只是协议的不同实现。

差异出现在高级功能上：Xray 的 XHTTP/XMUX 传输方式目前只有 Xray 客户端完整支持；sing-box 的 Hysteria2/TUIC 协议 Xray 不支持。选择内核时需要确认你使用的协议和传输方式是否在目标内核的支持范围内。

哪个性能最好？

实际差异很小。Xray 的 XTLS Vision 在代理 TLS 流量时有理论优势，因为它避免了内层 TLS 数据的重复加密/解密，CPU 开销更低。但在真实使用中，网络延迟、丢包率、带宽限制通常远大于内核层面的性能差异。对绝大多数用户来说，三个内核的性能表现在体感上没有区别。

如果你的场景对 CPU 开销极度敏感（比如在低性能 ARM 设备上跑高带宽代理），XTLS Vision 的优势会更明显。

Sing-box 会取代 Xray 吗？

短期内不会，中长期两者更可能持续共存。原因是它们的定位有本质差异：

• Xray 的核心竞争力在于协议创新——Reality、XHTTP 等技术都诞生于 Xray 社区。它更像是代理协议的”研发实验室”。
• Sing-box 的核心竞争力在于平台统一性——用一个内核覆盖尽可能多的协议和平台，提供一致的配置体验和路由功能。它更像是代理协议的”集成平台”。

两者在生态位上互补而非对立。

我在用 Clash，和这三个内核是什么关系？

Clash（包括 Clash Meta / Mihomo）是一个独立的内核体系，有自己的配置格式和协议实现。它和 V2Ray/Xray/Sing-box 是平行关系，不存在继承或依赖关系。不过，Clash 也支持 VMess、VLESS、Trojan 等协议——这些协议是通用标准，任何内核都可以独立实现。

值得注意的是，原版 Clash 已经停止维护。目前活跃的 mihomo（原 Clash Meta）和 Clash Verge Rev 等项目在继续推进 Clash 生态的发展。部分 Clash 衍生客户端（如 Clash Verge Rev 的某些版本）也开始支持使用 sing-box 作为可选内核。

写在最后

V2Ray 开创了”通用代理平台”的理念，Xray 在此基础上推动了协议层面的重大突破，Sing-box 则以全新的工程实践重新诠释了这一理念。三者的关系是技术演进的自然脉络，而非简单的优劣之分。

对于普通用户，选一个好用的客户端，确保它支持你需要的协议，就足够了。内核的选择通常已经被客户端开发者做好了。

对于进阶用户和服务端运维者，理解这三个内核的差异有助于做出更合理的技术决策——比如服务端用 Xray 获得最完整的协议支持，客户端侧选择 sing-box 系客户端获得更好的路由和分流能力。

代理技术仍在快速迭代。本文反映的是 2026 年中的状态，半年后具体的功能对比可能已经发生变化。但核心逻辑不会变：理解工具的设计思路，比记住工具的功能列表更重要。

摘要: 代理节点突然连不上是最常遇到的问题。原因可能是节点被封、本地网络问题、配置错误或客户端故障。本文提供一套系统化的排查流程，帮助你快速定位问题并解决。

第一步：确认问题范围

排查之前，先花一分钟判断问题的范围，避免盲目操作浪费时间。

是所有节点还是部分节点？

• 所有节点都连不上 → 大概率是本地网络问题或客户端问题
• 只有部分节点连不上 → 这些节点可能已经被封或宕机
• 只有某个地区的节点不行（如香港全挂但日本正常）→ 该地区线路可能被针对性封锁

之前能用吗？发生了什么变化？

• 之前正常，突然不行 → 节点可能被封，或者本地网络环境变了（换了 WiFi、连了公司网络等）
• 从来没成功过 → 大概率是配置问题，从头检查配置
• 更新客户端后不行了 → 新版本可能有兼容性问题，尝试回退版本

其他用户是否受影响？

• 查看机场的 Telegram 群组或状态页面
• 如果大家都反映有问题 → 服务端问题，等待机场修复
• 如果只有你一个人有问题 → 本地问题，继续排查

第二步：检查本地网络

基础连通性测试

首先确认你的基础网络是通的（不经过代理）：

1
2
3
4
5

# 测试国内网站连通性
ping baidu.com

# 测试 DNS 解析是否正常
nslookup baidu.com

如果 ping baidu.com 都不通，说明你的基础网络就有问题，先解决本地上网问题再说。

防火墙和安全软件

防火墙和杀毒软件是导致代理客户端无法正常工作的常见原因：

• Windows Defender / 第三方杀毒软件：可能把代理客户端识别为可疑程序并拦截
• Windows 防火墙：可能阻止代理客户端监听的端口

排查方法：

1. 临时关闭防火墙和杀毒软件
2. 重新测试代理是否正常
3. 如果关闭后正常 → 将代理客户端添加到防火墙和杀毒软件的白名单/例外列表中
4. 重新开启防火墙和杀毒软件，确认白名单生效

网络环境限制

某些网络环境会主动限制代理流量：

• 公司/学校网络：通常有防火墙策略，会封锁非标准端口和协议
• 公共 WiFi：酒店、咖啡厅的 WiFi 往往限制较多
• 运营商限制：部分地区的运营商会对特定协议做 QoS 限速

排查方法：

1. 切换到手机移动数据（4G/5G）热点测试
2. 如果移动数据下正常 → 确认是当前网络环境的限制
3. 尝试切换到 443 端口的节点（443 是 HTTPS 端口，通常不会被封）
4. 尝试使用支持 UDP 的协议（如 Hysteria2），有些网络只封 TCP 不封 UDP

第三步：检查客户端

客户端是否正常运行

最基本的检查，但很多人会忽略：

• 客户端进程是否在运行？ 检查系统托盘（Windows 右下角）是否有客户端图标
• 代理模式是否开启？ 确认已开启系统代理或 TUN 模式
• 尝试重启客户端：关闭后等待几秒再重新启动

订阅是否过期或需要更新

订阅问题是最常见的原因之一：

• 订阅到期：套餐到期后节点自然无法连接，检查机场账户的到期时间
• 流量用完：月流量耗尽同样无法使用，查看剩余流量
• 订阅未更新：机场更换或新增了节点，但你的本地订阅还是旧的

操作方法：

1. 在客户端中找到订阅管理
2. 手动更新订阅（Clash Verge：右键订阅 → 更新；v2rayN：订阅 → 更新全部）
3. 如果更新失败 → 尝试在浏览器中直接打开订阅链接，看是否能访问
4. 如果订阅链接打不开 → 登录机场面板检查是否更换了订阅地址

端口冲突

代理客户端需要监听本地端口（常见的有 7890、7891、1080 等），如果端口被其他程序占用就会启动失败。

检查方法：

1
2
3
4
5

# Windows - 检查端口占用
netstat -ano | findstr 7890

# macOS / Linux - 检查端口占用
lsof -i :7890

如果发现端口被占用：

• 关闭占用端口的程序
• 或者在代理客户端的设置中更改本地监听端口

TUN 模式问题

TUN 模式创建虚拟网卡来接管系统全部流量，功能更强但也更容易出问题：

• 需要管理员权限：客户端必须以管理员身份运行（Windows：右键 → 以管理员身份运行）
• 与其他 VPN 冲突：如果同时安装了其他 VPN 软件或者有残留的虚拟网卡，可能产生冲突
• 驱动问题：TUN 驱动安装不正确或版本不匹配

排查方法：

1. 先切换到系统代理模式测试，排除 TUN 特有的问题
2. 如果系统代理模式正常 → 问题出在 TUN 模式
3. 检查是否有其他 VPN 软件在运行，关闭它们
4. 尝试重新安装 TUN 驱动（Clash Verge：设置 → Service Mode → Install）

第四步：测试节点连通性

TCPing 测试

TCPing 测试可以判断你的网络到节点服务器的 TCP 连通性：

1
2
3
4
5
6
7

# 方法一：使用客户端内置的测试功能
# Clash Verge → 代理页面 → 点击测速按钮（闪电图标）
# v2rayN → 服务器列表 → 测试真连接延迟

# 方法二：命令行测试
# 需要先安装 tcping 工具
tcping your-server-ip 443

结果判断：

• 超时（timeout） → 节点不可达，IP 可能被封或服务器宕机
• 有延迟数值返回 → 节点可达，问题可能出在其他环节
• 延迟极高（> 500ms） → 线路质量差，可能影响使用体验

切换节点测试

不要在一个节点上死磕，多试几个：

• 尝试不同地区的节点（香港、日本、新加坡、美国等）
• 如果某个地区全部不行但其他地区正常 → 该地区线路被封
• 如果所有节点全部不行 → 不太可能所有节点同时被封，重点检查本地问题

切换协议测试

如果你的机场提供多种协议的节点，切换协议是非常有效的排查手段：

• VLESS (TCP) 不行 → 尝试 Hysteria2 (UDP)
• Shadowsocks 不行 → 尝试 VLESS + WebSocket
• 某个协议不行但另一个正常 → 说明是协议层面的封锁，使用可用的协议即可

第五步：检查具体错误信息

客户端日志中的错误信息是最直接的线索。以下是常见错误及其含义：

connection refused（连接被拒绝）

• 含义：TCP 连接到达了服务器，但服务器拒绝了连接
• 可能原因：服务器未运行、端口配置错误、服务器防火墙拦截
• 处理：联系机场客服确认服务器状态；更新订阅获取最新配置

connection timeout（连接超时）

• 含义：TCP 连接请求发出后没有收到任何响应
• 可能原因：IP 被 GFW 封锁、网络路由问题、服务器下线
• 处理：切换到其他节点；切换网络环境（WiFi ↔ 移动数据）；等待机场更换 IP

TLS handshake failed（TLS 握手失败）

• 含义：TCP 连接成功但 TLS 加密握手失败
• 可能原因：系统时间不准确、TLS 证书过期、服务端 TLS 配置变更、SNI 被阻断
• 处理：
  1. 检查系统时间是否准确（TLS 握手对时间敏感，误差超过几分钟就可能失败）
  2. 更新订阅获取最新配置
  3. 如果使用了自定义 SNI，确认 SNI 域名未被封锁

authentication failed（认证失败）

• 含义：连接到服务器了，但 UUID/密码验证不通过
• 可能原因：订阅配置过期，服务端已更换密钥但你本地还是旧的
• 处理：更新订阅；如果更新后仍然失败，删除旧配置重新导入

DNS resolution failed（DNS 解析失败）

• 含义：无法解析代理服务器的域名
• 可能原因：DNS 服务器故障、DNS 被污染、域名过期
• 处理：
  1. 尝试更换 DNS 服务器（推荐 223.5.5.5 或 119.29.29.29）
  2. 如果知道服务器 IP，尝试直接用 IP 连接
  3. 清除本地 DNS 缓存：ipconfig /flushdns（Windows）

EOF 或 connection reset（连接重置）

• 含义：连接建立后被立即中断
• 可能原因：GFW 发送 RST 包主动中断连接、协议特征被识别、服务端防火墙规则
• 处理：
  1. 切换协议（从 VMess 换到 VLESS，或使用 Hysteria2 等基于 UDP 的协议）
  2. 更换端口（尝试 443、8443、2053 等）
  3. 如果可用，启用 WebSocket 或 gRPC 传输层

第六步：高级排查

如果前五步都没有解决问题，可以用以下方法做更深入的分析。

抓包分析

使用 Wireshark 抓包可以精确判断连接在哪个环节出了问题：

1. 打开 Wireshark，选择你的网络接口
2. 设置过滤器：ip.addr == 你的服务器IP
3. 尝试连接代理，观察抓包结果

判断方法：

• 只有 SYN 包，没有 SYN-ACK → IP 被完全封锁，数据包被丢弃
• SYN-ACK 正常但之后收到 RST → 存在主动探测或 DPI（深度包检测）识别
• TLS 握手阶段失败 → 可能是 SNI 被阻断或 TLS 指纹被识别
• 握手完成但数据传输中断 → 协议层面被识别，流量被中断

路由追踪

路由追踪可以帮助你了解数据包到服务器的路径，以及在哪一跳出了问题：

1
2
3
4
5
6
7
8
9

# Windows
tracert your-server-ip

# macOS / Linux
traceroute your-server-ip

# 更好的工具：BestTrace（Windows）或 nexttrace（跨平台）
# 可以显示每一跳的地理位置和 ISP 信息
nexttrace your-server-ip

结果分析：

• 如果路由在某一跳之后全部超时 → 该位置存在封锁（通常是国际出口）
• 如果路由能到达服务器但代理仍然不通 → 服务端问题
• 如果路由在本地就超时 → 本地网络或 ISP 问题

日志分析

客户端日志是最重要的排查信息来源：

图片来源：clash.info

• Clash Verge Rev：设置 → 日志等级调为 Debug → 查看实时日志
• v2rayN：主界面底部有日志窗口，或点击菜单 → 查看日志
• sing-box：检查日志文件或终端输出

图片来源：ZGC VPN

重点关注：

• 重复出现的错误信息
• 连接超时的目标地址和端口
• DNS 解析相关的错误
• TLS 和认证相关的错误

快速排查清单

按顺序逐项检查，快速定位问题：

• 本地网络正常？（能打开 baidu.com）
• 客户端正在运行？代理模式已开启？
• 订阅已更新？未过期？流量未用完？
• 防火墙/杀毒软件没有拦截客户端？
• 没有其他 VPN/代理软件冲突？
• 系统时间准确？（TLS 握手需要准确的系统时间）
• 尝试了不同节点？不同地区？
• 尝试了不同协议？（VLESS ↔ Hysteria2）
• 尝试了不同网络？（WiFi ↔ 移动数据）
• 检查了客户端日志的错误信息？
• 确认了不是服务商那边的问题？（查 Telegram 群）

常见问题

Q：所有节点突然全挂了怎么办？

先看机场 Telegram 群是否有通知。如果是敏感时期（两会、国庆、重大会议等），可能是临时加强封锁。这种情况通常持续数小时到数天会逐步恢复。如果只有你一个人出问题，重点检查本地网络和客户端配置。特别留意是否刚切换了网络环境（比如从家里到了公司）。

Q：节点有时能连有时不能？

间歇性问题通常与网络质量有关：

• 丢包：网络不稳定导致连接时断时续
• 路由波动：国际线路拥堵或路由变更
• 晚高峰拥堵：晚间 8-11 点是上网高峰期，线路质量下降

尝试以下方法：

1. 切换到有中转（IPLC/IEPL）的线路，稳定性更好
2. 不同 ISP 测试（电信、联通、移动表现可能不同）
3. 避开晚高峰时段测试，确认是否为高峰期拥堵

Q：重装客户端能解决问题吗？

有时可以，特别是在配置文件损坏、缓存异常的情况下。但操作前请注意：

1. 备份订阅链接：重装后需要重新导入
2. 备份自定义配置：自定义规则、分流配置等
3. 大多数问题不需要重装：重启客户端 + 更新订阅通常就能解决

Q：怎么判断是 GFW 封的还是服务器挂了？

可以通过以下方法判断：

Q：敏感时期如何保持连接？

• 优先使用基于 UDP 的协议（Hysteria2），TCP 封锁更常见
• 使用中转线路（IPLC/IEPL），不经过 GFW 审查
• 多备几个不同机场，鸡蛋不要放在一个篮子里
• 提前下载好备用客户端和配置文件
• 保存机场面板地址和备用域名

摘要：机场自带的规则集能满足大多数需求，但总有一些特殊情况——某个网站应该走代理但走了直连，公司内网需要直连，特定游戏需要走特定地区节点。本文教你如何在 Clash（mihomo）中自定义分流规则，覆盖三种主流方式、五个实用场景、完整的调试方法和规则语法速查表。

什么时候需要自定义规则

机场订阅里自带的规则集和社区公共规则集（如 Loyalsoldier、ACL4SSR）已经覆盖了绝大多数常见网站。但以下场景，你必须自己动手：

某个网站路由不正确。 最常见的情况。一个被墙的网站没有出现在任何公共规则集里，导致它匹配到了兜底规则走了直连，打不开。或者反过来——一个国内网站被误判为需要代理，访问变慢了。公共规则集不可能收录互联网上的每一个域名，漏掉的那个恰好就是你需要的。

公司内网或 VPN 需要绕过代理。 你在公司网络环境中使用代理，但公司内部的 GitLab、Jira、OA 系统、打印机管理页面等只能在内网访问。这些流量如果走了代理，会直接超时。你需要把公司的域名和 IP 段加入直连规则。

特定游戏需要走特定地区的节点。 你玩日服的游戏，需要流量走日本节点以获得最低延迟。或者你玩的游戏服务器在韩国，需要走首尔的节点。通用的”Proxy”策略组不够精确，你需要把游戏的域名和进程指向专门的节点组。

想屏蔽默认规则没覆盖的广告和追踪器。 公共的广告拦截规则集更新再勤快，也总有漏网之鱼。某个 App 里弹出的广告域名、某个网站上的追踪脚本，你可以自己加 REJECT 规则来屏蔽。

特定服务需要走专用节点组。 AI 服务（ChatGPT、Claude）对 IP 地区有要求，流媒体（Netflix、Disney+）需要解锁节点，Telegram 需要稳定的线路。你想让这些服务各走各的最优路径，而不是混在一起。

自定义的三种方式

方式一：在配置文件中直接添加规则

最直接的方法——打开你的 Clash 配置文件（YAML 格式），在 rules: 段中插入自定义规则。

关键原则：自定义规则必须放在通用规则和兜底规则之前。 Clash 的规则匹配是从上到下、先到先得的。如果你把自定义规则放在 MATCH,Proxy 后面，它永远不会被匹配到。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

rules:
  # ========== 自定义规则 - 放在最前面 ==========
  # 公司内网直连
  - DOMAIN-SUFFIX,company-internal.com,DIRECT
  # 特定游戏走日本节点
  - DOMAIN-SUFFIX,specific-game.com,GameNodes
  # 某个网站强制走代理
  - DOMAIN,blocked-site.example.com,Proxy
  # 屏蔽某个广告域名
  - DOMAIN-SUFFIX,annoying-tracker.com,REJECT
  
  # ========== 以下是默认规则集 ==========
  - RULE-SET,reject,REJECT
  - RULE-SET,direct,DIRECT
  - RULE-SET,proxy,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

优点：简单直观，改完保存就生效。

缺点：当你的机场订阅更新时，配置文件会被覆盖，你加的自定义规则会丢失。每次更新订阅后都需要手动重新添加。如果你只有两三条规则还能忍，规则多了就很痛苦。

适合场景：临时测试、规则数量极少（1-3 条）、不使用订阅更新的情况。

方式二：使用 Clash Verge Rev 的覆写功能（推荐）

Clash Verge Rev 提供了”覆写”（Override / Script）功能，允许你用一段 JavaScript 脚本在订阅配置加载后对其进行修改。这段脚本不会被订阅更新覆盖——它在订阅配置更新之后运行，每次都会把你的自定义规则注入进去。

操作步骤：

1. 打开 Clash Verge Rev
2. 进入”订阅”页面
3. 点击你正在使用的订阅配置右侧的编辑图标
4. 切换到”Script”（脚本）标签页
5. 输入覆写脚本

基础覆写脚本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// Clash Verge Rev 覆写脚本
function main(config) {
  // 定义自定义规则 - 这些规则会被插入到所有规则的最前面
  const customRules = [
    // 公司内网直连
    "DOMAIN-SUFFIX,company.com,DIRECT",
    "DOMAIN-SUFFIX,internal.corp,DIRECT",
    "IP-CIDR,10.0.0.0/8,DIRECT,no-resolve",
    
    // 特定网站走代理
    "DOMAIN-SUFFIX,special-site.com,Proxy",
    "DOMAIN,blocked-site.example.com,Proxy",
    
    // 游戏走特定节点组
    "PROCESS-NAME,game.exe,GameNodes",
    "DOMAIN-SUFFIX,game-server.com,GameNodes",
    
    // 屏蔽广告
    "DOMAIN-SUFFIX,ad-tracker.com,REJECT",
  ];
  
  // 将自定义规则插入到现有规则的最前面
  config.rules = [...customRules, ...config.rules];
  
  return config;
}

进阶覆写脚本——同时添加策略组和规则：

如果你的订阅配置里没有你想用的策略组（比如没有”AI-Services”组），你可以在脚本中同时创建策略组和规则：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

function main(config) {
  // ---- 1. 添加自定义策略组 ----
  // 从现有的节点中筛选出日本节点，创建一个"Gaming-JP"策略组
  const allProxies = config.proxies.map(p => p.name);
  const jpProxies = allProxies.filter(name => 
    name.includes("日本") || name.includes("JP") || name.includes("Japan")
  );
  
  if (jpProxies.length > 0) {
    config["proxy-groups"].push({
      name: "Gaming-JP",
      type: "url-test",
      proxies: jpProxies,
      url: "http://www.gstatic.com/generate_204",
      interval: 300,
    });
  }
  
  // 创建一个"AI-Services"策略组
  const usProxies = allProxies.filter(name =>
    name.includes("美国") || name.includes("US") || name.includes("United States")
  );
  
  if (usProxies.length > 0) {
    config["proxy-groups"].push({
      name: "AI-Services",
      type: "select",
      proxies: [...usProxies, "DIRECT"],
    });
  }
  
  // ---- 2. 添加自定义规则 ----
  const customRules = [
    // AI 服务走专用组
    "DOMAIN-SUFFIX,openai.com,AI-Services",
    "DOMAIN-SUFFIX,chatgpt.com,AI-Services",
    "DOMAIN-SUFFIX,anthropic.com,AI-Services",
    "DOMAIN-SUFFIX,claude.ai,AI-Services",
    
    // 游戏走日本节点
    "DOMAIN-SUFFIX,riotgames.com,Gaming-JP",
    "PROCESS-NAME,LeagueClient.exe,Gaming-JP",
  ];
  
  config.rules = [...customRules, ...config.rules];
  
  return config;
}

优点：订阅更新不会覆盖你的自定义规则。脚本逻辑灵活，可以根据现有节点动态创建策略组。一次配置，长期有效。

缺点：需要基本的 JavaScript 知识。脚本写错可能导致整个配置加载失败（但不会丢失原始配置，修改脚本即可恢复）。

适合场景：长期使用的自定义规则、需要自动创建策略组、使用订阅更新的用户。这是大多数用户的最佳选择。

方式三：创建自己的 rule-provider 文件

当你的自定义规则数量较多（几十条甚至上百条），把它们全写在脚本或配置文件里不太方便管理。这时候可以创建独立的规则文件，通过 rule-provider 机制加载。

创建规则文件：

在 Clash 配置目录下创建一个 custom 文件夹，在里面放你的规则文件。

以域名列表为例，创建 my-direct-domains.txt：

1
2
3
4
5
6
7

company.com
internal.corp
oa.mycompany.cn
gitlab.mycompany.com
jira.mycompany.com
vpn.mycompany.com
printer.office.local

以混合规则为例，创建 my-custom-rules.txt（需要使用 classical behavior）：

1
2
3
4
5
6

DOMAIN-SUFFIX,company.com
DOMAIN-SUFFIX,internal.corp
IP-CIDR,10.0.0.0/8,no-resolve
IP-CIDR,172.16.0.0/12,no-resolve
IP-CIDR,192.168.0.0/16,no-resolve
PROCESS-NAME,enterprise-vpn.exe

在配置中引用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

rule-providers:
  my-direct-domains:
    type: file
    behavior: domain
    path: ./custom/my-direct-domains.txt
    format: text

  my-custom-rules:
    type: file
    behavior: classical
    path: ./custom/my-custom-rules.txt
    format: text

rules:
  # 自定义规则集 - 放在其他 RULE-SET 前面
  - RULE-SET,my-direct-domains,DIRECT
  - RULE-SET,my-custom-rules,DIRECT
  
  # 然后是默认规则
  - RULE-SET,reject,REJECT
  - RULE-SET,google,Proxy
  # ... 其他规则
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

如果配合覆写脚本使用，可以在脚本中动态注入 rule-provider 定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

function main(config) {
  // 添加自定义 rule-provider
  if (!config["rule-providers"]) {
    config["rule-providers"] = {};
  }
  
  config["rule-providers"]["my-direct"] = {
    type: "file",
    behavior: "domain",
    path: "./custom/my-direct-domains.txt",
    format: "text",
  };
  
  // 在规则最前面引用
  config.rules.unshift("RULE-SET,my-direct,DIRECT");
  
  return config;
}

优点：规则和配置分离，便于管理大量规则。规则文件可以独立编辑，不影响主配置。如果托管到 GitHub 等平台，还可以设置自动更新。

缺点：多一层文件管理。本地文件在多设备间不能自动同步（除非托管到远程）。

适合场景：自定义规则数量较多、需要在多台设备间共享自定义规则、需要独立维护和版本管理的情况。

实用场景示例

场景一：公司内网直连

上班时开着代理，但公司内部系统必须直连，否则打不开。

1
2
3
4
5
6
7
8
9
10
11
12
13

# 公司域名直连
- DOMAIN-SUFFIX,company.com,DIRECT
- DOMAIN-SUFFIX,corp.internal,DIRECT
- DOMAIN-SUFFIX,oa.mycompany.cn,DIRECT
- DOMAIN-SUFFIX,mail.mycompany.com,DIRECT

# 公司 IP 段直连（RFC 1918 私有地址）
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

# 如果公司有专用的公网 IP 段
- IP-CIDR,203.0.113.0/24,DIRECT

注意 IP-CIDR 规则后面的 no-resolve。这个参数的作用是：当请求的目标是域名时，不要先解析 DNS 再拿 IP 去匹配这条规则。这可以避免不必要的 DNS 查询，提升匹配效率。对于只用来匹配内网 IP 段的规则，加上 no-resolve 是好习惯。

场景二：特定游戏走特定地区节点

你玩的游戏服务器在日本，需要走日本节点来降低延迟。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# 需要先在 proxy-groups 中定义 Gaming-JP 策略组
# proxy-groups:
#   - name: Gaming-JP
#     type: url-test
#     proxies: [JP-01, JP-02, JP-03]
#     url: http://www.gstatic.com/generate_204
#     interval: 300

# Steam 平台
- DOMAIN-SUFFIX,steampowered.com,Gaming
- DOMAIN-SUFFIX,steamcommunity.com,Gaming
- DOMAIN-SUFFIX,steamstatic.com,Gaming
- DOMAIN-SUFFIX,steam-chat.com,Gaming
- PROCESS-NAME,steam.exe,Gaming

# 英雄联盟日服
- DOMAIN-SUFFIX,riotgames.com,Gaming-JP
- DOMAIN-SUFFIX,leagueoflegends.com,Gaming-JP
- PROCESS-NAME,LeagueClient.exe,Gaming-JP
- PROCESS-NAME,League of Legends.exe,Gaming-JP

# 最终幻想14
- DOMAIN-SUFFIX,finalfantasyxiv.com,Gaming-JP
- DOMAIN-SUFFIX,square-enix.com,Gaming-JP
- PROCESS-NAME,ffxiv_dx11.exe,Gaming-JP

# 原神（国际服）
- DOMAIN-SUFFIX,hoyoverse.com,Gaming
- DOMAIN-SUFFIX,mihoyo.com,Gaming
- PROCESS-NAME,GenshinImpact.exe,Gaming

注意：PROCESS-NAME 规则需要在 TUN 模式下才能生效。系统代理模式无法捕获进程信息。如果你还没开启 TUN 模式，参考客户端设置中的 TUN 选项。

场景三：AI 服务走专用节点组

ChatGPT、Claude 等 AI 服务对 IP 地区有要求。有些节点的 IP 被这些服务封禁了，有些节点地区根本无法使用这些服务。把 AI 服务单独分组，方便切换到可用的节点。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# AI 服务 - 走专用策略组
# OpenAI / ChatGPT
- DOMAIN-SUFFIX,openai.com,AI-Services
- DOMAIN-SUFFIX,chatgpt.com,AI-Services
- DOMAIN-SUFFIX,oaistatic.com,AI-Services
- DOMAIN-SUFFIX,oaiusercontent.com,AI-Services
- DOMAIN-SUFFIX,ai.com,AI-Services

# Anthropic / Claude
- DOMAIN-SUFFIX,anthropic.com,AI-Services
- DOMAIN-SUFFIX,claude.ai,AI-Services

# Google AI
- DOMAIN-SUFFIX,gemini.google.com,AI-Services
- DOMAIN-SUFFIX,deepmind.google,AI-Services
- DOMAIN-SUFFIX,bard.google.com,AI-Services

# Microsoft Copilot
- DOMAIN-SUFFIX,copilot.microsoft.com,AI-Services

# Perplexity
- DOMAIN-SUFFIX,perplexity.ai,AI-Services

# Midjourney
- DOMAIN-SUFFIX,midjourney.com,AI-Services

# Suno (AI 音乐)
- DOMAIN-SUFFIX,suno.com,AI-Services

建议 AI-Services 策略组使用 select（手动选择）类型而不是 url-test（自动选最快）。原因是延迟最低的节点不一定能正常访问这些 AI 服务，手动选择可以确保切换到实际可用的节点。

场景四：强制某些网站走代理

有些网站在中国能访问，但走代理更快、功能更全，或者你需要以境外 IP 访问获得不同的内容。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# GitHub - 国内虽然能访问，但速度极不稳定，走代理更流畅
- DOMAIN-SUFFIX,github.com,Proxy
- DOMAIN-SUFFIX,githubusercontent.com,Proxy
- DOMAIN-SUFFIX,github.io,Proxy
- DOMAIN-SUFFIX,githubassets.com,Proxy

# Stack Overflow - 国内能访问但经常很慢
- DOMAIN-SUFFIX,stackoverflow.com,Proxy
- DOMAIN-SUFFIX,stackexchange.com,Proxy
- DOMAIN-SUFFIX,sstatic.net,Proxy

# Docker Hub - 镜像拉取经常超时
- DOMAIN-SUFFIX,docker.com,Proxy
- DOMAIN-SUFFIX,docker.io,Proxy

# npm 源 - 默认源在国内很慢（也可以改用国内镜像，但走代理更简单）
- DOMAIN-SUFFIX,npmjs.org,Proxy
- DOMAIN-SUFFIX,npmjs.com,Proxy

# Wikipedia - 部分地区已被墙
- DOMAIN-SUFFIX,wikipedia.org,Proxy
- DOMAIN-SUFFIX,wikimedia.org,Proxy

场景五：屏蔽特定域名

除了公共广告拦截规则之外，自己补充屏蔽名单。

1
2
3
4
5
6
7
8
9
10
11

# 屏蔽特定广告和追踪域名
- DOMAIN-SUFFIX,annoying-ads.com,REJECT
- DOMAIN-SUFFIX,user-tracker.net,REJECT

# 用关键词匹配批量屏蔽 - 注意：关键词匹配范围广，可能误伤
- DOMAIN-KEYWORD,adservice,REJECT
- DOMAIN-KEYWORD,analytics,REJECT
- DOMAIN-KEYWORD,tracking,REJECT

# 屏蔽特定 App 的联网请求（需要 TUN 模式）
- PROCESS-NAME,bloatware.exe,REJECT

警告：DOMAIN-KEYWORD 规则的匹配范围很广。DOMAIN-KEYWORD,analytics,REJECT 会屏蔽所有域名中包含”analytics”的请求，可能影响到正常网站的功能（比如某些网站用 analytics 子域名做非追踪用途）。建议优先使用 DOMAIN-SUFFIX（精确）而不是 DOMAIN-KEYWORD（模糊），只在你确定关键词不会误伤时才使用关键词规则。

调试自定义规则

规则写好了，怎么确认它生效了？怎么排查没生效的原因？

查看规则匹配结果

Clash Verge Rev：打开”连接”（Connections）标签页。这里列出了所有当前活跃的网络连接，每条连接显示以下信息：

• Host：目标域名或 IP
• Rule：匹配到的规则（比如 DOMAIN-SUFFIX,github.com）
• Chains：使用的策略组和最终节点
• Type：连接类型（TCP/UDP）

找到你想检查的连接，看”Rule”列。如果显示的规则不是你写的自定义规则，说明你的规则没有被匹配到——通常是因为位置不对（放在了其他规则后面）或者写法有误。

实际操作：在浏览器中访问目标网站，然后立即切到 Clash Verge Rev 的连接页面查看。注意一个域名可能产生多个连接（主页面、CSS、JS、图片等可能来自不同域名），需要找到对应的那条。

常见错误和排查方法

错误 1：自定义规则放在了兜底规则后面

这是最常见的错误。MATCH,Proxy 会匹配一切流量，所有放在它后面的规则都永远不会被检查。

1
2
3
4
5
6

# 错误写法
rules:
  - RULE-SET,proxy,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy               # 这条匹配一切，后面的规则永远无效
  - DOMAIN-SUFFIX,my-site.com,DIRECT  # 永远不会被匹配到

1
2
3
4
5
6

# 正确写法
rules:
  - DOMAIN-SUFFIX,my-site.com,DIRECT  # 自定义规则放最前面
  - RULE-SET,proxy,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

错误 2：域名拼写有误

规则不会做模糊匹配。DOMAIN-SUFFIX,gooogle.com,Proxy（多了一个 o）不会匹配 google.com。仔细检查域名拼写。

排查方法：在连接日志中搜索目标域名，看它实际命中了哪条规则。如果命中的是 MATCH（兜底）或其他通用规则而不是你的自定义规则，说明你的规则没有正确匹配。

错误 3：rule-provider 的 behavior 类型不对

如果你创建的规则文件内容是纯域名列表（每行一个域名），但 behavior 设成了 classical，Clash 会尝试解析每行的规则类型前缀，发现找不到，规则加载失败。

1
2
3
4
5
6

# 错误：文件内容是纯域名，但 behavior 写了 classical
my-rules:
  type: file
  behavior: classical     # 错！应该是 domain
  path: ./custom/domains.txt
  format: text

1
2
3
4
5
6

# 正确
my-rules:
  type: file
  behavior: domain        # 纯域名列表用 domain
  path: ./custom/domains.txt
  format: text

反过来，如果文件中包含 DOMAIN-SUFFIX,xxx.com 这样带前缀的规则，behavior 就必须用 classical。

错误 4：策略组名称不存在

规则指向的策略组必须在 proxy-groups 中定义过。如果你写了 DOMAIN-SUFFIX,example.com,GameNodes，但配置中没有名为”GameNodes”的策略组，Clash 会报错。

排查方法：检查 Clash Verge Rev 的日志页面，加载配置失败时通常会输出具体的错误信息。

错误 5：订阅更新覆盖了自定义规则

如果你直接在配置文件中添加规则，订阅更新会用新的配置文件替换旧的，你的修改全部丢失。

解决方案：使用方式二（覆写脚本）或方式三（独立 rule-provider 文件配合覆写脚本）。覆写脚本在订阅配置加载后运行，不受更新影响。

规则语法速查表

以下是 Clash / mihomo 支持的所有常用规则类型（完整规则文档请参阅 Clash Wiki）：

规则编写的优先级原则

组织规则的顺序直接决定分流的正确性。遵循以下优先级从上到下排列：

1
2
3
4
5
6

1. REJECT 规则（广告拦截）—— 最先处理，避免广告请求浪费带宽
2. 自定义直连规则（公司内网等）—— 确保内网流量不走代理
3. 自定义代理/特定节点规则 —— 特殊网站走指定路径
4. 公共规则集（RULE-SET）—— 覆盖常见网站
5. GEOIP,CN,DIRECT —— 兜底：中国 IP 直连
6. MATCH,Proxy —— 最终兜底：剩余流量走代理

完整实战：从零开始添加自定义规则

下面用一个完整的例子串起所有知识点。假设你的需求是：

1. 公司内网域名 *.mycompany.com 和 *.internal.corp 直连
2. GitHub 系列域名走代理（默认规则没覆盖到）
3. ChatGPT 和 Claude 走一个专门的美国节点组
4. 英雄联盟走日本节点
5. 屏蔽一个烦人的广告域名 spam-tracker.net

用覆写脚本实现（推荐方式）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

function main(config) {
  // ---------- 创建策略组 ----------
  const allProxies = config.proxies.map(p => p.name);
  
  // AI 服务策略组 - 筛选美国节点
  const usProxies = allProxies.filter(name =>
    /美国|US|United States|America/i.test(name)
  );
  if (usProxies.length > 0) {
    config["proxy-groups"].push({
      name: "AI-Services",
      type: "select",
      proxies: usProxies,
    });
  }
  
  // 游戏策略组 - 筛选日本节点
  const jpProxies = allProxies.filter(name =>
    /日本|JP|Japan|Tokyo|Osaka/i.test(name)
  );
  if (jpProxies.length > 0) {
    config["proxy-groups"].push({
      name: "Gaming-JP",
      type: "url-test",
      proxies: jpProxies,
      url: "http://www.gstatic.com/generate_204",
      interval: 300,
    });
  }
  
  // ---------- 自定义规则 ----------
  const customRules = [
    // 1. 屏蔽广告
    "DOMAIN-SUFFIX,spam-tracker.net,REJECT",
    
    // 2. 公司内网直连
    "DOMAIN-SUFFIX,mycompany.com,DIRECT",
    "DOMAIN-SUFFIX,internal.corp,DIRECT",
    "IP-CIDR,10.0.0.0/8,DIRECT,no-resolve",
    
    // 3. GitHub 走代理
    "DOMAIN-SUFFIX,github.com,Proxy",
    "DOMAIN-SUFFIX,githubusercontent.com,Proxy",
    "DOMAIN-SUFFIX,github.io,Proxy",
    "DOMAIN-SUFFIX,githubassets.com,Proxy",
    
    // 4. AI 服务走专用组
    "DOMAIN-SUFFIX,openai.com,AI-Services",
    "DOMAIN-SUFFIX,chatgpt.com,AI-Services",
    "DOMAIN-SUFFIX,anthropic.com,AI-Services",
    "DOMAIN-SUFFIX,claude.ai,AI-Services",
    
    // 5. 英雄联盟走日本节点
    "DOMAIN-SUFFIX,riotgames.com,Gaming-JP",
    "DOMAIN-SUFFIX,leagueoflegends.com,Gaming-JP",
    "PROCESS-NAME,LeagueClient.exe,Gaming-JP",
  ];
  
  config.rules = [...customRules, ...config.rules];
  
  return config;
}

保存脚本后，Clash Verge Rev 会自动重新加载配置。打开”连接”页面，访问 github.com，确认连接日志中显示的规则是 DOMAIN-SUFFIX,github.com 且走的是 Proxy 策略组。访问公司内网域名，确认走的是 DIRECT。

常见问题

自定义规则会影响性能吗？

几乎不会。Clash 的规则匹配本身就很快——几条到几十条自定义规则对性能的影响完全可以忽略。即使加上公共规则集的几千条规则，在现代设备上也不会造成可感知的延迟。

如果你的自定义规则确实达到了上百条的量级，建议整理成 rule-provider 文件，用 domain 或 ipcidr behavior 加载。这两种 behavior 会将规则加载到高效的数据结构中（哈希表或前缀树），查询速度接近 O(1)，远快于逐条线性匹配。

怎么找到某个网站对应的域名？

方法一：浏览器开发者工具。 按 F12 打开开发者工具，切换到 Network（网络）面板，然后访问目标网站。你会看到浏览器发出的所有请求及其目标域名。主域名通常就是你在地址栏看到的，但很多网站还会加载来自其他域名的资源（CDN、API 等）。

方法二：Clash 连接日志。 访问目标网站后，在 Clash Verge Rev 的”连接”页面中搜索。这里显示的是实际经过代理客户端的所有连接，比浏览器开发者工具更全面（包括非浏览器应用的流量）。

方法三：命令行工具。 在 PowerShell 或终端中使用 nslookup 或 ping 命令查看域名解析结果，确认域名是否正确。

订阅更新后自定义规则丢了怎么办？

这是最经典的”踩坑”场景。如果你是直接修改配置文件来添加规则的，每次订阅更新都会覆盖你的修改。

解决方案很明确：使用 Clash Verge Rev 的覆写（Override / Script）功能。 覆写脚本是独立于订阅配置的，订阅更新只替换配置文件本身，不会影响脚本。脚本会在每次加载配置时自动运行，把你的自定义规则注入进去。

如果你使用的客户端不支持覆写功能，替代方案是把自定义规则写成独立的 rule-provider 文件（本地文件），然后在配置中引用。订阅更新如果不覆盖 rule-providers 段和本地文件，规则就能保留。但这取决于具体客户端和订阅转换服务的行为，不如覆写脚本可靠。

可以给特定应用设置不同的代理节点吗？

可以，使用 PROCESS-NAME 规则。