Clash 从零到精通：安装、订阅、规则与 TUN

核心概念：先分清客户端、内核与配置

Clash 不是单一安装包

“Clash”通常指一套围绕规则代理形成的客户端与内核生态，而不是只有一个固定界面的软件。用户直接操作的是图形客户端，例如 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android 或 ClashX Meta；真正负责建立代理连接、解析配置和匹配规则的部分则是内核。当前常见客户端多围绕 mihomo 内核工作，界面负责把内核能力整理成开关、列表和状态页。

理解这层关系很重要。界面打不开、订阅无法更新和某条规则不生效，往往属于不同层级的问题。界面崩溃首先检查客户端本身；协议或规则行为异常，需要查看内核日志与配置；订阅内容不完整，则应先检查订阅源。把三者混在一起排查，容易反复重装却没有碰到真正原因。

一条连接经过哪些环节

应用发起网络请求后，流量需要先进入 Clash。系统代理通过操作系统提供的代理设置引导支持该设置的应用；TUN 模式则创建虚拟网卡，从网络层接收更广范围的流量。内核拿到请求后，会识别目标域名、目标 IP、端口和进程等信息，再按照配置文件中的规则从上到下匹配。匹配结果会指向某个策略组，策略组再决定使用具体节点、直接连接或拒绝连接。

域名请求还会经过 DNS。DNS 不只是把域名换成 IP，它也会影响规则是否能看到原始域名、是否发生解析污染，以及 IPv4 与 IPv6 连接如何选择。正常链路可以简化为：应用发起请求 → 系统代理或 TUN 接管 → DNS 获得地址或建立域名映射 → 规则匹配 → 策略组选择出口 → 节点建立连接。后续章节中的大多数设置，都在调整这条链路的某一段。

订阅、配置文件与节点的区别

订阅链接是配置内容的获取入口。客户端访问订阅链接后，服务端可能直接返回完整 YAML，也可能返回经过编码的节点列表。完整配置通常包含代理节点、策略组、规则、DNS 和其他内核参数；只有节点列表的订阅则需要客户端模板或订阅转换服务补齐策略组与规则。节点只是一个连接出口，不能代替完整配置。

本地保存的配置文件通常以 YAML 编写。YAML 对缩进敏感，层级一般使用空格，不应混入制表符。同一级字段必须保持相同缩进，列表项以短横线开头。许多“配置解析失败”并非协议不兼容，而是冒号后缺少空格、缩进错位、同名字段重复或特殊字符没有正确引用。修改前保留一份原文件，比事后凭记忆恢复稳妥得多。

mixed-port: 7890
mode: rule
allow-lan: false
log-level: info

proxies:
  - name: "Example Node"
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "Example Node"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,DIRECT

控制面板中的几个常见状态

“系统代理”表示客户端正在修改操作系统代理设置，但不代表所有程序都会遵循它。“TUN”表示虚拟网卡接管已经启用，但仍需确认路由、DNS 与权限是否正常。“Rule”是规则模式，表示连接按规则分流；“Global”是全局模式，通常把请求交给一个统一策略组；“Direct”则尽量直接连接。这些状态是不同维度的开关，并不是只能选一个。例如可以同时开启系统代理与 Rule 模式，也可以使用 TUN 搭配 Rule 模式。

初学阶段不必一次理解所有字段。先记住客户端负责操作，内核负责执行，配置负责描述行为，订阅负责更新配置，规则负责选择出口。后面每增加一个功能，都能放回这五个位置中判断。这样遇到陌生客户端时，界面名称即使不同，也能根据功能找到对应设置。

选择客户端：按平台和使用方式决定

先选图形客户端，还是直接使用内核

多数桌面和手机用户应从图形客户端开始。图形客户端已经处理配置存放、系统代理、开机启动、订阅更新、策略组切换与日志查看，出现问题时也更容易观察状态。直接运行 mihomo 内核更适合服务器、路由器、容器环境或需要自行管理服务进程的用户。这种方式需要手动准备配置、监听端口、启动参数和守护服务，也要自行处理权限与日志轮转。

本站下载页按 Windows、macOS、Android、iOS、Linux 与内核分类。Clash Plus 是各主要平台的首推选项，适合希望保持操作路径相近、直接导入订阅的用户。Clash Verge Rev、FlClash 与 Clash Nyanpasu 提供桌面图形界面；Clash Meta for Android 和 Surfboard 面向 Android；ClashX Meta 属于停止维护的 macOS 归档客户端；Clash for Windows 同样已经停止维护，只适合需要查看旧配置或迁移数据的场景。

Windows 与 macOS 如何取舍

