Clash 从零到精通：安装、订阅与规则分流完整手册

本手册按学习顺序组织，前一章是后一章的前提：先弄清内核与客户端的分工，才能理解后面每个设置项归谁管；先把订阅导进来，规则和 TUN 才有东西可调度。建议第一次阅读按顺序走一遍，之后把它当查阅手册，遇到具体问题时从上方目录直接跳到对应章节。文中所有配置片段都可以复制到 config.yaml 的对应段落里，示例中的服务器地址、密码、订阅链接均为占位值，实际使用时由订阅或自己的服务端提供。

核心概念：Clash、内核与客户端的关系

Clash 这个词在不同语境下指三样东西：一套规则化代理的配置规范、实现这套规范的内核程序、以及在它之上加了图形界面的客户端。初学者最容易卡住的地方，是把「下载一个 Clash」理解成下载一个软件——实际上，日常点开的是 GUI 客户端，真正建立连接、解析域名、按规则转发数据的是内核。理解这两层分工，后面所有配置项放在哪里、为什么有的设置改了要重启内核，都会顺理成章。

内核：真正处理流量的那一层

内核是一个没有界面的命令行程序。它启动时读取一份 YAML 配置文件，然后做四件事：监听本地端口接收应用发来的连接、把配置里的节点信息组织成可用的出站、按 rules 段逐条决定每条连接走哪个出站、把决策过程写进日志。

mihomo（原名 Clash Meta）是目前社区维护的主线内核，原版 Clash 内核已停止维护，新发布的客户端基本都基于 mihomo。内核本身不管订阅：它不会主动去下载配置，也不会自动更新——它只认启动时读到的那个文件。配置文件变了，需要重新加载或重启内核才会生效。

GUI 客户端：配置管理与交互外壳

GUI 客户端负责内核之外的所有事情：把订阅链接下载成 config.yaml、提供开关切换模式和节点、把内核日志渲染成可读面板、在系统托盘或通知栏常驻、在开机时拉起内核。不同客户端对同一份配置的呈现方式不同，但最终都是把文件交给内核执行。

这件事有一个很实用的推论：换客户端时，订阅链接通常可以直接沿用，需要重新适配的只是客户端自己那部分设置——端口号、TUN 开关、规则覆写的位置。节点定义不在客户端里，换外壳不用重建节点。

一份配置文件的三层结构

一份典型的 config.yaml 分三段：基础设置（端口、模式、日志等级、DNS）、出站定义（proxies 与 proxy-groups）、分流规则（rules）。三段的先后顺序在文件里可以调整，但逻辑关系是固定的：先定义有哪些节点和出口组，再决定什么流量走哪个出口。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: "node-a"
    type: ss
    server: 203.0.113.10
    port: 8443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "PROXY"
    type: select
    proxies: ["node-a", "DIRECT"]

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

示例里的 203.0.113.10 是文档保留地址，实际配置中 server 与 password 由订阅提供，不需要手写。这一段已经是一个最小可运行骨架：本地 7890 端口接收连接，规则模式，一个手动选择组，三条规则自上而下匹配。

本手册与快速上手教程的分工

快速上手教程是三步主线：导入订阅、选择模式、验证连通，目标是尽快跑起来。本页是系统查阅手册：同样是九个阶段，但每个阶段展开原理、参数含义、边界情况和排错分支。建议第一次安装时先跟着教程页走完主线，遇到「为什么这样设置」的问题再回到本页对应章节。

选客户端：按平台与维护状态筛选

三条判断标准

第一看内核。客户端是否基于 mihomo 或兼容 Clash 配置语法，决定了它能解析哪些字段。基于原版 Clash 内核的客户端无法跟进新的协议与规则类型，订阅里出现不认识的字段时会直接报错或静默忽略，表现为「订阅更新成功了但节点少了一半」。

第二看维护状态。客户端的更新频率决定了它对系统新版本的适配速度。已停止维护的客户端仍然能运行，但系统更新或内核新特性出现时不会再有修复，遇到问题只能自己解决。

