Clash Meta 全平台安装配置文档

CHAPTER 01 / PREPARATION

通用准备：客户端、订阅与权限边界

先区分客户端、内核和订阅

Clash Meta 的实际运行链路由三部分组成。mihomo 是负责协议连接、规则匹配、DNS 处理与流量转发的内核；Clash Plus、Clash Verge Rev、FlClash 等是管理内核的图形客户端；订阅则是一份由服务提供方生成的远程配置，其中通常包含代理节点、策略组和基础规则。安装客户端并不等于已经具备可用线路，订阅链接也不是安装包，两者需要分别取得并在客户端内完成组合。

选择客户端时先看操作系统与处理器架构。Windows 常见设备使用 x64 安装包；采用 ARM 处理器的设备需要确认应用是否提供对应构建。macOS 需要区分 Intel 与 Apple Silicon。Android 安装包可能按 arm64、arm 或通用架构区分，新设备通常使用 arm64，但无法确认时应从下载页选择客户端提供的通用构建。Linux 还需要区分发行版包格式、CPU 架构以及是否具备桌面环境。

图形客户端适合日常桌面与移动设备。直接使用 mihomo 内核更适合服务器、路由器、容器或需要自行编写服务管理脚本的环境。两类方式读取的核心配置语义接近，但图形客户端可能把系统代理、TUN、配置覆写和订阅更新包装为独立开关。排查时应明确问题发生在界面层、内核层还是上游订阅，避免反复重装却没有触及实际原因。

导入前检查订阅返回内容

订阅链接应从服务提供方的管理页面复制，不要手工截取聊天窗口中被折行的地址。链接中常含有访问凭据，应当按私密资料保存，不放入公开截图、代码仓库或共享文档。导入失败时，可以先在系统浏览器中直接访问链接：若返回 YAML 文本或触发配置文件下载，说明地址至少可达；若显示登录页、过期提示、访问被拒绝或空白响应，应先处理订阅侧问题。

同一服务可能同时提供 Clash YAML、通用分享链接和其他客户端格式。mihomo 客户端通常需要 Clash 或 mihomo 兼容配置。格式选择错误时，客户端可能报告解析失败，也可能导入后只有节点而没有策略组。更换格式前不要删除仍可用的旧配置，先为新配置使用不同名称并验证代理组、规则和 DNS 段是否完整，再决定是否替换。

建立可回退的配置基线

第一次启动后先保持默认端口和默认工作模式，只导入一份配置，选定一个代理节点，再测试浏览器连接。这个顺序有助于建立基线：默认状态可用，后续故障才可能由 TUN、覆写规则、DNS 或多个配置同时启用引起。不要在第一次测试时同时开启系统代理、TUN、局域网共享和自定义 DNS，否则出现异常后很难判断是哪一层改变了流量路径。

系统代理和 TUN 不是同一个入口。系统代理通常只影响遵循操作系统代理设置的应用，常见形式为 HTTP 或 SOCKS 端口；TUN 会创建虚拟网络接口，可接管更多不读取系统代理的程序。移动系统中的 VPN 开关通常承担与 TUN 相近的接管职责。两者可以满足不同场景，但日常桌面浏览通常先使用系统代理，游戏、命令行工具或行为不一致的应用再考虑 TUN。

CHAPTER 02 / WINDOWS

Windows：安装、系统代理与 TUN 接管

安装与首次启动

Windows 用户可在Windows 下载区选择 Clash Plus，或根据界面习惯选用 Clash Verge Rev、FlClash、Clash Nyanpasu。Clash for Windows 已停止维护，仅作为归档选择。下载前先在“设置 → 系统 → 系统信息”查看系统类型，常规 Intel 与 AMD 电脑通常选择 x64 构建。安装包与便携包的数据目录位置可能不同，需要长期保留配置时，安装后不要随意移动便携目录。

首次启动若出现 Windows 安全中心或防火墙询问，应根据使用范围授权。只在本机使用时，不需要为了代理功能开放公共网络访问；需要局域网设备连接本机端口时，才考虑允许相应的专用网络访问。客户端窗口关闭后是否继续驻留托盘取决于设置，判断是否仍在运行应查看任务栏托盘图标或任务管理器，而不是只看窗口是否消失。

