Clash 配置大全

一、YAML 结构与配置依赖

配置文件首先是一份 YAML 文档，其次才是 Clash 能理解的网络设置。解析器必须先读懂层级、列表和数据类型，内核才能继续检查字段。文件能在编辑器中打开，不代表结构正确；中文说明写在注释里通常没有问题，但用于分隔键和值的冒号、引号以及列表前的短横线应使用半角字符。建议把文件保存为 UTF-8，并让编辑器显示空白字符，避免肉眼看似对齐、实际混入制表符。

根字段、映射与列表

同一层级的键应在同一列。dns 是一个映射，它的子字段缩进在下方；proxies、proxy-groups 和 rules 通常是列表，每项以短横线开始。下面的配置可作为本地结构验证起点：仅监听回环地址，策略组只有直连选项，所有流量最终直连。它用于说明引用关系，并不包含可连接的远程代理。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: false

proxies: []

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Proxy

这里的 Proxy 不是预留关键字，而是策略组名称。末尾规则引用它，因此名称必须完全相同，包括大小写、空格和标点。DIRECT 则是内置策略，表示直接连接目标。读取配置时可以先顺着引用倒推：规则指向哪个组，组列出了哪些节点，节点是否确实定义；任何一环缺失，都可能导致加载报错或实际路径与预期不同。

缩进正确仍需检查数据类型

统一使用两个空格是便于阅读的约定，YAML 的关键要求是同层一致，不是所有位置都只能缩进两格。端口写成整数，开关写成 true 或 false，名称和密码按字符串处理。遇到包含冒号、井号或特殊字符的密码，使用引号包裹；双引号内的反斜杠有转义含义，单引号适合保留多数普通字符，单引号本身则需要重复书写来表示。

注释从符合 YAML 语法的井号位置开始，不能把密码的一部分误当作说明。不要在同一个映射里重复定义 dns 或 rules，即使某些解析器接受重复键，也可能只保留后者。空列表 [] 与空映射 {} 的用途不同，前者表示没有条目，后者表示没有键值；字段需要哪种结构，应以它的定义为准。

区分原始配置与运行配置

图形客户端常把订阅、全局设置、覆写片段共同生成一份运行配置。因此，订阅文件里的 mixed-port 不一定是当前监听端口，编辑下载缓存也不一定能持久保存。开始修改前先辨认三个位置：订阅原文、客户端持久化的自定义设置、内核正在读取的文件。路径因客户端而异，应从配置详情、运行信息或日志中确认，而不是按其他客户端的目录猜测。

维护时建议把一次修改限制在一个主题：先调整监听字段，再处理 DNS，最后变更规则。每完成一类修改就验证一次，这样报错能对应到有限的差异。若希望进一步理解文件各段的阅读顺序，可参阅config.yaml 逐段拆解；本页后续章节则分别展开字段边界，不要求按固定顺序把所有功能同时启用。

二、端口、模式与访问边界

通用字段决定客户端在哪里接收连接、按什么方式处理连接，以及向哪些设备开放入口。排查时应把“应用是否把请求送进内核”和“内核如何选择出口”分开。开启规则模式只影响已经进入内核的请求，并不会自动让所有应用使用代理；系统代理、应用内代理和 TUN 属于不同的接入方式，不能仅靠 mode 字段互相替代。

端口字段的分工

一般桌面使用保留一个 mixed-port 就足够清楚，不必为了“完整”同时开启全部监听。不同入口不能占用同一地址上的同一端口；如果另一个进程已经使用该端口，内核可能无法启动监听。修改端口后，还要同步系统代理、浏览器扩展、终端环境变量和应用内设置，否则应用仍会连接旧地址，表现得像节点不可用。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false
external-controller: "127.0.0.1:9090"

三种模式改变的是出口决策

rule 按规则列表从上到下决定目标；global 使用全局策略的选择处理已接入的流量；direct 让已接入流量直接连接。全局模式不等于系统级接管，直连模式也不代表应用绕开了本地内核。客户端可能把模式保存在自己的设置里，切换后再看最终配置或管理界面，才能知道当前生效值。需要具体场景对照时，可阅读规则、全局与直连模式区别。

log-level 常见取值包括 debug、info、warning、error 和 silent。日常使用可保留信息级别，复现问题时短暂提高详细程度，记录完成后再恢复。详细日志可能包含访问域名和连接信息，分享截图或文本前应删去订阅地址、认证信息以及不希望公开的目标。

