Clash 全平台安装配置大全 - Windows、macOS、Android、iOS 与 Linux

一、安装前的通用准备工作

先区分客户端、内核与配置文件

Clash 的实际使用链路由三个部分组成。图形客户端负责显示配置、切换策略、控制系统代理和管理更新；内核负责解析规则、建立连接、处理 DNS 与 TUN 流量；配置文件则保存代理入口、策略组、分流规则、端口和 DNS 参数。多数桌面与移动客户端已经打包兼容内核，普通用户不需要单独下载 Mihomo。只有服务器、路由器、容器环境或需要自行维护服务进程时，才应直接部署内核。

订阅链接也不是客户端自动生成的内容。它通常由网络服务提供方给出，客户端只负责读取链接并转换为本地配置。公开代码仓库、客户端官方网站和本站下载页都不提供可直接使用的代理订阅。收到订阅地址后，应把它视为敏感信息，不要放进截图、公开工单、命令历史共享文件或可公开访问的代码仓库。若只拿到一份 YAML 文件，也可以使用本地配置导入，不必先转换成订阅链接。

选择与设备匹配的客户端

首次安装优先选择图形客户端。Windows、macOS、Android 与 iOS 可先查看 Clash Plus；Windows 和 macOS 还可根据界面偏好选择 Clash Verge Rev、FlClash 或 Clash Nyanpasu；Android 可选 Clash Meta for Android、FlClash 或 Surfboard；Linux 桌面可选 Clash Verge Rev 与 FlClash。Clash for Windows 与 ClashX Meta 已停止维护，仅适合处理历史环境，不建议作为新安装的起点。全部可用入口集中在客户端下载页，不要根据旧教程中的文件名判断当前包是否适用。

下载前先确认处理器架构。Windows 常见设备使用 x64；Windows on ARM 设备需要确认客户端是否提供对应构建。Apple Silicon Mac 使用 arm64 架构，旧款 Intel Mac 使用 x64。Android 安装包常见 arm64、arm 与通用构建，近年的主流手机通常是 arm64，但不应仅凭品牌判断。Linux 还要同时区分 CPU 架构与包格式：Debian、Ubuntu 常用 deb，Fedora 系发行版常用 rpm，压缩包则需要自行配置可执行权限和服务管理。

平台	优先选择	安装前确认	流量接管方式
Windows	Clash Plus	x64 架构、管理员权限需求	系统代理或 TUN
macOS	Clash Plus	Apple Silicon 或 Intel	系统代理或 TUN
Android	Clash Plus	CPU 架构、系统 VPN 权限	本地 VPN 服务
iOS	Clash Plus	App Store 账号与系统权限	Network Extension
Linux	Clash Verge Rev	发行版、桌面环境、架构	桌面代理、TUN 或服务进程

整理安装所需信息

开始前准备订阅链接或 YAML 文件、设备管理员权限、可正常联网的基础网络，以及一个用于验证结果的浏览器。公司或校园设备可能由管理策略锁定代理、VPN、网络扩展和证书设置，此时即使客户端安装成功，也未必能修改系统网络状态。不要连续反复开启多个同类客户端。两个程序同时监听相同端口、写入系统代理或创建 TUN 接口时，常出现启动失败、网络循环和退出后无法恢复连接等问题。

默认配置经常使用 mixed-port 作为 HTTP 与 SOCKS 的统一入口。端口值由配置决定，常见示例是 7890，但客户端界面显示值应作为最终依据。手动填写浏览器或终端代理时，主机通常是本机回环地址 127.0.0.1，端口则必须和正在运行的配置一致。不要把订阅服务的远端端口误填到系统代理中，也不要把局域网地址作为默认监听地址，除非确实需要让其他设备接入。

理解规则、全局与直连模式

规则模式按照配置中的 rules 从上到下匹配域名、IP、进程或规则集，并把连接交给指定策略组，是日常使用的默认选择。全局模式忽略分流规则，把可代理流量统一交给全局策略，适合短时间判断规则是否误判，但不适合长期保持。直连模式绕过代理，主要用于恢复基础网络或确认故障是否来自客户端。模式切换不会修复无效订阅，也不会自动替换策略组里不可用的选择。

导入后应先查看策略组。常见组名包括 Proxy、Auto、Streaming、Final 与 REJECT。手动选择组需要明确选中一个可用策略；自动测试组会依据配置定义的测试方法更新选择；Final 一般承接前面规则均未命中的连接；REJECT 用于拒绝匹配流量。不同订阅生成的名称可能不同，操作时应依据组的类型和用途判断，不能机械寻找固定中文按钮。

二、Windows 下载、安装与系统代理配置