若安装程序无法写入目录，先确认下载文件完整到达本地，再尝试在用户有写入权限的位置运行。管理员权限主要用于安装驱动、注册服务或创建 TUN 接口，不应把“始终以管理员身份运行”当成所有故障的默认处理。普通系统代理模式通常不需要持续管理员权限，权限过高反而会改变程序与浏览器之间的运行边界。

导入订阅与确认配置生效

在客户端的配置、订阅或 Profiles 页面找到“从 URL 导入”入口，粘贴订阅地址并为配置设置可辨认的名称。导入完成后需要显式选中该配置；配置出现在列表里并不代表已经加载。随后进入代理或 Proxies 页面，确认至少存在一个策略组，并在最终出口策略组中选择节点。若页面只有节点列表、没有常见的选择组，可能是订阅格式不完整或客户端没有加载到正确配置。

完成选择后先打开系统代理。Windows 的系统代理设置应出现指向本机回环地址的代理服务器，端口与客户端当前监听值一致。不要手工把订阅服务器地址填入 Windows 系统代理；系统代理目标应是本机客户端，客户端再依据配置连接远端。测试时新开浏览器窗口，避免旧连接复用此前路径。若关闭客户端后网页也无法访问，检查系统代理是否被异常保留。

端口常见字段包括 port、socks-port 与 mixed-port。图形客户端通常使用 mixed 端口同时接收 HTTP 与 SOCKS 请求。端口被其他程序占用时，日志会出现监听失败，客户端可能仍显示已启动但无法处理连接。此时先退出同类代理程序，再更换为未被占用的本地端口，并同步检查系统代理目标是否自动更新。

何时开启 TUN

部分游戏平台、命令行程序、商店应用或自带网络栈的软件不读取 Windows 系统代理。确认浏览器可用而特定程序始终直连时，可以启用 TUN。首次开启通常需要安装虚拟网卡或服务，应接受客户端明确发起的系统权限请求。启用后检查客户端日志是否成功创建接口，以及系统路由表中是否出现对应路由，而不是只看界面开关颜色。

TUN 与其他 VPN、虚拟机网卡、网络加速器、企业安全软件可能同时修改路由。测试阶段只保留一个接管工具，确认基本连接后再逐项恢复。若开启 TUN 后局域网共享、打印机或公司内网失效，应检查规则中是否为私有地址保留直连，并确认绕过列表包含实际使用的内网网段。关闭 TUN 后需要等待接口和旧连接释放，再重新测试。

netsh winhttp show proxy
ipconfig /flushdns
netstat -ano | findstr LISTENING

CHAPTER 03 / MACOS

macOS：架构选择、网络服务与系统扩展

选择 Apple Silicon 或 Intel 构建

macOS 下载前先打开“关于本机”查看芯片信息。显示 Apple 芯片时选择 Apple Silicon 或 arm64 构建，显示 Intel 处理器时选择 x64 构建。可在macOS 下载区优先选择 Clash Plus，也可使用 Clash Verge Rev、FlClash；ClashX Meta 已停止维护，适合已有配置需要暂时延续的环境。架构选错时应用可能无法启动，或依赖转译运行并产生额外行为差异。

下载后将应用移动到“应用程序”目录，再从该目录启动。直接在下载镜像或临时目录中运行，可能导致更新、数据目录和权限状态不稳定。系统首次打开来自网络的应用时会显示安全确认，应核对文件来源为本站下载入口所指向的对应客户端。若系统阻止打开，可在“系统设置 → 隐私与安全性”查看该次阻止记录，并按系统提供的明确入口确认。

客户端的数据目录通常位于用户资料库范围，卸载应用本体不一定同时删除订阅和设置。准备更换客户端时，先记录订阅来源、当前策略与自定义覆写，再退出旧客户端。不要让两个客户端同时设置系统代理，因为后启动的程序可能覆盖代理端口，退出时又恢复到另一组已经失效的值。

