Clash 常见问题
配置与连接排查

客户端负责订阅管理、策略组选择和系统代理开关；mihomo 内核负责监听端口、解析 DNS 和执行分流规则。Linux 桌面用户可先使用 Clash Verge Rev，服务器用户可直接运行内核。两者的配置保存位置不一定相同，图形客户端还可能生成运行配置。排查前先确认实际启动的二进制和配置目录，不要修改另一份闲置的 config.yaml。命令行部署通常使用 ~/.config/mihomo/，最终仍以启动参数中的 -d 或 -f 为准。

日常使用先选规则模式，即 mode: rule，再检查请求命中的规则与策略组。全局模式把一般连接交给 GLOBAL 策略组，但该组仍可能选中 DIRECT；它也不会自动接管没有进入内核的程序流量。直连模式让进入内核的连接直接访问目标，适合对照测试。切换模式后应新建连接，旧的长连接可能继续沿用原路径。若某个软件没有变化，先确认它是否使用系统代理或已被 TUN 接管，再判断模式设置。

客户端与内核提供连接和分流能力，不等于已经具备可用的远端代理。订阅通常包含节点、策略组或规则，也可能只提供节点集合。导入前确认服务方提供的是 Clash 或 mihomo 可识别的格式；仅含节点的 Provider 文件不能直接替代完整配置。成功导入后还要激活对应配置，在策略组中选择可用出口，并检查服务有效期与流量额度。订阅链接通常带访问凭据，不要贴到公开日志、截图或在线转换页面。

不必同时开启。系统代理适合遵循桌面代理设置的浏览器与应用，TUN 则通过虚拟网络设备和路由接管更多连接。首次部署建议先关闭 TUN，用显式代理验证节点与端口，再单独测试 TUN，便于区分配置问题和系统权限问题。两者同时启用时，还需检查客户端的路由排除和 DNS 设置，避免重复接管或连接回环。TUN 也不是所有流量必然被代理；最终出口仍受规则、策略组和绕过设置影响。

先确认导入的配置已设为当前使用项，而不只是保存在配置列表中。随后查看订阅更新日志，检查返回内容是否实际为登录页、错误页或空文件。若配置使用 proxy-providers，主配置加载成功不代表节点集合已拉取成功，还要查看对应 Provider 的状态、路径与远端响应。命令行部署可执行 mihomo -t -d ~/.config/mihomo 检查配置，再检查运行日志中的下载错误。不要把包含凭据的订阅 URL 直接提交到公开求助区。

401 通常与认证缺失或凭据失效有关，先从服务方重新获取链接；403 还可能涉及访问策略、请求头或额度限制，应结合响应正文判断。超时则先确认网络能否访问订阅地址，必要时检查拉取订阅所用的代理是否依赖尚未加载的节点。证书错误先用 timedatectl 检查系统时间，再检查发行版的 CA 证书。不要通过关闭证书验证长期绕过报错。若链接已更新，替换旧地址后手动刷新，并查看具体的 HTTP 状态与日志。

先运行 ls -l /dev/net/tun 检查设备是否存在；缺失时可检查 tun 模块，必要时执行 sudo modprobe tun。然后确认实际运行的内核具备创建虚拟网卡和修改路由的权限，优先使用图形客户端提供的服务安装方式。直接部署时，部分环境可通过 sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo 授权，但必须与实际二进制路径一致；更新文件后可能需要重新授权。容器还需放行设备与网络能力，systemd 的能力限制也可能阻止授权生效。

先执行 systemctl --user cat mihomo 检查 ExecStart，确认二进制与配置目录都存在。服务中优先写明确路径，配置目录可使用 %h/.config/mihomo，不要依赖 shell 展开 ~ 或读取交互式终端的环境变量。再用 mihomo -t -d ~/.config/mihomo 测试同一目录，并执行 journalctl --user -u mihomo -b -n 80 --no-pager 查看退出原因。修改服务文件后运行 systemctl --user daemon-reload，再重启服务；用户级与系统级服务命令不要混用。