下载与安装图形客户端

Windows 新安装可从Windows 客户端区选择 Clash Plus。也可以使用 Clash Verge Rev、FlClash 或 Clash Nyanpasu。Clash for Windows 已停止维护，只应在必须兼容旧配置或迁移历史数据时使用。下载完成后运行安装包，若系统弹出用户账户控制提示，应确认文件来源和当前操作，再决定是否授权。安装目录尽量使用普通本地磁盘路径，避免放在临时目录、同步盘或受企业策略限制的文件夹中。

部分客户端提供当前用户安装与所有用户安装。前者通常不需要持续使用管理员权限，后者便于多账户共享程序文件，但配置数据仍可能分别保存在用户目录。若准备启用 TUN、安装服务或设置开机启动，客户端可能在首次操作时请求管理员权限。仅开启传统系统代理时，通常不需要一直以管理员身份运行。长期强制管理员运行会让拖放、浏览器调用和普通用户目录访问出现额外边界，不应把它当成通用修复手段。

导入订阅与确认配置激活

进入配置文件或 Profiles 页面，选择从 URL 导入，将完整订阅地址粘贴到输入框后执行下载。导入成功并不等于配置已启用，还要在配置列表中选中刚导入的条目，使它成为当前配置。若使用本地 YAML，选择本地文件导入或把文件放入客户端允许的配置目录。直接编辑客户端内部缓存文件可能在订阅更新时被覆盖；需要长期保留的自定义规则，应使用客户端提供的覆写、合并或脚本功能。

配置激活后依次检查代理模式、策略组和端口。规则模式适合日常使用。打开 Proxy 等手动策略组，选择订阅中实际存在的策略；若配置包含 Auto 或 url-test 组，可先触发一次更新。此处不要用界面是否出现绿色状态作为唯一判断，仍需在后续验证真实连接。若配置下载后列表为空，通常是订阅返回格式、授权状态或网络访问问题，而不是系统代理开关造成的。

系统代理与 TUN 的适用范围

Windows 系统代理会把本机代理地址写入系统设置。遵循 WinINET 或系统代理设置的浏览器与桌面应用会自动使用它，但部分游戏、命令行工具、商店应用和自行实现网络栈的软件可能忽略该设置。启用后可在 Windows 的代理设置中看到本地地址和端口。正常退出客户端时通常会恢复设置；若程序被强制结束或系统异常关机，可能留下指向已停止端口的代理项，表现为所有网页都无法打开。

TUN 模式通过虚拟网络接口接管更广泛的 IP 流量，适合不读取系统代理的应用。首次启用可能安装驱动或系统服务，并触发管理员授权。开启后应观察路由表、DNS 与防火墙是否正常，不要同时运行其他创建 TUN 或全局 VPN 接口的软件。系统代理和 TUN 能否同时开启取决于客户端实现；对于初次排查，建议只保留一种接管方式，确认稳定后再决定是否组合使用。

命令行、终端与开发工具

PowerShell、命令提示符、Git、包管理器和开发语言运行时并不总是读取 Windows 系统代理。需要时可在当前终端会话设置环境变量，端口应替换为客户端当前 mixed-port。临时变量只影响该终端及其子进程，关闭窗口后失效，适合测试；写入用户级环境变量前应确认不会让离线开发、局域网服务或容器工具走错路径。

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7890"

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

若之后停用客户端，应同时删除持久化的 Git 代理配置，否则 Git 会继续连接本机已关闭的端口。可使用 git config --global --unset http.proxy 与对应的 HTTPS 命令清理。终端能访问而浏览器不能访问，优先检查系统代理、浏览器扩展与安全软件；浏览器能访问而终端不能访问，则重点检查环境变量、Git 配置和工具自己的代理字段。

Windows 特有故障边界

端口占用是 Windows 上常见的启动失败原因。客户端日志若显示地址已被使用，应先确认是否有另一个 Clash 实例或残留进程，再决定结束进程还是修改 mixed-port。完整定位方法可参考端口占用排查步骤。修改端口后，系统代理、浏览器手动代理、终端环境变量和局域网设备都必须同步调整。

退出后网络中断时，先关闭 Windows 手动代理，再检查是否遗留虚拟网卡、代理环境变量或其他 VPN。不要立即重置全部网络组件，因为这会同时清除虚拟交换机、静态 DNS 和开发环境配置。应先确认客户端进程已经结束，再逐层恢复：系统代理、DNS、默认路由、TUN 服务。若只在休眠唤醒后失效，可先重启客户端核心，再重建 TUN；频繁重装通常不能解决由路由竞争或安全策略引起的问题。

三、macOS 安装、网络扩展与代理切换