Windows 用户首先确认系统架构。当前普通电脑大多使用 x64，ARM Windows 设备则需要对应架构的软件包。安装型程序通常能创建快捷方式并处理卸载，压缩包版本便于独立存放，但更新与文件关联可能需要手动管理。首次运行若出现系统防火墙提示，应根据实际使用范围决定是否允许专用网络访问；只有需要局域网设备连接本机代理端口时，才需要进一步开启局域网访问。

macOS 用户要区分 Apple Silicon 与 Intel。Apple Silicon 包对应采用 M 系列芯片的设备，Intel 包对应较早的 x86_64 设备。装错架构可能无法启动，也可能通过兼容层运行但带来额外问题。客户端首次修改系统代理、创建网络扩展或启用 TUN 时，系统会请求管理员授权，这是写入网络设置所需的正常步骤。若只想先验证订阅，可以暂时不开 TUN，先使用系统代理完成基础连接。

移动平台的重点不是功能数量

Android 客户端通常通过系统 VPN 接口接管流量。安装完成后，需要允许客户端建立 VPN 连接，并根据系统厂商设置调整电池优化、后台活动与自启动权限。若客户端退到后台几分钟后连接消失，优先检查系统省电策略，而不是立即修改节点。分应用代理可以控制哪些应用进入隧道，但不同客户端的“包含模式”和“排除模式”含义相反，保存前应仔细看说明。

iOS 与 iPadOS 同样通过系统 VPN 配置工作。首次连接会出现系统授权窗口，确认后才能建立隧道。移动端切换 Wi-Fi 与蜂窝网络时，短暂重连属于网络路径变化；若一直无法恢复，可以先断开再连接，并检查订阅中的节点是否可用。移动设备资源有限，不建议一开始就加载规模很大的规则集和过多配置副本。

停止维护的客户端怎样处理

停止维护不等于已有配置会立刻失效，但意味着未来系统更新、协议变化和安全问题可能不再得到适配。Clash for Windows 与 ClashX Meta 适合用于旧环境迁移，不适合作为新安装的长期首选。迁移时先导出或找到原有配置目录，记录常用策略组选择，再在新客户端中重新导入订阅。不要把旧客户端的整个程序目录直接覆盖到新客户端目录，两者的数据结构和设置字段可能不同。

选择客户端时，不需要追求设置项最多。能够稳定更新订阅、正确开启系统代理或 TUN、方便查看日志，已经覆盖大多数需求。需要具体安装包时前往下载中心，按平台标签选择即可。先确定平台与架构，再下载对应文件，可以避开很多看似复杂、实际只是包型不匹配的问题。

安装与首次启动：先让基础链路跑通

安装前先整理旧环境

同一台设备上可以保存多个客户端，但不建议同时让它们修改系统代理或建立 TUN。安装新客户端前，先在旧客户端中关闭系统代理和 TUN，再完全退出程序。Windows 可到系统网络代理设置中确认手动代理已关闭；macOS 可在当前网络服务的代理页检查 HTTP、HTTPS 与 SOCKS 项；移动端则确认旧 VPN 已断开。这样能避免两个客户端争用端口、反复覆盖系统设置。

如果准备迁移旧配置，先复制配置目录或导出 YAML。需要保留的是订阅地址、自己修改过的规则、策略组偏好和 DNS 调整，而不是缓存、日志与临时数据库。订阅地址属于个人使用信息，不应发布到公开截图、论坛或代码仓库。完成备份后，再从下载中心选择平台对应安装包。

Windows 安装与首次检查

Windows 安装程序下载完成后，按向导选择安装位置并启动客户端。若系统提示需要安装网络组件或请求管理员权限，应先确认正在操作的确实是刚下载的客户端，再继续。应用启动后不要急着打开所有开关，先找到“配置”或“订阅”页面，确认界面能够正常加载；随后查看设置页中的混合端口、系统代理与 TUN 状态。

常见的本地混合端口是 7890，但端口并非必须固定为这个值。只要没有被其他程序占用，并且手动设置代理的应用使用相同端口即可。如果日志出现“address already in use”，说明监听端口冲突。可先退出其他代理程序，或把 mixed-port 改为未占用端口。端口改变后，浏览器扩展、开发工具和命令行环境中的代理地址也要同步修改。

netstat -ano | findstr :7890

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

第一条命令用于查看 Windows 上是否有进程占用 7890 端口，第二条命令用于明确通过本地 HTTP 代理发起请求。测试地址只是用于确认代理端口能够接收连接，不代表业务网站是否可访问。若 curl 无法连接到 127.0.0.1，应先检查客户端内核是否启动，而不是检查远端节点。

macOS 安装与系统授权