局域网访问需要单独设计

让手机或另一台电脑通过本机代理上网时，仅把 allow-lan 改为真并不总是足够，还要确认监听地址覆盖局域网接口、系统防火墙允许入站，以及访问端填写的是代理主机的局域网地址。移动设备填写自身的 127.0.0.1 只会访问自身，并不会找到电脑。公共网络或共享网络中，应审慎开放监听，必要时为代理入口配置认证并限制来源。

管理接口与代理入口应分开对待。控制器能够读取状态并修改部分运行设置，不应直接暴露到公网；确有远程管理需求时，再结合认证、访问控制和受保护的传输通道设计。示例将其绑定到回环地址，只供本机工具使用。不要把控制器端口填入浏览器代理设置，也不要因为管理界面可打开，就认定代理监听和远端连接已经正常。

还需区分顶层 ipv6 与 DNS 下的同名字段：前者涉及内核 IPv6 使用行为，后者控制内置 DNS 的 AAAA 回答行为，两者不是同一开关。若网络确实依赖 IPv6，不能把关闭它当作通用优化。先记录故障发生在解析、连接还是路由阶段，再决定是否调整；端口冲突的具体定位命令见7890 冲突定位与 mixed-port 修改方法。

三、DNS、Fake-IP 与解析路径

DNS 配置解决域名如何得到地址，以及内核怎样保留域名与连接之间的关联。它不等同于代理规则，也不保证应用一定把解析请求交给内核。启用内置 DNS 后，系统或应用仍可能使用原有解析器；通过系统 DNS、TUN 的 DNS 劫持或应用代理协议传递域名，才可能让相应请求进入这条路径。检查前应画清楚“应用、系统解析、内核、上游解析器”之间的实际关系。

基本字段与引导解析

enable 开启内置解析服务，listen 指定监听地址，nameserver 提供常规上游。使用带域名的加密 DNS 地址时，还可能先需要解析这个上游自身的主机名；default-nameserver 用于这类引导场景，应选择在当前网络中可达、符合内核要求的地址。下例监听本机非标准端口，便于测试，但不会自动改变操作系统 DNS。

dns:
  enable: true
  listen: "127.0.0.1:1053"
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query

示例中的上游只是可读的配置实例，是否适合当前网络需要实测。加密 DNS 能保护相应解析链路的传输，不意味着后续业务连接必然经代理。标准 DNS 查询通常使用五十三端口，而示例使用一〇五三端口；普通系统设置只允许填写地址时，不能直接把带端口字符串照搬进去，应通过客户端提供的接管方式或受支持的转发器衔接。

Fake-IP 与 Redir-Host 的区别

fake-ip 为被处理的域名分配一个合成地址，再由内核把后续连接映射回域名。这样可以减少部分路径对预先获得真实地址的依赖，并保留域名规则的判断条件。redir-host 以真实解析结果为基础处理连接，适合需要真实地址的场景，但实际规则判断仍受接入方式、缓存和域名关联信息影响，不能简单概括为某一种模式永远更快。

fake-ip-filter 指定不使用合成地址的域名，常用于局域网名称或需要真实地址的应用。添加例外应针对确实出现兼容问题的域名，而不是把整个常用站点列表全部排除。过滤 DNS 合成行为不会自动添加直连规则；一个域名即使拿到真实地址，连接仍可能被规则送往代理组。DNS 例外与出口策略是两个需要分别检查的层级。

切换增强模式后，系统、浏览器和应用可能还保留旧缓存，已有连接也可能继续复用先前路径。验证时先结束测试应用的相关连接，必要时刷新其 DNS 缓存，再发起新请求。看到合成地址不能直接判定解析故障；但如果客户端已经退出，系统仍缓存合成地址，就可能出现暂时无法访问的现象，此时应恢复正常解析链路并刷新缓存。

分域解析与代理端点解析

更复杂的配置可以用 nameserver-policy 对指定域名选择不同上游，也可以用 proxy-server-nameserver 单独处理代理服务器域名。后者有助于避免启动时的循环依赖：代理端点还没有解析完成，却要求先经过这个代理去访问解析器。是否需要这些字段，取决于网络和内核支持情况，先让基础解析可用，再逐项引入策略，比一次复制完整 DNS 配方更容易定位错误。

