Clash 从零到进阶配置手册

一、核心概念与连接路径

客户端、内核与服务的分工

Clash 生态中的名称不都指向同一层软件。客户端通常负责显示窗口、管理配置、修改系统代理与启动后台服务；内核负责监听本地端口、解析规则并建立出站连接。mihomo 是这一生态中持续发展的代理内核，Clash Meta 是理解相关历史资料时经常遇到的名称。安装图形客户端后，界面能够打开，只能说明前台程序运行，不能据此判断内核已经启动或订阅已经有效。

订阅提供的是远程配置或节点信息，节点则描述连接代理服务器所需的地址、协议和认证参数。客户端本身不会因为安装完成而产生可用线路，线路的有效期、流量限制与服务质量由相应服务决定。导入订阅前，应确认来源可信且具有使用授权。分享日志或截图时，也要意识到订阅链接常包含访问凭据，不能把它当作普通网页地址公开粘贴。

把一次访问拆成四个环节

一次网页访问可以按入口、决策、解析和出站理解。入口决定应用流量是否进入内核；决策决定命中哪条规则、使用哪个策略组；解析把域名转换为连接所需的地址；出站则执行直连、代理或拒绝。实际处理流程会因 DNS 模式、域名嗅探和连接类型交织，但这四个问题适合排查。浏览器打不开网页时，先确认入口，而不是立刻修改所有 DNS 字段。

DIRECT 表示由本机网络直接连接目标，REJECT 表示拒绝相应连接，策略组则可以指向一个或多个代理节点。规则模式下，不同网站可以走不同出口，因此看到本机地址与代理出口同时出现并不必然异常。相反，全局模式中选中了 DIRECT，也可能让进入内核的连接全部直连。判断行为必须结合当前模式、实际命中规则与最终出站，不能只看窗口上的连接状态。

建立能够重复的验证方法

准备两个具有明确预期的访问目标：一个应该直连，另一个应该通过代理。打开连接面板，记录目标域名、命中规则、策略组和最终节点，再检查页面是否加载。不要仅凭某个网站展示的出口地址推断所有应用的路径，因为浏览器缓存、应用代理设置、IPv6 与不同连接协议都可能改变结果。验证的重点是把一次请求与内核记录对应起来，而非收集孤立的测速数字。

配置学习也应沿着这条路径推进。先保证节点能够建立连接，再保证应用进入代理，最后处理规则与 DNS 的精细化需求。如果前一阶段尚未成立，增加更多规则只会扩大变量。建议建立一份本地配置记录，写下客户端名称、系统架构、监听端口、接管方式与验证结果。涉及订阅和认证的原始内容单独保存，不写入可公开的排错材料。

二、按平台与维护需求选择客户端

先选客户端，再确认功能边界

首次使用可优先查看 Clash Plus，再依据平台和具体需求比较其他客户端。选择时先看操作系统与处理器架构，其次看订阅管理、系统代理、TUN、日志导出和配置覆写是否满足要求。界面中出现某个开关不代表所有系统都具有相同实现；同一客户端在不同平台可能受权限、后台运行和系统网络接口约束。需要特定功能时，应在安装后用实际连接验证。

Windows 可比较 Clash Plus、Clash Verge Rev、FlClash 与 Clash Nyanpasu；Clash for Windows 属于停止维护的归档选择。macOS 可比较 Clash Plus、Clash Verge Rev 与 FlClash，ClashX Meta 同样属于归档选择。归档软件可以用于理解旧教程或迁移配置，但不适合作为新手长期维护的默认起点。旧界面的截图、按钮位置和配置选项也不能直接当作当前客户端的操作依据。

Android 可查看 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard；iOS 可查看 Clash Plus，官网为 clashplus.io。Linux 可优先比较 Clash Verge Rev 与 FlClash。这里的候选清单不是配置兼容性承诺，尤其 Surfboard 的配置体系与 mihomo YAML 不应直接混用。具体安装入口统一见安装包页面，先确认平台再选择应用。

区分架构、发行格式与运行权限

处理器架构决定程序能否运行，发行格式决定如何安装。Windows 常见 x64 与 ARM64，macOS 需要区分 Apple Silicon 与 Intel，Android 则要辨别 ARM64 与较旧的 ARM 环境。Linux 的 DEB、RPM 是面向不同发行版的软件包形式，不代表相同安装命令通用。桌面系统即使具备兼容运行能力，也应优先选择匹配架构的软件包，减少服务组件和虚拟网卡层面的差异。