macOS 下载后通常需要把应用移入“应用程序”目录，再从该目录启动。首次运行可能出现来源确认或权限提示，应通过系统提供的安全设置完成确认。修改系统代理时，客户端可能请求管理员授权；启用 TUN 或网络扩展时，还可能要求允许新增 VPN 配置。授权完成后返回客户端，确认开关状态是否真的变为开启，不能只以弹窗消失作为成功依据。

若菜单栏已有另一个代理客户端图标，先退出旧程序。系统代理开关显示开启但浏览器完全不受影响时，可到“系统设置 → 网络 → 当前网络 → 详细信息 → 代理”核对地址是否指向 127.0.0.1，以及端口是否与客户端一致。关闭客户端前，最好先关闭系统代理，让客户端主动清理设置。遇到程序异常退出造成代理残留，也可在系统网络设置中手动取消。

Android、iOS 与 Linux 的首次启动

Android 安装后先授予建立 VPN 连接所需权限。若系统开启了“始终开启的 VPN”并绑定其他应用，需要先调整该设置，否则新客户端无法接管。部分系统会限制后台网络与电池使用，连接能建立但锁屏后中断时，应把客户端加入允许后台运行的范围。首次测试阶段先关闭复杂的分应用规则，确认所有应用都能通过后，再逐步增加排除项。

iOS 或 iPadOS 从 App Store 安装 Clash Plus 后，首次连接需要允许新增 VPN 配置。系统状态栏出现 VPN 标识只说明隧道已建立，不代表订阅中的每个节点都可用。仍应回到客户端观察连接日志，并用一个普通网页验证。若蜂窝网络能用而 Wi-Fi 不行，需要检查当前 Wi-Fi 的 DNS、认证页面与路由限制。

Linux 图形客户端的安装方式取决于包类型和发行版。Debian、Ubuntu 及其衍生系统可安装 deb 包；其他发行版应选择兼容包型。安装后如果托盘图标缺失，不一定代表内核没有运行，可从应用窗口和进程列表检查。单独运行 mihomo 内核时，应明确指定配置目录，并先执行配置测试。

mihomo -t -d ./clash-config
mihomo -d ./clash-config

-t用于检查配置是否能解析，-d指定包含配置文件与运行数据的目录。先测试再启动，可以把 YAML 格式错误与网络连接错误分开。作为长期服务运行时，还应使用系统服务管理器处理自动启动、崩溃重启和日志，而不是把终端窗口一直留在前台。

首次启动后的最小验收

安装完成后按固定顺序检查：客户端界面正常打开；内核状态显示运行；本地端口成功监听；系统代理或 VPN/TUN 中至少选择一种接管方式；导入配置后能看到策略组；选中可用节点后能够产生连接日志。不要用“某一个网站能否打开”作为唯一标准，因为网站自身、DNS、规则和节点出口都可能影响结果。

如果基础链路没有跑通，先不要调整 Fake-IP、规则集和脚本。保持默认设置更容易定位问题。下载与安装相关的常见疑问可查看下载页常见问题区；希望只走一遍最短操作路径，可回到使用指南。

订阅导入：从链接到可用配置

导入前先确认订阅返回什么

订阅链接通常由服务提供方生成，可能带有识别参数，因此应当像账号信息一样保存。不要把完整地址放进公开截图、浏览器同步笔记或公开仓库。导入前可以先确认链接是否仍在有效期内，以及服务方是否明确提供 Clash 或 mihomo 格式。浏览器能打开链接，不等于客户端一定能解析；浏览器下载到文本也不等于内容就是完整 YAML。

完整配置应至少包含代理节点与策略组，常见字段包括 proxies、proxy-groups 和 rules。如果返回内容只有一串编码文本，客户端可能需要先识别为通用订阅，再转换为 Clash 配置。若转换由远端服务完成，需要理解订阅地址会被该服务读取。优先使用服务提供方明确支持的格式，能少经过一层就少一层故障点。

在客户端中添加订阅

不同客户端的入口可能叫“订阅”“配置”“Profiles”或“远程配置”，操作逻辑大致一致：新建远程配置，粘贴链接，填写便于识别的名称，保存并触发更新。更新成功后，选择这份配置作为当前配置，再到策略组页面选择需要的出口。只把链接加入列表但没有切换到该配置，是初次使用中很常见的遗漏。

配置名称建议描述用途，例如“日常订阅”或“备用配置”，不必把访问凭据写进名称。自动更新时间不宜过短。订阅内容通常不会按分钟变化，频繁刷新只会增加请求并可能触发服务端限制。每天或按服务方建议更新即可；需要立即获取变化时再手动刷新。

更新失败时按响应阶段排查