按处理器架构选择安装包

macOS 下载前先打开“关于本机”确认芯片类型。Apple Silicon 对应 arm64 构建，Intel 处理器对应 x64 构建。新安装可从macOS 客户端区选择 Clash Plus，也可使用 Clash Verge Rev 或 FlClash。ClashX Meta 已停止维护，主要用于历史环境迁移。选错架构可能导致程序无法启动、依赖转译层运行或辅助服务安装失败，不应仅凭文件名中是否出现 macOS 判断兼容性。

常见安装方式是打开磁盘映像，把应用拖入“应用程序”目录，然后从该目录首次启动。不要长期从下载目录或挂载的磁盘映像直接运行，否则自动更新、登录启动和辅助服务路径可能不稳定。系统若阻止打开，应先核对下载来源，再在“隐私与安全性”中查看对应提示。不要通过全局降低系统安全设置来处理单个应用的授权问题。

导入配置与菜单栏操作

进入 Profiles 或配置页面，通过 URL 导入订阅，或导入本地 YAML。下载完成后明确选中配置，再进入策略页面选择 Proxy、Auto 或配置定义的其他组。macOS 客户端常驻菜单栏，主窗口关闭不等于核心停止；排查端口占用或代理残留时，需要从菜单栏执行退出，或在活动监视器中确认相关进程是否仍在运行。

订阅更新会重新获取远端内容。若客户端支持自动更新间隔，应根据服务提供方的更新方式设置，不宜设置过于频繁的轮询。远端配置与本地修改同时存在时，下一次更新可能覆盖直接编辑的内容。需要补充分流规则、DNS 或脚本时，优先使用覆写配置。导出包含完整代理信息的配置文件前，应确认接收位置和访问权限。

系统代理的工作方式

开启系统代理后，客户端会修改当前网络服务的 Web 代理与安全 Web 代理设置。Safari 和遵循系统配置的应用通常会直接生效，但某些命令行工具、沙盒应用和自行管理连接的软件不会读取这些设置。切换 Wi-Fi、以太网、热点或新增网络服务后，应重新确认代理状态，因为 macOS 的代理设置与具体网络服务关联。

可以使用 scutil --proxy 查看系统当前读取到的代理信息。该命令只说明配置是否写入，不代表本地端口能够接受连接，也不代表策略组已有可用选择。若代理地址仍在但客户端已退出，可先从客户端重新开启再正常关闭，让它执行恢复流程；也可以在系统网络设置中手动关闭对应代理项。不要同时让浏览器扩展、自动代理配置文件和客户端系统代理互相覆盖。

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

TUN、系统扩展与权限

macOS 的 TUN 模式通常需要安装辅助服务、创建虚拟接口或获得网络扩展权限。首次启用时，系统可能要求输入管理员凭据，并在隐私与安全设置中确认。授权完成后仍应回到客户端检查核心是否真正启动。若按钮短暂开启后自动关闭，应查看日志中的权限、路由、DNS 或接口创建错误，而不是重复点击。

TUN 可以覆盖不遵循系统代理的应用，但也更容易与其他 VPN、企业安全客户端、虚拟机网络和容器网络发生路由冲突。排查时先退出其他创建默认路由或 DNS 代理的程序，只保留一个流量接管工具。若局域网打印机、NAS 或开发服务器无法访问，应检查配置中的私有地址直连规则和绕过路由，而不是直接把全部流量改成直连。

终端代理与证书边界

Terminal、Homebrew、Git、curl 和语言包管理器可能需要单独设置代理。可在当前 shell 中导出 HTTP、HTTPS 与 ALL_PROXY。若使用 zsh，并把变量写进配置文件，应同时准备取消设置的方法。长期保留代理变量会让终端在客户端未启动时表现为连接拒绝，也可能影响访问本地开发服务器。

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

普通 Clash 代理不要求为了基本连接安装自定义根证书。只有明确使用 HTTPS 解密、脚本调试或特定工具链时，才涉及证书信任。遇到 TLS 错误时，先核对系统时间、域名解析、代理策略和应用自己的证书存储，不要把关闭证书验证作为长期方案。公司设备上的证书与网络扩展可能受管理配置控制，此类限制应由设备管理员处理。

四、Android 安装、VPN 权限与后台运行

选择安装包与完成安装

Android 可从Android 客户端区选择 Clash Plus，也可使用 Clash Meta for Android、FlClash 或 Surfboard。安装包可能按 arm64、arm 和通用架构提供。近年的主流设备通常采用 arm64，但旧设备、电视盒子和模拟器可能不同。无法确定时可使用客户端提供的通用构建；若系统提示解析包失败，应同时检查架构、系统版本、文件是否完整下载以及设备是否允许安装该来源的应用。

