Clash 配置手册

一、核心概念与连接路径

区分客户端、内核与服务端

先把三个层次分开。Clash Plus、Clash Verge Rev、FlClash 等名称通常指用户操作的客户端；界面负责导入配置、展示策略组、切换开关和管理后台进程。mihomo 是处理代理连接、规则匹配及域名解析的内核。服务端位于远端，接收客户端转发的连接。安装界面并不等于获得可用服务端，客户端下载入口也不等于订阅购买入口。

理解一次访问的路径，比记住所有设置名称更重要。应用先解析目标或发出连接，再通过系统代理、手动代理或虚拟网卡进入内核；内核读取目标域名、地址和规则，决定直连、拒绝，或交给某个策略组；策略组最终选择具体出口。页面打不开时，故障可能在任一环节，不能仅凭客户端图标亮起就认定全部链路正常。

区分订阅、节点与策略组

订阅链接是获取配置或节点资料的入口，通常带有访问凭据，应按密码管理。节点描述一个远端连接，包括服务器地址、端口、协议及认证参数；策略组把若干节点或其他组组织起来，提供手动选择、可用性回退等行为。同一个节点可以被多个组引用，但组名称不代表真实地理位置，也不保证某个网站一定可访问。

配置文件还可能包含 DNS、监听端口、规则集合和远程资源地址。部分订阅只返回节点列表，需要客户端的模板或合并机制补齐其余内容；另一些直接返回完整配置。两种形式不能不加区分地互换。导入成功只说明客户端接受了资源，不说明配置已选中、内核已加载，也不说明远端账号仍在有效期内。

建立逐层验证的方法

本地监听端口是应用进入内核的入口，不是远端服务器端口。以 mixed-port 为例，它可以在同一监听端口接受 HTTP 和 SOCKS 代理请求。Windows 上常见的本地地址是 127.0.0.1，只代表当前设备。手动填写代理时，应复制客户端实际显示的地址和端口，不要照抄截图中的数字，更不要把订阅地址填进代理服务器栏。

连接验证分成四层：先确认内核运行，再确认流量进入，再看规则选择，最后判断出口响应。连接列表完全没有记录，优先检查应用是否遵循系统代理；有记录但显示拒绝，查看命中规则；已走预期策略却超时，再检查节点、远端服务和目标站点。这个顺序能减少反复重装，也能避免把 DNS 问题误当成订阅问题。

还要区分传输加密与访问安全。客户端支持某种协议，不代表配置来源可信；把流量交给远端出口，也不会自动保护账号免受钓鱼页面影响。只导入可信来源的配置，浏览器出现证书异常时停止操作，不为解决连接问题安装来历不明的根证书。项目历史与分工可继续阅读Clash、mihomo 与 Clash Verge Rev 的关系梳理。

二、选择客户端与设备架构

先按使用平台缩小范围

首次选择客户端，先看设备平台、处理器架构和需要的功能，再比较界面习惯。Windows 用户首推从 Clash Plus 开始，在Windows 下载入口查看安装要求；需要跟随本手册中的服务模式、日志及规则示例时，也可选择 Clash Verge Rev。后文以它的常见页面名称说明操作，其他客户端应寻找含义相同的配置、代理与设置入口。

Windows 可选项还包括 FlClash 和 Clash Nyanpasu。不要同时启动多个客户端测试，否则监听端口、系统代理和虚拟网卡可能互相影响。切换客户端前，先关闭旧客户端的系统代理与 TUN，再完全退出旧进程。保留旧配置备份即可，不必为了比较界面把所有程序都设为开机启动；排错时只保留一个明确的流量入口。

核对架构，不只看系统名称

打开 Windows 的“设置 → 系统 → 系统信息”，检查“系统类型”。基于 x64 的处理器通常选择 x64 或 AMD64 安装包，这两个标签在此处指同一类架构，不代表仅适用于某个处理器品牌。ARM64 设备应先确认下载页确实提供相应构建，以及该客户端对当前 Windows 环境的支持，不要把内核压缩包误当成图形客户端安装包。