桌面系统代理不是统一的流量接管接口，部分命令行程序只读取环境变量，部分应用使用自己的代理设置。先用 curl -I -x http://127.0.0.1:7890 https://example.com 验证显式代理路径，再按程序文档设置 http_proxy、https_proxy 或 ALL_PROXY。注意变量大小写支持存在差异，NO_PROXY 也可能让目标绕过代理。若需要接管不支持代理设置的程序，可在显式代理验证通过后考虑 TUN；不要仅凭桌面开关判断终端已经走代理。

先确认普通桌面浏览器可以通过同一端口连接，再判断是否为应用容器的回环限制。部分 UWP 应用访问 127.0.0.1 上的代理需要回环豁免，可优先使用客户端提供的 UWP 回环设置，按需选择目标应用。管理员终端中的 CheckNetIsolation LoopbackExempt -s 可查看现有豁免列表，手动修改时应先确认准确的包族名称。只为需要的应用开放，不要批量修改未知应用。若已经启用 TUN，则同时检查该应用流量是否真正进入内核，避免把所有失败都归因于回环限制。

需要同时满足监听地址、allow-lan 与防火墙三项条件。启用 allow-lan: true 后，检查 bind-address 是否允许局域网地址，并用 ss -lntp 确认实际监听位置；其他设备应填写这台电脑的局域网 IP 和 mixed-port，而不是 127.0.0.1。防火墙仅对可信网段开放代理端口，按需设置代理认证。external-controller 管理接口应继续限制在本机，除非已明确配置访问控制。HTTP 代理共享与让电脑充当透明网关是两种部署，不要把设置代理端口等同于完成网关配置。

HTTP 类型的 proxy-providers 可用 interval 指定更新间隔，单位为秒，例如 interval: 3600 表示按小时检查。每个 Provider 应使用独立的缓存路径，并确认运行用户对目录具有写权限。health-check.interval 控制节点健康检查，不是订阅刷新周期，缩短它不会更快获得新节点，反而会增加请求与耗电。图形客户端的配置更新计划还可能独立于内核 Provider 工作，先明确更新的是整份配置还是节点集合。修改前备份配置，再检查日志中实际的拉取结果。

先确认订阅有效、策略组确实选中了远端节点，再检查节点服务器地址能否解析、系统时间是否准确。单个节点失败而其他节点可用，优先排查该节点或测试目标；全部失败则检查本地网络、防火墙、订阅状态与内核日志。延迟测试只反映指定测试地址的连接结果，不代表所有网站都不可访问。可用显式代理请求一个实际需要访问的 HTTPS 网站作对照，并记录连接阶段报错。不要同时更换 DNS、端口与模式，每次只改一项，才能确认是哪一环恢复。

先检查 mixed-port 是否监听，再比较显式 HTTP 代理和浏览器访问结果。可运行 curl -I -x http://127.0.0.1:7890 https://example.com；若请求成功而浏览器失败，重点检查浏览器代理、扩展与安全 DNS。若日志显示域名解析错误，再核对 dns.enable、上游 DNS 可达性以及 TUN 的 DNS 接管。fake-ip 模式下返回映射地址通常属于预期行为，不能仅凭地址判断故障。应用缓存旧解析结果时，可重启应用并重新建立连接，必要时检查系统与浏览器各自的缓存。

执行 ss -lntp 查看 TCP 监听端口，重点检查 mixed-port 和 external-controller 对应的端口；需要查看其他用户进程时可使用 sudo。常见原因是图形客户端与手动启动的内核同时运行，或者用户级和系统级服务重复启动。先识别进程归属，再停止不需要的实例，不要直接终止所有同名进程。也可修改冲突端口，但必须同步调整系统代理、环境变量和面板连接地址。若错误涉及 UDP 监听，补查 ss -lnup，避免只检查 TCP 后误判端口空闲。

先运行 systemctl --user is-enabled mihomo 与 systemctl --user status mihomo，区分服务未启用和启动失败。需要开机后随用户管理器启动时，可执行 systemctl --user enable --now mihomo。用户服务在退出登录后是否继续运行还取决于 linger 设置，可用 loginctl show-user "$USER" -p Linger 查看；确需脱离登录保持运行时，再评估 loginctl enable-linger 的影响。若 TUN 依赖额外权限，应单独检查权限是否在升级后丢失。最后确认桌面代理或终端变量仍指向正在监听的端口，而不是只检查服务状态。