Clash 常见问题

Clash 是代理内核及相关生态的名称，ClashX 是面向 macOS 的客户端名称，mihomo 则是持续发展的兼容内核。客户端负责菜单、订阅管理和系统集成，内核负责连接、DNS 与规则处理。不同客户端捆绑的内核、维护状态及功能入口并不一致，不能仅凭名称判断是否支持 TUN 或某种协议。选型时先核对项目说明与内核信息，再按对应客户端的文档操作。

客户端提供连接与分流功能，并不自动附带可用的代理服务。远程订阅通常包含节点、策略组和规则；也可以使用自行维护的本地 YAML 配置。导入前需要确认来源可信、服务仍在有效期内，而且输出格式与当前内核兼容。订阅链接中的令牌通常具有访问权限，不应公开截图或发送到公共转换网站。本站示例地址仅用于解释填写方式，不能用于实际连接。

日常使用通常从规则模式开始，连接会按配置中的规则顺序选择出站策略。全局模式将受内核处理的连接交给全局策略，但不代表所有应用流量都已被接管；系统代理或 TUN 仍需正确启用。直连模式用于绕过代理出站，适合对照排查。切换模式后应新建连接测试，已有长连接可能继续使用原来的路径，不宜仅刷新同一个页面就下结论。

系统代理向操作系统登记本地代理地址，主要影响遵循该设置的应用。TUN 通过虚拟网络接口接管符合路由条件的流量，覆盖范围通常更广，但依赖权限、路由与 DNS 配置。两者并非必须同时开启，也不能保证接管所有网络场景。初次配置可先验证系统代理，再按游戏、命令行或其他应用的实际需求启用 TUN，避免多个接管机制同时变化而难以定位问题。

延迟测试只能说明某个测试地址在当时通过指定节点完成了探测，不能证明所有网站、协议和端口都可访问。实际浏览还取决于策略组选择、规则命中、DNS 解析以及目标站点的限制。应同时查看连接记录中的目标域名、命中规则和实际出站，再用目标应用发起新请求。不要只按最小延迟选节点；连续请求能否稳定完成，比单次测试结果更有参考价值。

在客户端的订阅、配置或 Profiles 页面新增远程配置，粘贴完整 URL，保存后下载并选中该配置。不同客户端的入口名称会有差异，保存成功不等于配置已经激活。如果提示解析失败，应确认提供方输出的是兼容的 Clash YAML，而不是网页、单个节点链接或仅含 Base64 节点串的内容。优先使用提供方的适配入口；必须转换时，应理解令牌暴露和规则被改写的风险。

先确认内核正在运行，核对客户端显示的本地监听地址与混合端口，再检查 Windows 代理设置中的地址和端口是否一致。不要默认所有配置都使用 7890。随后检查浏览器扩展、独立代理设置以及代理绕过列表，避免它们覆盖系统设置。访问一个新页面并查看客户端连接记录；若完全没有新连接，重点排查流量接管，若已有记录，则继续核对规则和策略组的实际出站。

先将应用移入应用程序目录，再按当前客户端的提示完成首次启动。只有使用相关实现时才可能出现网络扩展、辅助服务或钥匙串授权，并非所有 ClashX 客户端都会出现同一组弹窗。系统设置中的放行入口随 macOS 版本变化，可查看隐私与安全性及网络相关设置。授权前核对请求来自刚安装的应用；此前拒绝过授权时，按项目文档重新触发，不要直接关闭系统安全机制。

先关闭 TUN，确认客户端支持当前系统的接管方式，再检查其服务模式、辅助服务或网络扩展是否安装并获得授权。Windows 客户端可能要求安装系统服务，Linux 常涉及服务权限或网络管理能力，macOS 则依实现使用授权辅助程序或扩展。只按当前项目的说明授予所需权限，不要反复以管理员身份启动来替代故障定位。完成授权后重新启用 TUN，并检查接口、路由与启动日志。

移动端通常通过系统 VPN 接口接管流量，首次连接需要确认系统授权。先检查是否已有其他 VPN、广告过滤或防火墙应用占用同一能力，再断开其他连接后重试。Android 还应检查始终开启的 VPN、阻止未使用 VPN 的连接及后台电池限制；iOS 则检查已有 VPN 配置和按需连接设置。先确认配置已启用且策略组有可用节点，再处理授权，避免将订阅错误误判为系统权限问题。