启用 respect-rules 会让 DNS 上游连接的路由遵循相应规则，配置者必须同时考虑代理端点的独立解析与启动顺序。不要把远端解析器、代理组和代理主机名互相指向，形成必须先完成自身才能启动的闭环。若采用规则集匹配 DNS 策略，还需确认相关规则集已成功加载；解析器选择本身的失败，可能发生在业务分流之前。

四、代理节点字段与协议边界

proxies 描述远端代理端点，每个条目至少要满足对应协议所需的字段。节点名称只是本地引用标识，服务器地址才是连接目标，端口则是远端服务的监听端口。它们与本机的 mixed-port 没有替换关系。手动配置前，应从服务提供方取得完整参数；只有服务器地址和密码，并不意味着已经知道加密方式、传输层以及证书校验所需的信息。

名称、类型、地址与认证

name 应保持唯一且便于辨认，策略组通过名称引用节点。type 决定后续字段怎样解释，不能把一种协议的密码直接放入另一种协议的示例中。server 可以是域名或地址，port 应为有效端口整数。下面以 Shadowsocks 展示节点映射结构，地址和密码均为教学值；实际使用必须同时替换成服务端提供的参数。

proxies:
  - name: "示例 SS"
    type: ss
    server: ss.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

cipher 必须与服务端一致，不能因为某个名称看起来更新就自行替换。密码中存在空格、井号或冒号时应妥善引用，避免解析后字符串发生变化。udp: true 表示允许相应节点使用 UDP 能力，并不保证每个应用的 UDP 都会被接入，也不能让不支持该能力的远端服务自动具备它。最终效果还取决于接入方式、协议和服务端配置。

TLS 身份与传输字段

涉及 TLS 的节点，还要区分实际连接地址和用于证书验证的服务器名称。某些协议使用 sni，某些使用 servername，字段名并非在所有协议下通用。下面以 Trojan 说明这一层关系：server 决定连接到哪里，sni 告诉 TLS 握手预期的主机名；两者是否相同，应以服务端部署方式为准，而不是按浏览器访问地址推断。

proxies:
  - name: "示例 Trojan"
    type: trojan
    server: gateway.example.com
    port: 443
    password: "your-password"
    sni: gateway.example.com
    skip-cert-verify: false
    udp: true

skip-cert-verify: false 保持证书验证。出现证书错误时，先检查系统时间、预期主机名、服务端证书链和连接是否被重定向，再判断配置是否有误。关闭验证可能掩盖身份错误，不应作为所有 TLS 问题的默认修复。使用 WebSocket、gRPC 等传输时，还应按协议要求检查路径、服务名或请求头；端口能建立连接，不代表这些上层参数已经匹配。

订阅节点与外部节点提供器

订阅可能直接生成 proxies，也可能通过 proxy-providers 提供节点集合。后者是命名资源，通常由策略组的 use 引用，不等同于在 proxies 列表里写一个节点名。提供器的远程地址、缓存路径、更新间隔和健康检查各有职责；下载成功与节点可连接也是两件事，前者只说明配置资源能够取得。

使用外部节点时，先检查资源本身是否为内核接受的结构，再检查策略组有没有引用正确的提供器名称。某些服务返回的是供客户端导入的完整配置，不能直接当作只含节点的提供器文件。若客户端提供订阅转换，应确认转换结果的协议和字段没有被丢弃，尤其留意传输参数、证书名称及专属选项，不能仅凭节点总数相似就认为内容一致。

手工改名会影响所有引用该名称的策略组。删除节点前，先在配置内查找其名称；批量替换时注意同名字符串可能还出现在规则或说明文字中。订阅更新后名称可能改变，因此固定引用少量节点的自定义组需要定期检查。发布配置或求助时，应把服务器、密码、订阅地址和可识别账户的信息一起脱敏，保留字段结构与错误类型即可支持多数初步判断。

五、策略组类型与引用关系

策略组把出口选择与规则匹配分离。规则只需要指向一个稳定名称，节点更换或选择方式调整时，可以在组内部处理。proxy-groups 的每个条目包含名称、类型和候选来源；候选可以是节点、内置策略，也可以是其他策略组。名称是引用契约，不只是界面标签，调整名称时必须同步修改规则和上层组，否则原本正确的链路会出现断点。

手动选择与自动探测