“无法连接”通常表示请求还没有获得有效响应，应检查当前网络、域名解析、系统时间和链接是否完整。“请求被拒绝”或 HTTP 认证类错误，多与链接过期、参数缺失或访问条件有关。“解析失败”表示已经拿到内容，但格式不符合客户端预期，常见原因是返回网页、编码订阅、YAML 缩进错误或客户端不支持其中的字段。“更新成功但节点为空”则要检查订阅本身是否包含节点，以及是否有筛选规则把节点全部排除。

排查时先复制链接到当前设备的浏览器地址栏，只用于观察响应类型，不要转发给他人。如果打开后跳到登录页、错误页或验证码页面，客户端自然无法把它当作配置解析。若浏览器下载了文件，可用文本编辑器查看开头字段。完整 YAML 通常能看到键名和缩进；网页内容往往以 HTML 标签开头；编码订阅则可能是一整行连续字符。

某些服务会根据请求的 User-Agent 返回不同格式。客户端设置中若有订阅 User-Agent 选项，应优先使用服务方要求的值，不要随机尝试多个伪装名称。需要进一步定位订阅解析、缓存和格式转换问题，可阅读Clash 订阅链接失效自查步骤。

本地修改与远程更新的覆盖关系

远程订阅更新通常会重新写入配置，因此直接在订阅生成的 YAML 中增加规则，下一次更新后可能消失。需要长期保留的修改，应使用客户端提供的覆写、合并或脚本功能；如果客户端没有这些能力，就保留一份独立本地配置，并建立清楚的更新流程。不要一边让远程配置自动更新，一边把它当作永久手写文件。

合并逻辑通常分为前置插入、后置追加和字段覆盖。规则具有顺序，想让自定义规则优先生效，应插入到通用规则之前；DNS、端口和模式等单值字段则通常由后写入的值覆盖。不同客户端对覆写语法的实现并不完全一致，迁移客户端时要重新核对，而不是假定旧脚本可以原样使用。

prepend-rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN,api.example.net,PROXY

append-rules:
  - MATCH,PROXY

上面的结构用于表达“把特定规则放到前面，并保留最终兜底”的思路，实际字段名称要以客户端的覆写功能为准。若直接编辑标准 Clash 配置，则应把规则写入 rules 列表，并保证只存在一个最终兜底。多个 MATCH 中只有最先遇到的一个有意义。

订阅转换应该解决什么问题

订阅转换主要用于把节点列表整理成客户端可读取的配置，或套用规则与策略组模板。它不能修复已经失效的节点，也不能凭空提高连接质量。转换后节点名称、策略组和规则可能变化，更新前应保存旧配置。若转换结果突然少了节点，检查模板过滤条件、协议支持和节点名称正则，而不是只盯着链接是否能打开。

完成导入后，应先在规则模式下选择一个明确节点，开启系统代理并观察日志。确认基础连接正常，再开启自动选择、复杂规则和 TUN。把验证步骤拆开，出现问题时才知道是订阅内容、策略选择还是接管方式造成的。

代理模式：Rule、Global 与 Direct 怎样选

Rule 模式适合长期使用

Rule 模式会按配置中的规则逐条判断请求应该走哪个策略组。常见结果包括 PROXY、DIRECT、REJECT 或自定义策略组。它的优势不是“自动变快”，而是让不同流量按用途选择出口：本地服务可以直连，需要代理的域名交给代理组，广告或已知无效请求可以拒绝。规则设计合理时，不必频繁手动开关整个客户端。

规则从上到下匹配，命中后停止继续查找。因此具体规则应放在宽泛规则之前。例如单个域名规则要放在覆盖范围更大的域名后缀或规则集之前，局域网与保留地址通常要在最终代理兜底之前处理。最后一条常用 MATCH 作为兜底，保证未被前面规则识别的连接仍有明确去向。

Global 模式用于临时验证

Global 模式通常把所有可接管流量交给全局策略组，再由用户选择一个节点或出口。它适合判断“问题是否由规则造成”。某网站在 Rule 模式打不开，切到 Global 后立即正常，说明节点和接管链路大概率可用，下一步应检查域名规则、IP 规则与 DNS，而不是重装客户端。

全局模式不等于设备上的每一个数据包都会自动进入代理。是否接管仍取决于系统代理或 TUN。只切换到 Global 却没有开启任何接管方式，许多应用仍会直接连接。反过来，开启 TUN 但选择 Direct 模式，流量虽然经过内核，也可能按直接连接处理。模式与接管方式要分开看。

Direct 模式用于快速旁路

Direct 模式让流量尽量直接连接，可用于临时停用代理决策、比较直连与代理差异，或在保留客户端运行的同时排查本地网络。它不一定等同于完全退出客户端：本地端口可能仍在监听，TUN 也可能继续接管后再直连。需要彻底恢复原始网络状态时，应关闭系统代理和 TUN，再退出客户端。