macOS 要区分 Apple Silicon 与 Intel；Android 要结合设备架构选择通用包或对应架构包；Linux 还需区分软件包管理方式。包能下载，不代表能在任意系统安装。桌面客户端所需的图形环境、权限和系统组件与命令行内核不同，服务器、路由器用户才需要进一步研究独立 mihomo 内核的运行方式与服务管理。

按维护状态与功能需求取舍

Clash for Windows 与 ClashX Meta 已停止维护，适合查阅旧操作记录，不宜作为新用户的默认起点。旧客户端可能缺少新配置字段、协议能力或系统适配。遇到导入报错时，先核对配置要求，再考虑迁移到仍在维护的客户端；不要把删除报错字段当作通用办法，因为删掉的内容可能正是订阅正常工作所需的设置。

不同客户端即使使用相近内核，配置存储方式、增强脚本和服务安装流程也可能不同。迁移时优先重新导入订阅，再逐项搬运必要规则，不要直接复制整个程序数据目录。尤其不要把某个客户端生成的运行配置当成长期源文件：其中可能含临时端口、控制接口地址、绝对路径和仅适用于原环境的覆盖字段。

最后确认日常需求。浏览器访问为主，通常先用系统代理；需要接管不遵循系统代理的应用，再评估 TUN；需要按域名区分出口，则重点看规则和策略组管理。功能越多并不等于初次配置越好。先建立最小可用连接，再增加一个需求、验证一次，能让后续故障始终有明确的回退点。

三、安装客户端与首次检查

安装前清理冲突入口

进入下载中心，按系统与架构选择安装包。保存位置使用容易找到的本地目录，避免从临时压缩目录反复启动程序。安装前退出正在运行的其他代理客户端，记录原有代理端口以及是否启用 TUN；如果设备由组织管理，先确认网络策略是否允许安装虚拟网卡与后台服务，不通过修改系统策略绕开管理限制。

运行安装程序时，阅读系统显示的发布者和权限请求。需要管理员权限的步骤应与安装目录、服务或网络组件有关；来源、文件类型或提示与预期不一致时暂停安装。Windows 安全提示不能一概视作误报，也不应为安装一个客户端长期关闭防护。优先重新核对下载来源、设备架构及系统要求，再决定下一步。

先检查内核，再开启系统代理

首次启动后，先进入设置页查看内核是否运行、监听端口是否建立。此时没有订阅，代理页可能没有可选节点，这是预期状态，不需要立即重装。暂时保持系统代理与 TUN 关闭，先完成基础设置和订阅导入。若内核启动失败，打开日志，寻找最先出现的配置解析错误、地址占用或权限错误，而不是只看最后一条退出提示。

端口冲突常见于旧客户端没有退出，或者同一程序被重复启动。确认占用进程后再处理，不要随机结束系统进程。下面以端口 7897 演示查询，实际操作应替换为设置页显示的端口。命令列出的进程编号用于进一步确认程序身份，并不表示该进程一定有故障；检查完成后，优先通过对应软件的正常退出入口释放端口。

netstat -ano | findstr ":7897"
tasklist /FI "PID eq 1234"

第二行中的 1234 是演示进程编号，执行前换成第一行查到的实际编号。若端口确由其他必要程序使用，可以在客户端设置中改为一个未占用的端口，再确认依赖该端口的工具同步更新。不要只改 Windows 系统代理中的端口而不改内核监听；两者不一致时，应用会把请求发往没有服务监听的位置。

按需要安装服务模式

Clash Verge Rev 的服务模式用于让后台服务承担需要相应权限的内核操作，常用于 TUN 场景。打开“设置”，找到“服务模式”相关入口并执行安装，按系统提示授权；不同界面版本的入口文字可能略有变化。安装结束后检查服务状态，再按客户端要求重启相关组件。服务装好不代表 TUN 已开启，二者是不同状态。