select 由用户在客户端界面选择候选项，适合明确控制出口。url-test 根据测试结果选择候选，fallback 更强调按候选顺序维持可用出口，load-balance 则按其策略分配连接。它们不是四个不同风格的同义字段；选择前应先决定希望手动固定、自动比较、优先备用，还是分散连接，再填相应参数。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    proxies:
      - "示例 SS"
      - "示例 Trojan"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

此片段引用上一章的两个教学节点，只能与实际存在的节点定义配套使用。interval 在此表示测试间隔秒数，tolerance 用于减少候选间小幅差异引发的切换；它们不是界面展示的实时测量结果。测试地址应选择当前环境允许访问且响应稳定的目标，测试失败也可能是该地址受限，而不是所有业务访问都不可用。

测试结果不代表完整业务体验

健康检查通常衡量访问特定 URL 的结果，不能直接等同于下载速度、视频播放质量或所有目标站点的可达性。某个出口通过探测，但访问特定服务仍失败，可能与目标限制、协议、地域或远端网络路径有关。此时应对实际业务发起新连接，结合连接详情检查，而不是只反复改变测试间隔，或把一次探测成功当作所有网络层都正常的证明。

候选中包含 DIRECT 意味着用户可能主动或通过组行为选择直连。若某项业务必须固定走代理，就不应在对应组里加入直连作为看似方便的候选。相反，用于本地服务的组应明确是否允许远端代理。策略组名称也应反映用途或选择方式，避免把“自动”“备用”“直连”混在相似名称中，导致界面选错后难以发现。

提供器引用、组嵌套与循环

通过 use 引用提供器时，填的是 proxy-providers 下定义的键，而不是订阅的显示标题。使用过滤表达式筛选节点，还要确认结果至少包含一个有效候选；名称规则变化可能让过滤结果变空。编辑后先看组内实际出现的选项，再判断规则是否正确，避免规则已经命中目标组，组却没有可用节点的情况。

组可以引用另一个组，以实现“业务组选择手动组或自动组”的分层，但依赖必须最终落到节点或内置策略。甲组引用乙组、乙组再引用甲组就是循环，给组换名不会解决它。复杂配置可以画成一条简短链路：业务规则、业务组、出口组、节点。链路层数越多，越需要检查每一层当前选项，否则界面看到的第一层选择并不等于实际出口。

客户端通常能够记住手动选择，但记忆状态可能来自运行数据而不是 YAML 默认排序。重载配置后是否保持选择，要看客户端与内核的保存机制；只把节点挪到列表第一位，不一定改变已保存的选项。调试时明确查看当前选中值，必要时手动重选，然后用新连接验证，不要凭文件顺序推断运行状态。

六、规则语法、顺序与兜底

rules 是有顺序的决策列表，而不是无序标签集合。内核从上到下检查当前连接可用的信息，命中一条后就采用对应策略，不会继续寻找“更具体”的后续规则。因此，优先级首先来自位置。排查分流结果时，除了看规则内容，还要看它前面有没有更宽泛的域名、地址或兜底规则，尤其注意订阅生成规则与自定义规则的合并位置。

常见规则类型与匹配范围

域名规则填写主机名，不带 https://、路径或查询参数。想让某个网站走代理时，不能把浏览器地址栏整条 URL 粘贴进 DOMAIN。一个页面也可能请求多个域名，只覆盖主页面主机并不能覆盖静态资源、认证和接口；应依据连接记录确定真正需要处理的主机，再选择精确匹配或后缀匹配。

rules:
  - DOMAIN,router.home.arpa,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-KEYWORD,github,Proxy
  - DOMAIN-SUFFIX,googleapis.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

地址规则与 no-resolve

no-resolve 用于相应地址类规则，表示不为了评估该规则额外进行域名解析，不是关闭整套 DNS。若连接目标本来就是地址，内核仍可按地址匹配；若只有域名且缺少可用于判断的地址，规则可能无法据此命中。是否添加这个参数，应根据是否希望这条规则触发解析决定，不能把它当成每条规则都应追加的性能开关。

GEOIP 判断依赖地址归属数据库，不以公司归属或用户所在地区为依据。域名使用境外服务商的地址、本地服务采用公共网络，都会影响直觉与实际匹配的关系。数据库更新也可能改变结果，所以对必须固定处理的业务，应在宽泛地域规则前添加更明确的域名例外。数据文件是否可用，还需在内核日志中确认。

