Clash 常见问题

Clash 通常指代理内核及其配置生态；mihomo 是从 Clash Meta 延续发展的内核，负责协议连接、规则匹配与流量转发。Mac 图形客户端在内核之外提供菜单栏、订阅管理和系统代理开关。两个客户端即使都使用 mihomo，设置入口、辅助服务和内核更新节奏也可能不同。排查时应同时记录客户端名称、客户端版本与内核版本，不要只写 Clash。旧配置能否沿用还取决于具体字段，客户端界面相似并不代表支持范围完全一致。

客户端提供运行配置的工具，不会因安装完成就自动获得可用的远程代理。订阅通常由服务提供方交付，用来获取节点、策略组和规则；也可以导入自行维护的本地配置。导入前先确认对方提供的是兼容 Clash 或 mihomo 的格式，并了解有效期与设备限制。订阅地址可能包含账户凭据，应按密码保管，不要贴到公开论坛、截图或在线转换页面。若暂时没有配置，先完成安装即可，反复开启系统代理不能补齐缺少的连接信息。

日常使用通常先选规则模式，由配置中的规则决定流量进入哪个出站策略。全局模式把连接交给全局策略组，但策略组仍需选中可用出站，并不保证每个程序的流量都会被客户端接管。直连模式让已接管的连接直接访问目标，也不等于关闭系统代理或退出客户端。遇到单个网站异常，可以短暂切换模式对照，再回到规则模式定位命中的规则。是否接管应用与如何选择出站是两件事，前者由系统代理、应用设置或 TUN 等入口决定。

正常的 HTTPS 连接由应用与目标网站完成加密，普通代理转发不要求安装根证书。代理服务仍可能接触连接时间、目标地址或流量规模等元数据，因此应了解服务方的数据处理方式。若某项操作要求安装证书并启用 HTTPS 解密，就需要另外评估其用途和信任范围。客户端日志也可能包含域名、连接错误与配置路径。分享诊断信息前，应遮盖订阅地址、认证字段和个人信息；不应把开启代理理解为所有访问都不可追踪。

打开苹果菜单中的关于本机，显示 Apple M 系列芯片时选择 arm64 或 Apple Silicon 安装包，显示 Intel 处理器时选择 x64 或 x86_64 安装包。若提供 Universal 通用包，可按该客户端说明安装。Apple 芯片运行 Intel 版本可能需要 Rosetta，但优先选择原生架构更便于减少兼容环节。还要检查客户端要求的最低 macOS 版本，架构匹配不代表系统版本也满足条件。具体入口见安装包页面，不能仅凭 MacBook 的外观或购买年份判断。

先区分系统提示的具体内容，并确认安装包来源、芯片架构和系统要求。将应用移入应用程序文件夹后尝试打开；若系统阻止启动，可到系统设置的隐私与安全性查看是否提供仍要打开，并仅对已确认来源的应用操作。已损坏提示也可能来自下载不完整、签名异常或版本不兼容，可重新下载并查看发布说明。不要为了启动未知应用而全局关闭系统安全保护，也不要直接复制来源不明的终端命令。若提示包含恶意软件警告，应停止运行并核实来源。

在客户端的订阅或配置页面选择从 URL 导入，粘贴服务方提供的完整地址并保存，等待获取和解析完成。随后明确选中这份配置作为当前配置，检查代理页面是否出现对应策略组，并在需要手动选择的组内指定出站。列表中出现一条订阅记录，只代表记录已保存，不代表下载成功或配置已启用。若导入失败，先查看 HTTP 状态与解析错误，区分地址不可访问和格式不兼容。不要把网页账户登录地址当作订阅地址；本地文件则应通过文件导入入口打开。

TUN 需要创建虚拟网络接口并调整路由，Mac 客户端通常通过特权辅助服务完成这些操作，因此可能弹出管理员授权。先在客户端设置中按提示安装或修复辅助服务，再开启 TUN，并查看内核日志是否报告接口创建成功。授权取消、服务未启动或服务与客户端版本不匹配，都可能导致开关立即回落。可以先关闭其他 VPN 或同类隧道工具后重试，但不要随意删除系统网络配置。若设备受组织管理且没有授权权限，应联系管理员；系统代理可作为支持它的应用的临时使用方式。

