摘要：ChatGPT、Claude、Gemini 等 AI 服务对访问 IP 有不同程度的限制。部分服务在中国大陆不可直接访问，部分对数据中心 IP 有封锁。本文整理主流 AI 服务的 IP 策略、可用地区和解锁方法，帮助你顺畅使用这些工具。

为什么 AI 服务需要”解锁”

如果你之前了解过流媒体解锁，会发现 AI 服务的访问限制有很多相似之处——但也有本质区别。

图片来源：Tenorshare

与流媒体解锁的异同

流媒体解锁的核心问题是版权授权的地域分割：Netflix 在不同国家拥有不同的内容库，解锁的目的是访问特定地区的内容。

AI 服务的访问限制则有所不同。它的根源主要是以下几点：

合规与法律限制：OpenAI、Anthropic 等公司在服务条款中明确列出了不支持的国家和地区。这些限制通常与出口管制法规、数据隐私法规以及公司自身的风险评估有关。中国大陆、俄罗斯、伊朗等地区被多数美国 AI 公司排除在服务范围之外。

滥用防控：AI 服务的运营成本远高于流媒体。每一次对话都在消耗 GPU 算力，而 GPU 算力是有限且昂贵的。为了防止大规模滥用——比如通过自动化脚本批量调用、利用免费额度套利——AI 服务商会主动封锁大量数据中心 IP。这个逻辑和流媒体封锁数据中心 IP 类似：正常用户不会从数据中心访问 ChatGPT。

反欺诈需求：AI 服务的免费层级（如 ChatGPT 的免费版、Claude 的免费额度）吸引了大量用户。部分用户通过不断注册新账号来突破使用限制，代理和 VPN IP 是这类行为的常见特征。封锁这些 IP 可以有效降低此类滥用。

变化频繁

与流媒体平台相比，AI 服务的 IP 策略变化更加频繁。这些公司仍处在快速发展阶段，服务条款、可用地区、IP 检测策略都在不断调整。一个月前还能正常使用的 IP 段，下个月可能就被封锁了；一个之前限制严格的服务，可能突然放宽了地区限制。

这意味着本文的具体信息有一定的时效性。文中描述的是截至更新日期的情况，实际使用中请以当时的测试结果为准。

各服务 IP 策略详解

ChatGPT (OpenAI)

ChatGPT 是目前对 IP 限制最严格的主流 AI 服务。

可用地区

OpenAI 官方公布了一份支持国家列表。截至目前，以下地区不可使用 ChatGPT：

• 中国大陆
• 中国香港（SAR）
• 俄罗斯
• 伊朗
• 朝鲜
• 叙利亚
• 其他受美国制裁的国家/地区

注意香港被明确列入不可用地区，这是很多用户踩坑的点——不要以为香港节点就能用 ChatGPT。

IP 限制策略

OpenAI 对 IP 类型的检测比大多数流媒体平台更加激进：

• 大规模封锁数据中心 IP：AWS、GCP、Azure、Vultr、DigitalOcean、BandwagonHost 等主流云服务商的 IP 段被广泛封锁。这不是逐个 IP 封锁，而是对整个 ASN 或 IP 段进行批量标记。
• 共享代理 IP 高危：被大量用户同时使用的代理出口 IP 会被检测并封锁。这就是为什么很多机场的节点能看 Netflix 但用不了 ChatGPT——太多人通过同一个 IP 访问 ChatGPT，触发了 OpenAI 的异常检测。
• IP 信誉评分机制：OpenAI 使用的 IP 检测系统会综合评估 IP 的类型、历史行为、并发访问量等多个维度。即使一个 IP 没有被明确列入黑名单，低信誉分也可能导致频繁的人机验证或直接拒绝访问。

常见报错

使用不合规 IP 访问 ChatGPT 时，你可能会遇到以下提示：

• “Access denied” 或 “You do not have access to chat.openai.com”
• 反复出现 Cloudflare 人机验证，验证通过后仍然无法访问
• 登录后被强制登出，页面显示服务在你的地区不可用
• 更严重的情况：账号被标记甚至封禁

最后一种情况虽然不常见，但确实存在。OpenAI 的条款明确禁止从不支持的地区访问服务，如果系统检测到你的账号长期从受限地区登录，理论上有权封禁账号。

网页版 vs API

这是一个关键区别：ChatGPT 网页版和 OpenAI API 的 IP 限制程度不同。

ChatGPT 网页版（chat.openai.com / chatgpt.com）的限制最严格，因为它直接面向终端用户，是滥用的重灾区。OpenAI 在网页版前面部署了 Cloudflare 的防护层，对 IP 类型和地区的检测都很严格。

OpenAI API 的限制则相对宽松。API 的计费模式是按量付费，用户已经通过信用卡验证了身份，滥用的经济动机较低。因此 API 对数据中心 IP 的封锁力度明显弱于网页版。很多在网页版被封锁的 IP，通过 API 仍然可以正常调用。

这意味着如果你的主要需求是使用 ChatGPT 的能力（而非必须使用网页界面），通过 API 接入可以绕过大部分 IP 限制。市面上有不少基于 OpenAI API 的第三方客户端，它们的可用性通常优于直接访问 ChatGPT 网页版。

推荐地区与节点类型

• 美国、日本、新加坡、台湾地区、英国的原生 IP 节点可用性最好
• 部分干净的数据中心 IP 仍然可用，但比例在持续下降
• 机场中标注”ChatGPT 可用”或”AI 解锁”的节点通常经过专门测试

付费订阅注意事项

ChatGPT Plus / Pro 订阅需要绑定支付方式。OpenAI 接受的支付方式有地区限制，中国大陆发行的信用卡通常无法使用。常见的解决方案包括使用虚拟信用卡服务（如 WildCard、Depay 等）或使用支持地区发行的实体信用卡。

Claude (Anthropic)

Claude 的 IP 限制策略目前比 ChatGPT 宽松不少，但服务的可用地区本身比较有限。

可用地区

Anthropic 在逐步扩展 Claude 的可用地区，但截至目前，claude.ai 网页版的正式可用地区仍然集中在以下区域：

• 美国
• 英国
• 部分欧洲国家
• 日本
• 澳大利亚
• 其他逐步扩展中的地区

中国大陆不在支持地区之列。但与 OpenAI 不同的是，Anthropic 对 IP 类型的检测并不算严格。

IP 限制策略

• 数据中心 IP 容忍度较高：相比 ChatGPT，Claude 对数据中心 IP 的封锁力度明显较弱。很多在 ChatGPT 上被封锁的数据中心 IP，访问 Claude 仍然正常。这可能与 Anthropic 目前的用户规模和策略侧重有关——公司仍处于扩张阶段，对用户增长的优先级高于严格的 IP 管控。
• 地区限制为主：Claude 的限制更多体现在地区层面而非 IP 类型层面。只要你的 IP 地理位置在支持的国家，不管是住宅 IP 还是数据中心 IP，大概率都能正常使用。
• 频率限制：Claude 免费版有明确的使用量限制。如果同一 IP 的使用量异常偏高，可能触发额外的限制。这种限制更多是防滥用，而非地区封锁。