第三看功能覆盖。三个差异最大的点：是否支持 TUN 模式、是否支持多份配置快速切换、是否支持规则覆写与合并。只做浏览器代理的用户对第一项无感，而需要代理游戏或 UWP 应用的用户必须确认第一项。

桌面端：Windows 与 macOS

Windows 上，Clash Plus 是当前的首推选择，安装包覆盖 x64 与 ARM64 两种架构；Clash Verge Rev 与 FlClash 提供相近的配置管理能力，界面组织方式不同；Clash Nyanpasu 的界面更简洁，适合只需要基本功能的用户。Clash for Windows 已停止维护，仅在旧环境兼容或历史配置迁移时作为归档选项。

macOS 上同样是 Clash Plus 首推，Clash Verge Rev 与 FlClash 作为备选。ClashX Meta 已停止维护，从它迁移过来的用户注意配置差异：策略组命名、DNS 段结构在新内核里更严格，旧配置里的简写字段可能不被识别。

移动端：Android 与 iOS

Android 生态里，Clash Plus、Clash Meta for Android、FlClash 都支持 TUN 与分应用代理——分应用代理决定哪些应用走代理、哪些直连，在手机上比桌面端更实用。Surfboard 使用另一套配置格式，导入订阅前要确认订阅是否提供对应格式的输出。

iOS 上客户端受系统限制，只能通过 App Store 安装。Clash Plus 在 App Store 提供，官网地址是 clashplus.io，配置导入方式与其他 iOS 代理工具类似，走系统 VPN 配置描述文件。

Linux 与服务器场景

Linux 桌面发行版可以用 Clash Verge Rev 或 FlClash，deb、rpm 包都有。服务器与路由器上没有图形界面，直接使用 mihomo 内核：下载对应架构的压缩包，解压后以命令行启动，配合 systemd 单元或进程守护脚本常驻。这条路径的好处是资源占用最低，代价是所有配置都要手写。

完整的横向对比与选型建议在选型指南；所有安装包按平台归类在下载页，平台入口直达对应区块。选型阶段不必纠结太久：同一份订阅在多数客户端之间可以通用，先装一个用起来，再按实际缺的功能调整。

安装：系统要求、权限与首次启动

安装前确认三件事

系统版本。Windows 10 1809 及以上，低于这个版本只能用系统代理模式，虚拟网卡驱动与部分系统接口不可用。macOS 需要较新的系统版本以支持网络扩展机制，旧系统上 TUN 无法授权。Android 需要允许安装来自浏览器或文件管理器的应用，部分 ROM 会在安装时二次确认。Linux 发行版需要满足客户端的 glibc 版本要求，太老的发行版建议直接用内核命令行方案。

权限。TUN 模式需要管理员（Windows）或 root、网络扩展授权（macOS、Linux）。只使用系统代理模式时普通权限即可。安装阶段可以先不开启 TUN，等配置导入完成后再开，避免两个变量同时变化。

网络环境。首次启动可能需要下载规则集或 GEOIP 数据库，网络不通时客户端会停在初始化状态。如果所在网络访问受限，先确认客户端自带的初始化请求是否被拦截，再决定是否改用离线配置。

Windows 安装顺序

• 从下载页的 Windows 区块选择对应架构的安装包：普通 PC 选 x64，ARM 设备选 ARM64，装错架构会直接提示不兼容。
• 运行安装程序，安装目录保持默认即可。
• 首次启动时如果弹出管理员权限请求，允许——这是为 TUN 模式准备虚拟网卡驱动。
• 启动后确认托盘图标出现，右键菜单里应能看到模式切换、配置管理和退出三项。
• 如果安装后无法启动：先看系统是否拦截了未签名的驱动安装，再看杀毒软件是否把主程序隔离，最后检查是否有旧版本残留的服务进程占用端口。

macOS 与 Linux

macOS 下载 dmg 后拖入应用程序目录。首次打开如果被 Gatekeeper 拦下，到「系统设置 → 隐私与安全性」里选择仍要打开。启用 TUN 时系统会要求授权网络扩展，这一步必须允许，否则 TUN 无法接管流量；授权后如果仍然不生效，重启一次客户端让扩展重新加载。

