Clash Nyanpasu 常见问题

Clash Nyanpasu 是管理配置和代理设置的图形客户端，mihomo 是负责协议连接、DNS 解析与规则执行的内核，订阅服务则提供服务器信息与配置内容。安装客户端不会自动获得可用线路；还需要来源可信、仍在有效期内的订阅或自建服务器配置。遇到连接问题时，应先区分是界面设置未生效、内核未运行，还是订阅中的服务器不可用，再检查对应环节。

规则模式按当前配置的规则顺序，为每条连接选择直连或某个策略组，适合作为日常起点。全局模式把进入内核的连接交给全局策略选择的出口，但并不代表电脑上所有程序都已被接管。直连模式通常让进入内核的连接直接访问目标。切换模式不会替代系统代理或 TUN 设置；如果应用流量根本没有进入内核，切换这三种模式也不会改变它的出口。

不能。安装包需要同时匹配操作系统与处理器架构，Windows 可执行文件不能直接用于 macOS、Linux 或手机。下载中心按平台列出可选客户端，不表示每款客户端都覆盖所有平台。先查看设备系统信息，再选择对应入口；手机端还要确认客户端支持订阅使用的协议与字段。桌面配置可以作为迁移参考，但本地路径、监听地址、权限和 TUN 选项往往需要重新调整。

订阅链接是获取配置内容的地址，YAML 是常见的配置文件格式，两者不是同一种东西。有些链接返回完整配置，包含代理、策略组、规则与 DNS；另一些只返回节点信息，需要客户端或订阅服务支持相应转换。导入前应查看服务说明中的兼容格式，不能仅凭链接外观判断。订阅地址可能包含访问凭据，排查时不要公开完整链接，也不要提交到不熟悉的在线转换页面。

日常使用优先选择客户端提供且与当前配置兼容的稳定版。Alpha 通常用于验证新功能或修复，行为可能继续调整，不应只因名称较新就切换。确实需要某个新字段或协议特性时，先核对内核发布说明，再备份配置并测试。切换后如果出现启动失败，应阅读第一条配置错误并恢复原内核；不同内核支持的字段并不完全相同，切换内核不等于自动转换配置。

导入成功只表示内容已保存，不代表配置已经启用。先在配置列表中选中刚导入的项目，确认内核启动成功，再在代理页面为实际使用的策略组选择可用出口。日常可先使用规则模式，并开启系统代理；不遵循系统代理的应用再考虑 TUN。最后访问一个明确可用的站点，同时查看连接记录。若记录为空，应先检查流量接管方式，而不是反复更换订阅或节点。

先检查订阅是否过期、被重置或复制不完整，再在日志中区分请求失败与解析失败。请求失败要检查本机网络、证书与服务端响应；解析失败要确认返回的不是登录页、错误页或客户端不支持的格式。若服务商要求特定 User-Agent，应按其说明设置。手动修改过 YAML 时还要检查缩进与字段类型。排查期间保留旧配置，避免删除后失去仍可使用的线路。

先关闭 TUN，确认普通代理方式可以工作，再按客户端当前版本的说明安装或启用服务模式，并在系统提示时授予所需权限。Windows 需要检查服务是否运行、网卡组件是否被安全软件阻止；其他系统则检查辅助服务与网络扩展授权。不要连续启动多个代理客户端争用虚拟网卡。仍然失败时保存日志中的首条错误，关闭冲突程序后重试，避免直接删除不明网卡或修改系统路由。

不一定。系统代理让遵循操作系统代理设置的应用连接到本地代理端口，适合先验证浏览器访问。TUN 通过虚拟网络接口接管符合路由条件的流量，常用于不读取系统代理设置的程序，也需要额外权限和正确的 DNS 配置。两者可以在部分配置中共存，但排查时建议先只启用一种方式。确认单独工作正常后，再按实际需求组合，避免把路由、端口和解析问题混在一起。

优先备份订阅来源、手动维护的配置、覆写或合并规则，以及自定义 DNS、端口和内核选择。使用客户端提供的导出或备份功能，并确认恢复方式；如果复制配置目录，应先退出客户端，避免文件尚未写入。自动更新订阅可能覆盖直接编辑的内容，因此长期修改应放在受支持的覆写机制中。备份文件也可能包含订阅凭据和服务器密码，应放在受保护的位置，不要附在公开问题反馈里。