网页版 vs API

Claude API 的可用范围比网页版更广。API 通过 API Key 认证和按量计费，对 IP 的限制进一步降低。在很多地区，即使 claude.ai 网页版无法直接访问，API 调用仍然正常。

和 OpenAI 类似，如果你主要需要 Claude 的能力，通过 API 接入是更稳定的方案。

推荐地区与节点类型

• 美国、英国节点的可用性最佳
• 日本节点通常也可以正常使用
• 数据中心 IP 在多数情况下可用，选择范围比 ChatGPT 宽很多

付费订阅

Claude Pro 订阅同样需要绑定国际信用卡。支持的支付方式与 OpenAI 类似，中国大陆发行的卡一般不可用，需要通过虚拟信用卡或海外卡解决。

Google Gemini

Gemini 是三大主流 AI 服务中访问限制最宽松的。

可用地区

Gemini 在大多数 Google 服务可用的国家和地区都可以访问。Google 的基础设施覆盖面极广，对 IP 管控的经验也最丰富——但这种经验被用来提供更好的服务覆盖，而非更严格的限制。

中国大陆由于 Google 服务本身被屏蔽，自然无法直接访问 Gemini。但这是 GFW 层面的封锁，而非 Google 自身的地区限制。只要你能访问 Google，基本就能使用 Gemini。

IP 限制策略

• 对 IP 类型不敏感：Gemini 对数据中心 IP 的封锁力度最低。Google 自身就是全球最大的云服务商之一（GCP），对来自数据中心的流量有更高的容忍度。
• 依赖 Google 账号体系：Gemini 的访问控制更多依赖 Google 账号本身，而非 IP 地址。只要你有一个正常的 Google 账号，从大多数 IP 都可以正常使用 Gemini。
• Gemini Advanced 可能有额外限制：付费版的 Gemini Advanced 在某些地区可能暂未上线，但这更多是产品推广节奏的问题，而非 IP 封锁。

推荐地区与节点类型

• 几乎任何能访问 Google 的节点都可以使用 Gemini
• 美国、日本、新加坡、台湾地区等节点均可
• 数据中心 IP 通常不会遇到问题

付费订阅

Gemini Advanced（Google One AI Premium）的订阅通过 Google One 平台完成。Google 的支付体系比 OpenAI 和 Anthropic 更成熟，支持的支付方式也更多。但中国大陆的支付方式仍然不被接受，需要使用外区 Google 账号配合国际支付方式。

其他 AI 服务

Midjourney

Midjourney 通过 Discord 平台提供服务（同时也有独立网页版）。Discord 本身在中国大陆被屏蔽，但只要你能访问 Discord，Midjourney 的使用基本不会遇到 IP 相关的限制。Discord 对 IP 类型不敏感，数据中心 IP 正常使用。

Microsoft Copilot / Bing AI

作为微软的产品，Copilot 在全球大部分地区可用，包括中国大陆（通过 bing.com 访问）。IP 限制极少，可能是主流 AI 服务中最容易访问的。但部分高级功能可能有地区差异。

Perplexity

Perplexity 的可访问性介于 ChatGPT 和 Gemini 之间。对数据中心 IP 有一定的限制，但远不如 ChatGPT 严格。美国、日本等地区的节点通常可以正常使用。

Suno / Udio（AI 音乐生成）

这类垂直领域的 AI 服务通常限制较少，但各自有不同的策略，需要逐个测试。一般来说，能访问 ChatGPT 的节点也能访问这些服务。

对比表

封锁力度说明：⭐ 越多表示越严格。⭐ = 几乎无限制，⭐⭐⭐⭐ = 主动封锁数据中心 IP 且限制地区。

实用建议

节点选择策略

不同 AI 服务对节点的要求不同，以下是针对性的选择建议：

ChatGPT 用户

ChatGPT 对节点质量的要求最高。优先选择以下类型的节点：

• 美国、日本原生 IP 节点：可用性最好，被封锁概率最低
• 新加坡、台湾地区节点：可用性较好，延迟对亚洲用户更友好
• 避免使用香港节点：香港在 OpenAI 的封锁名单中，使用香港 IP 访问可能导致账号被标记
• 避免使用热门共享节点：如果一个节点有几千人同时使用，该出口 IP 大概率已被 OpenAI 标记

Claude 用户

Claude 的要求相对宽松：

• 美国、英国节点是首选
• 日本节点通常可用
• 数据中心 IP 在大多数情况下不会遇到问题
• 选择范围比 ChatGPT 大很多，不需要刻意寻找原生 IP 节点

多 AI 服务用户

如果你同时使用多个 AI 服务，建议在代理客户端中创建一个专门的”AI”策略组。将所有 AI 服务的域名指向这个策略组，选择一个质量较高的节点作为默认出口。这样既保证了 AI 服务的可用性，又不会影响其他流量的路由。

代理规则配置

在 Clash（mihomo）配置中，为 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 服务分流规则
rules:
  # OpenAI / ChatGPT
  - DOMAIN-SUFFIX,openai.com,AI
  - DOMAIN-SUFFIX,chatgpt.com,AI
  - DOMAIN-SUFFIX,oaistatic.com,AI
  - DOMAIN-SUFFIX,oaiusercontent.com,AI

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

  # Google Gemini
  - DOMAIN-SUFFIX,gemini.google.com,AI
  - DOMAIN-SUFFIX,bard.google.com,AI
  - DOMAIN-SUFFIX,aistudio.google.com,AI

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

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

  # Suno
  - DOMAIN-SUFFIX,suno.com,AI

  # 通用 AI 相关
  - DOMAIN-SUFFIX,openrouter.ai,AI

如果使用 rule-provider，也可以将这些规则整理为一个独立的规则集文件，方便维护和更新。

对于 Sing-box 用户，对应的路由规则写法不同（使用 JSON 格式），但逻辑一致——将 AI 服务的域名指向专门的出站节点或策略组。

账号注册建议

AI 服务的账号注册环节同样需要注意 IP 问题：

注册时使用干净 IP

注册新账号时，尽量使用原生 IP 或干净的住宅 IP。原因是这些平台在注册阶段的 IP 检测往往比日常使用时更严格——注册是滥用者的必经之路，平台会在这个环节设置更高的门槛。

如果你使用一个被大量其他用户注册过的共享代理 IP，注册过程中可能会遇到更多的验证步骤，甚至直接被拒绝。

手机号验证

ChatGPT 和 Claude 的注册都需要手机号验证。中国大陆的手机号（+86）在这些平台通常不被接受。常见的解决方案：

• 使用海外实体手机号（如果你有的话）
• 使用接码平台获取临时海外手机号（注意选择可靠的平台，避免号码被大量复用导致注册失败）
• 使用 Google Voice 等虚拟号码服务（部分平台可能不接受虚拟号码）

支付方式

ChatGPT Plus、Claude Pro 等付费订阅需要国际支付方式。解决方案包括：