图形客户端与独立内核的取舍

独立 mihomo 内核适合服务器、路由器及已经熟悉系统服务的用户。它可以读取配置并提供代理监听，但不会自动具备桌面托盘、订阅编辑器或系统代理按钮。使用独立内核时，进程重启、文件权限、服务启动顺序和日志保存都需要自行规划。普通桌面用户先通过图形界面理解工作流程，再迁移到命令行，可以避免同时学习网络配置与服务管理两套机制。

迁移客户端时，保留原订阅来源、策略组选择和必要的覆写规则，不要整个复制旧程序的数据目录。不同客户端的数据结构、加密存储与服务配置可能不兼容。更稳妥的做法是在新客户端中重新导入配置，完成基础验证，再迁移少量自定义规则。迁移期间只开启一套系统代理或隧道接管，原客户端退出但系统代理残留的情况，需要在系统网络设置中一并检查。

三、安装、权限与最小运行基线

安装前清理接管冲突

从下载页选择匹配系统与架构的安装包，按客户端提供的正常安装流程完成部署。首次启动前，先退出其他正在修改代理或路由的工具，检查系统是否保留旧代理地址。企业设备、学校网络或受管理的电脑可能限制虚拟网卡与后台服务安装，不应绕过管理策略强行修改。普通界面能够运行而服务安装失败时，应先核对权限提示和系统限制，而不是重复覆盖安装。

Windows 中，服务模式与管理员权限可能用于后台内核或 TUN；macOS 可能要求确认网络相关授权；移动系统通常需要用户同意创建 VPN 配置。这里的 VPN 标识表示系统使用相应网络接管接口，不足以推断远端协议。授权只在需要时按客户端流程授予。若系统提示应用来源或签名异常，应回到下载来源与系统安全提示查明原因，不把关闭系统防护作为标准安装步骤。

先验证本地监听，再导入复杂配置

最小基线只需要本地监听、规则模式和明确的直连出口。下面的配置可以用于独立内核的本地测试，不包含代理节点，因此不能用来验证远程代理线路。图形客户端可能自行管理监听端口与控制接口，导入后应查看有效配置，确认这些字段是否被覆写。测试的目标是让内核成功读取配置，并让一条明确使用本地代理的请求进入连接记录。

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

rules:
  - MATCH,DIRECT

mixed-port 在同一监听端口接收 HTTP 与 SOCKS 代理连接；它不是远程服务器端口。allow-lan: false 用于限制局域网共享，本地测试没有必要把代理暴露给其他设备。监听地址与允许来源还会受系统防火墙影响，不能把一个字段当作完整访问控制。后续若确实需要局域网共享，应另外明确允许设备、网络范围和防火墙规则。

检查端口与配置语法

使用独立内核时，可先执行下面的配置检查命令；可执行文件名称与路径需要对应本机实际安装位置。检查通过表示配置可以被解析，不代表订阅中的远端服务器可达。YAML 应使用空格缩进，同一级字段保持对齐，列表项保留短横线。复制文章片段时尤其注意不要把缩进变成制表符，也不要在现有配置中创建两个同名顶级字段，让其中一段被覆盖或产生歧义。

mihomo -t -f config.yaml
curl -I -x http://127.0.0.1:7890 https://example.com

如果启动日志提示端口占用，先查清占用进程，再决定退出旧程序还是调整监听端口。修改后，系统代理、浏览器扩展和终端环境变量中的端口也要同步。Windows 可运行 netstat -ano | findstr :7890 查看相关连接；根据进程编号继续确认所属应用，不要直接结束未知系统进程。更完整的操作分支见端口冲突与 mixed-port 修改说明。

四、订阅导入、有效配置与覆写

识别订阅内容与导入结果

在客户端的配置或订阅管理界面添加远程地址，填写本地可辨认的名称，再执行下载或更新。导入成功后，先确认该配置已经被选为当前配置，并检查是否出现代理节点与策略组。有的来源返回完整 YAML，有的只返回节点列表，还有的返回其他软件使用的格式；服务器响应成功不等于内容适合当前客户端。若导入后出现解析错误，应先核对来源格式和订阅说明。