安全软件或组织权限限制可能使服务安装失败。记录具体错误，并到 Windows 的服务管理工具中确认服务是否存在、是否能启动。不要仅凭一个开关颜色判断安装成功，也不要反复执行来源不明的修复命令。普通系统代理可工作而服务安装失败时，先保留系统代理方案，再单独排查服务权限，避免把已可用的网络路径一起破坏。

安装检查的终点是：客户端可正常打开，内核日志没有持续启动失败，端口与预期一致，退出和重开行为可控。开机自启留到验证连接后再开启，并区分“启动界面”“启动后台服务”和“自动恢复系统代理”。需要认识配置页、代理页与日志页时，可查看Clash Verge Rev 界面速览。

四、订阅导入与配置生效

导入后明确选择活动配置

先从服务提供方获得适用于当前客户端或 mihomo 的订阅链接。完整复制地址，避免带入聊天软件附加的标点、空格或换行。打开客户端“配置”页，在订阅地址输入位置粘贴链接并点击“导入”；有些界面将该页称为“订阅”。等待下载完成后检查新条目，再明确选中或启用它，不要把列表中出现一张配置卡片当作已经切换成功。

活动配置加载后，进入“代理”页查看策略组是否出现。若只有节点但没有预期的规则和组，先判断订阅返回的是节点资源还是完整配置。部分客户端能通过模板生成组与规则，另一些需要导入完整 YAML。应使用服务方提供的对应入口，不把订阅链接提交到不熟悉的在线转换网站；转换过程可能暴露链接内的认证信息。

区分下载失败与解析失败

订阅下载失败，先检查当前网络能否访问订阅域名，再看日志中的 HTTP 状态和连接错误。认证失败可能意味着链接过期或账号状态变化；连接超时可能与 DNS、网络限制或服务方故障有关。浏览器能打开某个页面也不代表客户端可以成功获取订阅，因为两者的代理路径、证书环境及请求行为可能不同。

下载完成但解析失败，通常要检查返回内容与配置格式。服务端可能返回登录页面、错误提示或不兼容字段，而不是预期的 YAML。查看错误涉及的字段和行号，联系订阅提供方确认支持范围。不要把含个人凭据的完整配置贴到公开问答区；需要求助时，只截取去除服务器、认证参数和订阅地址后的错误上下文。

分清源配置、覆盖与运行配置

订阅更新会重新获取远端内容。直接修改已下载文件，可能在下次更新时被覆盖；直接修改运行时合成配置，也可能在切换配置或重启内核后消失。长期自定义应放在客户端支持的覆写、合并或脚本机制中，并了解其执行顺序。先保存一个小改动，重载内核并检查最终配置，再验证更新订阅后该改动是否仍然存在。

YAML 对缩进和类型敏感。使用空格缩进，不混入制表符；列表项保留短横线，字符串中有特殊字符时正确加引号。同名键重复出现不等于“追加”，不同解析器可能报错或只保留其中一项。不要把两份完整配置直接拼接；节点、策略组、规则和 DNS 各自需要按结构合并，并确认引用的组名都存在。

自动更新间隔应结合服务方建议，不必设置得过于频繁。更新前保留可恢复的配置和本地覆写；更新后检查组内原先选择的节点是否仍存在。节点名称发生变化时，旧选择可能失效，表现为组恢复默认选项或出口改变。对重要使用场景，再次检查规则命中与出口，而不是只看更新提示显示成功。

订阅导入阶段的验收是：活动配置明确、内核成功加载、策略组可见、至少一个可用出口能被选中。需要从本地文件迁移时，确认文件来自可信设备并保留必要认证参数；通过云盘或聊天工具传输前考虑暴露范围。配置能被读取不等于可以公开分享，节点密码、控制接口密钥和订阅链接都不应出现在截图中。

五、代理模式与连接验证

区分流量入口与出口决策