某些客户端还有 Script 等扩展模式，行为取决于脚本实现。初学阶段不建议把脚本模式作为默认方案，因为脚本错误、运行环境和返回值都会增加排查层级。规则能够清楚表达的逻辑，优先使用标准规则。

策略组才是模式之后的实际出口

规则通常不会直接写死某个节点，而是指向策略组。select 组由用户手动选择；url-test 会按测试结果选择候选节点；fallback 按顺序尝试可用节点；load-balance 根据策略在多个节点之间分配连接。不同组解决的问题不同，不应只根据名称中的“自动”判断优劣。

自动测试使用的是指定测试地址和间隔，它只能反映到该地址的连接情况。测试结果较好，不代表访问所有服务都相同。节点出口位置、路由、目标网站限制和连接复用都会影响实际体验。日常可保留一个手动选择组与一个自动测试组：自动组负责普通浏览，遇到特定服务异常时切回手动组验证。

proxy-groups:
  - name: "手动选择"
    type: select
    proxies:
      - "节点 A"
      - "节点 B"
      - DIRECT

  - name: "自动选择"
    type: url-test
    proxies:
      - "节点 A"
      - "节点 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

interval表示测试间隔秒数，过短会产生额外请求；tolerance用于避免节点之间只有很小差异时频繁切换。测试地址应稳定返回轻量响应。如果当前网络无法访问测试地址，自动组可能把所有节点判定为异常，此时应更换适合当前环境的检测地址。

切换模式时怎样验证

先固定一个已知可用节点，开启系统代理或 TUN，再分别测试 Rule 与 Global。若两者都失败，查看本地监听、节点连接和 DNS；若 Global 成功而 Rule 失败，查看日志中命中的规则和策略组；若浏览器成功而命令行失败，检查命令行程序是否读取系统代理，必要时使用显式代理参数或 TUN。

判断当前模式不要只看首页按钮颜色。查看日志中的规则命中和出口名称更可靠。一次完整记录应包含目标域名或 IP、匹配规则、策略组和最终节点。掌握这四项后，“某应用无法连接”就能拆成可检查的步骤，而不是反复切换所有开关。

规则分流与 DNS：让请求走到正确出口

规则类型与匹配顺序

域名规则最容易阅读。DOMAIN只匹配完整域名，DOMAIN-SUFFIX匹配指定后缀及其子域名，DOMAIN-KEYWORD按域名中的关键字匹配。IP 规则根据目标地址判断，常见有 IP-CIDR、IP-CIDR6 和地理数据库规则。进程规则可以按程序名或路径分流，但不同系统的支持程度与权限要求不同。规则集则把大量规则拆到独立文件中，便于更新和复用。

规则越宽泛，越应该靠后。假设先写 DOMAIN-SUFFIX,example.com,PROXY，后面再写 DOMAIN,internal.example.com,DIRECT，内部域名会先命中后缀规则，后面的直连规则永远没有机会执行。正确做法是把具体例外放到通用规则之前。最终使用 MATCH 兜底，避免请求落入不明确状态。

rules:
  - DOMAIN,internal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,PROXY

no-resolve表示匹配该 IP 规则时不为了获得 IP 而额外触发域名解析。它适合已经拿到目标 IP 的连接，或不希望 IP 规则提前引发解析的场景。并非所有 IP 规则都应机械添加该选项；如果规则需要由域名解析结果参与判断，就要允许解析发生。

规则集、GeoIP 与 GeoSite

规则集把域名、IP 或经典规则放在独立资源中，主配置只通过 RULE-SET引用。这样可以单独更新规则，不必每次替换整个订阅。使用时要确认规则集行为类型与内容匹配：domain 类型只包含域名行为，ipcidr 类型用于网段，classical 类型可以承载完整规则行。类型写错可能导致加载失败或规则无法命中。

GeoIP 根据 IP 地理数据库分类，GeoSite 根据域名集合分类。它们依赖本地数据库，数据库长期不更新会造成新域名缺失或地址归类偏差。配置能够正常解析但分流逐渐失准时，应检查数据库更新时间与下载来源。具体更新思路可参考GeoIP 与 GeoSite 数据库更新指南。

DNS 为什么会影响规则

应用访问域名时，可能先自行解析，再向代理发起 IP 连接；也可能把域名直接交给代理。前一种情况下，内核看到的可能只有 IP，域名规则难以参与；后一种情况下，内核能保留域名信息并按域名规则分流。系统代理、SOCKS、TUN、浏览器安全 DNS 与应用内置解析方式都会改变这条路径。