订阅失败时，把问题分成下载失败与解析失败。下载失败通常表现为超时、证书问题、认证失效或服务端拒绝；解析失败则可能来自返回网页、格式不兼容或字段错误。先在客户端中查看具体错误信息，不要把订阅地址提交到不明在线转换网站。链接中的查询参数可能直接代表账户权限，故障截图也应遮盖完整地址及节点认证信息，只保留足以判断错误类型的部分。

找到真正生效的配置层

图形客户端经常同时存在原始订阅、本地覆写和运行时有效配置。原始订阅是下载内容，覆写用于补充端口、DNS 或规则，有效配置才是内核最终读取的结果。界面里修改了某个开关后，应查看运行时配置是否已经改变；直接编辑缓存文件，则可能在下一次更新时被覆盖。遇到设置反复恢复的现象，先确认修改位置，不要反复编辑同一个临时文件。

适合长期保留的个性化内容，应放在客户端明确支持的覆写或合并机制中。不同客户端对数组的处理差异很大：有的替换整个列表，有的支持前置或后置插入，不能假设合并一定保留原规则。特别是 rules、proxy-groups 与 dns.nameserver，一次整体替换可能删除订阅原有结构。首次使用覆写前先备份，并通过有效配置确认最后的字段顺序。

更新订阅时保持引用完整

规则引用策略组，策略组引用节点或提供者，任何名称变化都会影响引用关系。远程更新如果移除了某个节点，本地手写策略组仍引用旧名称，就可能导致加载失败或策略不可选。尽量让本地规则引用稳定的策略组名称，而不是供应方经常改动的单个节点名。下面示例只用于解释结构，不是一份完整代理配置；名为“代理出口”的策略组必须已经在实际配置中定义。

rules:
  - DOMAIN-SUFFIX,example.com,代理出口
  - DOMAIN-SUFFIX,lan,DIRECT
  - MATCH,DIRECT

更新前记录当前可用的策略选择，更新后重新验证节点与规则。自动更新频率不宜设置得过于密集，它无法解决服务端配额或认证失效，也可能触发访问限制。新订阅下载失败时，应优先保留上一次可用配置，避免故障期间清空全部记录。若客户端支持配置历史，先确认可以回退到哪一份内容；若只保存最新结果，就额外保留必要的本地备份。

订阅转换只有在来源格式与目标格式不一致时才有必要，而且转换过程不保证完整保留协议参数、规则集和 DNS 行为。完成转换后仍需做语法检查和连接验证，不能用“已转换成功”替代运行结果。日常管理还应区分更新订阅与切换节点：前者改变配置数据，后者只是改变当前出站选择。基础操作步骤可对照入门指南的订阅导入流程逐项检查。

五、代理模式、系统代理与实际接管

规则、全局与直连解决什么问题

规则模式根据配置中的匹配顺序决定出站，是日常分流的主要起点。全局模式把进入内核的连接交给全局策略选择，适合临时判断某条线路能否访问目标。直连模式则让进入内核的连接走直接出口，可用于比较本机网络与代理路径。三种模式改变的是内核收到流量后的决策，不能替代入口接管；应用根本没有经过内核时，切换模式通常不会改变它的连接。

首次连接时先在策略组中选择一个明确节点，再用规则模式验证。如果目标失败，可临时切到全局模式并明确选择同一节点，比较连接面板的结果。全局可用而规则不可用，才有理由重点检查规则与组选择；两者都失败，则继续检查节点、网络或解析。完成对照后恢复原模式，避免把临时诊断状态留作日常配置，导致本应直连的服务也通过代理。

系统代理只影响遵循设置的应用

系统代理通常把系统支持的代理设置指向本机监听地址，常用于浏览器和遵循这些设置的桌面应用。部分终端程序、游戏、自带网络栈的软件和后台服务不会自动读取它们。因此浏览器可用而命令行失败，并不直接说明节点异常。检查终端工具是否支持显式代理参数，先用明确入口完成一次测试，再决定是否需要环境变量或 TUN 扩大接管范围。

curl -I -x http://127.0.0.1:7890 https://example.com
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

上述两条命令使用不同代理入口。socks5h 表示由代理端处理目标域名解析，而不是让当前工具先在本地解析；实际后续 DNS 路径仍取决于内核配置。显式代理测试成功后，再检查程序自己的代理选项。环境变量的识别方式并不统一，部分工具只读小写变量，部分还会被自身配置覆盖。不要把一套变量设置推广为所有命令行应用都适用的结论。

用连接记录排除入口问题