系统代理与网络服务

macOS 的系统代理按网络服务保存，Wi-Fi、有线网络和其他接口可能分别维护设置。客户端开启系统代理后，通常会为当前服务设置网页代理、安全网页代理和 SOCKS 代理。切换 Wi-Fi 到有线连接后若状态异常，应检查新网络服务是否也被客户端接管。企业网络的自动代理配置文件也可能与手工代理同时存在，需要先明确哪一种设置应当生效。

验证代理状态可以在系统网络详情中查看，也可以使用命令读取当前设置。代理服务器应为 127.0.0.1 或本机回环地址，端口与客户端一致。若客户端退出后网络中断，重新打开客户端关闭系统代理，或在系统设置中清理遗留选项。只删除应用而不恢复系统代理，会让浏览器继续把请求发送到已经没有程序监听的本地端口。

scutil --proxy
networksetup -listallnetworkservices
lsof -nP -iTCP -sTCP:LISTEN

终端中的 curl、包管理器和开发工具不一定完全遵循图形系统代理。需要临时测试时，可以仅在当前终端会话设置代理环境变量，并在测试完成后清除。端口应替换为客户端实际 mixed 端口，不要把示例值视为固定要求。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

curl -I https://example.com

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

TUN、系统扩展与本地网络

需要接管不读取系统代理的应用时，可在客户端中启用 TUN。macOS 可能要求输入管理员凭据、允许网络扩展或添加 VPN 配置。权限只需按照系统弹窗的对象逐项确认；若此前拒绝，可在隐私与安全性、网络扩展或 VPN 设置中重新检查。开关打开但接口创建失败时，日志通常会记录权限、服务或路由错误。

macOS 上同时运行企业 VPN、容器网络、虚拟机软件时，多个虚拟接口会竞争默认路由或 DNS。先关闭其他网络接管工具，确认 Clash 单独运行时的结果，再恢复必要软件。如果公司内网依赖指定 DNS 或搜索域，TUN 的 DNS 接管可能改变解析路径，应把内网域名和网段加入直连规则，并让对应查询使用可解析内部名称的服务器。

局域网访问异常时，不要直接把所有私有地址都交给代理。家庭路由器、打印机、文件共享和开发设备通常应保持直连。配置中的 allow-lan 控制其他设备能否连接本机代理端口，并不决定本机是否能访问局域网；局域网是否直连主要由规则和路由共同决定。只在明确需要共享代理时开启局域网监听，并配合系统防火墙限制网络范围。

CHAPTER 04 / ANDROID

Android：应用安装、VPN 接管与后台运行

安装与订阅导入

Android 可在Android 下载区优先选择 Clash Plus，也可使用 Clash Meta for Android、FlClash 或 Surfboard。下载包按架构区分时，新近的主流设备通常使用 arm64；较旧设备可能需要 arm 构建。无法确认架构时，优先选择客户端提供的通用包。安装系统若要求允许浏览器或文件管理器安装应用，只对本次使用的来源开启权限，安装结束后可按需要关闭。

首次启动后，在配置页面选择从 URL 导入，粘贴订阅链接并等待解析。移动网络可能对首次请求产生短暂切换，因此导入失败时要分别在 Wi-Fi 与移动数据下测试。配置下载成功后还需要将其设为活动配置，再进入代理组选择节点。仅看到配置名称并不能说明 VPN 已连接，状态栏出现 VPN 标识且客户端日志开始处理连接后，流量接管才真正建立。

通过二维码导入时，应确认二维码内容确实是订阅地址，而不是单个节点分享链接。单节点链接可能被客户端识别，但通常不包含完整规则与策略组。扫描过程需要相机权限，从相册识别则需要图片访问权限；若不希望提供这些权限，直接复制 URL 是更清晰的路径。导入后可删除包含订阅二维码的临时截图，避免在相册同步中长期留存。

Android VPN 与应用分流