在当前配置支持的覆写或规则编辑入口中，将目标域名的直连规则放到可能匹配它的宽泛规则之前，并保持规则模式。域名后缀规则会覆盖相应子域名，修改时要确认范围符合预期。保存并重载配置后，关闭旧连接或重启相关应用，再查看连接记录中的匹配规则与实际出口。不要只看浏览器页面是否打开；缓存、复用连接以及应用自身的代理设置都可能影响判断。

先确认该连接匹配的确实是刚修改的策略组。配置可能包含嵌套策略组，外层选择自动测速组后，实际节点仍由内层决定。已经建立的连接也通常不会因切换选择而立即迁移，需要断开旧连接或重启应用后再测。如果策略组类型为自动选择，应检查它的测试地址、周期和超时设置；这些结果反映测试条件下的可达性，不保证所有业务在同一节点上表现一致。

延迟测试通常测量访问指定测试地址的响应时间，不等于可用带宽，也不直接反映视频站点或下载服务器的速度。线路拥塞、服务端限速、目标站点的位置、丢包与协议开销都会影响实际体验。应在相近时段、同一网络和同一业务下比较节点，并查看连接记录是否使用预期出口。不要只依据单次最低延迟自动下结论；持续传输稳定性往往比几次测试的数值更有参考意义。

直接修改订阅下载得到的文件，可能在下次更新时被新内容替换。需要长期保留的规则，应使用客户端当前版本支持的覆写、合并或脚本处理机制，并先确认执行顺序。修改后分别测试手动重载和订阅更新，检查最终生效配置里是否仍有目标规则。订阅中策略组名称发生变化时，原有引用也可能失效；出现找不到策略的报错，应同步检查规则引用，而不是只恢复旧文件。

Fake-IP 会向应用返回用于映射域名的虚拟地址，内核再根据映射处理连接，有助于在接管流量时保留域名信息。它不是单独解决所有 DNS 问题的开关，还需要正确的 DNS 监听、流量接管与上游解析设置。某些局域网服务或依赖真实地址的应用可能需要例外处理。调整后应清理相关缓存并重新建立连接，结合日志与实际解析路径验证，不要仅凭检测页面出现某个地区就判断配置正确或泄漏。

先关闭代理验证基础网络，并确认系统时间准确，再检查配置是否启用、订阅是否仍有效以及内核日志是否报错。所有节点同时超时，更应关注共同环节，例如 DNS、测试地址不可达、网络限制或内核未运行；只有个别节点失败，才优先检查对应服务器。可在另一条可信网络上做对照，并尝试真实访问，而不是只依赖测速按钮。反馈时提供错误时间和脱敏日志，不公开完整订阅。

先查看客户端连接记录是否出现该程序的请求。没有记录时，检查系统代理地址与端口是否和内核实际监听一致，以及浏览器扩展、应用独立代理或其他 VPN 是否覆盖了设置。部分程序不读取系统代理，需要单独配置代理，或在明确需求后使用 TUN。若连接已经进入内核却走直连，则应检查匹配规则和策略组。不要将系统代理显示开启等同于所有应用都已被代理。

部分采用 AppContainer 隔离的 UWP 应用受到回环访问限制，可能无法连接本机代理端口。先确认桌面浏览器可以正常使用，再检查受影响应用是否属于该情况。若客户端提供 UWP 回环解限工具，可仅为需要的应用设置例外，并按提示授予管理员权限；也可使用系统的 CheckNetIsolation 工具管理例外。不要对所有应用批量放开权限。仍然失败时，还需检查应用是否遵循系统代理，或评估 TUN 接管方式。

先检查系统是否仍指向已经停止监听的本地代理地址，关闭残留的手动代理设置。再确认 TUN、服务模式或其他 VPN 是否仍在运行，正常停止后重新连接网络。如果此前手动修改过 DNS，应恢复为适合当前网络的设置，并刷新缓存。不要一开始就重置所有网卡或删除路由；这些操作可能影响公司网络和其他软件。恢复基础网络后，再重新启动客户端逐项开启功能，定位造成残留的设置。

先关闭 TUN 做对照，确认问题是否与流量接管有关，再检查当前配置对局域网地址、私有网段和内网域名的路由及解析处理。需要直连的目标应匹配到正确规则，内网域名也应交给能解析它的 DNS；仅修改代理规则未必能修复错误解析。公司 VPN 与 TUN 同时运行时还可能出现路由冲突。应根据实际网络范围设置例外，避免把过大的地址范围全部排除，从而改变其他连接的预期出口。