访问目标时，如果连接面板完全没有记录，优先检查系统代理是否启用、监听端口是否一致、应用是否设置了绕过地址，以及是否存在其他代理扩展。若有记录但命中 DIRECT，应检查模式与规则；若命中代理却失败，再看连接错误和远端状态。记录可能因界面刷新或连接过短而难以捕捉，必要时临时观察日志，但不要一开始就长时间开启最详细日志。

停止使用时，先关闭系统代理或确认客户端退出会自动恢复，再结束内核。若进程退出而系统仍指向本机端口，遵循系统代理的应用会继续访问一个已经不存在的监听服务，表现为普遍断网。移动设备还应查看系统 VPN 配置是否仍处于连接状态。不同入口的机制对照，可继续阅读TUN 模式与系统代理区别，不要把“全局模式”与“全系统接管”视为同义词。

六、规则顺序、策略组与规则集

先匹配的规则决定出站

规则按顺序检查，通常在第一次匹配后确定处理方向。精确例外应放在宽泛规则之前，兜底规则应放在最后。DOMAIN 匹配一个完整域名，DOMAIN-SUFFIX 匹配指定域名及其子域名，IP-CIDR 匹配目标地址范围，MATCH 用于处理前面没有命中的连接。规则类型不同，依赖的信息也不同，域名不可见时仅靠域名规则未必能达到预期。

下面是一份可独立运行的直连演示配置，用于理解顺序与组引用，不提供远程代理能力。“日常出口”目前只有 DIRECT，因此所有允许连接最终仍走本机网络。实际使用时，只有在已有节点或提供者后，才把相应名称加入策略组。不要只复制一条引用规则，却遗漏被引用的组定义；内核加载配置时需要把这些名称解析成完整依赖关系。

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

proxy-groups:
  - name: 日常出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN,example.com,日常出口
  - DOMAIN-SUFFIX,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,日常出口

策略组是规则与节点之间的稳定接口

手动选择组适合建立可解释的行为：规则指向固定组，用户在组内更换出口。自动测速组可以根据测试结果选择节点，但测试地址、超时和检测周期都会影响选择。测试值主要反映请求建立与响应过程，不等于文件下载带宽，也不保证对所有目标都最优。连接切换还可能影响登录状态或远端会话，因此自动选择不是越频繁越好，应结合实际应用观察。

no-resolve 用于部分 IP 类规则，表示不要仅为判断这条规则而触发域名解析；它不是关闭整个客户端 DNS。若连接已经带有目标 IP，仍可据此匹配。加入这个参数之前，要先明确该规则承担什么责任：是只处理已有地址的连接，还是希望域名也经过解析再判断。机械地给所有地址规则附加同一参数，可能使规则行为与原始预期不同。

规则集管理与更新边界

规则提供者可把一组规则移到单独文件或远程来源，主配置再通过 RULE-SET 引用。使用时必须确认提供者的行为类型与内容格式相符，例如域名列表与经典规则行不是同一种输入。先用小规模本地规则验证，再接入可信来源的规则集。规则集下载失败、缓存过旧或格式不符时，检查提供者加载记录，而不是只观察主配置是否通过语法检查。

新增规则后，关闭或重新发起目标连接再验证。已经建立的长连接未必因为规则改变就立即迁移，浏览器缓存也可能掩盖新请求。排查时记录目标、规则、组和节点四项，比直接贴出全部规则更有效。规则数量增加不等于分流精度提高，大量重叠列表会提高理解和维护成本。只有能够解释用途、来源与匹配顺序的规则，才适合长期保留。

局域网、公司内网与开发环境尤其需要单独测试。私有地址直连通常合理，但本地服务可能使用自定义域名、分离 DNS 或特定路由，单靠一条地址规则并不总能覆盖。新增内网例外时尽量缩小范围，避免用过宽的域名后缀意外改变其他服务路径。遇到规则不生效的具体问题，可到帮助中心继续查阅，并附上脱敏后的命中信息。

七、TUN、DNS 与虚拟网卡接管

在基础代理可用后再开启 TUN

TUN 通过虚拟网络接口和路由安排接收流量，适合需要接管不遵循系统代理设置的应用。它并不意味着任何流量都会必然经过代理：系统路由、排除地址、进程权限、其他隧道和内核限制仍然影响结果。启用前应确保普通代理入口已经可以访问目标，再记录当前网络状态。否则节点故障、DNS 问题和虚拟网卡问题同时出现，很难判断新增配置究竟改变了什么。