• 虚拟信用卡服务：如 WildCard 等平台提供针对 AI 服务订阅优化的虚拟卡
• 海外实体信用卡：如果你有海外银行账户
• Apple ID 余额：部分 AI 服务的 iOS 应用支持通过 App Store 订阅，可以使用外区 Apple ID 配合礼品卡充值

注册后的注意事项

• 不要频繁切换登录地区。今天从美国登录，明天从日本登录，后天从新加坡登录——这种模式在 AI 平台的安全系统看来非常可疑，可能触发安全审查甚至账号锁定
• 选定一个地区后尽量保持一致，偶尔切换问题不大，但频繁跳转风险较高
• 正常使用的情况下（不是大规模自动化调用），通过代理访问通常不会导致封号。但风险始终存在，因为它在技术上违反了这些服务的使用条款

常见坑与避坑指南

坑一：香港节点与 ChatGPT

这是最常见的坑之一。很多用户想当然地认为香港节点是访问海外服务的最佳选择——延迟低、速度快、带宽充足。但 OpenAI 明确将香港列为不支持的地区。使用香港 IP 访问 ChatGPT 不仅会被拒绝，还可能导致账号被标记。

如果你的机场默认节点是香港，务必为 ChatGPT 相关域名单独配置路由规则，将流量导向美国、日本等支持地区的节点。

坑二：Netflix 能解锁不代表 ChatGPT 能用

流媒体解锁和 AI 服务解锁使用不同的 IP 检测数据库和策略。Netflix 可能使用 MaxMind 的数据库来判断 IP 类型，而 OpenAI 可能使用另一套检测系统（包括但不限于 ipinfo.io、IPQualityScore 等）。

一个 IP 在 MaxMind 中被标记为住宅 IP（解锁 Netflix），但在 ipinfo.io 中被标记为数据中心 IP（无法使用 ChatGPT）——这种不一致完全可能发生。

所以不要用”能看 Netflix”来推断”能用 ChatGPT”，这两件事需要分别测试。

坑三：频繁切换节点

很多代理客户端支持自动切换节点（如延迟最低自动选择、负载均衡等）。对于普通上网来说这很方便，但对 AI 服务来说可能带来问题。

如果你的客户端在一次对话过程中自动切换了节点——你的 IP 地址在会话中间突然从美国变成了日本——AI 平台的安全系统可能判定这是异常行为。轻则触发重新验证，重则导致会话中断。

建议为 AI 服务使用固定节点，而不是自动切换的策略组。或者至少将自动切换的范围限制在同一国家的节点之间。

坑四：浏览器指纹

IP 地址不是 AI 平台检测的唯一维度。浏览器指纹——包括 User-Agent、屏幕分辨率、时区、语言设置、已安装的插件等——也是判断用户真实性的重要参考。

如果你的 IP 显示在美国，但浏览器的时区设置是 UTC+8（中国标准时间），语言是 zh-CN，这种不一致可能引起平台的怀疑。

建议：

• 使用无痕/隐私模式访问 AI 服务
• 或使用独立的浏览器配置文件（Profile），将语言和时区设置与节点所在地区匹配
• 避免在同一浏览器配置文件中混用不同地区的代理

坑五：免费节点的风险

免费代理节点（无论是免费机场还是公开的节点分享）在访问 AI 服务时问题尤其严重。这些节点通常被大量用户共享，出口 IP 早已被各大 AI 平台标记。不仅 ChatGPT 用不了，还可能因为节点提供者的监控导致账号信息泄露。

对于 AI 服务的访问，使用付费、有信誉的代理服务是基本要求。

长期方案

API 优先策略

如果你是 AI 工具的重度用户，强烈建议考虑 API 接入方案。

为什么 API 更稳定？

• IP 限制比网页版宽松：API 用户已经通过付费验证了身份，平台对 API 流量的 IP 管控明显更松
• 不受前端变化影响：网页版的 Cloudflare 防护、验证码机制经常变化，API 调用不受这些影响
• 可以自由选择客户端：不必依赖官方网页界面，可以使用本地客户端、终端工具、或自建前端

API 接入方式

• 直接使用 OpenAI / Anthropic / Google AI 的官方 API
• 通过 OpenRouter 等 API 聚合服务统一调用多个模型
• 使用 ChatBox、LobeChat、NextChat 等开源客户端连接 API

API 的缺点是需要按量付费，没有”包月无限使用”的选项（不像 ChatGPT Plus 月付固定金额）。但对于普通使用量的用户来说，API 的月费用通常低于 Plus 订阅费。

专门的 AI 解锁节点

越来越多的代理服务提供商意识到 AI 服务解锁的需求，开始提供专门的”AI 解锁”节点组。这些节点通常具备以下特征：

• 使用经过 AI 服务可用性测试的 IP
• 用户密度较低（减少因共享 IP 被封的风险）
• 定期检测和更换被封锁的 IP

如果你的机场提供此类节点，在代理规则中将 AI 服务域名指向这些专用节点是最省心的方案。

自建方案

如果你有技术能力并且对可控性有更高要求，自建代理节点来访问 AI 服务也是可行的：

• 选择服务商时关注 IP 质量，而非只看价格和带宽。部分小众 VPS 供应商的 IP 尚未被大规模标记
• 定期检测你的 IP 是否仍然可用。可以通过 ipinfo.io 查询 IP 类型，或直接访问 AI 服务进行测试
• 如果你的 VPS IP 被封锁，联系供应商更换 IP 或更换供应商

自建的优势在于独享 IP、没有其他用户的滥用行为影响你的 IP 信誉。劣势在于成本较高、维护需要一定的技术能力、且 IP 被封后需要自行解决。

常见问题

Q: 为什么我的节点能看 Netflix 但不能用 ChatGPT？

不同服务使用不同的 IP 检测系统和数据库。Netflix 的 IP 检测主要依赖 MaxMind 等地理位置数据库，而 OpenAI 可能使用 ipinfo.io、IPQualityScore 等更侧重于 IP 类型识别的服务。一个 IP 在不同数据库中的分类可能不一致——在 A 数据库中被标记为住宅 IP，在 B 数据库中被标记为数据中心 IP。因此，流媒体解锁能力和 AI 服务解锁能力需要分别测试，不能互相推断。

Q: 用代理访问 ChatGPT 会被封号吗？

有风险，但实际概率较低。OpenAI 的服务条款确实限制了从不支持地区的访问，从技术上说，使用代理绕过地区限制违反了条款。但在实际执行中，OpenAI 目前的主要精力集中在封锁 IP 端（阻止访问），而非封禁单个用户账号端。

在以下条件下，封号风险相对较低：

• 使用干净的 IP（非大规模共享的代理 IP）
• 不频繁切换登录地区
• 正常的个人使用（非自动化批量调用）
• 账号有正常的付费记录

但风险始终存在，这一点需要明确认知。

Q: API 和网页版的 IP 限制有什么区别？

API 的 IP 限制通常比网页版宽松得多。具体差异如下：

