FlClash Help · Install / Profile / Proxy / TUN / DNS 围绕 FlClash 在 Android、Windows、macOS 与 Linux 上的安装、Profile、Override、系统代理、TUN、DNS、端口、连接和日志整理常见问题。排查时先确认 FlClash 与 Mihomo Core 是否正常，再逐层检查配置、流量接入方式和上游网络。 FlClash 是客户端与配置管理层，Mihomo Core 执行代理、Rules、DNS 和 TUN；Profile 提供具体节点和策略。把三者分开检查，比同时修改多个设置更容易定位问题。 FlClash 安装后为什么不能直接连接？ FlClash 本身不提供代理节点或订阅服务。首次使用需要导入订阅链接或本地 Profile，确认 Mihomo Core 能加载配置，再选择代理组并启用适合当前设备的网络接入方式。 Profile 导入成功却没有节点，先看哪里？ 先确认订阅实际返回有效的 Mihomo 配置，再检查当前激活的 Profile、更新时间、Override / Override Script 和 Core 加载错误。空响应、格式异常或覆写错误都会导致节点缺失。 系统代理、TUN 与 Android VPN 怎么区分？ 桌面系统代理主要影响遵循系统代理设置的应用；桌面 TUN 通过虚拟网卡接管更广的流量；Android 则通过系统 VpnService 接入。三者都只是把流量送入 Mihomo，具体出口仍由 Rules 和代理组决定。 按 FlClash 使用阶段查找问题 从安装、Profile、流量接入到运行排障分别处理，避免把客户端安装问题、Mihomo 配置问题和节点网络问题混在一起。 FlClash 平台、架构与首次启动问题 FlClash 官方支持 Android、Windows、macOS 与 Linux。下载时先确认平台、CPU 架构和安装包格式，再处理权限、Linux 依赖或系统兼容问题。 官方项目明确支持 Android、Windows、macOS 和 Linux，并使用 Flutter 构建统一的多平台客户端。当前官方 README 没有把 iOS 列为支持平台，因此不要把第三方 iOS 客户端当成 FlClash 官方版本。 大多数 Intel / AMD 64 位 Windows 电脑选择 amd64；Windows on ARM 设备选择 ARM64。FlClash 当前 Windows 构建提供 exe / zip 形式，具体文件名和架构应以当前 Release Assets 为准。 Apple M 系列芯片选择 macOS arm64 构建，Intel 处理器 Mac 选择 amd64 构建。FlClash 官方 README 还提供 Homebrew cask 安装方式。 FlClash 构建系统区分 arm、arm64 和 x64 Android 目标。多数现代手机和平板使用 arm64；较旧 ARM 设备或 x86_64 模拟器应根据设备 ABI 选择对应 APK。 官方 README 要求 Linux 安装 libayatana-appindicator3-dev 与 libkeybinder-3.0-dev。构建系统还提供 DEB，并为 amd64 增加 AppImage / RPM；实际包格式和架构以当前 Release 为准。 项目维护者已经关闭 Windows 7 支持请求并标记为 not planned。当前使用应以受支持的现代 Windows 环境和最新 Release 为准，不建议把 Windows 7 作为可保证兼容的平台。 Profile 与 Override 订阅、YAML、覆写与最终 Mihomo 配置 FlClash 通过 Profile 管理远程订阅或本地配置，并可使用 Override、附加规则与 Override Script 调整最终运行配置。排错时应区分原始 Profile 与传给 Mihomo Core 的最终配置。 Profile 是配置来源，可以来自订阅 URL 或本地文件。FlClash 会结合当前客户端设置和覆写层生成最终配置，再交给 Mihomo Core 执行代理组、Rules、DNS、TUN 等行为。

