FlClash进阶教程：规则、TUN、DNS与覆写排障步骤

更新于 2026-10-24 · vpnpn.shop

简答：FlClash进阶配置建议按“备份Profile→确认代理组→选择Rule、Global或Direct→决定System Proxy、Android VPN或TUN→再调整DNS与Override”的顺序操作。规则不生效时，先检查最终运行配置、连接日志和规则命中情况，不要直接反复修改远程订阅原文件。不同版本的菜单名称可能变化，请以当前界面和官方项目资料为准。

定义：FlClash是一个基于ClashMeta的多平台代理客户端，Profile提供基础配置，Override保存本地调整，而System Proxy、Android VPN或桌面TUN决定流量如何进入内核。

先试这一步：把“基础可用”和“进阶配置”分开验证

FlClash本身不是节点或订阅服务，而是用于管理配置文件、代理组、规则和流量接管的客户端。其公开项目资料显示，项目基于ClashMeta并提供Android、Windows、Linux和macOS构建方式，可通过FlClash项目仓库核对项目来源。

备份当前Profile、Override和本地配置，记录当前可用节点与代理组。
关闭其他VPN、代理软件或可能修改系统代理的工具，避免多个流量入口互相覆盖。
确认订阅更新成功，代理组中有成员，并手动选择一个已知可用节点。
先用Rule模式验证普通网页，再分别测试Global和Direct；不要一开始同时开启TUN、DNS覆写和大量自定义规则。
每次只改一个项目，并记录修改字段、是否重新加载配置以及连接日志变化。

现象	优先检查	暂时不要做
所有应用都无法连接	节点、代理组、系统代理或TUN状态	不要先改大量规则
浏览器可用，命令行不可用	命令行是否遵循系统代理，是否需要TUN	不要直接判断节点失效
只有部分域名异常	规则顺序、DNS和规则集更新状态	不要马上切换全部流量到Global
开启TUN后断网	权限、路由、DNS劫持和其他VPN冲突	不要连续更改多个stack参数

Rule、Global、Direct与代理组如何配合

Rule、Global和Direct是流量决策模式，并不等同于节点。Rule根据规则匹配结果交给指定策略组，Global通常将流量交给全局策略，Direct则直接连接。实际行为还取决于Profile中的proxy-groups、rules、DNS和客户端本地设置。

模式	适合场景	排错重点
Rule	希望不同域名或应用分别直连、代理	规则是否命中、顺序是否正确、策略组是否有可用成员
Global	临时确认节点和统一出口是否可用	全局策略组是否选中了节点；Global不保证所有应用都进入客户端
Direct	验证本地网络、DNS和直连状态	Direct也失败时，问题可能不在规则或节点

代理组排错时建议先手动选择节点，便于确认实际使用对象。确认多个节点都能连接后，再考虑url-test或fallback。一次测试中的低延迟只代表特定请求的往返时间，不等于持续速度、稳定性、丢包率或某个应用的实际体验。

规则配置：先处理优先级，再检查规则集和策略组

常见规则包括DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、PROCESS-NAME、RULE-SET和MATCH。实际字段和行为应以当前配置与Mihomo文档为准。

先用一个明确域名做测试，不要同时加入大量关键词规则。
将更具体的规则放在更宽泛的规则前面，例如先处理单个域名，再处理域名后缀。
检查规则指向的策略组名称是否真实存在，策略组中是否有节点或可用的嵌套组。
更新规则集后查看更新时间、错误日志和实际命中记录；更新失败时检查URL、TLS、网络和返回内容。
如果域名解析后进入了IP-CIDR规则，同时检查DNS模式和规则顺序，不要只查看域名规则。
确认末尾的MATCH兜底策略符合预期，避免前面的规则全部未命中后流量被错误处理。

规则不生效时，重点不是只看远程订阅文本，而是确认客户端最终加载的配置。Profile、Override和本地脚本可能共同影响运行配置，因此应结合连接记录、规则命中信息和实际应用测试判断。

Override怎么改，才能减少订阅更新后的丢失

直接修改远程订阅生成的YAML，下一次更新后可能被重新生成的内容覆盖。更稳妥的做法是把本地规则、DNS或策略调整放入Override；复杂字段转换再考虑Override Script。这里的关键不是修改更多内容，而是让本地改动与远程基础Profile分离。

先导出当前配置或复制本地文件，确认有可用的恢复版本。
优先添加少量、目的明确的本地规则，不要一次覆盖代理组、DNS、TUN等多个区域。
保存后重新载入Profile，检查最终配置中相关字段是否仍然存在。
通过连接记录、DNS查询记录或实际应用测试确认Override真的生效。
订阅更新后再次检查；如果本地修改失效，区分Override未加载、字段冲突或策略组名称变化。

回滚时先停用最近新增的Override条目，恢复到上一次已知可用状态，再逐项启用。不要在没有备份的情况下直接删除整个配置。

System Proxy、Android VPN与TUN怎么选

三种入口解决的是不同问题：桌面System Proxy修改操作系统代理设置，通常只影响遵循系统代理的应用；Android VPN使用系统VPN接口；桌面TUN创建虚拟网络接口，可覆盖更多不读取系统代理的程序。Mihomo官方文档将TUN用于系统流量接管、自动路由、DNS劫持和按应用路由等场景，具体行为取决于平台与字段设置。Mihomo TUN配置文档