• OpenAI：API 不限制访问地区（只限制注册地区和支付方式），对数据中心 IP 的容忍度也比网页版高。很多网页版被封锁的 IP 通过 API 仍可正常调用
• Anthropic：Claude API 同样比 claude.ai 网页版限制更少，可用地区更广
• Google：Gemini API（通过 AI Studio 或 Vertex AI）的地区限制与网页版大致相同，因为 Google 的 API 基础设施本身就是全球化的

如果网页版遇到限制，可以优先尝试 API 接入。

Q: 有免费使用这些 AI 服务的方法吗？

三大主流 AI 服务都提供免费层级：

• ChatGPT：免费版可使用 GPT-4o mini 模型，有一定的使用频率限制
• Claude：免费版可使用 Claude Sonnet 模型，有每日使用量限制
• Gemini：免费版功能较为完整，使用限制相对宽松

核心问题不在于服务本身是否免费，而在于访问通道是否畅通。上述免费层级在支持的地区可以直接使用，关键是解决从受限地区访问的问题。

Q: 哪个 AI 服务最容易访问？

从 IP 限制的角度排序（从易到难）：

1. Gemini —— 最容易。只要能访问 Google，基本就能用 Gemini。对 IP 类型不敏感
2. Copilot —— 很容易。微软服务全球可用性好，中国大陆可直接访问部分功能
3. Claude —— 中等。地区限制有但 IP 类型检测不严格
4. Perplexity —— 中等。有一定限制但不算严格
5. ChatGPT —— 最难。地区限制 + IP 类型检测双重封锁

如果你只是想尝试 AI 工具，从 Gemini 或 Copilot 开始是最省事的选择。

Q: AI 服务的 IP 策略未来会怎么变？

难以准确预测，但可以观察到几个趋势：

• 可用地区逐步扩展：OpenAI 和 Anthropic 都在逐步开放更多地区的访问。随着这些公司的国际化战略推进，限制可能会逐步放宽
• 对数据中心 IP 的封锁可能持续收紧：随着 AI 服务用户量增长，滥用问题只会更加严重，对数据中心 IP 的封锁力度预计会持续加强
• API 可能保持相对宽松：API 的按量付费模式天然减少了滥用动机，预计 API 的 IP 限制不会大幅收紧
• 可能出现新的检测手段：除了 IP 类型检测之外，行为分析、设备指纹等更高级的检测手段可能被引入

总体而言，通过高质量的代理节点访问 AI 服务在可预见的未来仍然是可行的，但对节点质量的要求会越来越高。

摘要：你可能有过这样的体验——同样的目标网站，换一个代理节点速度天差地别。这背后的原因往往不是服务器配置的差异，而是网络路由的差异。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 不需要成为网络工程师，但掌握这些基础知识能帮助你做出更好的节点选择，并理解为什么某些线路的价格差异如此之大。

摘要：选择机场套餐时，你会看到”月流量 500G”、”倍率 0.5x”、”限速 300Mbps”、”同时在线 3 设备”等参数。这些数字直接影响你的使用体验和实际成本。本文逐一解释每个参数的含义和选择要点。

流量（Traffic / Bandwidth Quota）

什么是月流量

月流量是你每个月可以通过代理传输的数据总量，通常以 GB 或 TB 为单位。它在每个计费周期（通常是订阅日当天）重置。

需要明确的一点：月流量只计算经过代理的流量。你的直连流量（比如访问国内网站）走的是你自己的宽带，不消耗机场的配额。代理客户端的分流规则决定了哪些流量走代理、哪些直连——这也是为什么合理的分流配置不仅影响速度，还直接影响流量消耗。

大部分机场的流量计算方式是上传+下载合并计算。也就是说，你从 YouTube 下载了 1GB 的视频数据，实际消耗的流量就是 1GB 左右（上传请求的数据量很小，可以忽略）。少数机场会将上传和下载分开计算，这种情况下实际消耗会略高，但差异不大。

多少流量够用

不同使用场景下的月流量消耗差异很大。以下是实际估算值：

轻度使用（30-50 GB/月）：日常浏览网页、收发邮件、使用社交媒体（Twitter、Telegram、Instagram）。文字和图片为主的内容消耗流量很少，刷一天 Twitter 大概消耗 1-2GB。

中度使用（100-200 GB/月）：经常观看 YouTube 视频，以 1080p 为主。YouTube 1080p 视频的码率大约在 4-8 Mbps，一小时消耗约 2-4GB。每天看两小时视频，一个月就是 120-240GB。

重度使用（300-500 GB/月）：高频观看 4K 流媒体内容（Netflix、Disney+等）。4K 视频的码率约 15-25 Mbps，一小时消耗约 7-10GB。如果你是影视重度用户，这个范围是起步。

远程办公（200-400 GB/月）：全天通过代理进行远程工作，包括视频会议（Zoom/Google Meet）、代码仓库同步、云文档协作。视频会议一小时约消耗 1-2GB，加上其他工作流量，全天大约 8-15GB。

极重度使用（500GB-1TB+/月）：大量下载文件、高频使用 AI 服务（ChatGPT、Claude 等生成大量图片或长上下文对话）、做种或下载大型资源。如果你属于这个级别，通常需要 1TB 以上的套餐或不限量套餐。

注意事项

“不限量”套餐的真相。号称不限量的套餐往往附带隐性限制：可能有公平使用政策（Fair Use Policy），超过某个阈值后自动降速；可能高峰时段优先级低于限量套餐用户；也可能只是把限速设得很低，让你物理上用不了太多。购买前务必看清条款。

闲时流量不计费。部分机场会在非高峰时段（通常是凌晨到早上）不计算流量消耗。如果你有大文件需要下载，可以安排在这个时间段进行，可以省下不少配额。

流量用完后的处理。大多数机场在流量耗尽后会直接断开代理连接，或者将速度限制到极低（如 128Kbps 或 1Mbps），直到下个计费周期重置。部分机场提供额外购买流量包的选项。需要注意的是，与手机流量超额计费不同，机场通常不会产生额外费用——用完就是用完了。

倍率（Rate / Multiplier）

什么是倍率

倍率是机场对不同节点设置的流量计算系数。它改变的不是你实际传输的数据量，而是从你套餐配额中扣除的量。

具体来说：

• 1x（一倍率）：标准计费。使用 1GB 实际数据，扣除 1GB 配额。
• 0.5x（半倍率）：半价计费。使用 1GB 实际数据，只扣除 0.5GB 配额。
• 0.1x（低倍率）：近乎免费。使用 1GB 实际数据，只扣除 0.1GB 配额。
• 2x（双倍率）：加倍计费。使用 1GB 实际数据，扣除 2GB 配额。
• 3x 或更高：高倍率，通常出现在最高品质的专线节点上。

举个实际的例子：你有一个 300GB 的月套餐。如果你只使用 0.5x 倍率的节点，你实际可以传输 600GB 的数据。反过来，如果你只使用 2x 倍率的节点，你的实际可用流量只有 150GB。

为什么存在倍率

倍率本质上是机场运营者的成本管理工具。不同类型的线路成本差异巨大：

低倍率节点（0.1x-0.5x） 通常是直连线路或普通中转线路。这些线路的带宽成本低，但可能在高峰期拥堵、延迟较高、稳定性一般。机场用低倍率鼓励用户使用这些线路，分担高端线路的负载压力。