通过浏览器或文件管理器安装时，Android 会要求为当前来源授予安装权限。安装完成后可以撤销该来源权限，不影响客户端后续运行。系统若已安装相同包名但签名不同的版本，可能拒绝覆盖安装。此时先导出需要保留的配置，再卸载旧应用并重新安装。不要假设卸载前的应用数据一定会自动恢复，尤其是本地覆写、脚本和手工导入的 YAML。

导入订阅与建立本地 VPN

打开客户端后，在配置页面添加订阅 URL，填写便于识别的名称并执行更新。更新完成后选择该配置作为当前配置，再进入代理组选择策略。首次启动连接时，Android 会显示 VPN 连接请求；这是系统授予应用创建本地 VPN 接口的权限。确认后，状态栏通常出现 VPN 标识。该标识只说明接口已建立，仍需通过浏览器或客户端日志验证流量是否成功转发。

Android 同一时间通常只允许一个常规 VPN 服务处于活动状态。若系统已经连接其他 VPN、企业工作资料网络或广告过滤工具，新连接可能替换旧连接，或被系统拒绝。私有 DNS 与 Clash 内部 DNS 也可能形成不同解析路径。出现域名打不开但直接访问 IP 正常时，应暂时检查私有 DNS 设置，并确认配置中的 nameserver、fallback 或 fake-ip 行为。

应用分流与绕过设置

移动客户端常提供按应用选择代理、绕过或仅代理指定应用的功能。该功能适合让银行、局域网控制、投屏或对 VPN 敏感的应用保持直连，也适合只接管浏览器和通信工具。修改应用列表后需要重新建立 VPN 接口才能确保规则生效。系统应用可能以多个包组成，单凭桌面图标名称无法覆盖全部相关进程。

规则模式仍由配置规则决定目标连接走向，应用分流则在更前一层决定某个应用是否进入 Clash。两者不要混淆。某应用被设置为绕过后，其流量不会再进入域名规则，即使规则中明确写了代理也不会生效。排查单个应用时，应先检查应用分流名单，再检查规则命中和策略组，最后检查该应用是否使用 QUIC、自定义 DNS 或证书固定。

后台限制与连接被系统回收

Android 厂商常对后台活动、电池使用和自启动进行额外限制。表现包括锁屏一段时间后连接失效、清理最近任务后 VPN 消失、切换移动网络后无法恢复。应在系统设置中允许客户端后台运行，按设备提供的选项关闭过度电池优化，并允许必要的自启动。不同厂商菜单名称差异较大，但核心目标是避免系统冻结客户端进程或限制其 VPN 服务。

始终开启的 VPN 可以由 Android 系统在网络变化后尝试恢复，但在确认配置稳定前不宜同时启用“阻止未使用 VPN 的连接”。如果订阅失效、客户端崩溃或核心启动失败，该选项可能让设备完全无法联网。先验证 Wi-Fi、移动网络、休眠唤醒和重启后的行为，再决定是否启用严格模式。需要临时恢复网络时，应先从系统 VPN 页面断开，而不是只关闭客户端界面。

热点、局域网与 IPv6

手机开启热点后，连接热点的设备是否经过 Clash，取决于系统版本、客户端能力和转发实现。普通 Android VPN 通常只保证本机应用流量，不应默认认为热点下游设备会被接管。需要共享时，应确认客户端是否明确提供热点转发或允许局域网连接，并在下游设备手动设置手机局域网地址与代理端口。此时还要允许应用监听局域网，并注意公共网络中的访问风险。

部分移动网络优先使用 IPv6。配置若只提供 IPv4 DNS 或规则只覆盖 IPv4，可能出现应用间表现不一致。不要直接关闭系统 IPv6作为长期处理。应先确认内核 IPv6 开关、DNS 返回、规则匹配与代理入口是否支持对应连接。若日志显示连接尝试停留在不可达的 IPv6 地址，可临时调整配置用于定位，再根据网络环境决定是否启用双栈。

Android 端日志是判断故障层级的重要依据。配置解析错误通常在核心启动前出现；DNS 错误会显示解析失败或超时；策略问题会显示规则命中后连接失败；应用被排除时可能完全没有对应请求。按这四个层级排查，比反复更换客户端更容易定位原因。

五、iOS 安装、配置导入与按需连接

通过 App Store 安装 Clash Plus

iPhone 与 iPad 可在iOS 下载区进入 Clash Plus 的 App Store 页面，客户端官方网站为 clashplus.io。安装完成后首次启动，系统可能要求添加 VPN 配置。该授权用于创建 Network Extension，并不等于所有连接已经成功代理。授权后仍需导入配置、选择策略并启动连接。