系统代理解决“应用怎样把请求送入内核”，规则、全局和直连模式解决“进入内核后怎样选择路径”。这两组设置不能互相替代。打开全局模式，不会自动接管所有 Windows 应用；打开系统代理，也不会让所有请求必定走远端节点。先明确正在改变的是入口还是路由，再观察连接记录，才能理解开关产生的实际效果。

日常使用先选“规则”模式，内核按配置规则匹配请求。选择“全局”模式时，进入内核的请求通常交给全局策略组，需要在该组中选择合适出口；若选中了直连选项，仍可能直接访问。选择“直连”模式则让进入内核的连接直接发出。各模式都不能补救未进入内核的流量，也不能替代远端账号和节点有效性检查。

开启系统代理并确认应用行为

确认配置和节点已就绪后，在客户端开启“系统代理”。到 Windows“设置 → 网络和 Internet → 代理”检查当前状态，核对地址与端口是否指向正在运行的本地监听。客户端可能通过不同方式维护代理设置，组织策略也可能覆盖该项；发现状态不一致时先关闭其他代理软件，不在多个位置反复争抢设置。

浏览器通常可以使用系统代理，但扩展、独立代理设置或管理策略可能改变行为。关闭已有连接并重新打开测试页面，同时观察客户端连接页。仅刷新页面可能复用旧连接或本地缓存，不能证明新设置已生效。测试时选一个可以明确识别的新请求，核对域名、策略链和连接状态，不把网页右下角的提示当作唯一证据。

命令行工具不一定自动遵循 Windows 系统代理。需要单独验证本地 HTTP 入口时，可以显式指定代理地址。下面使用 7897 演示混合端口；执行前换成当前实际端口。该命令用于观察目标响应，不承诺某个公共站点在所有网络都可达，也不用于证明所有应用都已被接管。

curl.exe --proxy http://127.0.0.1:7897 --head https://example.com

若返回 HTTP 响应，说明这一次请求已完成到目标的往返，但仍需在客户端确认它走了哪个策略。若提示连接本地端口失败，先检查内核和监听；若本地已接收却远端超时，检查出口；若提示证书问题，检查设备时间与可信证书环境，不直接添加忽略证书参数。按错误层次处理，比切换多个节点后重复刷新更有效。

正确理解测速与全局排查

节点测速通常是针对客户端配置的测试地址发起请求，结果受测试目标、网络路径和协议实现影响。测试成功不保证其他站点可访问，测试失败也不一定说明节点完全不可用。对实际问题，应访问真实目标，并查看是否发生域名解析失败、规则误匹配或目标拒绝。比较节点时保持测试条件一致，不用不同时间的单次数字判断长期质量。

退出客户端前，先关闭系统代理，尤其是在尚未确认程序会自动恢复设置时。若程序异常退出后浏览器断网，到 Windows 代理设置中检查是否还指向已经停止的本地端口。恢复网络后再重启客户端；不要为了修复残留系统代理立即重置所有网卡。系统代理能覆盖主要需求时，可先保持这一方案，下一章再细化出口选择。

六、规则分流与自定义配置

按顺序理解规则匹配

规则模式通常从上到下匹配，命中后采用对应策略。更具体的规则应放在宽泛规则之前，最终兜底的 MATCH 放在末尾。新增规则后，必须确认请求实际带有规则所需的信息：域名规则依赖可识别的域名，地址段规则针对目标 IP，进程规则还取决于平台权限和内核获取进程信息的能力，不能只凭应用名称推断一定匹配。

常见的 DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名及其子域范围，IP-CIDR 匹配地址段。内置策略 DIRECT 表示直连，REJECT 表示拒绝，其他策略名称通常引用现有代理组或节点。名称必须逐字一致，包括大小写与空格；引用一个不存在的组，会造成加载失败或不符合预期的路由。

先做一条可验证的小规则

