Mihomo 常见问题

Mihomo 是处理代理连接、DNS 和规则匹配的内核，图形客户端则提供配置导入、代理组选择与系统代理等操作界面。不同客户端即使使用同一内核，菜单名称、权限申请和配置合并方式也可能不同。查阅教程时先确认客户端名称，再查看设置页或日志里的内核信息。遇到配置项不识别，应结合实际内核版本查看文档，不能只凭窗口外观判断功能是否支持。普通桌面用户通常选择带图形界面的客户端，内核包主要用于命令行、服务器和路由器部署。

客户端负责执行配置，并不自动提供可用的远程代理服务。订阅链接通常由服务提供方生成，用来获取节点、代理组和规则等内容；本地 YAML 文件也可以承载这些设置。导入前应确认配置适用于 Mihomo，不能把服务商网页地址或账号登录页当成订阅地址。订阅链接可能包含访问凭据，应按账号信息保管，避免放进公开截图、群聊和代码仓库。若链接已经泄露，应在提供方后台重置，再更新各设备保存的地址。

规则模式按照配置中的规则顺序决定请求走直连、代理组或其他策略，适合日常分流。全局模式将交给内核处理的请求交由全局策略选择，适合短时对比规则是否影响访问。直连模式让这些请求直接连接目标。模式只决定内核收到请求后如何处理，不代表所有应用流量都已经进入内核；系统代理和 TUN 决定的是流量接入方式。排查时可临时切换全局模式并选择可用节点，测试结束后恢复规则模式，避免把临时设置长期保留。

UDP 能否转发取决于整条链路，包括应用流量是否进入内核、节点配置是否启用 UDP、代理协议和服务端是否支持，以及网络是否允许相关报文通过。客户端显示节点可用或网页能打开，只能证明部分连接成立，不能替代实际 UDP 测试。游戏和通话还可能同时依赖 DNS、直连策略及 NAT 环境。应先确认应用的接入方式，再检查命中的代理组和节点，最后在实际应用内测试。仅打开一个 UDP 选项无法补足服务端缺失的能力。

先查看更新日志中的 HTTP 状态和错误内容。401 常与认证缺失或凭据失效有关，403 则可能是访问限制、套餐状态或服务端策略，需要结合提供方说明判断。到后台重新复制完整订阅地址，检查是否漏掉查询参数、混入空格或复制成网页链接。若地址能够访问但导入提示 YAML 错误，应确认返回内容不是登录页或错误提示页。区分下载失败与配置解析失败后再处理，不要反复删除当前可用配置；旧配置可保留为临时回退。

TUN 需要创建虚拟网络接口并调整路由，通常比系统代理需要更多权限。Windows 上先查看客户端的服务模式是否已安装并运行，按客户端提示完成管理员授权；不要同时启动多个会接管路由的代理工具。macOS 应按所用客户端的说明检查系统授权或辅助服务，不能把所有弹窗都当成同一种网络扩展请求。授权后重新开启 TUN，并查看第一条失败日志。若仍无法创建接口，先关闭 TUN 验证系统代理是否可用，再分别排查权限、驱动与路由问题。

先查看操作系统提供的硬件信息，而不是根据设备年份猜测。Windows 可在设置的系统信息中查看系统类型，常见 Intel 或 AMD 电脑使用 x64，ARM 设备则需核对客户端是否提供兼容安装包。macOS 可在关于本机中区分 Apple 芯片与 Intel 处理器，分别选择对应架构。架构不匹配可能导致无法启动，或需要系统转译支持。更新前保留配置备份，并退出正在运行的旧实例。若安装器提示系统版本不满足要求，应查阅该客户端的发布说明，而不是重复安装。

Android 客户端常通过 VpnService 接入设备流量，首次连接需要确认系统 VPN 授权。它表示允许建立本地 VPN 接口，并不等于服务端节点已经可用。同一用户环境通常只能有一个活动 VPN，启动另一个 VPN 工具可能中断当前连接。后台断开时，先查看系统是否限制电池使用、后台活动或自启动，再按设备提供的设置放行客户端。还要区分进程被结束与节点连接失败：前者通常伴随通知消失，后者应继续查看日志和订阅状态。