DNS 配置通常包含监听、IPv6、增强模式、默认解析器与主要 nameserver。默认解析器用于解析其他 DNS 服务器自身的域名，应该选择当前网络能直接访问的地址，避免形成“需要先通过代理访问 DNS，但代理节点域名又必须先解析”的循环。主要 nameserver 负责普通查询，可根据网络环境选择支持 UDP、TCP、DoH 或 DoT 的服务。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

这段配置展示字段关系，不代表所有网络环境都应照抄。监听在 0.0.0.0意味着所有本机接口都可能访问该端口，若设备处于不受信任网络，应结合防火墙或改为本地监听。关闭 IPv6 会让 Clash DNS 不返回 IPv6 结果，但系统和其他应用是否仍发起 IPv6 请求，还取决于接管方式与系统网络。

Fake-IP 与 Redir-Host 的差异

Fake-IP 模式先向应用返回保留地址，内核维护这个地址与原始域名的映射。当应用连接保留地址时，内核仍知道原始域名，因此可以较早进行域名规则判断，并减少某些重复解析。保留地址不是目标网站的真实地址，只在本机映射流程中使用。详细原理和过滤方式可阅读Clash Fake-IP 模式说明。

部分局域网发现、打印机、游戏、时间同步或依赖真实 IP 返回值的应用不适合 Fake-IP，可加入 fake-ip-filter。过滤项不宜一次加入大量宽泛域名，否则会削弱 Fake-IP 的域名映射优势。遇到单个应用异常时，先从日志确认域名，再增加最小范围过滤并复测。

Redir-Host 更接近先解析真实地址再处理连接，兼容某些依赖真实 DNS 结果的程序，但可能更依赖 DNS 路径质量。两种模式没有绝对优劣。桌面日常使用可以先保持客户端默认值；出现局域网设备发现失败、特定应用登录异常或域名规则丢失时，再根据日志决定调整。

规则不命中的排查方法

第一步查看连接日志中显示的是域名还是 IP。若只有 IP，域名规则自然可能无法匹配，需要检查应用解析方式、TUN 嗅探与 DNS 接管。第二步确认目标规则是否排在更宽泛规则之前。第三步确认规则指向的策略组名称完全一致，包括大小写、空格与符号。第四步检查规则集是否成功下载，行为类型是否匹配。第五步再考虑数据库与缓存。

修改后应重新加载配置，并建立一条新连接测试。已有连接可能继续复用旧出口，刷新网页不一定会新建连接。可以关闭对应应用、清理连接记录或等待连接结束后再试。不要同时改规则顺序、DNS 模式和 TUN 参数，否则即使恢复正常，也无法知道哪项修改真正起效。

TUN 模式：接管不读取系统代理的流量

什么时候需要 TUN

系统代理只对主动读取系统代理设置的程序有效。浏览器通常支持良好，但命令行工具、游戏启动器、部分桌面应用、容器与使用自定义网络栈的软件可能忽略它。TUN 模式创建虚拟网卡，通过系统路由把更广范围的 IP 流量送入内核，因此适合处理系统代理覆盖不到的应用。

TUN 不是“更高级所以必须开启”的开关。只使用浏览器和遵循系统代理的应用时，系统代理结构更简单，也更容易排错。只有明确遇到未被接管的程序，或需要统一处理 UDP、命令行和多个应用时，再启用 TUN。它会引入虚拟网卡、路由、DNS 劫持和权限等额外环节，配置不当时也更容易与其他 VPN、虚拟机网络和安全软件冲突。

核心参数怎样理解

enable控制 TUN 是否启用；stack决定数据包在用户态和系统网络栈之间如何处理，常见值包括 system、gVisor 与 mixed，具体支持以当前内核与客户端为准；auto-route用于自动写入路由；auto-detect-interface尝试识别默认出口接口；dns-hijack把指定 DNS 请求交给 Clash 处理。客户端图形开关通常会生成或覆盖这些字段。

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

mixed通常用于兼顾不同流量处理路径，但并非所有设备都必须选择它。若客户端已经提供 stack 选项，应先使用默认值。strict-route会更严格地限制路由泄漏，在部分系统上可能影响局域网、热点或虚拟网络。初次启用时保持关闭更容易验证，确认基础流量正常后，再根据需求测试。

桌面系统的启用步骤

先关闭其他 VPN 和旧客户端的 TUN，保留当前客户端运行。导入一份已在系统代理模式下验证可用的配置，固定一个可用节点，再开启 TUN。系统请求管理员权限时完成授权，随后观察客户端是否显示内核运行、虚拟网卡创建和路由写入成功。此时可暂时关闭系统代理，用一个原本不读取系统代理的命令行工具测试，以确认流量确实来自 TUN。