标准倍率节点（1x） 是最常见的配置，使用的是普通中转线路，品质和成本都处于中间水平。

高倍率节点（1.5x-3x+） 通常是 IPLC/IEPL 专线或优质 BGP 中转线路。IPLC 专线的带宽成本可以是普通线路的 5-10 倍，质量也确实更好——延迟低、稳定、不受国际出口拥堵影响。机场用高倍率来覆盖这些成本，同时防止所有用户都涌向这些节点。

倍率机制实现了一种经济层面的分流：对速度和稳定性要求不高的日常浏览被引导到低成本线路，而高品质线路被保留给真正需要的场景。

选择策略

日常浏览：优先选择低倍率节点。刷 Twitter、看新闻、浏览网页这类操作对延迟和速度要求不高，使用 0.1x-0.5x 的节点完全够用，还能大幅节省配额。

流媒体和远程办公：根据实际需求选择。如果低倍率节点能流畅播放 YouTube 1080p，就没必要切到高倍率节点。但如果你需要稳定的 4K 播放或者不能断线的视频会议，高倍率的专线节点值得消耗。

计算有效流量。在比较不同机场的套餐时，不要只看标称流量，要考虑倍率的影响。一个 500GB 套餐如果大部分节点是 0.5x 倍率，实际可用流量约 1TB；而另一个 800GB 套餐如果节点全是 1x 倍率，实际可用就是 800GB。前者反而更划算。

不要过度纠结倍率。如果你的套餐流量本身很充裕（比如 1TB 以上），倍率的影响就不大了。优先选择速度和稳定性最好的节点，不必为了省流量而忍受差的体验。

限速（Speed Limit）

限速的类型

限速分为多个层面，理解它们的区别很重要：

套餐限速（Plan Speed Limit）：这是你购买的套餐所允许的最大速度，适用于你通过代理传输的所有数据。不同价位的套餐通常有不同的速度上限：

• 入门套餐：50-100 Mbps
• 标准套餐：100-300 Mbps
• 高级套餐：300-1000 Mbps
• 旗舰套餐：不限速（通常标注为”Unlimited”或”不限速”）

节点限速（Node Speed Limit）：单个节点本身的带宽上限。即使你的套餐不限速，如果某个节点只有 500Mbps 的带宽上限，你在这个节点上就跑不到更高。节点限速通常不在套餐说明中体现，需要实际测试才能知道。

共享带宽 vs 独享带宽：这是一个经常被忽略的概念。

• 共享带宽：一个节点的总带宽由所有使用该节点的用户共享。如果一个节点有 1Gbps 带宽，100 个用户同时使用，平均每人只有 10Mbps。高峰期速度会明显下降。
• 独享带宽：你的速度不受其他用户影响。这种模式成本极高，通常只出现在高端套餐或自建服务器中。

绝大多数机场采用的是共享带宽模式。这意味着标称速度只是理论最大值，实际速度取决于同时在线的用户数量和他们的使用情况。

实际速度需求

很多用户高估了自己对带宽的需求。以下是各场景的实际需求：

• 网页浏览：10 Mbps 绰绰有余。网页加载速度更多取决于延迟而非带宽。
• 1080p 视频流：10-20 Mbps。YouTube 和 Netflix 的 1080p 流需要约 5-8 Mbps 的持续带宽，留一些余量就够了。
• 4K 视频流：25-50 Mbps。Netflix 4K 需要约 25 Mbps，YouTube 4K 可能更高一些。
• 游戏：5-10 Mbps 的带宽就够了，但延迟（Ping）比带宽重要得多。一个延迟 30ms 但速度只有 10Mbps 的节点，游戏体验远好于延迟 200ms 但速度 500Mbps 的节点。
• 远程办公（视频会议）：10-30 Mbps。Zoom 高清视频通话需要约 3-5 Mbps 上下行，多人会议需要更多。
• 大文件下载：越快越好，但这不是常态需求。

结论是：对大多数用户来说，100 Mbps 的套餐限速已经远超日常需求。除非你有持续的大文件下载需求或者同时进行多个高带宽活动，否则为不限速套餐额外付费通常不划算。

注意事项

标称速度不等于实际速度。机场标称的速度是理论最大值。实际速度受多种因素影响：当前使用该节点的用户数量、国际出口的拥堵程度、你本地的网络环境、目标服务器的响应速度等。高峰时段（晚上 8-11 点）速度下降是普遍现象。

ISP 带宽是天花板。你的本地宽带速度是一切的前提。如果你的家庭宽带是 100Mbps，那么花钱买 500Mbps 限速的代理套餐就是浪费——你的速度永远不会超过 100Mbps。购买代理套餐前，先用 Speedtest 测一下你的裸连速度。

测速结果仅供参考。很多用户热衷于跑测速截图，但测速和实际使用是两回事。测速时服务器负载可能较低，且测速工具会尽力拉满带宽。日常使用中的体验更取决于延迟、丢包率和稳定性，而不是峰值带宽。一个速度中等但全天稳定的节点，体验远好于时快时慢的节点。

在线设备数（Device Limit）

什么是设备限制

设备限制是指你的订阅允许同时使用代理服务的设备数量。关键词是”同时”——不是你总共可以在多少设备上安装客户端，而是同一时间有多少设备在活跃使用。

常见的设备限制从 1 到 5 台不等，取决于套餐等级。

怎么计算

基本计算方式：每个运行代理客户端并连接到节点的设备算一台。你的手机开着 Shadowrocket 连接代理、笔记本开着 Clash Verge Rev 连接代理、台式机开着 v2rayN 连接代理——这就是 3 台设备。

超出限制的后果：如果你的套餐限制 3 台设备，尝试连接第 4 台时，通常会出现以下情况之一：

• 第 4 台设备无法连接（最常见）
• 最早连接的设备被踢下线
• 所有设备的速度被平均分配（限速惩罚）

不同的计算方式：不同机场计算”设备”的方式可能不同：

• 按客户端连接数：最常见。每个建立连接的客户端算一台设备。
• 按 IP 地址：所有使用同一个公网 IP 的设备算一台。如果你的手机和电脑都在家里使用同一个 Wi-Fi，它们共享同一个公网 IP，可能只算一台设备。但这种计算方式在你切换网络（比如手机从 Wi-Fi 切到蜂窝数据）时可能出问题。
• 按活跃连接：只计算正在活跃传输数据的设备，而不是所有已连接的设备。这种方式最宽松。

选择建议

个人用户：2-3 台就够了。手机一台、电脑一台，偶尔需要平板或备用设备算一台。大部分时间你不会同时在所有设备上使用代理。

家庭用户：3-5 台。夫妻或家庭成员各有手机和电脑，需要的设备数更多。

路由器方案：突破设备限制的最佳方式。如果你把代理配置在路由器上（通过 OpenWrt + OpenClash/PassWall 等方案），所有通过这个路由器上网的设备都走代理，但机场只会看到一台设备（路由器本身）。这是在设备限制较低时服务多台设备的最有效方案。一台路由器可以覆盖全家所有设备。