Android 客户端通常通过系统 VPN 接口接管流量。首次连接时系统会显示 VPN 授权窗口，确认后客户端才能创建接口。系统同一时间通常只允许一个常规 VPN 生效，因此其他 VPN、过滤工具或使用本地 VPN 接口的防火墙会被断开。若连接按钮反复回到停止状态，应先检查是否有另一应用正在持续争用 VPN 权限。

部分客户端提供按应用代理或绕过列表。规则模式解决的是域名、IP 与规则集如何选择出口，按应用分流解决的是哪些应用进入 VPN，两者处在不同层。某应用被设为绕过后，其连接不会进入 mihomo，后续域名规则也就无法处理它。排查单个应用不可用时，先检查应用分流名单，再查看规则命中，最后确认所选节点是否支持该应用需要的协议与网络环境。

局域网设备发现、投屏和打印依赖多播或本地网段，VPN 接管后可能受到系统限制。可以先确认私有地址使用 DIRECT，并在客户端支持时允许局域网访问。即使规则正确，某些应用仍会基于 Android VPN 状态改变发现行为，此时应临时断开 VPN 对照测试，以区分是规则错误还是应用自身对虚拟网络的限制。

后台、省电与网络切换

Android 厂商的省电策略可能在熄屏后停止客户端后台进程。表现通常是刚连接时可用，锁屏一段时间后 VPN 图标消失或网络恢复直连。应在系统应用设置中允许后台活动，将电池策略调整为不限制或同等选项，并根据系统能力锁定最近任务。设置名称因系统界面不同而变化，判断标准是应用在熄屏和网络切换后仍能保持 VPN 服务。

从 Wi-Fi 切换到移动数据时，既有 TCP 连接无法沿用原网络路径，短暂中断属于正常重建过程。若长时间不恢复，可以在客户端内执行重连，而不是反复切换飞行模式。启用了“始终开启 VPN”时，系统可能同时启用阻止未经过 VPN 的连接；一旦客户端未成功启动，所有网络都会被阻断。启用这类系统策略前，应确认客户端在重启后可以稳定自启动。

DNS 异常在移动端常表现为部分应用可访问 IP、域名却失败，或同一站点在 Wi-Fi 与移动数据结果不同。先关闭私有 DNS、浏览器安全 DNS等额外变量进行对照，再检查客户端 DNS 模式。确定冲突来源后再决定保留哪一层，不应长期叠加系统私有 DNS、应用内 DNS 和多个过滤工具，却让每一层都尝试改写查询。

CHAPTER 05 / IOS

iOS：Clash Plus、VPN 配置与按需连接

安装与配置入口

iPhone 与 iPad 可从iOS 下载区进入 Clash Plus 的 App Store 页面，客户端相关信息也可查看官网 clashplus.io。安装完成后，先在系统设置中确认设备日期、网络和 App Store 登录状态正常。iOS 的网络接管由系统 VPN 框架管理，客户端无法绕过系统授权直接修改其他应用的连接。

打开 Clash Plus 后，从配置页面选择订阅导入，粘贴服务提供方给出的 Clash 兼容链接。若链接通过剪贴板传入，系统可能显示粘贴许可提示；拒绝后可以重新进入输入框并主动粘贴。导入完成后检查策略组与节点是否出现，再把该配置设为当前配置。订阅列表中的更新时间只表示最近一次请求结果，不代表节点连通性已经得到验证。

首次启动连接时，iOS 会要求添加 VPN 配置，并使用设备解锁凭据或生物识别确认。该步骤由系统完成，成功后可在状态栏或控制中心观察 VPN 状态。若系统设置中已存在其他 VPN，启动 Clash Plus 时通常会切换当前配置。企业管理设备还可能由管理策略限制新增 VPN，这类限制需要由设备管理方处理，反复安装应用不会改变系统策略。

规则模式、策略组与按需连接

日常使用建议先保持规则模式。规则模式会按配置中的域名、IP、规则集和最终 MATCH 规则决定 DIRECT 或代理策略；全局模式则把连接集中交给一个代理组，适合临时验证节点，不适合作为所有问题的永久绕过方法。若规则模式下某站点异常而全局模式正常，应查看该连接在日志中的命中规则，而不是简单认定节点失效。