桌面客户端可能需要安装后台服务或申请提权，移动端则通常使用系统提供的隧道接口。启用失败先看权限与服务状态，再看网卡和路由日志。公司 VPN、虚拟机网络、容器网桥与其他代理隧道都可能改变路由优先级。测试期间一次只保留必要的接管工具，记录必须保留的内网目标；如果远程办公依赖特定隧道，应在可恢复的环境中逐步验证。

理解 DNS 监听、上游与劫持

DNS 配置至少要区分三层：内核是否提供 DNS 服务，系统或应用的查询是否进入该服务，以及内核使用什么上游完成解析。启用 dns.enable 并不自动保证所有查询都交给内核。下面是用于说明 TUN 与 DNS 配合的合并片段，需要加入已有可用配置，并确保客户端不会另行覆盖；已有 dns 或 tun 段时，应合并字段而非重复添加顶级键。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

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

示例上游的可达性取决于当前网络，不能把它视为所有环境的默认答案。加密 DNS 使用域名作为服务器地址时，还可能需要先解决该服务器自身的解析，这属于引导解析问题。dns-hijack 中的端口规则也不能覆盖所有应用内置加密 DNS：浏览器或应用直接建立的 HTTPS 解析连接，不会因为使用 DNS 名称就自动变成普通的五十三端口查询。

fake-ip 的作用与兼容性验证

fake-ip 模式向应用返回合成地址，内核保存地址与域名的对应关系，以便后续连接继续按域名处理。看到相应地址段不应立即判断为错误，但某些局域网发现、特殊认证或依赖真实地址的应用可能需要例外。例外应依据具体应用验证后添加，而不是把所有域名都排除。切换 DNS 模式后，应用与系统仍可能保留旧结果，必要时重新连接并清理相应缓存。

验证 DNS 时，既要看解析结果，也要看查询路径与最终连接出口。出口地址正确，不等于解析路径符合预期；某个在线检测页面的结果，也不能代表所有应用。IPv6 是另一条需要独立核对的路径，关闭一个 DNS 选项并不等于系统 IPv6 已停止。若不准备使用 IPv6，应明确客户端、系统和网络侧的行为，而非只根据一项开关推断整体状态。

启用后逐项测试浏览器、终端、局域网服务、休眠恢复与网络切换。出现普遍断网时，先关闭 TUN 恢复已知可用的系统代理基线，再比较日志与路由；不要同时更换节点、上游和网络栈。关于“已连接但无法访问”的分层检查，可参阅连接后打不开网页排查清单。恢复能力是启用高级接管前必须具备的条件。

八、日常维护、备份与故障恢复

分别维护程序、内核与订阅

客户端更新、内核更新与订阅更新是不同事件。客户端更新可能改变界面、服务组件和配置生成方式；内核更新可能增加字段支持或调整网络行为；订阅更新则改变节点、规则或策略组。发生故障时先回顾最近改变的是哪一层，不要把所有变化笼统归为升级。重要环境中尽量错开这些操作，每完成一项就做一次基线测试，这样更容易确定回退范围。

备份应包含原始订阅来源的安全记录、自定义覆写、重要策略组选择、监听端口与接管方式。仅保存客户端截图不足以恢复配置，直接复制整个数据目录又可能带入缓存、旧服务状态与机器相关路径。把必要配置与临时数据分开，备份存放在有访问控制的位置。同步到云端或其他设备前，确认其中包含的订阅地址、节点认证与控制接口信息是否适合进入该同步范围。

用固定顺序定位异常

建议依次检查本机网络、内核进程、配置加载、流量入口、规则决策、DNS 与远程节点。先关闭代理测试基础网络，随后恢复代理并观察目标请求是否出现。能进入内核但无可用策略时查配置和组引用；策略明确但连接失败时看错误原因。超时只说明在等待窗口内没有完成操作，不能直接判定为 DNS 故障。拒绝连接、认证失败和证书错误则各有不同处理方向。

每次只改一个变量，并记录改动前后的目标与结果。例如更换节点后目标恢复，而规则与 DNS 未变，说明应继续关注出站路径；修改规则后命中符合预期但仍超时，则不能宣布问题解决。排错记录不需要复杂表格，只需时间、现象、改动和结果四项。遇到间歇性故障时，这些记录比重复重启更有价值，也便于判断是否与休眠、切网或订阅更新有关。