注意：路由器方案虽然在设备数上有优势，但所有设备的流量都会叠加。一家人同时使用代理时，流量消耗速度会成倍增长。

其他常见参数

重置日期

月流量的重置日期通常有两种模式：

• 订阅日重置：从你购买或续费的那天起算。比如你 3 月 15 日购买，流量在每个月 15 日重置。
• 固定日期重置：不管你何时购买，统一在每月 1 号（或其他固定日期）重置。

订阅日重置更公平，固定日期重置更便于机场管理。购买前了解清楚，避免月底买了套餐却发现几天后就重置浪费了。

套餐周期

机场通常提供多种订阅周期：

• 月付：灵活，随时可以不续费。适合试用期或不确定是否长期使用的阶段。
• 季付：通常打 9 折左右。在确认机场质量后可以考虑。
• 半年付：通常打 8 折左右。适合已经使用 2-3 个月并确认满意的情况。
• 年付：通常打 6-8 折，折扣最大。但风险也最大——如果机场跑路或质量下降，损失最大。

建议的策略是：先月付使用 1-2 个月，确认速度、稳定性和客服都满意后，再考虑季付或半年付。年付需要对机场的运营稳定性有足够的信心。机场行业跑路事件并不罕见，年付要谨慎。

节点数量与地区

节点数量不是越多越好——质量远比数量重要。100 个来自同一上游供应商的转售节点，不如 20 个分布在不同地区和运营商的自建节点。

对大多数中国大陆用户而言，关键地区是：

• 香港：延迟最低（通常 30-50ms），是日常使用的首选地区
• 日本：延迟较低（50-80ms），节点选择多，流媒体解锁好
• 新加坡：稳定性好，ChatGPT 等 AI 服务友好
• 美国：延迟较高（150-200ms+），但很多服务的原生支持最好
• 台湾：延迟低，中文内容友好
• 小众地区：英国（BBC iPlayer）、韩国（韩国内容）、德国（特定需求）——按需选择

协议支持

机场支持的代理协议直接关系到安全性和抗干扰能力。在 2026 年的当下：

• 最低要求：支持 VLESS + Reality。这是目前安全性和隐蔽性最高的主流组合。
• 加分项：支持 Hysteria2（基于 QUIC 的协议，高丢包环境下表现优异）、AnyTLS（新兴的抗检测协议）。
• 警告信号：仍在使用裸 VMess（无 TLS）——这类协议的流量特征已经可以被精准识别，说明机场的技术能力堪忧。

一个实际案例

以下是一个假设的机场套餐对比。通过这个例子，你可以直观地看到各参数如何影响实际使用体验和性价比。

分析：

入门套餐（¥15/月）：100GB 流量 + 1x 倍率 = 实际可用 100GB。配合 100Mbps 限速和直连线路，适合轻度使用——日常浏览、社交媒体、偶尔看看视频。2 台设备限制对个人用户足够。缺点是直连线路在敏感时期可能不稳定。

标准套餐（¥30/月）：300GB 流量 + 0.5x-1x 倍率。如果你主要使用 0.5x 倍率的节点，有效可用流量约 600GB。300Mbps 限速对绝大多数使用场景绰绰有余。中转线路意味着更好的稳定性。3 台设备满足个人多设备需求。这是大多数用户的最佳选择——性价比最高，流量充裕，速度和稳定性都有保障。

高级套餐（¥60/月）：800GB 流量 + 0.2x-1x 倍率。如果大量使用 0.2x 节点，有效流量可达 4TB，基本等同于不限量。不限速 + IPLC 专线是最好的体验。5 台设备适合家庭使用。但价格翻倍，适合重度用户或对品质有极高要求的用户。

对大多数用户来说，标准套餐是最均衡的选择。如果你发现标准套餐的流量每个月都用不完，说明你甚至可以降级到入门套餐。

常见问题

Q: 流量用完了会怎样？

大多数机场会断开连接或限速到极低速度（如 1Mbps），直到下个周期重置。部分机场允许额外购买流量包补充当月配额。关键点是：不会像手机流量那样超额计费，你不用担心会产生意料之外的费用。如果代理突然断了而且离重置日还很远，优先检查一下是不是流量用完了。

Q: 倍率 0.1x 的节点值得用吗？

值得用，但要看场景。0.1x 倍率的节点几乎不消耗配额，非常省流量。但这些节点通常是直连线路或低优先级线路，速度和稳定性会差一些。

适合使用 0.1x 节点的场景：日常浏览网页、收发消息、查阅文档——这些对速度和延迟要求不高的轻度活动。

不适合使用 0.1x 节点的场景：看视频（可能卡顿）、视频会议（容易断线）、在线游戏（延迟高）、任何对稳定性有要求的工作。

实际操作中，可以在代理客户端中设置策略：轻度流量走低倍率节点，视频和重要应用走高品质节点。这样既省流量，又不牺牲关键场景的体验。

Q: 限速 300Mbps 和不限速差别大吗？

对大多数用户来说，没有实质性差别。日常使用中你很少能持续跑满 300Mbps，除非你在做以下事情：

• 持续下载大文件（几十 GB 级别的游戏、数据集等）
• 跑测速工具验证线路质量
• 多线程 BT/PT 下载

300Mbps 已经可以同时流畅播放多路 4K 视频，支持多个设备同时高强度使用。为”不限速”额外付费，性价比通常不高。

Q: 可以多人共享一个账号吗？

技术上可以——在设备数限制内，多人可以同时使用同一个订阅。但需要注意几点：

服务条款：大多数机场在用户协议中明确禁止账号共享。虽然技术上很难检测，但一旦被发现可能导致封号。

流量分摊：多人共享意味着流量消耗速度成倍增长。300GB 的月流量一个人用可能绰绰有余，两个人分就变紧张了。

隐私风险：共享账号意味着你的代理使用和对方的代理使用混在一起。虽然代理内容本身是加密的，但使用记录是共享的。

更好的方案：如果是家庭使用，把代理配置在路由器上（算一台设备），全家共用。如果是朋友之间，各买各的套餐更省心——很多机场有便宜的入门套餐，人均成本可能和分摊差不多。

Q: 买年付划算吗？

价格上确实划算——年付通常是月付价格的 6-8 折。但”划算”不能只看价格，还要考虑风险。

风险一：机场跑路。机场行业不受监管，运营者随时可能关停服务。年付意味着一旦跑路，你损失的是一整年的费用。

风险二：质量下降。有些机场在早期为了吸引用户提供高品质服务，用户基数增长后开始超售（卖出的带宽总量超过实际带宽），导致速度和稳定性下降。如果你是月付，可以随时走人；年付就只能忍受。

建议：先月付试用 1-2 个月，确认机场的速度、稳定性、客服响应都满意后，再考虑季付或半年付。年付只推荐给已经使用超过半年且运营稳定的机场。不要被首次年付的大幅折扣冲昏头脑。