策略组可能包括自动选择、故障转移、手动选择和直连。自动选择的结果取决于订阅定义的测试地址与间隔，并不表示任何时刻都适合所有业务。对稳定性要求较高时，可以在手动组中固定一个节点，排除自动切换变量；确认连接稳定后再恢复自动策略。切换节点只影响新建立的连接，已有会话可能继续使用旧路径，测试时应完全关闭并重新打开目标应用。

按需连接可以在特定网络条件下自动启用 VPN，但规则设置过宽会导致回家、进入公司或切换蜂窝网络时频繁重连。首次配置阶段先使用手动连接，确认订阅和规则稳定后，再根据可信 Wi-Fi、蜂窝网络等条件建立按需策略。设置后应实际测试锁屏、解锁、飞行模式恢复和网络切换，不能只依据开关状态判断。

iOS 的 DNS 与局域网权限

iOS 会限制应用对本地网络的访问。若需要访问 NAS、投屏设备或局域网控制页面，应在系统隐私设置中允许客户端或相关应用使用本地网络，并确保配置将私有地址设为直连。客户端本身拥有权限并不自动授予其他应用权限，具体访问还取决于目标应用和系统网络策略。

使用 fake-ip 模式时，DNS 返回的地址由内核映射到域名，再按规则处理。多数普通网页适合该模式，但依赖局域网发现、特殊域名解析或直接校验 IP 的应用可能需要加入 fake-ip 过滤。修改过滤项后应重新加载配置并建立新连接，因为旧 DNS 缓存不会随配置文本立即消失。问题只在某个 Wi-Fi 出现时，还应检查该网络是否要求门户认证。

连接显示正常但网页打不开时，先在 Safari 打开一个常规 HTTP 页面确认是否存在酒店、机场或校园网认证页。VPN 在认证完成前可能无法建立有效外部连接。完成认证后重新启动连接，再查看日志是否出现 DNS 超时、路由失败或节点握手错误。若蜂窝网络正常而指定 Wi-Fi 异常，优先处理该网络的认证、DNS 与 IPv6 条件，而不是立即更换订阅。

CHAPTER 06 / LINUX

Linux：桌面客户端、mihomo 服务与环境变量

桌面客户端与软件包选择

有桌面环境的 Linux 用户可在Linux 下载区选择 Clash Verge Rev 或 FlClash。下载前使用 uname -m 确认架构：常见桌面电脑多为 x86_64，ARM 设备可能显示 aarch64。同时确认发行版使用的包管理格式，Debian、Ubuntu 系通常使用 deb，其他发行版应选择明确支持的格式或采用适合本机的安装方式。

图形客户端启动后，订阅导入、策略组选择与系统代理逻辑和其他桌面平台接近。差异主要在桌面环境：GNOME、KDE 与精简窗口管理器对系统代理的实现并不一致，部分命令行程序完全忽略桌面代理。先在客户端内确认 mixed 端口正在监听，再分别测试浏览器、终端和需要代理的应用，不要把某一个浏览器的结果当作整个系统的结果。

安装软件包后若应用无法启动，可从终端执行程序以读取缺少依赖、权限或图形会话相关的错误。Wayland 与 X11 下托盘图标、窗口缩放和自动启动行为可能不同，但这些界面问题不一定影响内核运行。可以通过监听端口、进程列表和日志判断代理服务是否工作，再单独处理桌面集成。

直接运行 mihomo 内核

服务器、路由器或无桌面环境通常直接运行 mihomo。下载页的内核区提供不同架构构建，必须按 uname -m 结果选择。配置文件应存放在权限受控的目录，因为其中可能包含订阅展开后的认证信息。首次运行先在前台加载配置，观察语法检查、端口监听与规则加载是否成功，再编写 systemd 服务，避免服务反复重启却看不到首个错误。

mkdir -p ~/.config/mihomo
mihomo -d ~/.config/mihomo

ss -lntp
journalctl --user -u mihomo --no-pager -n 100