下面是规则写法示例，展示保留域名、回环地址与局域网地址的直连规则。它不是完整配置，不含节点和策略组，也不能直接替换远端订阅。若使用本地规则覆写，应把需要的条目插入已有规则列表的合适位置，保留原有末尾策略。局域网地址是否都应直连，还要结合设备所在网络和实际安全边界决定。

rules:
  - DOMAIN,example.com,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve

no-resolve 用于避免仅为判断该地址规则而主动解析域名，不表示关闭整套 DNS。域名请求如果在前面的域名规则命中，后面的地址规则不会再参与选择。排查时先打开连接详情，读取实际命中的规则，再检查它在列表中的位置。不要为了“提高优先级”把所有地址规则都放到最前，这可能改变原有域名分流结果。

用规则集合管理规模

规则较多时，可通过 rule-providers 管理远程或本地集合，再使用 RULE-SET 引用。集合的 behavior、格式与内容必须对应，域名列表不能不经转换就当作完整经典规则列表使用。资源获取失败时，检查下载路径、缓存文件和日志；客户端能更新订阅，不代表每一个远程规则资源也已成功更新。

选择规则源时，考虑维护范围和更新行为，而不是一次导入大量来源。多个规则集可能重复覆盖同一目标，最终仍由引用顺序决定结果。对工作应用、支付页面或局域网设备增加例外时，记录例外原因和验证日期，避免日后忘记某条规则的用途。源配置更新后，也要检查自定义规则是否被合并到预期位置。

验证分流时应结束旧连接再发起请求，因为已经建立的连接一般不会因规则修改立刻迁移出口。浏览器和桌面应用可能同时请求多个域名，一条页面主域规则未必覆盖图片、认证和接口域名。先观察缺失请求，再补充准确规则，不通过一个极宽泛的关键词规则把大量不相关业务一起改道。

最后把路由与 DNS 分开看。规则决定出口，但域名解析可能发生在本地、内核或远端；地址规则还可能受到解析结果影响。出现解析异常时，不要连续追加规则掩盖问题。先确认 DNS 返回与连接目标，再决定是否调整解析策略。每次保留能复现问题的一条请求记录，后续进入 TUN 与 Fake-IP 配置时才有可靠的比较基线。

七、TUN 模式与 DNS 检查

确认需要虚拟网卡接管

TUN 模式通过虚拟网卡与路由接管流量，适合处理不遵循系统代理的应用，但接管范围受操作系统、路由、排除设置及客户端实现影响。它不是“所有问题的增强开关”。浏览器已经正常、只有某个应用失败时，先确认应用实际走的网络接口和协议，再判断是否需要 TUN；如果问题在节点认证或规则错误，切换入口不会修复出口。

启用前先关闭其他 VPN、虚拟网卡代理或同类接管工具，记录当前系统代理状态。在 Clash Verge Rev 中确认服务模式已经安装且正常运行，再打开 TUN。初次测试可以暂时关闭系统代理，让请求来源更明确；若客户端要求特定组合，以其说明为准。开启后先检查普通网站、局域网资源和必要工作应用，不要只验证一个网页就长期保留。

理解常见 TUN 字段

下面展示 mihomo 配置中的 TUN 段落，仅用于说明字段结构，不是完整可运行配置。客户端可能通过界面生成同一段内容，应优先使用一种维护方式，避免界面覆盖与手写配置互相冲突。字段支持范围依赖实际内核；加载报错时查对应文档，不通过删除所有报错字段强行开启一个行为不明的接管环境。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

enable 控制是否启用，stack 选择网络栈实现，auto-route 用于自动配置路由，auto-detect-interface 用于识别出站接口。dns-hijack 中的示例用于接管相应的普通 DNS 流量；它不会自动涵盖应用内通过 HTTPS 或其他加密通道发送的所有解析请求，也不能替代完整的内核 DNS 配置。

把 DNS 路径单独验证

Fake-IP 模式用保留地址映射域名，让内核在后续连接中恢复目标域名并参与路由；这些地址不是目标服务器的真实公网地址。看到解析结果落在 Fake-IP 地址段时，不要立即判断为污染。要结合内核日志、连接详情和最终响应判断。如果应用要求真实地址或存在兼容性问题，再考虑有针对性地加入 fake-ip-filter。