先确认内核正在运行，当前配置有效，系统代理使用的地址与端口和客户端实际监听值一致。然后到系统设置的网络页面，查看当前正在使用的 Wi-Fi 或以太网服务中的代理设置；切换网络服务后，原服务的设置不一定适用。浏览器扩展、应用内代理和其他 VPN 也可能覆盖连接路径。打开客户端连接页面，刷新一个测试网站，观察是否出现连接及其出站策略。没有连接时先查接管入口；出现连接但选择直连时，应检查规则和绕过列表，而不是反复点击系统代理开关。

很多命令行程序不读取 macOS 系统代理，而是使用自身配置或代理环境变量。先查看客户端实际的 HTTP 或混合监听端口，再按工具文档设置代理，例如 curl 可用单次命令参数指定代理，Git 可配置自身的代理选项。需要接管更多不读取系统代理的程序时，再评估 TUN。排查时留意旧的 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 环境变量，它们可能仍指向已退出的客户端或旧端口。修改变量后还要确认当前终端会话已更新；不要同时改多套入口，否则很难判断哪一项产生效果。

先在连接页面找到目标请求，查看实际域名、命中规则与最终出站。规则一般按顺序匹配，前面的宽泛规则可能先于后面的精确规则生效；策略组还可能引用另一个组，因此要沿组关系确认最终选择。若需要为单个域名调整路径，优先使用客户端支持的覆写或扩展规则功能，并遵循该功能的插入顺序说明。直接编辑订阅下载后的文件，可能在下次更新时被覆盖。规则使用的策略组名称必须真实存在；修改后重新加载配置并建立新连接，旧连接通常不会立即迁移。

这是 Windows 应用容器相关的问题，不属于 macOS 权限设置。部分在应用容器中运行的 UWP 应用默认不能访问本机回环地址，而桌面代理通常监听在本机，因此浏览器正常并不意味着这些应用也能连接。可先使用 Windows 客户端提供的回环豁免工具，按需允许对应应用访问本机代理，并遵循管理员授权提示。若客户端支持，也可评估 TUN 接管，但仍需检查应用自身行为和其他防火墙限制。不要在 Mac 上寻找同名开关，也不要通过长期关闭整套防火墙来绕过这个问题。

先查看服务方账户中的有效期、流量状态和订阅地址是否已重置。401 通常与认证有关，403 可能涉及访问策略或账户限制，404 可能表示链接已变更，但应以服务方说明为准。若收到的是登录网页或验证页面，客户端会因内容不是配置而解析失败。确认地址完整后再更新，并尝试客户端支持的直连或经代理获取方式，避免订阅获取路径依赖已经失效的连接。保留原有可用配置再操作，不要先清空全部订阅；向服务方求助时提供状态码与时间，不要公开完整链接。

先关闭代理确认基础网络可用，再区分单个出站异常和全部出站异常。只有一个超时时，可切换同一策略组内的其他出站，检查该服务是否维护。全部超时时，应核对订阅状态、系统时间、内核是否支持配置协议，以及日志中的解析、握手或认证错误。连通性测试超时也可能来自测试地址不可用或超时阈值过短，不应仅凭测试结果认定节点失效，可结合实际网页请求判断。更换网络后恢复通常提示当前网络路径存在差异；排查期间每次只改变一个条件，并记录结果。

先查看日志是否出现域名解析失败、DNS 请求超时或路由回环，再检查当前配置的 DNS 服务、TUN DNS 劫持和路由设置是否相互配合。浏览器的安全 DNS、其他 VPN 和系统中的自定义 DNS，可能让不同应用走上不同解析路径。macOS 的解析工具与应用不一定采用相同路径，单次命令结果不能代表全部应用。若使用 fake-ip，应确认相关地址能被正确接管，并按配置说明为不兼容的局域网服务设置例外。先恢复一份已知可用配置进行对照，不要同时更换 DNS、规则与全部节点。

如果客户端仍能打开，先关闭系统代理与 TUN，再正常退出，观察网络是否恢复。若应用已经异常退出，到系统设置的网络页面，选择当前活动的网络服务，在详细信息中的代理页面检查是否残留指向本机的代理地址；关闭确认属于该客户端的项目，再应用设置。同时检查其他 VPN、终端代理环境变量和曾手动填写的 DNS。受管理设备上的代理可能由组织配置，不应直接删除。若 TUN 路由或辅助服务未正常清理，可在保存工作后重新启动 Mac，再用不经过代理的请求验证基础网络。