摘要：AnyTLS 是一种针对 TLS-in-TLS 检测问题提出的代理传输方案。与 Reality 在握手阶段借用目标站证书不同，AnyTLS 的思路是与目标网站建立一条真实的 TLS 连接，然后在这条已建立的 TLS 会话中混入代理数据。两者代表了两种截然不同的抗检测哲学。本文深入解析 AnyTLS 的工作原理、技术优劣势、与 Reality 的对比，以及实际部署中的选择建议。

TLS-in-TLS 问题回顾

在讨论 AnyTLS 之前，需要先理解它试图解决的核心问题。

当代理客户端通过 TLS 隧道访问一个 HTTPS 网站时，会出现一个结构性问题：外层是客户端与代理服务器之间的 TLS 连接，内层是客户端通过代理访问目标网站时产生的 TLS 连接。这就是所谓的 TLS-in-TLS——加密隧道内部嵌套了另一层加密隧道。

问题在于，内层 TLS 握手的数据包有非常明显的长度和时序特征。GFW 的深度包检测（DPI）系统虽然无法解密外层 TLS 的内容，但可以通过分析加密数据包的长度序列来推断内部是否嵌套了另一个 TLS 会话。如果一条”普通的 HTTPS 连接”内部持续出现符合 TLS 握手模式的数据包长度分布，审查者就有理由怀疑这是一条代理连接。

现有的应对方案包括 Xray 的 xtls-rprx-vision（通过对内层握手包进行 padding 来打破长度特征）和 Reality（在握手阶段借用真实证书）。而 AnyTLS 提供了第三种思路：既然 TLS-in-TLS 的特征难以完全消除，那就直接建立一条真实的 TLS 连接，让代理数据在真实 TLS 会话的掩护下传输。

AnyTLS 是什么

AnyTLS 是由 anytls 项目开发的一种代理传输技术。它的核心目标是让代理流量与真实的 HTTPS 流量在网络层面上难以区分，但采用的方法与 Reality 截然不同。

Reality 的思路是在 TLS 握手阶段做文章——借用目标站的真实证书完成握手伪装，握手成功后再切换到代理数据传输模式。整个过程中，代理服务器实际上并没有与目标站建立持续的数据连接，证书只是”借来用一下”。

AnyTLS 的思路则是在数据传输阶段做文章——代理服务器与目标网站之间建立一条真实的、完整的 TLS 连接，然后在这条真实连接的数据流中混入代理数据。从外部观察者的角度看，这条连接不仅握手是真实的，数据传输也是真实的，因为它确实在与目标网站进行通信。

简单来说：Reality 是”借皮”，AnyTLS 是”寄生”。

核心工作原理

AnyTLS 的运作过程可以分为以下几个阶段。

第一阶段：建立真实连接

代理服务器首先与一个预配置的目标网站（如一个高流量的 HTTPS 站点）建立一条标准的 TLS 连接。这条连接是完全真实的——使用目标站的真实证书、完成完整的 TLS 握手、可以正常交换 HTTP 数据。从网络层面看，这就是一台服务器在正常访问一个网站。

第二阶段：会话复用

当代理客户端需要传输数据时，AnyTLS 将代理数据编码并嵌入到这条已建立的真实 TLS 会话中。具体的混入方式涉及到数据的分片、编码和调度，目标是让混合后的流量在统计特征上尽可能接近正常的 HTTPS 数据交换。

第三阶段：数据分离与转发

代理服务器接收到混合数据后，将代理数据与正常网站数据分离，代理数据被转发到实际的目标地址，而与目标站的正常通信则继续维持，保持连接的”真实性”。

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

sequenceDiagram
    participant C as 代理客户端
    participant S as AnyTLS 代理服务器
    participant T as 目标站(example.com)
    participant D as 实际访问目标
    participant G as GFW

    S->>T: 建立真实 TLS 连接
    T->>S: 完成 TLS 握手 + 正常数据交换
    Note over G: 看到: 正常的 HTTPS 连接 ✓

    C->>S: 发送代理请求(加密)
    S->>S: 将代理数据混入真实 TLS 会话
    S->>T: 混合数据流(外观为正常 HTTPS)
    Note over G: 看到: 持续的正常 HTTPS 数据交换 ✓

    S->>D: 分离并转发代理数据
    D->>S: 返回响应
    S->>S: 将响应混入 TLS 会话
    S->>C: 返回代理响应(加密)

与传统代理的关键区别

传统的 TLS 代理（包括使用 Reality 的方案）在握手完成后，数据传输阶段的流量内容完全是代理数据。虽然外层 TLS 加密使内容不可见，但流量的统计特征（包大小分布、时序模式、持续时间等）可能与真实的 HTTPS 流量有所不同。

AnyTLS 的不同之处在于，它维持了一条真实的 HTTPS 数据流作为”载体”，代理数据嵌入其中。这意味着即使审查者对加密流量进行统计分析，也会看到真实的 HTTPS 数据交换模式——因为确实存在真实的数据交换。

AnyTLS 与 Reality 的深度对比

AnyTLS 和 Reality 都是为了让代理流量不被 GFW 识别，但它们的技术哲学有着根本性的差异。理解这些差异，才能在实际部署中做出正确的选择。

伪装层次不同

抗检测能力对比

Reality 的检测风险：

Reality 在 TLS 握手阶段几乎无懈可击——证书是真的、指纹是真的、SNI 是真的。但握手完成后，连接进入数据传输阶段时，流量内容完全是代理数据。如果 GFW 在握手后对流量进行深度统计分析（比如比较与同一目标站正常流量的差异），理论上存在被识别的可能性。此外，长时间保持连接但几乎不与 dest 站点进行 HTTP 数据交换，这种行为模式本身也可能引起关注。

AnyTLS 的检测风险：

AnyTLS 的优势在于数据传输阶段的流量中混合了真实的 HTTPS 数据。审查者在分析加密流量的统计特征时，会看到真实的数据交换模式。但它也有自身的风险：如果代理数据量远大于正常网站数据量，混合后的流量在数据量上可能与该目标站的典型访问模式不符。

设计哲学的差异

可以用一个比喻来理解两者的区别：

• Reality 像是拿着别人的身份证进入一栋大楼。门卫（GFW）检查身份证时发现是真的，于是放行。但进入大楼后，你的行为与身份证上的身份无关。如果有人跟踪你在大楼内的活动，可能会发现异常。

• AnyTLS 像是和一个有合法身份的人一起进入大楼，并且一直跟着这个人活动。门卫看到的是两个人正常出入，跟踪者看到的也是正常的访客行为。但维持这种”同行”关系需要额外的协调成本。

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

flowchart TB
    subgraph Reality["Reality 的伪装策略"]
        R1[借用目标站 TLS 证书] --> R2[完成握手伪装]
        R2 --> R3[切换到代理模式]
        R3 --> R4[纯代理数据传输]
        style R4 fill:#fff3cd
    end

    subgraph AnyTLS["AnyTLS 的伪装策略"]
        A1[与目标站建立真实连接] --> A2[维持真实 TLS 会话]
        A2 --> A3[代理数据混入会话]
        A3 --> A4[真实数据 + 代理数据混合传输]
        style A4 fill:#d4edda
    end