Windows 若开启后完全断网，先关闭 TUN，检查是否残留其他虚拟网卡、第三方 VPN、Hyper-V 或安全软件网络过滤。重新开启前可重启客户端并恢复自动路由。macOS 需要关注网络扩展或 VPN 配置授权，权限被拒绝时开关可能立即回落。Linux 则需要创建 TUN 设备和修改路由的权限，服务进程还应具备读取配置与写入运行目录的权限。

curl https://example.com/
curl --noproxy "*" https://example.com/

在 TUN 已正确接管的情况下，即使第二条命令要求 curl 不使用传统代理环境变量，流量仍可能由系统路由进入 TUN。这个测试可以帮助区分“程序读取了 HTTP 代理”还是“流量被虚拟网卡接管”。测试时还应查看 Clash 日志是否出现对应连接，不能只根据网页结果推断。

DNS 劫持与 Fake-IP 的配合

TUN 接管 IP 流量后，如果 DNS 仍由应用直接发送到局域网解析器，内核可能只看到解析后的 IP，域名规则与 Fake-IP 映射就会受影响。dns-hijack用于把常见 DNS 请求送入 Clash DNS。现代浏览器和部分应用可能使用加密 DNS，普通 53 端口劫持无法直接读取这类请求，需要在应用中关闭独立安全 DNS，或确保其连接本身能被规则正确处理。

启用 DNS 劫持后出现局域网域名无法解析，应检查本地域名是否需要由路由器 DNS 处理，并为它配置 nameserver-policy 或合适的回退路径。打印机、NAS 与公司内部域名往往只在特定网络的 DNS 中存在，公共解析器无法回答。解决方式应是把这些域名交给正确的本地解析器，而不是把所有 DNS 都改回直连。

局域网、虚拟机与容器边界

TUN 改写路由后，局域网访问可能经过内核。配置中应保留私有网段直连规则，并注意 IPv6 本地地址。若需要让其他设备使用本机代理，应单独开启 allow-lan、监听合适接口并配置防火墙；这和本机 TUN 是两件事。不要为了本机接管而随意把代理端口暴露到所有网络。

虚拟机与容器有自己的虚拟网卡和网段。TUN 自动路由可能与 Docker、虚拟机桥接、WSL 或企业 VPN 的路由发生覆盖。问题只在虚拟环境出现时，应比较启用 TUN 前后的路由表，确认目标网段被哪个接口接管。必要时把虚拟网段加入排除路由或直连规则，而不是关闭所有规则。

TUN 失败的固定排查顺序

先确认同一节点在系统代理下可用，排除节点问题；再确认 TUN 开关确实保持开启，虚拟网卡已经创建；然后查看自动路由和默认接口识别；接着检查 DNS 是否被接管、日志中是否出现请求；最后检查其他 VPN、安全软件、虚拟网卡与防火墙。每一步只改一个变量，修改后重新建立连接。

系统代理正常而 TUN 不正常，通常不需要重新导入订阅。重点应放在权限、路由、DNS 和网络冲突。更完整的工作原理、stack 选择与平台差异，可继续阅读Clash TUN 模式开启教程。

日常维护与进阶路线：保持配置可恢复

建立稳定的日常检查节奏

Clash 正常运行时不需要频繁调整。日常只需关注订阅是否能更新、常用策略组是否有可用节点、规则与地理数据库是否过旧，以及客户端更新后关键设置是否保持。订阅可以按天或按服务方建议更新；规则集和数据库按实际变化周期更新即可。过度频繁的自动测试与订阅刷新会增加请求，也可能让节点选择不断变化。

客户端启动后发现设置恢复默认，先确认是否切换了配置、是否使用便携目录、配置目录是否可写。系统更新后 TUN 权限丢失，应重新检查网络扩展或虚拟网卡授权。休眠唤醒后短暂断连，可以先等待网络接口恢复，再重连内核；如果每次都无法自动恢复，再检查默认接口识别与客户端后台行为。

备份哪些内容最有价值

优先备份订阅地址清单、自定义规则、覆写脚本、DNS 调整和本地独立配置。缓存数据库、临时连接记录与普通运行日志通常不必长期保留。备份文件中可能包含订阅参数、节点认证信息和局域网地址，应存放在受控位置，不要直接上传到公开代码仓库。

多设备同步时，订阅链接集中下发最省维护，但设备特有设置不应强行共用。例如桌面端的 TUN stack、Android 分应用代理和 macOS 网络扩展属于平台差异。可以让各设备共享节点与基础规则，再把系统相关字段留在本地覆写层。关于订阅、WebDAV 与手动导出的取舍，可参考Clash 多设备配置同步方案对比。