入口	优先适用	常见限制
System Proxy	浏览器、常见桌面应用和基础验证	不遵循系统代理的程序可能不受影响
Android VPN	Android上需要系统接管应用流量	可能与其他VPN、Private DNS或电池策略冲突
TUN	命令行工具、部分开发工具、游戏或不读取系统代理的应用	需要权限，可能涉及路由、DNS劫持和虚拟网卡冲突

开启TUN前先关闭其他VPN，确认客户端有创建虚拟网卡的权限，并保留关闭TUN的回滚路径。官方文档说明，auto-route、strict-route、dns-hijack、dns-mode和mtu会影响路由、DNS和传输行为；普通用户通常可以先保持MTU默认值。

TUN断网时按顺序回滚：关闭TUN并恢复System Proxy或Direct→确认基础节点可用→只重新打开TUN→再检查DNS劫持→最后测试strict-route、stack或接口选择。

DNS、Fake-IP与浏览器安全DNS的排查顺序

Mihomo DNS支持fake-ip和redir-host等增强模式，也提供DNS监听、IPv6、fake-IP过滤器、nameserver-policy和DNS劫持等配置。官方文档列出了这些字段及其默认行为，可参考Mihomo DNS配置文档。

先在FlClash的DNS或连接记录中确认请求是否产生。
比较Rule、Global和Direct三种模式下同一域名的解析与连接结果。
临时关闭浏览器安全DNS或自定义DoH，确认是否绕过了客户端DNS。
如果只有IPv6访问异常，分别测试IPv4和IPv6，不要直接清空全部DNS设置。
检查TUN的DNS劫持状态、Android Private DNS、系统hosts和其他网络工具是否重复接管。

DNS解析成功不代表后续连接一定成功。排查时将“解析成功”“TCP或QUIC建立”“应用页面加载”分成三层记录，才能判断问题位于DNS、节点、路由、TLS还是应用自身代理设置。

按平台和应用类型做最终验证

Windows：先验证系统代理，再验证TUN。UWP应用、虚拟机、容器和安全软件可能使用独立网络路径；只有某类应用异常时，先确认它是否遵循系统代理。

macOS：检查系统代理是否正确写入，并留意其他VPN、网络扩展和IPv6设置。关闭FlClash后若系统仍无法联网，先恢复系统网络代理状态。

Linux：命令行工具通常需要显式设置HTTP、HTTPS或SOCKS代理，或者通过TUN接管；同时检查网卡名称、路由和权限。终端变量生效不代表所有图形程序都会使用代理。

Android：确认VPN权限、Private DNS、电池限制和其他VPN是否冲突。单个应用异常时，比较全局应用接管与分应用设置，再检查应用是否使用独立DNS或QUIC。

浏览器、命令行、游戏和开发工具：浏览器常遵循系统代理，但命令行、游戏、Git、容器和部分开发工具可能需要单独配置；如需TUN，先用一个应用做最小化测试，确认稳定后再扩大接管范围。

联系运营商或服务方前的速查卡

设备与系统：Windows、macOS、Linux或Android，具体版本。
客户端状态：FlClash版本、当前Profile名称、是否刚更新订阅。
连接对象：哪个应用、哪个域名、哪个节点或策略组异常。
模式对照：Rule、Global、Direct的结果是否一致。
接入方式：System Proxy、Android VPN、TUN是否开启，是否有其他VPN。
DNS信息：增强模式、浏览器安全DNS、IPv6和Private DNS状态。
时间线：从何时开始，改过哪些字段，回滚后是否恢复。
可复现证据：错误日志、连接日志、规则命中记录和订阅更新返回信息。

判断是否属于跨境线路问题前，先做本地对照：国内站点或本地服务正常、只有境外目标慢或丢包时，才继续核对节点、出口和跨境链路；如果所有站点都异常，应先排查本地网络、DNS、系统代理和TUN。

常见问题

FlClash进阶配置应该先开TUN还是先改规则？

先验证订阅、节点、代理组和Rule模式，再处理规则，最后根据应用是否遵循系统代理决定是否启用TUN。一次同时修改多个层级，会让故障原因难以区分。

为什么FlClash全局模式打开后，某些应用仍然不能连接？

Global只改变客户端的路由决策，不保证所有应用流量都会进入客户端。应用可能不遵循系统代理、使用独立网络栈或受到防火墙限制，可用TUN做单应用对照测试。

Override会不会被订阅更新覆盖？

Override用于把本地修改与基础Profile分离，但仍需确认当前版本的Override已加载且字段没有冲突。订阅更新后应检查最终配置和规则命中记录，失效时先停用最近改动。

url-test测出的低延迟节点是不是一定最快？

不是。延迟测试只反映特定测试请求的往返时间，不能直接代表下载速度、持续稳定性、丢包率或某个应用的实际体验。选择节点时应结合连接建立和持续使用验证。

TUN开启后断网，怎样最快恢复？

先关闭TUN，恢复System Proxy或Direct做基础连通性测试，再确认其他VPN已退出、客户端有创建虚拟网卡的权限。恢复后只重新打开TUN，最后逐项测试DNS劫持、路由和stack参数。

DNS正常但网页仍打不开，问题还可能在哪里？

DNS只说明域名解析阶段可能成功，后续仍可能受节点、路由、TLS、IPv6、QUIC或应用自身代理设置影响。建议分别记录解析、连接建立和页面加载三个结果。