iOS 上的网络接管由系统扩展管理，不使用桌面系统代理开关。状态栏或控制中心出现 VPN 标识，表示扩展处于连接状态。若应用主界面已关闭，扩展仍可能继续运行；若从系统设置断开，应用中的状态也应随之更新。排查时需要同时查看应用页面和“设置”中的 VPN 状态，避免只根据其中一个界面判断。

导入订阅与本地配置

在配置页面添加订阅 URL，执行更新后选择该配置。若订阅链接由其他应用复制，应检查首尾是否多出空格、换行或被聊天软件截断。通过文件应用导入 YAML 时，可使用系统分享菜单发送到 Clash Plus，随后在配置列表中确认导入结果。配置文件如果引用外部规则集，首次加载还需要下载相关资源；只有主 YAML 导入成功，不代表全部规则资源已经准备完成。

策略组的选择逻辑与其他平台相同。规则模式按规则分流，手动组需要选定实际策略，自动组按照配置测试方法更新。移动网络环境变化较频繁，某个策略在 Wi-Fi 下可用，不代表在蜂窝网络下也能建立连接。遇到单一网络失效时，应先保持配置不变，对比 Wi-Fi 与蜂窝网络日志，避免同时修改 DNS、模式和策略导致无法判断变量。

按需连接与系统网络切换

按需连接可根据系统网络状态自动启动扩展，适合已经验证稳定的配置。启用前先手动完成一次完整连接，并分别测试 Wi-Fi、蜂窝网络和锁屏恢复。若按需规则设置不当，可能在可信局域网中也自动接管，影响打印机、投屏与家庭设备访问。对局域网有明确需求时，应保留私有地址直连规则，并检查本地网络权限是否授予。

iOS 在网络切换、低电量和系统资源紧张时可能重建网络扩展。短暂断连后应先等待扩展重新协商，再查看应用日志。若反复卡在连接中，可以从系统设置断开 VPN，返回客户端重新启动。不要同时保留多个处于按需启用状态的 VPN 配置，否则系统选择行为会变得难以判断。

DNS、QUIC 与应用差异

Safari、原生应用和第三方浏览器可能使用不同连接策略。部分应用优先尝试 HTTP/3 或自定义解析，表现为浏览器可用而特定应用超时。配置中的 DNS 模式、规则和 UDP 支持会共同影响结果。若关闭 UDP 后某应用恢复，说明问题可能位于 UDP 转发或 QUIC 路径；这只是定位线索，不应长期以禁用全部 UDP 代替修复。

fake-ip 模式会给域名返回保留地址，再由内核恢复域名并匹配规则。它通常能提高分流一致性，但局域网发现、少量设备控制应用和特殊域名可能需要加入过滤列表。redir-host 更接近真实 DNS 返回，兼容思路不同。两种模式没有适用于全部网络的固定结论，应根据配置规则、局域网需求和日志选择。关于泄漏与 nameserver 的完整检查可参考DNS 检测与配置说明。

耗电、后台与配置维护

网络扩展持续处理连接会产生一定电量开销，规则数量、DNS 查询、日志级别和网络质量都会影响实际表现。日常使用不应长期保持 debug 日志；详细日志适合短时间复现问题，完成排查后应恢复常规级别。若耗电突然增加，先检查是否出现连接重试、DNS 循环或多个自动测试组高频运行，而不是只看 VPN 图标存在时间。

订阅更新前可记录当前策略组选择。部分配置更新会重建策略组，旧选择可能因为名称变化而回到默认项。更新后若突然无法访问，应依次确认配置是否激活、策略组是否仍有选择、规则资源是否下载完成、扩展是否重新建立。删除并重装应用会同时清除本地覆写和历史日志，应放在配置备份与基础排查之后。

iOS 端无法像桌面系统那样直接查看完整路由表和监听进程，因此更依赖客户端日志与对照测试。建议一次只改变一个条件：先换策略，再换模式，再检查 DNS。若在同一步同时重建配置和切换网络，最终即使恢复，也无法确认真正的故障来源。

六、Linux 桌面客户端与内核服务部署

桌面环境的安装选择

Linux 桌面可从Linux 下载区选择 Clash Verge Rev 或 FlClash。安装前确认发行版、CPU 架构和包格式。Debian、Ubuntu 及其衍生系统通常使用 deb，Fedora、RHEL 系发行版常见 rpm。使用包管理器安装本地包时，可以让系统同时检查依赖；直接解压可执行文件则需要自行处理桌面入口、权限、自动启动和更新。

