平台部署 预计阅读 14 分钟

Windows 安装 Clash 客户端全流程：从安装包到系统代理生效与常见报错处理

按顺序讲清 Windows 上安装客户端、放行防火墙、导入配置、开启系统代理的每一步，并整理 UWP 回环、端口占用、服务模式失败等高频问题的处理方法。

安装前确认：系统版本、客户端类型与配置来源

Windows 上常见的 Clash 客户端通常由图形界面、Clash 或 mihomo 内核、配置管理器和系统代理控制模块组成。图形界面负责导入订阅、切换节点和查看日志，内核负责监听本机端口、执行规则匹配、处理 DNS 与转发连接。安装成功只代表程序能够启动，真正可用还需要完成配置导入、内核运行、系统代理开启和连通性检查。

建议使用仍受支持的 Windows 10 22H2、Windows 11 23H2 或 Windows 11 24H2。Windows 7、Windows 8.1 以及较早的 Windows 10 版本可能缺少新版 WebView2、运行库、驱动接口或系统组件，即使安装程序能够打开，也可能在启动内核、渲染界面或启用 TUN 时失败。

先区分安装包与便携压缩包

  • EXE 安装包：通常包含安装向导、开始菜单入口和卸载信息，适合长期使用。
  • MSI 安装包：便于 Windows Installer 管理，也常用于批量部署。
  • ZIP 压缩包：解压后直接运行，更新时需要手动替换文件，配置目录是否随程序移动取决于客户端实现。
  • x64 与 ARM64：大多数 Intel、AMD 电脑选择 x64；搭载 Snapdragon 等 ARM 处理器的 Windows 设备优先选择 ARM64。

可在「设置」→「系统」→「系统信息」中查看“系统类型”。显示“基于 x64 的处理器”时选择 x64，显示“基于 ARM 的处理器”时选择 ARM64。不要仅根据 Windows 11 的名称判断架构。

安装 Clash 客户端并处理 Windows 安全提示

下载与当前处理器架构匹配的安装包后，先关闭正在运行的旧版客户端。若任务栏通知区域仍有旧客户端图标，应从菜单中选择“退出”，再打开任务管理器确认相关界面进程和内核进程已经结束。旧进程持续监听 7890、7891 或 9090 端口，会导致新版本启动后立即报告端口占用。

标准安装顺序

  1. 双击 EXE 或 MSI 安装包，阅读安装向导显示的版本与目标目录。
  2. 普通单用户设备可保留默认目录；受企业策略管理的设备应按管理员提供的目录安装。
  3. 完成安装后，从开始菜单启动客户端，不必在首次启动时直接使用管理员身份运行。
  4. 若 Windows 防火墙询问是否允许网络访问，家庭或可信办公网络可勾选“专用网络”。公共网络是否放行应根据实际用途决定。
  5. 等待界面加载完成，确认状态页没有出现“Core failed”“内核启动失败”或持续重启提示。

Clash 默认只需要在本机回环地址上监听代理端口。配置中的 allow-lan: false 表示不向局域网设备提供代理，更适合只在当前电脑使用的场景。如果确实需要让手机或其他电脑连接，应手动启用局域网访问，并同时设置防火墙入站范围、身份验证和可信网段，不能只把端口暴露到全部网络接口。

首次启动后建议检查的目录

不同客户端的目录名称不同，常见数据位置位于 %APPDATA%、%LOCALAPPDATA% 或用户目录下的专用文件夹。可按 Win+R，分别输入 %APPDATA% 与 %LOCALAPPDATA% 查看。配置文件、日志、内核和缓存通常不在安装目录内，因此卸载界面程序后，用户配置可能仍被保留。

导入订阅与验证 Clash 配置是否可加载

客户端启动后，先进入“配置”“Profiles”或“订阅管理”页面。不同项目的菜单文字略有差异，常见路径是「配置」→「新建订阅」，或「Profiles」→「Download from URL」。把订阅 URL 粘贴到地址栏，为配置填写便于识别的名称，然后执行下载或导入。

订阅导入后的四项检查

  1. 更新时间：确认页面显示刚刚完成更新，而不是停留在历史缓存时间。
  2. 配置状态：确认当前配置被选中，并且没有 YAML 解析错误。
  3. 代理组：检查“代理”“Proxy”或类似策略组中是否存在可选节点。
  4. 日志：查看内核启动阶段是否出现端口绑定、DNS 初始化或规则加载错误。

一个用于本机系统代理的基础配置通常会声明代理端口、代理组和规则。下面的片段只展示结构关系，不能代替完整订阅：

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

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Node-A
      - DIRECT

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

mixed-port: 7890 表示 HTTP 与 SOCKS 请求可进入同一个混合端口。部分旧配置会分别使用 port: 7890 和 socks-port: 7891。实际端口必须以当前配置和客户端状态页为准，不能只按照常见默认值填写。

YAML 解析失败怎么处理

