Windows 版 Clash 安装到上网全流程:防火墙、UAC 与系统代理排错

安装前：确认系统架构与客户端类型

Windows 上的 Clash 客户端通常由图形界面和代理内核组成。界面负责订阅、代理组、系统代理与服务管理；内核负责监听本地端口、匹配规则并建立连接。Clash Meta 后续以 mihomo 名称发展，使用 mihomo 的客户端也不意味着菜单布局完全相同。排错时需要同时记录客户端名称、客户端版本和内核版本，不能只记录“Clash”。

本文使用 Windows 11 的系统设置路径。Windows 10 的部分入口名称不同，但本地监听、系统代理与权限检查的方法相同。先完成普通系统代理连接，再按应用需要启用 TUN，避免同时改变多条网络路径。

安装包选择步骤

1. 打开「设置」→「系统」→「系统信息」，在「设备规格」中查看「系统类型」。基于 x64 的处理器通常选择 x64 安装包；基于 ARM 的设备优先选择客户端提供的 ARM64 包。
2. 在客户端下载页查看平台与架构。安装程序和单独的 mihomo 内核不是同一种交付物，内核压缩包通常不包含订阅管理界面。
3. 检查该客户端发布说明中的 Windows 最低版本、运行时依赖及维护状态。不要把旧版 Clash for Windows 的界面教程直接套用到所有新客户端。
4. 安装前退出其他代理客户端，记录当前代理和 VPN 设置。便携版解压到固定目录；服务注册后不要随意移动其内核文件。

首次连接：导入配置并建立最小可用路径

安装完成后，先导入有效订阅或本地 YAML 配置。订阅地址可能包含访问凭据，不要发送到公开群组或截图中。导入成功后检查配置是否被设为当前配置，以及代理组是否出现可选节点。仅显示“订阅已更新”还不能证明内核已成功加载。

1. 在客户端的订阅或配置页面执行导入，激活该配置，查看日志是否存在 YAML 解析错误、未知字段或规则提供器下载失败。
2. 在代理页面选择规则模式，并在实际被规则引用的代理组中选择节点。选择一个未被规则使用的组，不会改变该请求的出口。
3. 确认内核已运行，记下实际 HTTP 或混合代理端口。下文以 127.0.0.1:7890 为例；这不是所有客户端的固定默认值。
4. 开启客户端的系统代理，在浏览器中访问需要测试的站点，再打开连接列表查看规则、策略组和出口。

若配置由客户端生成，应在客户端设置或受支持的覆写功能里调整监听参数。直接修改订阅缓存文件，可能在下次更新时被覆盖。以下只是 mihomo 本地监听参数示例，不包含节点与分流规则，不能单独作为完整上网配置：

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

混合端口同时支持 HTTP 代理和 SOCKS 代理。仅供本机使用时，保持回环监听和关闭局域网访问；不要为了修复浏览器连接而把监听地址改成所有网卡，也不要把代理端口映射到公网。

用显式代理分离问题

在 PowerShell 中运行以下命令。这里指定 curl.exe，避免 Windows PowerShell 中同名别名造成参数差异。示例地址只用于连通性测试，不能代表所有站点的访问质量。

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

• TcpTestSucceeded : True 只证明本地 TCP 连接能建立，不能证明远端节点可用。
• 如果显式代理能收到 HTTP 响应，但浏览器失败，优先检查系统代理、浏览器扩展和应用自身设置。
• 如果显示无法连接 127.0.0.1:7890，先检查端口与内核状态，不必立即更换远端节点。
• 如果已连接本地端口，随后出现 TLS 或远端超时，再检查节点、规则、系统时间与客户端日志。不要用跳过证书验证作为常规修复。

UAC 与服务模式：按功能授予权限

普通本地代理监听通常不要求管理员权限。安装到受保护目录、注册系统服务、配置虚拟网卡或修改路由时，客户端才可能触发 UAC。UAC 是权限提升确认，不是网络连接许可；点击“是”也不会自动配置防火墙或选好节点。

服务安装与状态核对