日志应该怎样阅读

日志级别通常有 silent、error、warning、info 与 debug。日常使用保留 info 即可；排查短时间问题时可临时切到 debug，问题复现后立即恢复，避免日志快速增长。阅读时先找到故障发生的准确时间，再看目标域名或 IP、命中规则、策略组、最终出口与错误类型。不要从大量日志中随机挑一条报错作为结论。

连接超时通常表示请求已经发出但没有及时完成，可能是节点、路由、目标服务或网络限制；连接被拒绝表示目标地址明确拒绝；DNS 错误说明名称解析阶段失败；TLS 错误可能与系统时间、证书链、域名不匹配或中间网络有关；配置解析错误则应回到 YAML 行号和字段。错误发生在哪一层，决定下一步该查什么。

通用故障树：从范围最小的地方开始

所有网站都不通时，先看客户端内核、本地端口、接管方式和节点；只有一个网站不通时，先看规则命中、DNS、节点出口与网站自身限制；只有一个应用不通时，先确认它是否读取系统代理，是否使用独立 DNS 或 QUIC；只有 TUN 不通时，检查权限、路由和冲突；只有订阅更新失败时，不要改代理规则，直接检查链接响应与格式。

系统代理关闭后仍无法恢复直连，检查操作系统代理是否残留、环境变量是否仍存在、浏览器是否设置了独立代理。TUN 关闭后仍异常，检查虚拟网卡与路由是否已经清理，必要时正常重启系统让网络栈重新建立。不要使用来源不明的“一键网络修复”脚本，它可能同时重置 DNS、防火墙和网卡，反而抹掉有价值的现场信息。

# macOS 与 Linux 查看常见代理环境变量
env | grep -i proxy

# 临时移除当前终端会话中的代理变量
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
unset http_proxy https_proxy all_proxy

# 测试本地代理端口
curl -x http://127.0.0.1:7890 https://example.com/

环境变量只影响读取它们的程序和当前会话，图形客户端修改系统代理并不会自动清理终端中手动设置的变量。反过来，终端里设置了 HTTPS_PROXY，也不代表其他桌面应用会使用它。明确每个应用通过哪种方式接管，是长期稳定使用的重要习惯。

升级客户端与迁移配置

升级前查看客户端提供的更新说明，确认是否涉及配置目录、内核字段或网络扩展变化。先导出关键配置，再正常退出旧版本并安装新版本。升级后先检查配置是否加载、订阅是否能更新、系统代理与 TUN 权限是否保留，然后再恢复复杂覆写。不要在升级当天同时更换订阅、规则模板和 DNS 配置，多个变化叠加会让问题难以回溯。

从停止维护的 Clash for Windows 或 ClashX Meta 迁移时，建议重新导入远程订阅，而不是复制全部数据库。手写规则可以单独迁移，策略组选择重新确认。新客户端采用 mihomo 内核时，部分扩展字段可能更丰富，但旧字段是否继续兼容仍应通过配置测试和日志确认。

从日常使用走向进阶配置

完成基础连接后，进阶学习可以按依赖关系推进。第一阶段是读懂连接日志与规则顺序，能够解释某条请求为什么走某个出口；第二阶段是掌握策略组，让手动选择、自动测试与故障回退各司其职；第三阶段是理解 DNS、Fake-IP 和规则集，解决域名识别与分流准确性；第四阶段再深入 TUN、进程规则、局域网共享和多设备同步。

服务器或路由器用户还需要学习服务管理、配置目录权限、日志轮转、监听地址和防火墙。直接暴露控制接口或代理端口会扩大访问范围，因此控制端口应限制在可信接口，并设置适当认证。配置中的局域网访问能力只在确实需要时开启，同时用系统防火墙限制来源。

判断自己是否真正掌握 Clash，不看配置文件有多长，而看能否回答四个问题：流量如何进入内核；这条请求命中了什么规则；规则指向哪个策略组；策略组最终选择哪个出口。能够沿这条路径定位，换客户端、换平台或调整配置时都不会从头摸索。

手册之后的阅读顺序

如果还没有完成第一次连接，回到使用指南按步骤操作；需要更换客户端或确认系统架构，前往下载中心；遇到缩写和字段名，可打开术语手册。订阅解析、TUN、Fake-IP、数据库更新与多设备同步分别有独立技术笔记，可以按当前问题深入，不必一次读完所有高级配置。

稳定配置的原则很简单：先跑通，再分流；先看日志，再改参数；一次只改一个变量；修改前保留可恢复版本。按照这套顺序，Clash 的设置项虽然多，但每个问题都能落到明确环节，不会变成一团缠在一起的网线。