Linux 桌面发行版优先用 deb 或 rpm 包，安装后从应用菜单启动。部分客户端采用「界面 + 服务」分离的架构：内核以服务身份运行，界面通过本地接口控制它，这样界面不需要 root 权限。按安装提示装好服务组件即可。服务器场景不装 GUI，下载 mihomo 内核压缩包，解压后直接用 -d 指定配置目录、-f 指定配置文件启动。

移动端安装

Android 安装 APK 后首次启动会请求 VPN 权限，这个权限是 TUN 模式的基础，拒绝后只能手动配置系统代理，而移动端手动配置系统代理的体验很差。iOS 从 App Store 安装后，首次连接会引导添加 VPN 配置描述文件，按提示在系统设置里允许，之后回到客户端内导入订阅。

首次安装的常见坑（权限、端口、系统代理三类）整理在博客《Clash 首次安装与初始设置》里，安装完成后可以对照检查一遍。

订阅导入：链接、托管配置与本地文件

订阅链接的本质

订阅就是一个 URL：客户端请求它，返回一份 YAML 配置或一段编码后的节点列表。Clash 系客户端需要 Clash 格式（YAML），如果服务方给的是通用格式，需要先转换或选择支持该格式的订阅输出。链接通常带一个查询参数作为身份标识，所以链接本身就是凭据，不要公开分享，也不要在截图里暴露完整参数。

导入的操作顺序

• 完整复制订阅链接，包括问号后面的全部参数。
• 打开客户端的配置或订阅页面，新建一个配置项。不同客户端把这个入口叫 Profiles、订阅、配置或节点，位置一般在侧边栏第一项。
• 粘贴链接并命名——名字只影响本地显示，不影响连接。
• 点击下载或更新，等待配置拉取完成。这一步会同时拉取节点列表和规则，网络不佳时可能要多试一次。
• 选中这份配置，让内核加载它。
• 回到代理页面，确认节点列表已经出现，随便选一个节点。

托管配置与本地修改的冲突

远程订阅每次更新都会整份覆盖本地文件，所以直接修改订阅下载下来的 config.yaml，会在下次更新时丢失。这是新手最常见的挫败点：花了半小时写的规则，一夜之间没了。三种应对方式：

• 用客户端自带的覆写或合并功能。把自定义规则写进单独的覆写文件，更新订阅时自动合并进去，原始订阅保持不动。
• 本地配置。把订阅内容另存为本地文件，之后手动维护。好处是完全可控，代价是节点列表不会自动更新。
• 自建托管。自己维护一份完整配置，把订阅里的节点段通过 proxy-providers 引入，规则与策略组全部自己写。

proxy-providers:
  provider-a:
    type: http
    url: "https://example.com/subscribe?token=xxxx"
    interval: 86400
    path: ./providers/provider-a.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

interval 单位是秒，86400 表示一天更新一次；health-check 决定节点延迟测试的目标地址与频率。用 provider 引入节点后，proxy-groups 里用 use: ["provider-a"] 引用，而不是逐个列出节点名——订阅更新后节点变化，策略组不需要改。

更新失败怎么处理

先看客户端日志里请求订阅的返回码：401 或 403 多半是链接失效、参数被改或服务方限制了当前 IP；请求超时是本地到订阅服务器这一段不通；返回内容解析失败说明拿到的不是 Clash 格式，可能服务方按客户端类型返回了不同格式。更新后如果只有部分节点变化，属于正常现象——服务方调整节点是常态，不需要处理。

多设备之间怎么让配置保持一致，见博客《Clash 多设备配置同步》，三种方案的适用场景与维护成本对比写在那篇里。

代理模式：规则、全局、直连与系统代理

三种模式的分工

规则模式（rule）按 rules 段逐条匹配，命中哪条走哪条，日常使用默认这个。全局模式（global）让所有流量都走当前选中的节点，忽略规则——它的价值是排查：怀疑规则写错时切到全局，如果连接正常，问题就在规则里。直连模式（direct）全部不走代理，用来排除客户端本身的影响：直连也不通，说明问题不在代理链路。

三种模式在配置文件里由 mode 字段决定，也可以在客户端界面临时切换，重启后以配置文件为准。