1. 在客户端设置中找到服务模式或后台服务入口。菜单名称以当前客户端为准，先确认安装动作来自该客户端。
2. 点击安装服务后，核对 UAC 提示的程序路径及发布者信息。路径异常或来源不明时取消授权。
3. 按 Win + R，输入 services.msc，查找客户端实际注册的服务，核对状态与可执行文件路径。不同客户端的服务名并不统一。
4. 回到客户端确认服务状态。若准备启用 TUN，再检查虚拟接口与内核日志，而不是只看服务安装成功提示。

遇到“拒绝访问”时，先确认安装服务的操作是否成功提升权限。遇到“服务文件不存在”或启动后立即停止时，检查是否移动过便携目录、文件是否被安全软件隔离，以及原服务是否仍指向旧路径。优先通过客户端的服务管理入口卸载旧服务再安装，不要猜测服务名执行删除命令。

系统代理：检查 Windows、浏览器与命令行的差异

Windows 11 的入口是「设置」→「网络和 Internet」→「代理」。检查「手动设置代理」中的地址和端口是否与客户端一致。本文示例应对应地址 127.0.0.1、端口 7890。若客户端采用 PAC 自动配置，则应检查「使用设置脚本」及脚本地址，而不是强行叠加手动代理。

Edge、Chrome 通常遵循系统代理，但扩展、启动参数和组织策略可以改变行为。Firefox 还可在「设置」→「常规」→「网络设置」中单独选择代理来源。如果只有某个浏览器失败，先核对该浏览器的代理设置，不要同时改动内核、DNS 和防火墙。

WinHTTP 与环境变量单独检查

netsh winhttp show proxy
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

netsh winhttp show proxy 查询的是 WinHTTP 设置，不等同于浏览器所用的当前用户系统代理。显示直接访问，不代表客户端的系统代理开关失效。部分开发工具则读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，还有些工具使用自己的配置文件。

不要在尚未确认应用代理来源时，直接把当前用户代理导入 WinHTTP。后台服务可能使用不同账户，修改系统范围设置也会影响其他软件。正确做法是先确定失败进程，再查看其代理文档与运行账户。

客户端退出后浏览器全部断网

这通常需要先排除代理残留：内核已经停止，但 Windows 仍指向本地代理端口。重新打开客户端并正常关闭系统代理，或在 Windows 代理设置里关闭本次设置的手动代理或脚本。企业配置的 PAC 不应随意删除。恢复后先测试直连，再重新启动客户端。

端口占用：从监听进程定位到配置冲突

日志中的 address already in use 通常表示监听冲突。它与远端节点延迟无关。先查询本地端口，再根据进程号定位，避免连续重装客户端。

Get-NetTCPConnection -State Listen -LocalPort 7890 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

netstat -ano | findstr ":7890"

第一条命令只列出指定端口的 TCP 监听；第二条命令也可能显示其他连接，必须核对本地地址列和监听状态。取得进程号后，在「任务管理器」→「详细信息」中按 PID 查找进程。若没有 PID 列，可右键单击列标题后选择该列。

• 如果是另一个代理客户端，先从其托盘菜单正常退出，并关闭其自动启动的后台服务。
• 如果是当前客户端的另一个内核实例，检查是否同时开启了便携版与安装版，以及服务模式与手动内核是否重复运行。
• 如果端口由其他必要程序使用，可把本地代理端口改为未占用端口，例如 7891，随后同步更新系统代理和应用内代理。

不要只改 YAML 中的端口而保留 Windows 中的旧值。出现 access denied 且查不到监听者时，还可能涉及安全策略或系统保留端口，不能一概判断为进程占用。应结合错误原文和系统策略继续检查，而不是反复结束未知进程。

防火墙与安全软件：核对被阻止的对象

Windows 防火墙弹窗主要涉及应用在不同网络配置文件下的通信许可。客户端界面、代理内核和后台服务可能是不同的可执行文件。只允许图形界面，不代表内核对应规则正确；但仅供本机使用的回环代理，也不需要因此向公共网络开放入站端口。