YAML 对缩进敏感，列表项前的空格数量必须保持一致，Tab 制表符也可能造成解析失败。若订阅由服务端生成，不要直接在客户端里大范围改写原文件；先重新更新一次订阅，排除下载中断和缓存异常。手动配置时可重点检查冒号后的空格、列表短横线、引号是否成对，以及代理组引用的节点名称是否真实存在。

选择节点、规则模式并开启 Windows 系统代理

配置加载完成后，进入“代理”“Proxies”或策略组页面。先在主要代理组中选择一个节点，再执行延迟测试。延迟数字反映测试 URL 的连接耗时，不代表持续下载速度。某个节点显示 85 ms，只能说明测试时较快；显示 Timeout 则表示在客户端设定的超时时间内没有完成测试。

Rule、Global 与 Direct 的区别

  • Rule：按配置中的 rules 从上到下匹配，决定直连、代理或拒绝，适合作为日常模式。
  • Global：把大多数进入 Clash 的连接交给指定全局策略，适合临时排查规则是否误分流。
  • Direct：进入 Clash 的连接直接访问目标，不经过代理节点，常用于对照测试。

模式切换不会自动改变 Windows 的代理开关。完成节点和模式选择后，还要在客户端首页或设置页开启“系统代理”“System Proxy”。常见菜单路径是「设置」→「系统代理」→“启用”，也有客户端把开关放在主界面顶部。

开启后，可进入 Windows 11 的「设置」→「网络和 Internet」→「代理」检查。客户端通常会写入手动代理地址 127.0.0.1 和对应 HTTP 或 mixed 端口，例如 7890。该值由客户端管理时，不建议同时在 Windows 设置中手工改成另一个端口，否则客户端状态与系统实际值可能不一致。

确认系统代理真正生效

  1. 打开客户端日志，把日志级别保持在 info。
  2. 完全关闭并重新打开浏览器，避免旧连接继续复用。
  3. 访问一个普通 HTTPS 页面，观察日志中是否出现对应域名和匹配策略。
  4. 分别测试规则模式与直连模式，比较出口和页面连通性。
  5. 关闭系统代理后再测试一次，确认结果确实随开关变化。

浏览器能够访问并不代表所有 Windows 程序都会自动使用代理。遵循 WinINET 或系统代理设置的程序通常会生效；自行实现网络栈、固定使用直连、只读取环境变量或使用特殊协议的程序，可能绕过系统代理。此时需要查看软件自身的代理选项，或在明确了解影响范围后使用 TUN 模式。

端口占用、内核失败与本地连接拒绝

如果日志出现 bind: Only one usage of each socket address、address already in use 或“端口被占用”，说明另一个进程已经监听相同地址与端口。常见来源包括旧版 Clash 内核、其他代理软件、开发调试工具，以及退出界面后仍留在后台的服务进程。

用命令确认 7890 端口占用者

netstat -ano | findstr :7890
tasklist /FI "PID eq 进程编号"

第一条命令末列会显示 PID。把实际数字代入第二条命令，可查看对应进程。PowerShell 也可以使用以下命令验证本机监听是否建立：

Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue

若 TcpTestSucceeded 为 False，先确认配置中监听的实际端口。若端口确实是 7890，应检查内核是否启动、配置是否加载成功，以及安全软件是否终止了进程。不要同时修改配置端口和 Windows 代理端口后立即反复测试；应先确定一个空闲端口，例如 7890 或 7892，再让客户端重新写入系统代理。

内核启动失败的排查顺序

  1. 查看日志第一条错误，不要只看后续重复重试信息。
  2. 切换到客户端自带的基础配置，判断问题来自内核还是订阅文件。
  3. 确认内核文件没有被移动，客户端设置中的内核路径有效。
  4. 关闭同类代理程序，排除端口和服务名称冲突。
  5. 重启 Windows，清理残留进程与尚未释放的驱动状态。
  6. 仍失败时导出必要日志，并移除其中的订阅地址、节点凭据和公网地址。

UWP 回环限制：商店应用无法连接代理

部分 Microsoft Store 应用和采用 AppContainer 隔离的程序，默认不能访问本机回环地址。此时浏览器可以通过 127.0.0.1:7890 正常连接，而某个商店应用持续显示断网。这个现象通常不是节点故障，而是 UWP 回环访问限制。

优先使用客户端提供的回环工具

部分 Windows Clash 客户端在「设置」→「UWP 回环」或「Settings」→「UWP Loopback」中提供管理入口。打开列表后，只勾选确实需要通过本机代理的应用，保存设置，再彻底退出并重启对应应用。不要一次勾选全部包，因为系统组件和后台应用的流量也可能因此改变。

如果客户端没有图形工具，可以在 PowerShell 中查询应用的 Package Family Name：

Get-AppxPackage | Select-Object Name, PackageFamilyName