更换 DNS 模式后，系统和应用缓存可能仍保留旧结果。可以关闭受影响应用、按需要清理系统 DNS 缓存，再重新建立连接。下面的 Windows 命令用于刷新系统解析缓存，不会清除所有浏览器内部缓存，也不修复远端服务异常。执行后仍应观察新请求，而不是把命令返回成功当作网络故障已经解决。

ipconfig /flushdns

公司网络、校园网络、虚拟机与多网卡环境尤其要注意路由边界。默认接口变化、无线与有线切换，可能使自动识别结果不符合预期；局域网打印机、共享目录或内网域名也可能需要保留原路径。遇到此类问题，先关闭 TUN 验证是否恢复，再检查路由和解析，避免直接删除网卡或执行系统级网络重置。

Windows UWP 应用还有独立的回环限制。使用本地系统代理时，应用可能因沙盒限制无法访问回环地址；这与普通桌面浏览器不同。可按UWP 回环豁免说明检查具体应用，不批量修改所有应用权限。更深入的解析流程和兼容性边界见Fake-IP 与 redir-host 的差异，先理解映射关系，再扩展过滤列表。

八、日常维护与故障定位

保存能恢复的配置状态

稳定使用后，把维护对象分成客户端、内核、订阅和本地覆写四类。升级客户端可能同时改变界面或附带内核；更新订阅会改变节点与规则；修改覆写则影响最终运行配置。每次只改变一类，记录操作前后状态。这样出现问题时可以回退到明确的一步，而不必猜测究竟是哪个更新造成连接变化。

备份应覆盖订阅入口的安全存储、本地自定义规则、覆写脚本和必要设置，但不要把所有日志和临时缓存都当作配置备份。运行配置可能含敏感凭据与本机路径，转移到新设备后也未必可直接使用。保存到加密存储或受控位置，并检查同步软件是否会将文件暴露给其他成员；备份文件本身同样需要限制访问。

按故障层次读取日志

遇到断连，先记下发生时间、所在网络、受影响应用和最近一次改动。检查内核是否仍运行，再看系统代理或 TUN 是否仍处于预期状态。只有某个站点失败时，不要马上重启整个系统；先用另一个应用或另一个目标交叉测试。全部应用同时失败，再检查本地监听、网络接口、DNS 与服务状态，逐层缩小问题范围。

日志中的配置解析错误需要回到字段和缩进；本地端口绑定失败要看占用；域名解析失败要看 DNS；远端握手或认证失败则检查协议参数与服务方状态。超时本身不是完整结论，它只能说明某一步没有在等待时间内完成。应结合上下文判断发生在订阅下载、目标连接、规则资源更新还是节点测试阶段，避免采用无关修复方法。

临时提高日志详细程度有助于复现，但不要长期保留大量调试日志。详细输出可能记录访问域名、目标地址和策略选择，分享前应脱敏。提交问题时提供系统类型、客户端名称、所用功能、错误时间和最小复现步骤即可；不提供订阅原链、节点认证信息或完整控制接口配置。截图也要检查地址栏、侧栏和通知内容是否带有隐私。

建立可执行的回退顺序

如果修改规则后失败，先撤回最后一组规则并重载；如果更新订阅后失败，检查组内选择和新增字段，再考虑恢复此前备份；如果开启 TUN 后失败，先关闭 TUN 验证系统代理路径；如果客户端异常退出后断网，先检查 Windows 是否残留本地代理。回退应恢复先前已验证的状态，不是随机关闭所有安全功能。

开机自启适合在稳定后启用。重启设备做一次完整验证，确认服务、界面和代理设置的启动顺序符合预期；如果系统代理先恢复、内核尚未监听，启动初期可能出现短暂访问失败。休眠唤醒和网络切换也应单独测试，因为接口与路由可能变化。问题若只在唤醒后出现，保留当时日志比反复重新安装更有帮助。