系统代理只是向遵循系统设置的应用提供代理地址，并不会强制接管所有网络连接。先核对系统设置中的地址和端口是否与客户端实际监听一致，再查看应用是否使用自带代理、浏览器扩展、环境变量或独立网络设置。测试时打开客户端连接列表，确认新请求是否出现；没有记录时，应先解决流量接入问题，而不是修改分流规则。对于不遵循系统代理的应用，可按需配置应用内代理或 TUN。切换接入方式时先关闭冲突设置，避免把多种代理叠加后难以判断路径。

部分受 AppContainer 网络隔离约束的 Windows 应用不能直接访问本机回环代理，因此浏览器正常并不能说明这些应用也能连接。应先确认应用确实受此限制，再使用客户端提供的回环豁免工具，或系统的 CheckNetIsolation 工具查看并管理指定应用的豁免。只为需要的应用授权，不要批量放开全部应用。修改后重启目标应用，再观察连接记录。回环豁免只处理本机代理访问限制，不能修复订阅失效、DNS 错误或远程节点超时，也不是所有商店应用都需要设置。

常见的延迟测试通常测量访问指定测试地址所需的时间，不等于可持续下载带宽。测试目标、超时阈值、缓存以及节点到目标站点的线路都会影响结果。选择节点时先在相同测试地址和相近时间比较，再用实际需要访问的服务确认体验。下载速度还可能受到服务端限速、出口拥塞、无线网络质量和目标站点限制。不要只凭一次延迟排序频繁切换节点；正在进行的连接可能继续使用原来的节点，新连接才使用新选择，需要分别观察。

Fake-IP 模式使用映射地址把域名与后续连接关联起来，客户端再按域名和规则处理请求。这些地址不是目标站点真实的公网地址，不能用普通直连地址的思路判断其是否可达。若局域网设备发现、特定登录程序或依赖真实解析结果的应用异常，应先确认 DNS 请求是否交给 Mihomo，再针对具体域名检查 fake-ip-filter 和相关解析策略。不要直接把所有域名加入过滤。调整后可能需要刷新系统及应用的 DNS 缓存，并重新建立连接；修改前保留原配置便于对照。

先关闭代理验证基础网络是否正常，再检查设备时间、订阅是否更新成功，以及套餐或节点是否仍可用。若只有一个节点超时，换同一订阅中的其他节点对比；若全部超时，优先检查网络出口、配置错误和服务提供方状态。查看日志时区分域名解析失败、连接被拒绝、认证失败和握手超时，它们需要不同处理。测试地址本身无法访问也可能导致延迟测试失败，因此还应尝试实际目标服务。不要一开始同时改端口、DNS 和规则，每次只改一项并记录结果。

已连接有时只表示内核或本地 VPN 接口已经启动，不代表目标请求能够完成。先查看连接列表是否出现浏览器请求：没有记录就检查系统代理、应用代理或 TUN 接入；有记录则查看命中的规则、代理组和节点。随后结合日志区分 DNS 失败与远程连接失败，再临时使用全局模式和另一可用节点做对照。如果换节点恢复，重点检查原节点；如果只有特定域名异常，重点检查规则及解析。每次测试应重新发起连接，避免浏览器复用旧连接影响判断。

先确认当前使用规则模式，并检查实际生效配置，而不只看编辑器里保存的文件。部分客户端会合并订阅、覆写和本地规则，后续更新也可能改变最终内容。Mihomo 的规则按顺序匹配，较靠前的宽泛规则或 MATCH 可能使后面的条目无法命中。用一个明确域名发起新请求，在连接详情中核对命中规则与策略。已经建立的长连接通常不会因规则修改自动迁移，可关闭相关连接后重试。需要长期保留的自定义规则，应放在客户端支持的覆写或合并入口中。

先重新打开客户端，关闭系统代理和 TUN，再正常退出，避免直接结束进程留下接管状态。随后到系统网络设置中检查是否仍指向本机代理端口；内核已经停止时，这个地址不会提供服务。若曾手动设置 DNS，也应记录原值后按当前网络要求恢复。还要确认没有其他代理工具或 VPN 同时运行。完成一项后测试一次，不要立即执行大范围网络重置。若问题仅出现在休眠唤醒或网络切换后，记录出现时机、接口状态与日志，再检查客户端更新说明。