使用 systemd 用户服务时，工作目录、可执行文件路径和配置目录都应写为绝对路径。服务账户必须具备读取配置和写入缓存目录的权限。若需要绑定低位端口、修改路由或创建 TUN，应采用系统服务并明确授予必要能力，不要为了省略权限配置而让无关目录长期对所有用户可写。

[Unit]
Description=mihomo proxy core
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

终端代理、TUN 与防火墙

命令行工具最清晰的接入方式是为当前会话设置环境变量。HTTP 工具通常读取 http_proxy 与 https_proxy，需要 SOCKS 时可按工具能力使用 all_proxy。环境变量区分大小写的行为由具体程序决定，脚本中最好显式设置需要的形式。不要把代理变量永久写入所有系统服务的全局环境，否则软件更新、内网访问和本地管理任务也可能被意外转发。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5h://127.0.0.1:7890

curl -I https://example.com
env | grep -i proxy

Linux TUN 需要内核 TUN 设备、路由权限与防火墙规则配合。容器环境还可能需要开放 /dev/net/tun 和网络管理能力。开启前记录当前默认路由、策略路由和 DNS 配置，出现问题时才能回退。使用 nftables、iptables、firewalld 或发行版网络管理器时，应避免让多套工具同时维护同一批转发规则。

服务器开启 allow-lan 或监听所有地址会把代理端口暴露到网络接口。只有明确需要其他设备接入时才这样设置，并使用主机防火墙限制来源地址。作为本机代理使用时，监听 127.0.0.1 即可。检查端口时同时查看监听地址：端口存在不等于访问范围正确，监听在回环地址与监听在全部接口具有完全不同的边界。

DNS 由 systemd-resolved、NetworkManager、容器运行时或手工 resolv.conf 管理时，TUN 接管结果可能互相覆盖。先确认 resolvectl status 显示的每个接口 DNS，再判断查询是否进入 mihomo。若仅容器内解析失败，应分别检查宿主机、容器 DNS 和转发规则，不能只修改主机浏览器的代理设置。

CHAPTER 07 / CONFIGURATION

通用配置：端口、DNS、规则与订阅更新

最小可读配置与监听边界

图形客户端通常从订阅生成配置，不要求用户从零编写 YAML，但理解关键字段有助于判断界面开关实际改变了什么。下面示例展示本机 mixed 端口、规则模式、日志级别、控制接口和 DNS 的基础关系。它不是完整订阅，缺少 proxies 与 proxy-groups 时不能凭空产生可用线路；实际使用应由订阅提供节点，并在保留结构的前提下进行覆写。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mixed-port 同时接收 HTTP 与 SOCKS 连接，便于桌面系统代理和命令行工具共用一个入口。allow-lan: false 配合回环绑定表示只允许本机访问。若需要让同一局域网的手机或其他设备使用该端口，必须同时调整监听地址、防火墙与访问规则；只改一个开关可能仍然无法连接，也可能意外扩大暴露范围。

external-controller 是管理接口，不是普通代理端口。图形客户端可能通过它读取连接和切换策略。直接暴露到局域网时应设置认证并限制访问来源；本机客户端则应保持回环监听。端口冲突时不要随意删除控制接口，因为界面可能因此失去与内核的通信，应先判断冲突的是 mixed、DNS 还是 controller 端口。

DNS 模式与 fake-ip 过滤

DNS 决定域名如何解析，也为域名规则提供识别基础。fake-ip 模式先返回保留地址，再由内核把连接映射回原始域名，因此能够在应用只发起 IP 连接时保留域名规则信息。redir-host 更接近传统解析流程，对少数特殊程序兼容性较直接，但域名映射与缓存行为不同。模式选择应根据应用表现判断，不宜只凭“速度”概念切换。

局域网域名、连通性检测域名、时间同步以及部分对返回地址有特殊要求的应用，可能需要加入 fake-ip-filter。过滤意味着这些域名获得真实解析结果，不代表它们自动直连；最终出口仍由 rules 决定。修改后应清理系统 DNS 缓存、重新加载配置并重建连接。只刷新网页可能继续使用浏览器内部缓存，造成配置看似没有生效。