在订阅设置中选择合适的更新间隔，并留意客户端是否需要运行才能执行定时任务。设备休眠或网络受限时，更新可能延后。远程配置常在更新时整体替换，直接编辑其中的规则可能丢失；有长期自定义需求时，优先使用客户端支持的覆写、合并或规则扩展功能。更新前保留可用配置副本，更新后核对策略组名称和当前选择，尤其要留意提供方删除或重命名节点的情况。

select 策略组适合手动指定出站，url-test 根据探测结果选择节点，fallback 则按配置顺序寻找可用候选。它们依赖配置中的测试地址、间隔及候选列表，名称相近不代表行为相同。先确认规则实际指向哪个组，再检查该组内部是否还嵌套其他策略组。排查时可暂时固定到一个已验证的节点，减少自动切换带来的变量；恢复日常使用时再调整自动组的候选范围。

规则按顺序匹配，通常使用第一条命中的结果，因此需要检查是否被前面的宽泛规则或兜底规则提前接走。域名规则还依赖内核是否获得域名信息，进程规则则受平台与进程识别能力影响。先在连接详情查看实际目标、命中规则和出站，再修改对应规则；不要仅凭配置里存在某条规则就认为它会生效。保存并重新载入后，用新连接验证，远程配置则优先通过覆写保留改动。

Fake-IP 会向应用返回虚拟地址，由内核在后续连接中关联域名，并不是真实服务器地址。若局域网设备、特定应用或域名解析出现兼容问题，应先确认其请求是否进入内核以及使用了哪个 DNS。对确认不兼容的域名，可依据当前内核语法加入 fake-ip-filter，再按客户端说明重新载入并清理相关 DNS 缓存。不要把所有域名都加入过滤列表；切换 DNS 模式前先备份配置并记录原设置。

先记录问题发生时间、系统版本、客户端及内核信息，再将日志级别临时调整到能复现问题的程度，通常先从 info 开始。只导出故障时间附近的必要片段，提交前检查订阅 URL、令牌、认证字段、节点地址和个人访问域名。不要直接发布完整配置文件或整张订阅页面截图。排查结束后恢复常用日志级别，删除为复现而生成的敏感副本，避免长期记录不必要的访问细节。

先核对链接是否完整、有无多余空格，再查看更新日志。401 或 403 常与凭据或访问权限有关，404 可能是入口变化，429 表示请求受到频率限制；这些状态仍需结合提供方说明判断。连接超时则应检查当前网络、DNS 和下载订阅所用的出站方式。若返回内容是登录页面或错误网页，客户端也会报解析失败。避免连续重复更新，确认服务有效期后，再按提供方说明重新生成或获取链接。

先关闭其他代理工具，确认基础网络可用，再固定一个节点访问明确的测试目标。查看日志中的失败目标：如果是节点服务器地址，重点检查节点状态、域名解析、端口及本地网络限制；如果是目标站点，则结合出站策略继续定位。可更换一个节点和一种网络做交叉测试，每次只改一个变量。单个节点超时不等于订阅全部失效，也不要为消除超时直接关闭系统防火墙。

优先重新打开原客户端，关闭系统代理和 TUN，再正常退出，观察网络是否恢复。若应用无法启动，可在操作系统的代理设置中清除遗留的本地代理，并检查是否仍有手动 DNS 或 VPN 配置。不要删除单位网络要求的代理或 DNS；不确定时先记录原值。若曾运行多个代理工具，应逐个确认接管状态。必要时重新连接网络并清理 DNS 缓存，恢复后再单独启动一个客户端验证。

部分受 AppContainer 隔离的应用无法直接访问本机回环代理，即使浏览器能联网也可能失败。先确认受影响应用确实使用系统代理，再使用客户端提供的 UWP 回环工具查看应用列表，仅为需要访问本地代理的应用设置豁免。相关操作可能需要管理员授权，设置后重启目标应用。并非所有商店应用都采用相同网络模型；若仍异常，应继续检查其独立代理、DNS 与日志，而不是对所有应用批量放开。

GeoIP 更新失败时先查看日志中的下载地址、网络错误和文件访问权限，再确认配置使用的是 GeoIP 数据库还是其他地理规则数据格式；不同数据文件不能随意互换。若日志提示 address already in use，则是本地端口绑定失败，应检查是否运行了另一个客户端或重复内核。关闭重复进程，或修改监听端口并同步系统代理设置。两类错误属于不同环节，不要通过反复导入订阅来处理。