规则集、进程匹配与作用边界

RULE-SET 可以把一组规则抽到 rule-providers 管理的资源中，便于更新和复用。提供器的行为类型与文件内容必须一致：域名集合、地址集合和传统规则集合不能随意互换。声明了远程规则集，不代表它已经下载成功；首次启动、网络受限或缓存路径错误时，都应检查加载日志，再分析引用它的规则是否能够执行。

进程规则依赖操作系统与接入方式能否提供进程信息。在一台路由设备上接收其他终端的连接，通常不能因此知道远端终端内部的应用名称；进程名匹配也不应被理解为跨平台恒定能力。使用这类规则前，先确认当前客户端支持范围。对于普通网站分流，明确的域名规则往往更容易复现，也更方便在不同设备间共享配置。

末尾 MATCH,Proxy 表示剩余流量进入代理组；写成 MATCH,DIRECT 则表示剩余流量直连，两者体现不同的默认策略。必须根据实际需求选择，而不是机械沿用示例。若把它放在列表开头，下方规则就失去作用。修改后应关闭测试应用的旧连接或发起新的独立请求，因为已建立的连接通常不会因规则重载而自动迁移出口。

规则命中只说明目标策略已经确定，并不证明出口连接成功。日志若显示命中 Proxy 后仍报握手错误，应继续看组的实际选择和节点参数，而不是把同一条规则重复添加多次。反过来，完全看不到请求记录时，应返回接入层检查系统代理或 TUN，避免在尚未进入内核的流量上反复修改规则。

七、订阅覆写与配置合并

订阅文件承担远程更新，自定义配置承担本地偏好，两者直接混写容易在下次更新时发生冲突。覆写的目的，是把端口、DNS、业务规则或自定义组保存在稳定位置，再由客户端生成最终配置。需要先确认当前客户端提供的是完整替换、字段合并、规则前置还是脚本处理；不同功能名称可能相似，实际合并算法却不相同，不能照搬另一款客户端的操作路径。

标量、映射与列表分别处理

端口和模式这类标量，通常只有一个最终值，后执行的覆盖可能替换前值。DNS 是嵌套映射，有的工具递归合并，有的替换整段；规则和策略组则是列表，常见行为包括全部替换、前置或追加。YAML 只描述数据，本身不会替客户端决定这些语义。因此，下例只是希望写入的字段片段，不保证在任何客户端中都能直接达到同样效果。

mixed-port: 7890
mode: rule

dns:
  enable: true
  enhanced-mode: fake-ip

rules:
  - DOMAIN,router.home.arpa,DIRECT

如果工具把 rules 视为整体替换，上例会让原订阅规则全部消失；如果工具把规则追加到已有 MATCH 后面，新规则又可能永远无法命中。正确做法是使用该客户端明确支持的规则前置功能，或在可控脚本中调整列表位置，并检查生成结果。不要仅根据覆写编辑器显示“保存成功”就推断规则已经在正确位置生效。

合并后需要保持引用完整

新增业务组时，必须确认它引用的节点或提供器在订阅更新后仍然存在；新增规则时，也必须确认目标策略名称没有被合并过程删除或改名。若订阅本来就有一个叫 Proxy 的组，自定义同名组可能导致冲突或被覆盖。采用能区分本地用途的名称，并在每次生成后检查名称唯一性，比依赖合并器自动去重更稳妥。

DNS 覆写尤其需要检查嵌套字段。只想改变 enhanced-mode，却整段替换了 dns，可能同时丢失原有上游、分域策略和代理端点解析设置。反过来，递归合并也可能保留已经不再需要的旧字段。建议先查看合并后的完整 DNS 段，再确认新旧设置是否组成一致的解析路径，而不是只搜索刚修改的那一行。

同样的风险也存在于节点提供器和规则提供器。缓存路径冲突可能让两个资源互相覆盖，名称变化可能让引用悬空，文件内容格式变化则可能让原有行为类型不再合适。订阅更新前保留一份可用配置，更新后观察加载日志和组内容；出现异常时先回退到已知可用状态，再比较具体差异，避免在失败结果上连续叠加补丁。

本地维护流程与共享边界