确认目标应用的包系列名称后，可在管理员命令提示符中添加回环豁免：

CheckNetIsolation LoopbackExempt -a -n=实际的PackageFamilyName
CheckNetIsolation LoopbackExempt -s

第一条命令添加指定应用，第二条命令列出当前豁免。应用卸载重装后，包身份可能变化，需要重新检查。若应用本身不读取 Windows 系统代理，即使完成回环豁免，也仍需在应用内配置代理或改用覆盖范围更广的网络接管方式。

服务模式失败、开机启动与权限处理

一些客户端提供“服务模式”“Service Mode”或“系统服务”。它通常用于以 Windows 服务承载特定网络能力，使 TUN、系统代理守护或内核启动不依赖前台界面。服务模式不是普通系统代理的必选项；只使用浏览器和遵循系统代理的软件时，客户端前台运行加系统代理开关通常已经足够。

服务安装失败的常见原因

  • 客户端目录已移动，服务记录仍指向旧路径。
  • 旧版本服务没有卸载，服务名称发生冲突。
  • 安装服务时没有完成 Windows 用户账户控制确认。
  • 企业组策略限制普通用户创建或启动系统服务。
  • 安全策略阻止驱动、服务程序或内核文件启动。

处理时先在客户端的「设置」→「服务模式」中执行卸载，再退出客户端并重启 Windows。重新打开客户端后安装服务，并完成权限确认。若按钮持续显示失败，可打开 services.msc 查看是否存在旧服务及其状态，但不要随意删除无法确认用途的服务项。

开机启动建议只启用一个入口。若客户端已在「设置」→「常规」→“开机启动”中创建启动任务，就不要再把快捷方式放入 shell:startup。重复启动可能同时拉起两个界面进程，进而造成端口冲突、系统代理反复切换或托盘图标重复。

TUN 模式适用范围与 DNS 排查

系统代理只影响主动读取 Windows 代理设置的程序。游戏启动器、命令行工具、部分即时通信软件和自行实现网络栈的应用可能不经过它。TUN 模式通过虚拟网络接口接管更广范围的 IP 流量，适合无法单独设置代理的程序，但配置复杂度、权限要求和故障影响范围也更高。

启用 TUN 前先完成三项基线测试

  1. 系统代理模式下浏览器可以稳定访问目标页面。
  2. 规则模式中的代理组已经选择可用节点。
  3. 日志中没有持续出现 DNS 超时、端口占用或配置解析错误。

完成基线后，再进入「设置」→「网络」→「TUN 模式」启用相关开关。首次启用可能要求管理员权限并安装虚拟网卡或服务。启用后应检查本地局域网访问、打印机、公司 VPN、虚拟机网络和游戏平台是否正常，因为多个虚拟网卡、VPN 与流量过滤驱动之间可能出现路由优先级冲突。

若日志显示连接目标域名时反复出现 DNS timeout、no such host 或解析结果异常，应先区分系统 DNS 与 Clash DNS。关闭 TUN 和系统代理后执行 nslookup example.com，确认基础网络能够解析；再启动 Clash，查看内核 DNS 模块是否监听配置指定的地址。mihomo 配置可能使用 fake-ip 或 redir-host 增强模式，两者的缓存和应用兼容表现不同，不应在不了解现有规则的情况下直接互换。

ipconfig /flushdns
nslookup example.com
route print

ipconfig /flushdns 只清理 Windows DNS 客户端缓存，不会清除所有浏览器缓存或 Clash 内核缓存。route print 可用于检查 TUN、企业 VPN 和物理网卡的路由优先级。排查时一次只改变一个变量：先节点，再规则模式，再 DNS，最后才是 TUN 与驱动。

安装完成后的核对清单

一次完整的 Windows Clash 部署，应同时满足程序、配置、端口、系统代理和规则五个层面的条件。只看到托盘图标或延迟数字，不能作为最终判断依据。

  • 客户端版本与 Windows 架构匹配，界面和内核均能稳定启动。
  • 订阅显示最新更新时间，当前配置可以正常加载。
  • 主要代理组已经选择节点，延迟测试有明确结果。
  • 本地 HTTP、SOCKS 或 mixed 端口处于监听状态。
  • Windows 系统代理地址与客户端监听端口一致。
  • 访问页面时，日志能够显示域名、规则和最终策略。
  • 关闭系统代理后，测试结果按预期变化。
  • 需要代理的 UWP 应用已设置回环豁免。
  • 只有确有需求时才启用服务模式和 TUN。
  • 订阅地址、配置文件与日志中的凭据信息得到妥善保存。

遇到故障时，最有效的顺序是先看第一条日志错误，再确认配置和端口，然后检查 Windows 系统代理，最后处理 UWP、服务模式、TUN 与 DNS。按层排查可以避免同时修改多个开关，也更容易定位问题发生在客户端界面、Clash 内核、Windows 网络设置还是远端节点。

下载 Clash 客户端