系统代理与 TUN 的区别

系统代理是客户端修改操作系统的代理设置（Windows 的 Internet 选项、macOS 的网络偏好设置），只对遵守系统代理的程序生效。浏览器和大部分命令行工具遵守；部分游戏、UWP 应用、以及自己实现网络栈的软件不受影响，流量会直接出去。

TUN 模式创建一个虚拟网卡，把系统路由表的默认路由指过去，所有 IP 层流量都会被内核接管，不受应用是否遵守系统代理的限制。代价是需要管理员权限，并且与部分 VPN、虚拟机网络存在路由冲突。

两者的另一处差别是 DNS：系统代理模式下，应用的 DNS 查询由系统处理；TUN 模式下 DNS 也由内核接管，这样才能配合 Fake-IP 做基于域名的规则匹配，第 7 章会展开。

端口与控制接口

mixed-port 同时提供 HTTP 与 SOCKS5 两种协议，是当前推荐的单一入口；老配置里可能分成 port（HTTP）与 socks-port（SOCKS5）两个字段。external-controller 是控制接口，面板通过它读取连接列表与日志。默认只监听 127.0.0.1，只有本机能访问；需要局域网内其他设备访问面板时，改监听地址为 0.0.0.0 并设置 secret，否则等于把控制接口开放给整个局域网。

mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090
secret: "your-password"
mode: rule
log-level: info

allow-lan 控制是否允许局域网设备通过本机代理上网，与 external-controller 是两件事：前者开的是代理端口，后者开的是控制接口。

选择顺序的建议

先用系统代理加规则模式跑通，确认节点可用、浏览器能正常访问；遇到程序不生效再开 TUN。不要一上来就开 TUN：出问题时需要同时判断节点、DNS、虚拟网卡、路由表四个因素，排查成本高很多。节点连不上时的七个排查环节写在博客《Clash 节点超时无法连接》里。

规则分流：rules 语法、策略组与优先级

匹配机制：自上而下，命中即停

内核从 rules 数组的第一条开始逐条比对，第一条命中的规则决定这条连接的去向，后面的规则不再参与。所以数组顺序就是优先级：范围最窄、最明确的规则放前面，宽泛的兜底放最后。MATCH 必须放在最后一条，写在前面会让它后面所有规则失效——这是规则写错里后果最严重的一种。

常用规则类型

• DOMAIN：精确匹配域名，只命中写出来的那一个。
• DOMAIN-SUFFIX：匹配域名后缀，example.com 同时命中 a.example.com 和 b.example.com。
• DOMAIN-KEYWORD：域名包含关键字即命中，范围宽，容易误伤，慎用。
• IP-CIDR：匹配目标 IP 段。纯 IP 规则需要先拿到 DNS 解析结果才能判断，加 no-resolve 可以避免为了匹配规则而多做一次解析。
• GEOIP：按 IP 归属地匹配，常用来把国内地址直连，通常放在域名规则之后。
• PROCESS-NAME：按发起连接的程序名匹配，桌面端可用，移动端一般不支持。
• RULE-SET：引用外部规则集文件，把成百上千条规则放进独立文件维护。
• MATCH：兜底规则，匹配所有剩余连接，必须最后一条。

策略组：规则指向的出口

proxy-groups 定义规则可以指向的出口组，组里既可以放节点，也可以放其他组。四种常用类型：select 手动选择，界面上点哪个用哪个；url-test 定期对组内节点测速，自动选延迟最低的；fallback 按顺序取第一个可用的节点；load-balance 在多个节点间分摊连接。

组可以嵌套。常见的三层结构是「手动选择组 → 自动测速组 → 具体节点」：日常用自动测速组，需要指定时在手动组里切换。

proxy-groups:
  - name: "PROXY"
    type: select
    proxies: ["AUTO", "DIRECT"]
  - name: "AUTO"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies: ["node-a", "node-b"]

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-KEYWORD,analytics,DIRECT
  - IP-CIDR,203.0.113.0/24,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