不同桌面环境对系统代理的支持并不统一。GNOME、KDE 和轻量桌面写入代理设置的位置不同，部分应用读取环境变量，部分应用读取桌面配置，还有应用完全忽略两者。因此图形客户端显示“系统代理已开启”后，仍要分别验证浏览器、终端和目标应用。Wayland 或 X11 通常不会直接决定代理能力，但会影响托盘图标、授权弹窗和桌面集成表现。

导入配置并验证监听端口

图形客户端的订阅导入流程与其他桌面平台相同：添加 URL、更新、选中配置、选择策略组，再开启系统代理或 TUN。若使用内核，应把配置保存到权限受控的目录，并以命令行指定路径启动。启动前可先执行配置测试，避免服务反复重启。不同 Mihomo 构建的参数应以当前程序帮助信息为准，常见启动形式如下。

mihomo -t -f /etc/mihomo/config.yaml
mihomo -d /etc/mihomo

ss -lntp | grep 7890
journalctl -u mihomo --no-pager -n 100

-t 用于检查配置是否能够解析，-f 指定单个配置文件，-d 指定工作目录。工作目录内可能包含缓存、规则集与数据库，运行用户必须拥有需要的读写权限。不要为了消除权限错误直接把整个目录改成所有用户可写。服务进程应使用专用低权限账户，仅在创建 TUN、修改路由或绑定受限资源时授予必要能力。

systemd 服务与自动启动

服务器或长期运行的桌面主机可使用 systemd 管理内核。服务应在基础网络可用后启动，并在异常退出时按合理间隔重试。配置更新前先执行语法检查，再重载或重启服务。下面示例假设二进制文件和配置目录已经按对应路径准备，实际用户名与路径需要按本机环境调整。

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

[Service]
Type=simple
User=mihomo
Group=mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

保存为服务单元后，先执行 systemctl daemon-reload，再启动并检查日志。自动启动应在一次手动运行稳定后开启。若服务一启动就循环失败，先停止自动重试，直接运行配置测试；持续重启会快速刷满日志，也可能反复修改路由。服务升级时应保留旧二进制和配置备份，以便在兼容性问题出现时回退。

环境变量、桌面代理与 TUN

终端工具可使用 http_proxy、https_proxy 与 all_proxy。变量名同时存在大小写形式时，不同工具读取规则可能不同。服务器上的 systemd 服务不会自动继承用户 shell 配置，需要在服务单元或专用环境文件中明确设置。对于只需代理单条命令的场景，建议把变量限定在命令前，避免影响整套系统。

http_proxy=http://127.0.0.1:7890 \
https_proxy=http://127.0.0.1:7890 \
curl -I https://example.com

all_proxy=socks5://127.0.0.1:7890 git fetch

Linux TUN 部署涉及虚拟接口、策略路由、DNS 与防火墙规则。内核需要访问 /dev/net/tun，并获得创建接口和修改网络配置所需权限。容器内运行还要显式传入 TUN 设备与网络能力。不要在不理解当前 nftables、iptables 或策略路由的情况下复制整套清空规则命令，这可能中断远程连接。路由器与旁路由场景可继续阅读OpenWrt 部署概览。

权限、DNS 与容器边界

直接以 root 长期运行可以绕开部分权限问题，但会扩大配置脚本、外部规则和管理接口带来的风险。更合适的做法是使用专用账户，通过 capabilities 或服务管理授予最小权限。管理控制端口若只在本机使用，应绑定回环地址；确需局域网访问时，应同时设置访问控制和主机防火墙，不要直接暴露到公网。

systemd-resolved、NetworkManager、dnsmasq 与 Clash DNS 可能争用本机 DNS 端口或互相转发。先画清查询路径：应用把请求发给谁、系统 stub 转给谁、Clash 监听哪个地址、上游 nameserver 在哪里。端口冲突时不要盲目停用系统解析服务，应调整监听地址或转发关系。容器内部的 127.0.0.1 指向容器自身，不是宿主机；容器应用若要使用宿主机代理，需要明确的网关地址和监听范围。

七、通用配置文件、DNS、规则与 TUN 参数

配置文件的基本结构

Clash 配置使用 YAML。缩进只能表达层级，不能随意混用制表符。键名后的冒号需要保留正确空格，列表项使用短横线。配置通常包含监听端口、运行模式、日志级别、代理定义、策略组、规则提供器、DNS 和最终规则。订阅生成的完整配置可能很长，但排查时应先确认顶层结构是否正确，再查看具体代理入口。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy

上例用于说明语法，不包含可用代理定义。mixed-port 同时接受 HTTP 与 SOCKS 连接；allow-lan 决定是否允许其他设备连接；bind-address 限制监听地址；mode 决定规则、全局或直连行为；log-level 控制日志详细程度。端口只要未被占用即可，不必固定使用示例值。修改监听端口后，所有外部代理设置都必须同步。