正确读取延迟与日志

节点测试值用于辅助选择，而不是给整条线路作最终评价。测试地址可能很近，实际业务目标却位于不同网络；连接建立很快，也可能受拥塞影响而下载缓慢。应结合实际目标的响应、连续请求稳定性与所需协议判断体验。自动测速失败也可能是测试地址不可达，不能据此立即删除所有节点。有关测量边界，可阅读url-test 延迟与实际网速的区别。

日志级别应满足当前诊断需要。平时保留常规信息，复现问题时短暂提高详细程度，完成后恢复。完整日志可能包含域名、地址、程序路径与认证相关内容，发布前必须脱敏。描述故障时提供客户端名称、系统、接管方式、复现步骤和关键错误行即可，不需要公开整份配置。对稳定复现的问题，优先保留最小复现场景，移除与故障无关的附加规则后再对照。

准备可执行的恢复顺序

恢复时先撤销最近一次修改，再关闭 TUN，回到显式代理或系统代理测试；必要时恢复上一份有效配置。如果客户端已经退出但系统仍无法联网，检查系统代理残留和其他隧道状态，而不是直接重置全部网络设置。远程管理设备尤其要谨慎修改默认路由，避免失去管理连接。任何影响系统网络的操作，都应提前准备本地访问或其他恢复途径。

九、进阶配置路线与验收清单

按问题增加能力，而不是堆叠字段

基础流程稳定后，进阶学习可以沿三个方向展开：把重复规则抽成规则提供者，把节点来源抽成代理提供者，以及通过策略组组织不同应用的出口。每次只引入一种机制，先在副本中验证再用于日常配置。高级字段并不是默认必需项，只有已经发现明确问题、理解字段责任并能够检验结果时，增加配置才具有意义。减少隐含依赖往往比增加选项更利于长期维护。

学习代理提供者时，先理解节点数据从哪里获取、缓存写到哪里、何时更新以及组如何引用。学习规则提供者时，先理解内容格式与行为类型，再规划加载失败时的观察方法。两者都涉及外部数据，配置语法正确并不能保证运行时下载成功。应分别检查下载路径、文件权限、缓存状态和引用名称，避免把提供者故障误判为全部节点不可用。

先掌握域名信息，再研究嗅探

某些连接进入内核时只有目标地址，域名规则因此缺少直接依据。域名嗅探可以在支持的协议和条件下提取域名信息，但它不是通用解密工具，也不保证每个连接都能获得域名。启用前应先确认当前问题是否真的来自域名缺失，再观察启用后的连接记录。不要仅因为教程中出现某段嗅探配置就整段复制，尤其应留意应用兼容性、排除范围与额外处理成本。

进程规则、接口绑定和路由排除同样需要结合系统环境。进程识别可能受到权限与平台支持影响，后台服务的身份也可能不同于前台窗口。按进程设置出口时，先验证真实进程信息，再补充规则；不能只凭程序显示名称推断可匹配路径。为虚拟机、容器或局域网设备提供代理时，还要额外考虑转发、访问控制与 DNS 来源，这已经超出单机浏览器代理的边界。

把安全边界写进配置习惯

控制接口、局域网监听与远程订阅都应该有明确用途。只在本机操作时保持本地绑定；需要跨设备访问时，再设计认证、允许来源与系统防火墙。不要为了方便调试，把所有监听都改成全网卡并长期保留。配置仓库与工单附件也应遵循最小暴露原则：可公开结构与脱敏样例，不公开真实订阅、认证字段或完整访问记录。示例配置与实际生产配置应明确分开保存。

进阶配置的验收不只看目标网站能否打开，还要检查本应直连的内网、应用登录、文件传输、休眠恢复与网络切换。规则更新后观察是否出现新误匹配，节点切换后观察长连接是否需要重建。对移动设备还应关注后台持续运行与电量策略对连接的影响。不同场景有不同约束，不能用桌面常驻环境的一次成功测试，推断所有设备都具有相同行为。

完成这条路线后，应能够从一次失败请求倒推入口、规则、解析和出站，而不是依赖反复重装。查阅新教程时，先确认它面向的客户端、内核和系统，再决定哪些字段适用于当前环境。需要重新核对首次连接流程，可返回入门指南；需要按具体症状继续排查，可使用帮助中心。保留一份简洁、能解释、可恢复的有效配置，作为之后所有试验的基线。