tolerance 是切换阈值（毫秒）：新节点延迟比当前节点低超过这个值才切换，避免两个节点延迟接近时反复横跳。interval 是测速间隔（秒），设得太短会让低性能设备持续跑测速请求。

常见写错方式

• MATCH 写在中间：后面所有规则变成死代码。
• GEOIP 放在具体域名规则之前：本该走代理的域名被判成国内地址直连。
• IP-CIDR 不带 no-resolve：每条连接先做一次 DNS 解析，延迟上升。
• 规则指向不存在的策略组名：内核报错或连接被拒，日志里能看到明确提示。
• 类型名大小写混用：domain-suffix 不会被识别，类型名必须大写。
• 规则集文件路径写错：启动时静默跳过，表现为该规则集覆盖的域名全部走兜底。

逐条拆解与更多写法示例见博客《Clash 自定义规则语法与优先级》。

TUN 模式：虚拟网卡、DNS 与 Fake-IP

TUN 做了什么

开启后，内核创建一个虚拟网卡（Windows 上是 Wintun，macOS 与 Linux 上是 utun 或 tun），并把系统默认路由指向它。应用发出的数据包先到虚拟网卡，内核读出来按规则处理，再决定直连还是走代理。因为工作在 IP 层，不依赖应用是否遵守系统代理设置，所以游戏、UWP 应用、自己实现网络栈的软件都能被接管。

代价也来自同一层：路由表被改写，与 VPN、虚拟机、多网卡环境都可能冲突。

关键配置项

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack 决定用户态协议栈的实现：system 性能好但兼容性一般，gvisor 兼容性好但吞吐略低，mixed 让内核按场景自行选择。auto-route 让内核自动写路由表；auto-detect-interface 自动识别物理出口网卡——这两项在多网卡机器上尤其重要，关掉后容易出现回程流量走错网卡，表现为能连上但速度极慢或频繁断流。dns-hijack 把发往 53 端口的 DNS 查询劫持给内核处理，这是 TUN 模式下 DNS 不泄漏的前提。

DNS 与 Fake-IP

TUN 模式下 DNS 必须交给内核处理，否则应用自己解析出真实 IP，规则里的域名匹配就失效了。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.pool.ntp.org"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

Fake-IP 的工作方式：内核收到 DNS 查询后立刻返回一个 198.18.x.x 段的假地址，同时记下这个假地址对应哪个域名。应用连到这个假地址时，内核从映射表里取出域名，用域名去匹配规则。好处有两个：规则匹配始终基于域名，即使应用先解析后连接；省掉一次真实解析的等待，首次连接更快。

fake-ip-filter 里的域名不走 Fake-IP，返回真实地址。局域网设备名、NTP 时间服务器、部分需要真实 IP 的局域网服务必须放进去，否则会出现网页能开、局域网设备连不上这类奇怪现象。nameserver 填本地可达的 DNS 服务器，不要填已经被代理的地址，否则解析请求会绕一圈回到自己，形成环路。

常见问题

• 开启后完全无法上网：先看日志里虚拟网卡是否创建成功，再看 auto-detect-interface 是否正确识别了物理网卡，最后检查是否有其他 VPN 在抢占路由。
• 部分应用异常：把它们加入 fake-ip-filter，或在规则里指定直连。
• Windows 上 UWP 应用不生效：UWP 应用运行在应用容器里，需要为它启用回环豁免，客户端一般提供对应开关。
• 与虚拟机冲突：虚拟机的虚拟网卡会被 TUN 的路由规则影响，需要把虚拟网卡加入排除列表，或分时使用。

节点超时的完整排查顺序见博客《Clash 节点超时无法连接》。

日常维护：更新、日志与多设备同步

订阅更新

更新频率取决于服务方的节点变动频率，一天一次是常见设置。更新后客户端会重新加载配置，正在进行的连接会短暂中断。如果发现节点列表长时间不变，先手动触发一次更新，再看日志里的返回内容；更新成功但节点没变，说明服务方确实没调整。

日志与连接面板

log-level 从 silent、error、warning、info 到 debug 逐级变详细。排查问题时临时调到 debug，看内核在连接建立时的实际决策——哪条规则命中、走了哪个出口、有没有解析失败。日常保持 info 即可，debug 会显著增加日志量，长时间开着会拖慢低性能设备。