优势分析

真实的 TLS 连接

AnyTLS 最大的优势是连接的真实性。与目标站的 TLS 连接从始至终都是真实的——真实的证书、真实的数据交换、真实的会话维持。这意味着任何试图验证连接真实性的检测手段（包括主动探测）都会得到”这是一条正常连接”的结论。

更强的抗统计分析能力

由于数据传输阶段存在真实的 HTTPS 数据流，加密流量的统计特征（包大小分布、传输间隔等）更接近正常的网站访问。对于依赖流量统计特征进行检测的 DPI 系统来说，这种混合流量更难被识别。

无 TLS-in-TLS 特征

传统的 TLS 代理在加密隧道内传输的数据可能包含内层 TLS 握手的特征性包长度序列。AnyTLS 由于复用了真实的 TLS 会话，代理数据被融入到真实的 HTTPS 数据流中，内层 TLS 握手的特征被有效稀释。

劣势与局限

需要目标站配合

AnyTLS 要求代理服务器能够与目标站建立并维持稳定的 TLS 连接。这意味着目标站必须始终可达，且不能对来自代理服务器的连接进行限制（如频率限制、IP 封锁等）。如果目标站的服务出现波动，代理连接也会受到直接影响。

与 Reality 只需在握手阶段获取一次证书不同，AnyTLS 需要持续维护与目标站的连接，对目标站的可用性有着更强的依赖。

性能开销

维护与目标站的真实连接意味着额外的网络开销。每一次代理数据传输都需要同时处理与目标站的数据交换，数据的混入和分离也需要额外的计算资源。在高并发场景下，这种开销可能会变得显著。

相比之下，Reality 在握手完成后就不再与 dest 站点通信，数据传输阶段的开销与普通 TLS 代理几乎一致。

部署复杂度

AnyTLS 的配置比 Reality 更复杂。除了基本的代理参数外，还需要配置和维护与目标站的连接参数、数据混入策略等。目标站的选择也更加讲究——不仅要满足 TLS 版本和证书要求，还要考虑数据交换模式是否适合混入代理数据。

成熟度与生态

作为一个相对较新的项目，AnyTLS 的生态系统远不如 Reality 成熟。Reality 已经集成在 Xray-core 中，被大量面板和管理工具支持，社区经验丰富，故障排查资料也相对充足。AnyTLS 在这些方面还处于早期阶段，遇到问题时可参考的资源有限。

客户端支持

目前 AnyTLS 的客户端支持情况如下：

需要注意的是，AnyTLS 的客户端支持范围远小于 Reality。如果你使用的客户端不支持 AnyTLS，那么 Reality 仍然是更务实的选择。

AnyTLS 与 Reality：如何选择

这两种方案并不是简单的”谁更好”的关系，而是适用于不同场景和需求。

推荐使用 Reality 的场景

• 多数用户的默认选择：如果你没有特殊的抗检测需求，Reality 已经足够安全，且部署运维成本远低于 AnyTLS。
• 需要广泛客户端兼容的场景：Reality 被几乎所有主流客户端支持，不用担心兼容性问题。
• 追求稳定性和性能的场景：Reality 在握手后不依赖目标站，数据传输阶段的稳定性和性能与普通 TLS 代理一致。
• 运维资源有限的场景：Reality 的配置和维护相对简单，社区经验丰富，遇到问题容易找到解决方案。

可以考虑 AnyTLS 的场景

• 对抗高强度流量分析：如果你的网络环境中 DPI 系统已经开始对 TLS 代理的数据传输阶段进行统计分析，AnyTLS 的混合流量策略可能提供额外的保护。
• 技术探索和研究：如果你对代理技术的前沿发展感兴趣，AnyTLS 代表了一种值得关注的新方向。
• 愿意承担额外运维成本：部署 AnyTLS 需要更多的配置工作和持续维护，确保你有足够的技术能力和时间。

决策参考

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

flowchart TD
    Start([选择传输方案]) --> Q1{是否需要对抗<br/>数据传输阶段的统计分析?}
    Q1 -->|否| Q2{客户端是否支持 AnyTLS?}
    Q1 -->|是| Q3{是否有足够的<br/>技术能力和运维资源?}
    Q2 -->|否| Reality[推荐 Reality]
    Q2 -->|是| Q4{是否愿意承担<br/>额外的性能开销?}
    Q3 -->|否| Reality
    Q3 -->|是| Q4
    Q4 -->|否| Reality
    Q4 -->|是| AnyTLS[可以尝试 AnyTLS]

    style Reality fill:#d4edda,stroke:#28a745
    style AnyTLS fill:#cce5ff,stroke:#007bff

常见问题

Q: AnyTLS 是否已经经过实战验证？

AnyTLS 作为一个相对较新的项目，其实战经验远不如 Reality 丰富。Reality 自发布以来已经经历了多轮 GFW 升级的考验，社区积累了大量的部署和调优经验。AnyTLS 的长期抗检测表现还需要时间和更多用户的实际使用来验证。在生产环境中，建议将 AnyTLS 作为备选方案而非唯一方案。

Q: AnyTLS 能和 VLESS 搭配使用吗？

AnyTLS 是一种传输层技术，理论上可以与不同的代理协议搭配。但具体的协议兼容性取决于实现方式和客户端支持。目前在 sing-box 中的集成是最为成熟的实现。关于具体的协议搭配方式，建议参考 AnyTLS 项目的官方文档。

Q: 目标站被封了怎么办？

与 Reality 类似，当 AnyTLS 使用的目标站被封锁或不可达时，代理连接也会受到影响。但 AnyTLS 对目标站的依赖更强——Reality 只在握手阶段需要目标站，而 AnyTLS 在整个连接生命周期内都需要维持与目标站的通信。因此，AnyTLS 需要更加仔细地选择目标站，建议选择极不可能被封锁的大型站点，并且准备多个备选目标站。

Q: AnyTLS 和 NaiveProxy 有什么区别？

两者都追求更高程度的流量真实性，但实现路径不同。NaiveProxy 使用 Chromium 的网络栈来生成流量，从协议栈层面确保流量特征与真实浏览器一致。AnyTLS 则通过在真实 TLS 连接中混入代理数据来实现伪装。NaiveProxy 的方案更”彻底”但部署更复杂（需要编译 Chromium 组件），AnyTLS 的方案相对轻量但在流量混合的精细度上面临更多挑战。

相关链接

• AnyTLS GitHub - AnyTLS 项目仓库
• sing-box - 支持 AnyTLS 的代理客户端
• Xray-core - VLESS + Reality 的主要实现
• REALITY - Reality 协议项目

摘要：每一个公网 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 规则。

1
2
3
4
5
6
7
8

# 微信走直连
- PROCESS-NAME,WeChat.exe,DIRECT
# Chrome 浏览器走代理
- PROCESS-NAME,chrome.exe,Proxy
# Telegram 走专用节点组
- PROCESS-NAME,Telegram.exe,Telegram
# Steam 走游戏节点
- PROCESS-NAME,steam.exe,Gaming