allow-lan 与监听地址

只在本机使用时，保持 allow-lan: false 并绑定回环地址更清晰。需要让同一局域网内其他设备使用代理时，可开启局域网访问，并确认客户端实际监听在局域网接口。随后在其他设备中填写运行 Clash 设备的局域网 IP 和 mixed-port。主机防火墙需要放行对应端口，但不应对所有网络配置文件无条件开放。

允许局域网连接不会自动把流量共享给其他设备，也不会配置网关。下游设备必须手动设置 HTTP/SOCKS 代理，或由网关完成透明转发。移动设备离开当前 Wi-Fi 后，原局域网地址不可达，应清除手动代理。公共 Wi-Fi 中不建议开放监听；如果确实需要，至少限制来源网段并确保控制接口没有一并暴露。

规则匹配顺序与策略组

规则按从上到下的顺序匹配，第一条命中后通常不再继续。因此更具体的域名、进程和私有网络规则应放在宽泛规则之前，MATCH 一般位于末尾。DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀，DOMAIN-KEYWORD 按关键字匹配，IP-CIDR 匹配地址段。IP 规则可能触发 DNS 解析，是否跳过解析取决于语法与内核支持。

策略组并不是代理入口本身，而是对多个策略进行选择、测试或回退的逻辑层。select 组由用户手动选择；url-test 根据测试地址与间隔更新选择；fallback 通常按可用性顺序切换；load-balance 用于按配置策略分配连接。测试结果只反映测试目标与当时网络，不等同于所有网站都能访问。过短的测试间隔会增加连接与耗电，不应为了界面频繁刷新而持续探测。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    proxies:
      - provider-a
      - provider-b
    url: https://www.gstatic.com/generate_204
    interval: 600

DNS 模式与查询路径

DNS 配置的目标不仅是解析域名，还要让解析结果与规则匹配、代理连接保持一致。fake-ip 模式返回保留地址，由内核记录域名映射并在连接阶段恢复域名，通常适合需要稳定域名分流的环境。redir-host 返回真实解析结果，对部分局域网与特殊应用更直观，但分流路径不同。选择前应理解客户端是否接管系统 DNS，以及未进入 Clash 的应用会向哪里查询。

nameserver 是常规上游，fallback 可提供另一组解析路径，default-nameserver 常用于解析 DoH 或 DoT 上游自身的域名。若上游填写域名而基础解析又依赖同一个上游，可能形成启动依赖循环。浏览器的安全 DNS也可能绕过系统路径。检测 DNS 泄漏时，应同时检查浏览器设置、系统解析器和 Clash 日志，不能只看单个网页结果。

TUN 参数与严格路由

TUN 模式常见参数包括是否启用、协议栈实现、自动路由、自动检测接口和严格路由。不同平台与内核版本支持范围可能不同，客户端界面也可能代为生成这些字段。开启自动路由后，内核负责加入必要路由；自动检测接口用于在 Wi-Fi、以太网或移动网络变化时识别出口；严格路由可减少流量绕过，但更容易暴露与虚拟机、容器或局域网路由的冲突。

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

首次启用时应从保守配置开始，只打开必要字段，确认浏览器、终端、局域网和休眠恢复均正常后再调整严格路由或 DNS 劫持。若系统已有企业 VPN、虚拟交换机、容器网桥或多条默认路由，应记录启用前后的路由差异。TUN 不是系统代理失效时的万能替代，它解决的是流量接管范围问题，不能修复无效订阅、错误策略和远端连接失败。

八、配置更新、连接异常与恢复流程

按层级定位，不同时修改多个变量

故障排查应依次确认基础网络、客户端进程、配置载入、监听端口、流量接管、规则匹配、策略连接和 DNS。先切到直连或完全退出客户端，确认设备本身能够联网；再启动客户端但暂不接管系统流量，检查核心是否正常运行；随后通过本机代理端口执行一次明确测试；最后才开启系统代理或 TUN。这样可以区分问题位于核心之前还是系统接管之后。

一次只改变一个条件。不要同时更新订阅、切换客户端、改 DNS、开 TUN 和更换策略。多项操作同时进行后，即使恢复也无法确定原因。客户端日志应先使用 info 级别观察，确需更多细节时短暂切到 debug。分享日志前清理订阅 URL、认证字段、代理地址和设备信息。

订阅更新失败