external-controller 提供的接口可以被面板读取，用来查看每条连接的命中规则、出站节点、上传下载字节数。判断规则是否按预期生效，连接面板比日志更直接：找到那条连接，看它命中的规则编号和出站组名，与写下的规则对照。

多设备同步

订阅链接同步：所有设备导入同一条链接，节点列表自动一致。适合以节点为主、本地自定义少的场景，代价是各设备的规则设置独立，改一处不会同步到其他设备。

自建配置托管：自己维护一份完整配置，所有设备拉同一个地址，规则与策略组完全一致。适合多设备且规则复杂的场景，维护成本最高——配置出问题会影响所有设备。

手动导出导入：把配置文件通过局域网或网盘传给其他设备。适合不常变动的场景，也适合作为前两种方案的备份手段。

资源占用与稳定性

规则条目数量直接影响每条连接的匹配耗时。几千条规则在桌面端几乎无感，但在路由器等低性能设备上要控制规模，把大段规则拆进 RULE-SET 按需加载。GEOIP 数据库随内核更新，不需要手动替换。内存占用与活动连接数、DNS 缓存规模相关，长时间运行后如果内存持续增长，先检查是不是有大量 url-test 组在频繁测速，或者日志等级一直停在 debug。

多设备同步三种方案的完整对比见博客《Clash 多设备配置同步》。

进阶路线：内核特性、自建配置与排错方法

mihomo 带来的变化

mihomo 在原版 Clash 的基础上扩展了入站类型、规则类型与 DNS 能力：更多入站协议、更多规则匹配维度（进程、规则集、逻辑组合）、DNS 支持更细的策略、TUN 实现更完整。订阅里出现原版内核不认识的字段时，换到基于 mihomo 的客户端即可解析。原版 Clash 内核已停止维护，长期使用建议直接以 mihomo 系客户端为起点。

从订阅使用者到配置维护者

进阶的第一步，是把订阅当节点来源而不是完整配置。做法在第 4 章已经给出：用 proxy-providers 引入节点，规则、策略组、DNS 全部自己写。好处是换服务方时只需要改 provider 的地址，规则体系不用动；规则可以按自己的使用习惯精调，而不是受订阅方默认规则的限制。

第二步是理解规则集的维护方式：把大段规则拆进 RULE-SET 引用的外部文件，定期更新，主配置保持精简。规则集的好处是更新时不影响主配置，坏处是多了一层文件依赖，路径写错会静默失效。

第三步是把配置纳入版本管理：每次改动前留一份备份，改动记录写清楚。配置出问题时能快速回滚，比逐行比对快得多。

一套可复用的排错顺序

1. 订阅：最近一次更新是否成功，节点列表是否为空。
2. 节点：切到全局模式单独测试一个节点，排除规则因素。
3. DNS：Fake-IP 是否开启，filter 是否误伤，解析是否正常。
4. 端口：本地端口是否被其他程序占用。
5. 系统代理或 TUN：开关状态是否与实际期望一致。
6. 规则：连接面板里看到的是否是预期的策略组。
7. 日志：把上面六步的观察与日志对照，定位真正出问题的一层。

这个顺序的价值在于：每一步都排除一类因素，而不是同时怀疑所有环节。七步走完仍然不通，说明问题在更底层（物理网络、服务端、系统防火墙），可以把日志带到服务方或客户端社区求助。

继续深入的方向

• 内核配置文档：理解每个配置项的默认值，比记住推荐值更有用。
• 规则集生态：了解常见规则集的维护方式与更新节奏，选择活跃维护的来源。
• 网络基础：DNS 解析链路、路由表、TCP 握手——排错时最有用的三块知识。
• 自动化：用脚本管理配置版本与规则更新，把改动记录下来。

内核差异的具体对比见博客《mihomo 内核与原版 Clash 差异》；首次安装的检查清单见博客《Clash 首次安装与初始设置》。想先看客户端横向对比，到选型指南；确定之后直接到下载页取对应平台的安装包，第一次配置跟着快速上手教程走一遍即可。