按证据处理拦截

1. 打开「Windows 安全中心」→「病毒和威胁防护」→「保护历史记录」，核对事件时间、被处理文件路径和检测名称。
2. 确认文件来源及其与当前客户端安装目录的关系。若仍无法判断，保留记录，交由客户端维护者或安全软件厂商分析。
3. 按 Win + R 输入 wf.msc，在高级安全防火墙中检查指向当前内核路径的出站规则，以及是否存在显式阻止。
4. 若确需调整许可，限定具体程序、方向和适用网络。更新内核后若路径变化，应重新核对规则目标。

显式阻止规则可能优先于允许规则，仅新增一条允许规则未必有效。第三方安全软件也可能具有独立网络过滤模块，应查看它自己的事件记录。不要把关闭全部防护、排除整个下载目录或开放所有端口作为默认排错步骤。

UWP 回环：仅处理确实受限制的应用

部分运行在 AppContainer 中的应用无法按普通桌面程序的方式连接本机回环代理。这时可能出现浏览器正常、某个商店应用失败的现象。并非所有 Microsoft Store 安装的程序都属于这种情况，也并非所有应用都遵循系统代理；应先确认应用类型及失败日志。

以管理员权限打开 PowerShell，先查看现有回环豁免及本机安装包信息。下面以 Microsoft Store 包为检查示例，查询不到结果时不要继续套用包名。

CheckNetIsolation.exe LoopbackExempt -s
Get-AppxPackage -Name Microsoft.WindowsStore |
  Select-Object Name, PackageFamilyName

确认该包就是需要处理的对象后，可通过变量读取当前用户实际安装的包族名，避免把包全名或安装目录当作包族名：

$app = Get-AppxPackage -Name Microsoft.WindowsStore
if ($app) {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($app.PackageFamilyName)"
}

完成后关闭并重新打开目标应用，再观察请求是否进入客户端。需要撤销时，对同一包族名执行删除操作：

$app = Get-AppxPackage -Name Microsoft.WindowsStore
if ($app) {
    CheckNetIsolation.exe LoopbackExempt -d "-n=$($app.PackageFamilyName)"
}

回环豁免只改变目标应用访问本机回环的限制，不负责设置代理、修复订阅或修改规则。若客户端提供回环管理工具，也应仅选择需要的应用，不批量放开所有包。启用 TUN 有时可改变应用流量路径，但不应把它当作所有商店应用问题的固定答案。

TUN 与 DNS：基础连接成功后再扩展接管范围

当显式代理与浏览器系统代理均正常，而游戏、命令行工具或不支持代理设置的应用仍直连时，再评估 TUN。mihomo 的 TUN 接管范围受虚拟接口、路由、排除项和 DNS 设置共同影响；开启一个开关不能保证所有流量都被接管。

• 确认客户端要求的服务或权限已就绪，再开启 TUN。检查日志中的虚拟接口创建与路由错误。
• 检查同时运行的企业 VPN、其他虚拟网卡和代理工具。多套自动路由可能争用默认路由，应一次只验证一项变化。
• 在连接列表查看目标应用是否出现，以及其规则和出口。应用没有连接记录时，优先查接管路径，而不是更换代理组。
• 域名失败但已知 IP 可达时，再检查 DNS。可用 Resolve-DnsName example.com 观察系统解析，但它不能单独证明内核内部解析也正常。

不要把公共 DNS 地址填入所有设置作为统一修复。系统 DNS、内核 DNS、代理节点域名解析和浏览器安全 DNS可能使用不同路径。改动前记录原值，一次调整一项，并检查内核是否报告解析超时或上游不可达。涉及 TUN 与路由配置时，可结合全平台安装指南核对对应平台的配置范围。

按故障现象收敛排查顺序

排错记录应包含系统版本与架构、客户端和内核版本、故障发生时间、监听端口、显式代理测试结果，以及相邻时间段的错误日志。分享前删除订阅地址、认证令牌、节点密码和个人域名信息。每次只改变一个条件，才能把权限、监听、规则与网络出口的问题分开定位。