订阅更新失败首先检查 URL 是否完整、是否过期、是否被复制出空格，以及基础网络能否访问对应地址。HTTP 状态错误通常来自授权、频率限制或服务端状态；连接超时可能是 DNS、当前代理链路或网络阻断；下载成功但解析失败则更可能是返回内容不是预期 YAML 或转换格式。不要把系统代理开关反复切换当作唯一处理。

若旧配置仍可使用而新配置无法更新，可以先保留旧配置，使用浏览器或 curl 单独请求订阅地址并观察响应类型。更新经由当前代理还是直连，取决于客户端实现，必要时可暂时切换接管方式做对照。配置包含远程规则集时，主订阅成功后仍可能在规则资源下载阶段失败，应从日志中区分具体 URL 与资源类型。

启动失败与端口冲突

日志出现 address already in use 时，表示监听地址或端口已被占用。常见原因是同一客户端启动两个实例、旧核心未退出、其他代理软件使用相同端口，或系统服务自动拉起了另一个实例。Windows 可使用 netstat 与任务管理器定位，macOS 和 Linux 可使用 lsof 或 ss。确认进程用途后再结束，不要仅凭端口号直接终止未知系统进程。

# Windows
netstat -ano | findstr :7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp | grep 7890

若决定修改 mixed-port，客户端界面、系统代理、环境变量、浏览器手动代理与局域网设备都要改成新值。只改 YAML 而客户端实际使用覆写配置时，端口可能在启动后被再次替换。详细分支见端口 7890 被占用的定位方法。

已连接但网页打不开

先检查策略组是否选择了实际策略，而不是空组或不可用的上级组。再观察请求日志是否出现：完全没有日志说明流量未进入客户端；有规则命中但连接失败说明问题位于策略或远端；只有域名解析失败说明优先检查 DNS；浏览器报证书或协议错误则应检查系统时间、QUIC、证书存储和中间网络。切换到全局模式只能帮助判断规则影响，不代表适合长期使用。

若只有部分网站异常，查看该域名命中了哪条规则以及最终策略。规则从上到下执行，前面的宽泛规则可能截获后面的精确规则。若只有某个应用异常，检查它是否忽略系统代理、是否被应用分流排除、是否使用 UDP 或自定义 DNS。此时 TUN 可以用于验证接管范围，但仍需通过日志确认请求是否真正进入。

DNS 异常与泄漏检查

域名失败而 IP 可访问，通常指向 DNS 路径。检查系统 DNS 指向、Clash DNS 监听端口、nameserver 可达性、浏览器安全 DNS 和 TUN 的 DNS 劫持配置。fake-ip 下看到保留地址并不自动表示异常，关键是连接是否被内核接管并恢复到原域名。若应用绕过 Clash 直接访问 fake-ip 地址，则会失败，需要调整接管范围或过滤规则。

检测 DNS 泄漏不能只依赖一次网页测试。应对比启用前后解析服务器、查看客户端日志中是否出现目标查询，并使用命令行工具指定系统默认解析器测试。企业网络、移动网络和浏览器自身的加密 DNS 都可能产生额外路径。完整操作可参考DNS 泄漏检测与 fake-ip 配置实操。

TUN 开启后局域网或虚拟机失效

TUN 会改变路由优先级，严格路由与 DNS 劫持还会扩大影响范围。局域网失效时，先确认私有地址直连规则，再查看路由表中目标网段由哪个接口承载。虚拟机、Docker、WSL 和容器平台通常创建自己的私有网段，若与物理局域网或代理保留地址重叠，就可能发生冲突。不要只添加单个设备 IP 作为长期补丁，应识别完整网段和实际出口。

关闭 strict-route 或暂停 DNS 劫持可以作为定位手段，但应记录哪项变化恢复了连接。若只在休眠、网络切换或 VPN 重连后出现，可能是自动检测接口没有刷新。重启核心或重新建立 TUN 通常比重启整台设备更有针对性。Linux 服务器还应检查 nftables、策略路由与反向路径过滤；Windows 和 macOS 则检查其他 VPN 与安全客户端。

建立可回退的维护习惯

更新客户端或大幅修改配置前，保留当前可用配置、覆写文件和关键设置记录。不要备份包含敏感订阅的文件到公开位置。修改后分别验证配置解析、核心启动、单端口代理、系统代理或 TUN、DNS、局域网和休眠恢复。任何一步失败，都回到最近一个明确可用状态，而不是继续叠加修改。

快速完成初次配置可回到Clash 快速上手教程；需要重新选择客户端可查看客户端横向评测；策略组、配置文件、fake-ip、mixed-port 等术语可在术语表中单独查阅。形成“下载来源明确、配置分层保存、一次只改一项、日志按层判断”的流程，比记住某个客户端界面的固定位置更可靠。