同时使用系统加密 DNS、浏览器独立 DNS 与客户端 DNS 时，一次查询可能绕过预期入口。排查阶段应暂时关闭额外层，只保留 mihomo DNS，观察日志能否看到域名和规则命中。确认基本链路后，再逐一恢复需要的安全 DNS 设置。关于泄漏检查与配置验证，可继续阅读Clash DNS 泄漏检测与防泄漏配置实操。

规则顺序与策略组

规则按从上到下的顺序匹配，第一条命中后不再继续。具体域名、进程或规则集通常放在较前位置，范围较大的 GEOIP、GEOSET 和最终 MATCH 放在后方。如果把 MATCH 放到前面，后续规则永远不会执行。修改规则后应在连接日志中检查“请求域名—命中规则—目标策略”三者，而不是只观察最终网页能否打开。

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN-KEYWORD,example,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

RULE-SET 用于引用独立规则集合，便于更新和复用。规则提供者下载失败时，已有缓存可能仍能运行，但新安装或缓存清理后会暴露问题。应检查 provider 地址可达性、behavior 类型与规则内容是否一致，以及策略名称是否真实存在。规则命中一个不存在的策略组时，配置通常会在加载阶段报错。

策略组名称由订阅决定，示例中的 PROXY 不是所有配置都固定存在。覆写规则时必须使用当前配置里的实际组名。全局模式会绕过大部分规则判断，把流量交给指定全局组；直连模式则跳过代理出口。三种模式的差异可参考规则、全局、直连三种模式说明。

订阅更新与覆写关系

订阅更新通常会重新下载并替换远程配置。如果直接编辑订阅生成的 YAML，下一次更新可能覆盖修改。支持覆写、脚本或 Mixin 的客户端应把本地端口、DNS 和附加规则放入专用覆写层；不支持时，应保留修改记录，并在更新后重新核对。不要通过永久关闭更新来保护一处修改，这会同时失去节点、策略和规则的正常变化。

自动更新间隔不宜短到频繁请求，也不应长到无法及时取得服务方调整。遇到更新失败，应区分 HTTP 请求失败、返回内容变化、解析错误和代理环路。客户端若使用当前代理请求订阅，而订阅域名又被错误规则送入不可用节点，就可能形成更新环路。详细步骤见订阅更新失败排查与自动更新设置。

CHAPTER 08 / TROUBLESHOOTING

配置常见问题：按流量路径逐层定位

客户端启动但没有网络

排查顺序应沿真实流量路径进行：目标应用是否把请求交给本地代理，本地端口是否监听，内核是否加载当前配置，规则是否把连接交给预期策略，节点是否能够建立远端连接，DNS 是否返回可用结果。只看到客户端主界面显示“运行中”，只能证明进程存在，不能证明以上每一层都成功。

先关闭 TUN，仅保留系统代理，使用浏览器访问常规站点。若浏览器失败，检查系统代理地址是否为本机、端口是否和客户端一致，再查看日志有无连接记录。没有任何日志通常意味着流量没有进入客户端；有请求但立即报拒绝，常见于端口错误或内核未启动；有规则命中但远端握手失败，则继续检查节点和网络条件。

若关闭系统代理后仍无法访问网页，可能存在代理残留、DNS 缓存或其他 VPN 路由。Windows 检查系统代理，macOS 检查当前网络服务，移动系统检查 VPN 状态，Linux 检查环境变量与默认路由。重启设备可以清理部分临时状态，但应在重启前记录设置和日志，否则复现后仍不知道是哪一层改变。

订阅无法更新或解析失败

订阅更新失败先用浏览器访问原链接，确认返回状态。如果链接不可达、过期或返回登录页面，应在服务提供方侧更新地址。浏览器可访问但客户端失败时，再检查客户端网络权限、当前代理规则和系统时间。证书连接依赖准确时间，设备时间偏差过大时可能出现看似网络故障的安全连接错误。

解析失败通常意味着返回内容不是兼容 YAML、字段结构不被当前客户端识别，或内容被网页认证与错误页面替代。不要只看 HTTP 状态码，返回成功也可能是一段 HTML。可将返回内容保存到本地，检查开头是否为配置字段，并确认缩进与编码。完整的逐项判断可参考订阅失效与解析失败自查清单。