不要把频繁切换节点当作日常维护。先确认规则与出口是否正确，再考虑更换可用节点；也不要根据一次测速删掉全部选择。需要进一步排查时，按帮助中心的分类查找对应症状，再附上去除敏感信息的错误上下文。维护的目标是减少不确定变化，让“最后一次可用状态”始终能被说明和恢复。

九、进阶配置与学习路线

先读懂最终运行配置

完成前八章后，进阶的第一步不是增加更多字段，而是读懂客户端提交给内核的最终配置。对照源订阅、本地覆写和运行结果，找出监听端口、代理组、规则及 DNS 各自来自哪里。保存一个最小改动，观察它在合成结果中的位置，再验证行为。若无法解释某个字段由谁生成，就先不要依赖它承载关键业务。

第二步是学习策略组行为。手动选择组适合明确指定出口，自动测试或回退组则依据测试条件决定选择。测试地址、间隔、容差和惰性检测会影响结果，不能把组名中的“自动”理解为对所有业务都最优。先在一类非关键流量上验证，再决定是否扩大范围；保持一个可以手动切回的选择组，有助于定位自动策略带来的变化。

再拆分资源与解析策略

第三步再研究 proxy-providers 与 rule-providers。前者管理代理资源，后者管理规则资源，引用关系与更新机制不同。资源拆分能减少重复配置，但也增加路径、缓存和远程下载依赖。检查每个资源的失败表现，并确认首次启动没有缓存时是否仍能完成加载；不要只在本机已有缓存的条件下判断方案可靠。

第四步细化 DNS。梳理系统、浏览器、内核和远端分别在哪一阶段解析，确认是否存在应用自带加密 DNS。再学习按域名选择解析器、直连域名解析和代理服务器地址解析等配置。不同字段可能互相依赖，错误组合会形成解析循环：例如获取代理服务器地址需要先连接代理，而连接代理又需要先完成该地址解析。

出现循环时，优先回到一个已验证的解析路径，再逐项增加策略。不要把公开解析器地址随意混成很长的列表，数量并不能证明兼容性。内网域名通常需要组织提供的解析环境，公共解析服务不一定知道它们的记录。规则出口、DNS 选择和局域网访问要一起验证，避免网页能开而工作资源悄悄失效。

最后评估接口、脚本与局域网共享

控制接口用于客户端或管理工具与内核交互，不是普通应用的代理端口。涉及 external-controller 时，先保持仅本机可达，了解认证和监听范围后再考虑扩展。不要为了方便管理直接暴露到公网；也不要把控制接口端口当成 HTTP 代理端口填写到浏览器。任何具备修改配置能力的接口，都应按管理入口而非普通网页看待。

局域网共享还涉及 allow-lan、绑定地址和 Windows 防火墙。只开启一个开关并不能保证其他设备可用，也可能意外扩大访问范围。需要共享时，先限定可信网络、来源设备与端口，再在另一台设备验证。公共 Wi-Fi、访客网络和组织网络不适合随意开放监听；测试结束后恢复最小暴露范围，避免留下忘记关闭的入口。

增强脚本和配置覆写适合解决重复劳动，但脚本属于可执行逻辑，应先审阅来源和修改范围。确认它只调整目标字段，不意外删除策略组、改写 DNS 或扩大控制接口监听。更换订阅后再次验证，因为脚本可能依赖特定组名；组名变化时，脚本仍能运行也不代表生成结果正确。保留不带脚本的基线配置作为对照。

最后形成学习闭环：用入门指南复核最短连接流程，用本手册解释行为，用日志和连接页验证假设，再把长期需要的调整写入可维护的覆写。普通桌面用户不必立刻转向独立内核部署；只有确实需要服务器、路由器或自动化管理时，再学习服务守护、文件权限和网络边界。配置越复杂，越应保留简单、已验证且可恢复的路径。