先确认订阅地址返回的是有效配置，再检查当前 Profile 是否激活、是否成功更新，以及 Override / Override Script 是否改变了 proxies、proxy-groups 或其他字段。Core 的配置加载错误也会导致节点无法显示。 标准 Override 用于覆盖基础配置并追加简单规则；Script 模式通过外部扩展脚本执行更灵活的配置覆写。两种方式都会影响最终交给 Mihomo Core 的配置，因此排错时要同时检查覆写层。 当前项目存在关于“多配置文件 Merge”的开放 Feature Request，因此不应把多 Profile 合并描述成已经稳定提供的核心功能。现有正式术语应以 Profile、Override、Override Script 和附加规则为主。 先确认订阅 URL 在当前网络下可访问且返回有效内容，再检查自定义 User-Agent、TLS、网络错误和更新日志。只有订阅源本身正常时，才适合继续排查 FlClash 的 Profile 更新流程。 不同客户端可能使用不同 Mihomo 版本、覆写逻辑、默认 DNS/TUN 参数和系统网络接入方式。比较问题时应查看最终生效配置、Core 版本和当前系统环境，而不是只比较原始 YAML。 Rule / Global / Direct、系统代理与 TUN 问题 代理模式决定 Mihomo 如何选择出口，系统代理或 TUN 决定流量如何进入 Mihomo。两者属于不同层级，开启 TUN 并不会自动改变 Rules 或当前代理组选择。 Rule 按当前 Mihomo Rules 决定每条连接的出口；Global 让流量统一交给全局代理策略；Direct 则直接连接。日常使用通常应根据 Profile 的规则设计选择，而不是长期固定使用某一种模式。 部分桌面应用不会读取操作系统代理设置，或使用自己的网络栈。先检查应用自身的代理设置；确实需要接管更广泛的系统流量时，再考虑 TUN。 系统代理修改桌面操作系统的代理设置，主要影响遵循这些设置的应用；TUN 通过虚拟网卡和路由接管更广的流量，并依赖管理员权限、DNS、路由和防火墙环境。 Android 主要通过系统 VpnService 将流量交给 FlClash / Mihomo，而桌面端还可以使用操作系统级的 System Proxy。不同平台的系统接口不同，因此界面和可用接入方式不会完全一致。 不需要。桌面浏览器和其他遵循系统代理的应用通常只开 System Proxy 就可以工作；Android 则使用系统 VPN 接口。TUN 主要用于需要接管更多不遵循系统代理设置的桌面流量。 先关闭 TUN 确认基础网络恢复，再检查 Core 状态、管理员权限、TUN stack、auto-route、DNS、strict-route 以及其他 VPN / 虚拟网卡冲突。每次只改一个变量，便于判断是哪一层导致问题。 Core、端口、DNS、Connections 与 Logs 怎么排查 运行问题建议从客户端和 Core 状态开始，再检查最终 Profile、端口、DNS、规则命中和连接记录，最后才判断是否属于节点或上游网络故障。 延迟测试只代表特定探测目标的响应时间，并不等于实际带宽或目标站点链路质量。继续检查当前代理组选择、Connections、节点负载、DNS、目标站点和本地网络。 FlClash 提供 Mixed Port、SOCKS Port、Redir Port 和 TProxy Port 等配置项。端口被占用时应换成未使用端口，并确认系统代理或其他手动代理配置也同步指向新的监听端口。 先查看 Logs / Core 状态并确认最终配置是否合法，再检查端口冲突、文件完整性和系统权限。不要只修改原始订阅，因为错误也可能来自 FlClash 的 Override、DNS 或 TUN 设置。 优先检查 DNS：enhanced mode、default-nameserver、nameserver、proxy-server-nameserver、nameserver-policy、Fake-IP 与 respect-rules。DNS 与 Rules 配合错误时，可能出现解析成功但路由异常，或节点域名自身无法解析。 Connections 用于查看当前连接及其网络路径，Requests 用于观察请求记录，Logs 用于查看客户端和 Core 运行日志。排障时三者可以帮助确认流量有没有进入 Mihomo、命中了什么规则以及 Core 是否报错。 如果 FlClash 与 Mihomo Core 正常运行、最终配置可以加载、System Proxy / TUN 或 Android VPN 状态正确，而且问题只发生在单个节点、单个域名或特定网络环境，更应继续检查节点服务、DNS 上游、目标站点或本地网络。 需要安装包选择或完整配置步骤？ 下载页负责 Android、Windows、macOS 与 Linux 的安装包和架构选择；配置教程负责 Profile 导入、Override、System Proxy、TUN 和常用操作。涉及 Mihomo 字段和 External Controller，则继续查看开发者文档。