导入后节点为空时，先确认选用的是 Clash 或 mihomo 格式，而不是仅适配其他工具的订阅。节点存在但策略组为空，可能是配置转换缺少 proxy-groups。不要手工把大量节点逐个复制到新文件，优先从订阅来源重新取得正确格式，避免认证字段和协议参数在复制中损坏。

只有部分网站或应用失败

部分网站失败时先查看连接日志中的域名、命中规则和策略。若误命中 DIRECT，应调整具体规则并放在更宽泛规则之前；若已经进入代理但失败，固定一个已验证节点重试，排除自动策略切换。若浏览器正常而某应用失败，检查该应用是否读取系统代理，必要时测试 TUN 或移动端应用分流。

网站打开但图片、登录或视频失败，往往是主域名与资源域名命中不同策略。开发者工具或连接列表可以看到附属域名，再判断是否应使用同一策略。不要用一条过宽的 DOMAIN-KEYWORD 规则覆盖所有相似名称，这可能把无关服务一起改变。更稳妥的方式是采用维护良好的规则集，或为明确的域名后缀添加规则。

节点切换后问题短时间保留，可能来自 DNS、HTTP/2、QUIC 或应用会话缓存。完全退出目标应用、清理必要缓存并重新建立连接后再测。浏览器隐私窗口只能减少部分缓存，不能替代系统 DNS 刷新。对比测试应每次只改变一个变量，并记录模式、节点、网络与命中规则。

DNS、端口与 TUN 冲突

DNS 故障的典型特征是 IP 可达而域名失败、日志持续出现查询超时，或相同域名在不同应用得到矛盾结果。先检查本地 DNS 监听端口是否被占用，再关闭浏览器独立 DNS和系统额外 DNS工具进行对照。fake-ip 模式下看到保留地址是设计行为，不应把该地址本身当作远端服务器故障。

端口冲突会导致代理或控制接口无法监听。查看日志中的 bind、address already in use 等信息，再用系统工具定位占用进程。修改端口后，系统代理、终端环境变量、浏览器扩展和局域网设备都必须同步更新。只改客户端字段而保留旧系统代理，会形成“内核运行正常但没有请求进入”的状态。

TUN 开启后全网断开时，先关闭 TUN 恢复基线，再检查虚拟接口权限、默认路由、DNS 劫持与其他 VPN。桌面虚拟机、容器、游戏加速器和企业网络软件都可能安装网络过滤驱动。按顺序停用冲突工具，每次只恢复一个。若问题只在休眠唤醒后出现，应重建 TUN 接口并观察路由是否残留。

日志怎么读，何时回退

日常排查使用 info 级别即可，debug 日志只在需要短时采集细节时开启，因为它会产生大量连接记录。重点寻找配置加载错误、监听失败、DNS 超时、规则命中、远端握手和路由创建信息。分享日志前移除订阅地址、认证字段、节点凭据与不希望公开的访问域名。

当多个修改叠加后无法判断，应回退到最小状态：停用 TUN 和覆写，只加载一份原始订阅，使用默认本地端口，固定一个节点，通过系统代理测试浏览器。基线恢复后，按“自定义 DNS—附加规则—TUN—局域网共享”的顺序逐项加回。某一步加入后立即复现，就能把调查范围限定在该层。

如果原始订阅在多个网络、多个客户端都无法连接，而链接返回内容正常，应联系订阅服务提供方确认节点状态；如果同一订阅在其他设备可用，则优先检查本机权限、端口、DNS 与路由。重新安装客户端只适合修复程序文件或系统集成损坏，不会自动修正订阅格式、规则逻辑和远端节点状态。

完成排查后，应把最终有效的客户端、配置名称、代理模式、DNS 选择和必要覆写记录在本地。后续更新只需与这份基线比较，不必重新猜测整条流量路径。需要重新安装或更换平台时，可返回客户端下载页核对系统架构与可用客户端。