推荐保留三份信息：远程订阅来源、本地自定义片段、最终运行配置。前两者说明配置从哪里来，第三份说明实际运行了什么。对比时先看顶层键和列表长度，再检查关键规则位置、组名及 DNS 路径。无需把每个远程节点都复制进自定义文件，否则订阅更新带来的地址变更和节点增删会失去作用，维护负担也会转移到手工修改。

覆写脚本若能执行代码，应把它视为有权限处理配置的程序。只引入能理解其作用的逻辑，避免为了插入一条规则而接受整段来源不明的处理代码。共享示例时，去掉真实订阅 URL、认证字段和个人路径；即使只是截图，完整查询字符串也可能包含账户信息。教学值可以保留字段位置，帮助他人复现结构问题，而不暴露实际账户。

八、配置验证与分层排错

验证应依次覆盖语法、引用、监听、解析、规则和远端连接。这个顺序能减少无关修改：文件尚未加载成功时，改变节点选择没有意义；请求尚未进入内核时，调整分流规则也无法影响它。开始前记录客户端名称、使用的内核、接入方式和刚修改的字段，不必公开真实订阅内容。保留最先出现的错误，后续大量连接失败可能只是同一个基础问题的连锁结果。

先做静态检查，再观察启动日志

独立运行 mihomo 时，可用测试参数检查配置。下面命令假设二进制在当前目录，配置保存在指定目录；测试过程可能还涉及配置引用的外部资源，因此报错不一定只是缩进错误。图形客户端应优先使用其检查与重载功能，避免同时启动第二个实例抢占端口。无论采用哪种方式，都应确认验证的是准备启用的同一份文件。

./mihomo -t -d ./config-dir -f ./config-dir/config.yaml

解析错误通常会指出行号或附近字段，但真正原因可能在上一行，例如未闭合引号、列表缩进改变或重复的根字段。引用错误则沿名称查找：规则目标是否存在，组的候选是否存在，提供器名称是否一致。遇到不支持的字段时，先确认当前内核是否实现该功能；客户端名称相同，不代表不同平台和安装来源使用的内核能力完全一致。

确认端口与请求接入

配置加载后检查监听成功与否。桌面环境存在多个代理客户端时，即使界面只打开一个，也可能有后台服务占用原端口。先定位进程，再决定关闭旧实例还是修改新配置，不要直接结束不认识的系统进程。随后用明确指定代理的请求验证 HTTP 接入路径，这样可以暂时绕开系统代理是否正确这一变量。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

命令使用本机混合端口，目标只是一个用于检查连通路径的示例站点。若能收到 HTTP 响应，说明这次请求经过了指定入口，但不代表所有应用都已接入。若提示连接被拒绝，优先检查监听和端口；若代理已接收请求后超时，再看规则、组选择和远端错误。目标返回访问限制也与本地入口无法连接不同，不能把所有非成功状态统一解释为代理失效。

沿日志定位解析与出口问题

解析错误应结合失败域名判断：失败的是业务目标、代理服务器，还是 DNS 上游自身的域名。若代理端点无法解析，先查引导解析和循环依赖；若仅局域网名称失败，再看本地解析器、Fake-IP 过滤与接入方式。业务请求已经解析并命中规则后，应读取实际策略和最终节点，确认不是多层组选择把流量送到了另一个出口。

TLS 错误先检查时间、主机名和证书链；认证错误先核对密码和协议字段；连接超时则继续检查地址、端口、传输参数及网络路径。不要同时关闭证书验证、替换 DNS 和切换模式，这会让原问题被新变量掩盖。每次只改一类字段，并使用同一目标的新连接复测，结果才能互相比较。旧连接复用、缓存和后台重试都可能干扰观察。

回退、记录与后续维护

确认修复后，保存一份最小变更说明：改了什么字段、解决了哪种错误、是否依赖特定网络。客户端或订阅更新后，优先检查这些容易受覆盖影响的位置。调试期间提高的日志级别、临时开放的监听地址和额外测试入口，也应恢复为日常所需设置。配置越复杂，越应保留一份已知可用的基础版本，便于区分环境变化与新功能带来的问题。

命令行部署与图形客户端的服务管理方式不同，尤其要避免系统服务和桌面程序同时启动同一内核；Linux 场景可继续阅读mihomo 桌面与 systemd 部署流程。常见现象的快速入口在常见问题，需要更换客户端时前往下载页按平台选择。完成验证的标准是配置被正确加载、测试请求走向可解释、日常应用行为符合预期，而不只是界面显示已启动。