Clash 全平台配置手册

通用准备与配置边界

先分清客户端、内核与订阅

Clash 生态中的图形客户端负责导入配置、管理策略组、设置系统代理以及展示连接；mihomo 等内核负责解析配置、监听本地端口并执行规则。订阅则是配置的来源，可能包含代理、策略组、规则和 DNS 设置。安装客户端不会自动生成可用的远端代理。开始操作前，应准备自己有权使用的订阅或配置文件，并确认提供方说明的格式、使用范围和更新方式。

本手册在 Windows、macOS、Android 与 iOS 优先介绍 Clash Plus 的使用路径；Linux 桌面可选 Clash Verge Rev 或 FlClash。不同客户端对订阅格式、扩展字段和配置覆写的支持并不完全相同，不能仅凭文件名判断兼容性。下载前先看平台下载选项与系统要求，再核对设备架构。不要把某个桌面客户端的按钮位置直接套到移动端，也不要把旧版内核支持的字段范围当作整个生态的共同标准。

准备材料与备份顺序

保存订阅时保留完整链接，包括查询参数，但不要发送到公共聊天、截图或问题报告中。链接通常具有访问权限意义，泄露后应到提供方重新生成。先记录原有代理软件的退出方式、系统代理当前状态和自定义 DNS，再安装新客户端。旧软件可以暂时保留，但测试期间只运行一套流量接管工具。若设备由单位管理，应先确认管理策略允许修改代理、安装网络扩展或创建虚拟接口。

第一次导入尽量保留原始配置，只调整运行所需的最少设置。客户端界面中的修改可能写入应用数据库、覆写文件或内存中的运行配置，并不一定改动订阅原文。备份应同时覆盖订阅来源、用户自定义覆写和必要的应用设置。只复制缓存中的 YAML，可能遗漏界面选中的策略或服务状态。迁移设备前可导出本地备份，但备份同样可能含敏感信息，应保存到受控位置。

建立可重复的验证基线

启动内核后，先检查日志是否出现配置解析失败、端口被占用或权限不足，再考虑切换节点。下表中的端口是常见示例，不是固定要求；所有测试都应替换成客户端实际监听值。控制接口用于管理内核，不是浏览器的代理入口。把浏览器指向控制接口，即使端口能够连接，也不会得到正常的代理转发。监听地址保持本机回环范围，可以减少意外向局域网暴露服务的风险。

建议按“内核启动、显式代理请求、应用系统代理、TUN”四层逐步验证。桌面端可先让一条命令明确经过代理端口，确认配置链路，再打开系统代理；只有应用不遵守系统代理或需要接管其他流量时，才增加 TUN。这样发生异常时可以确定是哪一层引入了变化。测速成功只能说明测试目标的探测结果，不能证明所有网站、协议和应用都正常，更不能替代连接记录检查。

验证时固定一个目标地址和一个应用，每次只改一项设置，记录改动前后的日志。浏览器可能复用已有连接，切换模式后应重新发起请求，必要时关闭旧连接。涉及账号登录的网站还可能受到地区、时间和服务策略影响，不应把所有访问限制都归因于代理。初次部署的目标是建立可解释、可恢复的工作状态，而不是同时开启所有高级选项。

Windows 安装配置

安装客户端与确认内核状态

前往Windows 下载区，优先选择 Clash Plus；需要其他界面或工作流时，可比较 Clash Verge Rev、FlClash 与 Clash Nyanpasu。Clash for Windows 属于已停止维护的归档客户端，不作为新部署的默认选择。下载前通过系统设置中的系统类型确认架构，并核对安装包适用范围。安装程序遇到安全提示时，应先核对下载来源与发布信息，不要为了继续安装而永久关闭系统安全功能。

安装完成后先以普通用户身份启动，确认客户端可以打开、配置目录可写、内核能够运行。若程序界面存在而内核反复退出，应查看日志中的首个错误，而不是连续点击连接。旧配置引用了不存在的文件、端口已被其他代理占用、目录位于权限受限位置，都会使启动失败。需要服务模式或 TUN 时再按客户端提示提升权限，日常使用不必把整个应用长期作为管理员运行。

导入订阅并选择实际配置

在配置或订阅页面新建远程配置，粘贴完整链接，设置一个便于识别的名称，再执行下载或更新。出现配置条目后，还要确认该条目已被选为当前运行配置。部分客户端允许保存多条订阅，但一次运行通常使用选中的配置与覆写结果。若列表里有代理而主界面仍显示旧策略组，应检查当前配置名称和内核重载结果，不要重复导入相同链接制造更多副本。

订阅导入失败时先区分网络请求错误与内容解析错误。连接超时表示还没有取得有效响应；YAML 行号错误则说明已经获取内容，但格式或字段存在问题。订阅链接返回登录页面、权限提示或 JSON 错误信息时，文件保存成功也不代表配置可用。更新前后可比较策略组名称与日志，不要仅凭列表中的更新时间判断。提供方更改了格式时，应使用对应格式入口，而不是随意删除报错字段。

系统代理、应用差异与 TUN

先选择规则模式，在主要选择组中指定可用代理，再打开系统代理。浏览器通常能够使用 Windows 的用户代理设置，但部分终端程序、后台服务和自行配置网络的应用不会跟随。可在 PowerShell 中使用下面的命令进行显式代理测试。这里使用 curl.exe，避免命令别名造成参数差异；若实际端口不是 7890，应同步修改。请求结果还要结合客户端连接记录判断实际出口。

curl.exe --proxy http://127.0.0.1:7890 --head https://example.com
Get-NetTCPConnection -LocalPort 7890 -State Listen

第一条命令能访问而浏览器失败时，检查系统代理地址、端口和浏览器扩展；浏览器正常而某个命令行工具失败时，检查工具自身的代理参数或环境变量。Windows 用户代理设置与某些服务采用的 WinHTTP 设置不是同一套机制，不建议一开始就修改全局服务代理。工作电脑还可能由组织策略覆盖配置，表现为代理开关自动恢复或地址不能保存，应先处理权限与管理策略。

TUN 用于接管更多应用的网络连接，通常依赖服务组件、虚拟接口和相应权限。启用前先确认系统代理路径已经可用，再按客户端的服务安装流程完成授权。启用后如果所有连接中断，检查虚拟网卡是否创建、默认路由是否异常，以及其他 VPN 是否同时运行。不要反复安装不同来源的网络驱动。可以先关闭 TUN 回到系统代理基线，再逐项检查 DNS、路由和排除网段。

UWP、退出清理与升级

部分商店应用受本地回环限制影响，无法直接访问本机代理入口。优先使用客户端提供的回环管理工具，只对需要的应用配置豁免；具体原理与命令见Windows UWP 回环豁免笔记。回环豁免只解决本地访问限制，不会修复订阅失效、代理不可达或规则错误。若应用已经通过 TUN 接管，应先查看连接是否进入内核，避免把两种接管路径混在一起排查。

退出或卸载前先关闭系统代理与 TUN，并确认系统设置已恢复。若客户端异常退出后浏览器提示代理服务器拒绝连接，检查 Windows 代理设置是否仍指向已经关闭的本地端口。升级前保留用户覆写与订阅来源，升级后重新检查开机启动和服务状态；界面能打开不代表后台服务仍然正常。休眠恢复后异常时，先重建连接和重载配置，再考虑重新安装。

macOS 安装配置

选择架构与完成首次授权

在“关于本机”中查看芯片类型，再进入macOS 下载区选择对应安装包。优先使用 Clash Plus，也可以按操作习惯选择 Clash Verge Rev 或 FlClash。ClashX Meta 为已停止维护的归档选项，使用旧工作流前需要额外评估兼容性。Apple Silicon 与 Intel 安装包不能只按文件体积判断；即使系统能够通过转译运行某些程序，也应优先选择与设备架构匹配的构建。

使用磁盘映像安装时，将应用移入“应用程序”后再启动，避免长期从临时挂载位置运行。首次打开如遇系统阻止提示，应检查来源与系统安全设置中的具体说明，不要批量移除整个下载目录的安全属性。客户端申请修改网络设置、安装辅助工具或添加网络扩展时，先确认请求来自当前应用。辅助服务安装成功后仍无法启动，应查看应用日志和系统授权状态，不能仅以密码输入成功作为判断依据。

订阅导入与用户配置保留

在配置管理中添加远程订阅，等待下载与解析完成，选中该配置后再进入代理选择页面。菜单栏显示运行状态，只代表客户端或内核正在工作，不代表订阅已经切换到新条目。首次导入后核对策略组与规则是否完整；若配置引用外部规则集或代理集合，还需要等待这些资源加载。某个资源请求失败可能不会立刻终止整个应用，但会影响对应的规则或策略行为。

本地修改建议放到客户端支持的覆写机制中，而不是直接编辑每次更新都会替换的订阅缓存。修改前确认覆写发生在订阅解析前还是运行配置生成后，不同客户端合并列表的方式可能不同。若同时设置了多个 DNS 块或同名策略组，最终结果应以运行配置为准。配置更新后检查日志，再核对必要字段是否保留，避免以为文件保存成功就等于内核使用了该内容。

系统代理与终端代理分别验证

打开系统代理后，浏览器通常通过当前网络服务的代理设置连接。本机可能同时存在 Wi-Fi、有线网络和其他网络服务，切换网络后应重新确认客户端是否更新了正确的服务。终端工具通常需要显式参数或环境变量，不会自动读取所有图形界面设置。先用单次命令验证，比直接修改 shell 启动文件更容易恢复。下面命令分别查看系统代理状态和实际端口占用。

scutil --proxy
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl --proxy http://127.0.0.1:7890 --head https://example.com

若需要当前终端会话使用代理，可临时设置 http_proxy 与 https_proxy；后者的值仍可以是 HTTP 代理入口，HTTPS 请求通过 CONNECT 建立隧道。不同工具对变量大小写和 SOCKS 支持不同，应查阅工具本身的说明。确认需求后再写入 shell 配置文件，并记录撤销位置。否则更换端口或退出客户端后，终端可能持续读取旧变量，造成“浏览器正常、命令全部失败”的分裂状态。

TUN、局域网与休眠恢复

需要接管不遵守系统代理的程序时，再评估 TUN 或客户端提供的增强接管功能。相关功能可能要求安装辅助服务或批准系统网络组件，授权入口随 macOS 版本与客户端实现变化，应按实际提示完成。不要把另一款客户端的授权路径机械套用。启用后先检查 DNS 与连接记录，再测试局域网设备、远程桌面和开发服务，确保局域网地址没有被错误送往远端代理。

如果访问打印机、路由器管理页或本地开发站点失败，应检查局域网绕过与路由排除，而不是直接改成全局模式。公司网络中常有仅通过内部 DNS 解析的域名，公共解析器不能替代内部解析服务。切换办公网络、热点或家庭网络后，应重新测试内部域名和直连规则。对这类环境，保留网络变化前后的日志和 DNS 结果，比频繁更换代理更有定位价值。

合盖休眠后恢复连接时，旧 TCP 会话可能已经失效，先重新发起请求或关闭旧连接，再判断是否需要重启内核。若菜单栏状态正常但所有新连接失败，检查网络是否实际恢复、系统代理是否指向当前端口以及辅助服务是否存活。卸载前关闭系统代理和接管功能，按客户端提供的流程处理辅助服务。不要仅删除应用图标就认定所有网络设置已恢复。

Android 安装配置

安装包、系统权限与 VPN 接口

进入Android 下载区，优先选择 Clash Plus，也可比较 Clash Meta for Android、FlClash 与 Surfboard。不同客户端接受的订阅格式与功能范围可能不同，特别是 Surfboard 的配置语法不能直接等同于 mihomo YAML。设备通常使用 ARM 架构，但仍应根据系统与安装包说明选择；若安装失败，先核对架构、系统要求和已安装应用的签名关系，不要反复覆盖来源不明的安装包。

从浏览器或文件管理器安装时，系统可能要求允许该来源安装应用。只对当前可信来源授权，安装完成后可按设备管理习惯收回该权限。首次连接出现 VPN 授权对话框属于 Android 的流量接管机制，授权后通常会显示系统 VPN 标识。这并不表示订阅由系统提供，也不意味着所有应用已经按预期分流；具体接管范围还取决于客户端的应用筛选、路由和运行配置。

订阅导入与首次连接

在配置页新增 URL 配置或从文件导入，等内容下载完成后选为当前配置，再检查代理组是否可选。通过分享菜单导入时，要确认传入的是完整订阅链接而不是网页标题或被截断的文本。剪贴板可能被其他应用读取，导入后不要长期保留敏感链接。若链接只能在登录后的网页内访问，需要向提供方获取客户端支持的订阅入口，不能用浏览器登录状态替代应用的请求凭据。

首次连接先采用规则模式，选择一个明确的代理策略，再批准系统 VPN 请求。打开浏览器访问测试地址，同时查看客户端中的连接记录。如果浏览器没有任何新连接，先检查 VPN 服务是否启动、浏览器是否被排除、当前运行配置是否正确。若连接已经进入内核但失败，再根据日志检查 DNS、远端握手或规则选择。不要把状态栏钥匙图标当作远端代理可用的充分证据。

应用分流与后台保活

Android 上常见的应用选择有“仅代理选定应用”和“绕过选定应用”两类，名单含义相反。设置后用一个明确在名单中的应用和一个不在名单中的应用分别测试，确认客户端采用哪种语义。应用分流与域名规则也不是同一层：应用被排除在 VPN 接管之外时，它的连接不会再进入内核规则。此时修改 MATCH 或切换策略组通常不会产生效果，应先修正应用接管范围。

若锁屏后连接消失，优先查看电池优化、后台活动限制、自动启动和系统清理策略。不同设备厂商的菜单名称不同，可在系统应用信息页检查电池与后台权限。只对需要持续运行的客户端做针对性调整，不必关闭整个系统的省电机制。设置后执行一次锁屏、等待、唤醒与重新请求的完整测试，观察服务是否重启、配置是否重新加载，以及后台任务是否有独立的网络限制。

DNS、其他 VPN 与网络切换

大多数 Android 设备同一用户环境只能同时维持一个普通 VPN 服务。广告过滤、防火墙或其他网络工具也可能占用该接口，表现为刚启动一款应用，另一款便断开。先停用其他 VPN 类工具再测试，不要误以为客户端随机退出。系统的私人 DNS 设置也可能改变解析路径，排查时先记录原值，再临时切回自动状态进行对照；确认原因后再决定长期配置，而不是永久关闭所有安全设置。

从 Wi-Fi 切换到移动网络后，远端地址解析、IPv6 可达性和既有连接状态都可能变化。只有旧连接失败时，可先断开重连；所有新连接都失败时，检查订阅是否限制网络、系统是否禁止应用使用移动数据，以及当前网络是否需要网页登录。门户认证通常需要先完成本地网络登录。此类问题不能通过修改策略组顺序解决，应先确认基础网络已经能够正常访问其登录页面。

系统设置中的始终开启 VPN 与阻止非 VPN 连接，会改变客户端停止后的联网行为。如果启用了阻止选项，客户端服务中断后断网可能是系统预期的保护行为，不是额外故障。远程协助前应先记下恢复入口，避免卸载后仍不知道如何解除限制。定期更新订阅时还要考虑后台请求条件；锁屏、节电或移动数据限制都可能推迟更新，具体排查可参考订阅更新失败与自动更新设置。

iOS 安装配置

通过商店安装 Clash Plus

iPhone 与 iPad 优先使用 Clash Plus。可从iOS 下载区进入商店，或直接打开Clash Plus 的 App Store 页面；项目官网为 clashplus.io。安装前阅读商店列出的系统要求与功能说明。桌面平台中同名的配置选项不一定在 iOS 上以相同方式呈现，操作时应以应用当前界面和系统授权提示为准。

首次建立连接通常需要允许添加 VPN 配置，并通过设备密码或系统认证确认。该配置用于让系统把相应流量交给应用的网络扩展，不是 Wi-Fi 密码，也不是订阅账号。授权前确认提示中的应用来源。若设备受描述文件或组织管理限制，可能不能添加个人 VPN；这属于设备策略范围，重新粘贴订阅链接无法解决，应先检查系统设置中的管理状态与允许的网络配置。

导入订阅与确认配置生效

在应用中使用订阅链接或文件导入入口，等待下载完成后选中需要运行的配置。若通过 Safari 打开链接，应区分订阅资源与服务商的用户中心网页；网页能显示内容不代表复制到的地址就是订阅地址。链接带有查询参数时必须完整保留，输入法替换标点或分享工具截断参数都可能导致请求失败。不要把包含私人订阅的页面截图上传到公开问题区。

导入成功后先核对代理组与选择项，再建立 VPN 连接。存在多份配置时，要确认当前选中的不是之前用于测试的本地文件。订阅更新可能替换代理列表，但应用保存的选择状态未必仍能对应旧名称；更新后应检查主策略组是否落到预期选项。如果连接记录显示直连，不应立即判断节点失效，还要确认规则是否本来就要求该目标直连，以及当前使用的是规则还是直连模式。

理解 iOS 的接管方式

iOS 客户端通常通过系统网络扩展接管流量，不能照搬 Windows 的“填写本地端口并打开系统代理”路径。Wi-Fi 详情中的 HTTP 代理属于另一套设置，不应为了让应用连接而随意填入桌面示例地址。手机上的 127.0.0.1 指手机本身，不是同一网络中的电脑；把电脑客户端的回环地址复制到手机，不能建立跨设备代理连接。局域网共享还需要服务端允许接入与正确的访问控制。

桌面文档中的 TUN、服务模式和系统代理开关用于解释不同接管机制，不表示 iOS 必须寻找同名按钮才能工作。实际接管范围、DNS 处理与可用规则由客户端实现及系统接口共同决定。若只在某个应用中失败，应先查看它是否建立了新连接、是否存在应用内部代理或独立网络策略，再检查规则。切换节点后，已建立的长连接也可能继续沿用旧路径，需要重新发起请求才能比较。

蜂窝网络、按需连接与恢复

首次验证建议关闭其他 VPN 配置，在稳定网络上手动连接，确认基础链路后再考虑按需连接等自动化选项。自动连接规则可能根据网络变化触发，导致用户手动断开后又恢复连接；排查时先记录相关设置，再暂时停用自动触发。若有系统或第三方的其他隐私网络功能同时运行，应分别测试各自状态，避免多层网络处理让请求路径难以判断。每次只改变一个功能，保留可比较的结果。

从无线局域网切换到蜂窝数据后失败，应检查系统是否允许 Clash Plus 使用蜂窝数据、当前网络是否实际可用，以及远端地址能否在该网络解析。锁屏期间网络扩展与主应用的运行方式不同，不能只凭应用没有显示在前台就判断服务停止。若反复断开，结合应用诊断信息和系统 VPN 状态确定断开发生在本地还是远端。对大型规则配置，应避免在排错期间不断叠加资源，先用较小的已知配置验证。

连接后整个设备无法联网时，先在应用中断开，再到系统 VPN 页面确认状态；必要时暂时关闭按需连接，防止刚断开又被拉起。恢复基础网络后，检查最近一次订阅更新、规则覆写和 DNS 变更。删除应用前先导出需要保留的配置，并确认其他设备上的订阅来源仍可访问。更多分层排查入口见帮助中心；提供诊断信息时只保留错误类型、必要字段和已遮盖敏感内容的日志。

Linux 桌面与服务

桌面客户端与无界面部署分开选择

桌面用户可从Linux 下载区选择 Clash Verge Rev 或 FlClash，先核对发行版的软件包格式、架构和依赖要求。图形客户端负责订阅管理与托盘交互，但 Linux 不同桌面环境的系统代理支持存在差异；设置写入桌面环境不代表所有程序都会读取。无界面服务器可直接运行 mihomo，通过配置文件与 systemd 管理。两条路径应选择一种作为主要管理入口，避免图形客户端和独立服务同时占用端口。

图形安装后先导入订阅、选择运行配置并检查日志，再设置桌面代理。若终端命令不跟随代理，使用单次命令参数确认链路，不要立即修改系统全局环境文件。服务器部署则先准备配置目录和权限，确认运行账户能够读取配置及其引用的规则资源。不要把整个用户主目录开放给服务，也不要为了消除一个权限错误而递归授予所有人写权限，这会扩大配置与订阅泄露的风险。

命令行启动与配置测试

以下示例假定 mihomo 可执行文件已经安装为 /usr/local/bin/mihomo，配置放在 /etc/mihomo/config.yaml。路径属于本例约定，实际部署可以不同，但命令和服务文件必须保持一致。先在前台验证，再建立常驻服务。下面的最小配置只验证本地监听与直连转发，不含远端代理；它不能替代自己的订阅，也不能用来证明某个代理出口可用。

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

/usr/local/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml
/usr/local/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml
curl --proxy http://127.0.0.1:7890 --head https://example.com

先运行测试命令处理解析错误，再以前台方式启动观察监听日志。规则资源、地理数据库或代理集合可能需要额外文件与网络请求；配置语法通过不代表所有外部依赖已经可用。若使用服务商配置，将其完整保存后重新测试，并检查引用路径与运行目录。前台验证结束应停止该进程，再交给 systemd，避免后台服务启动时只得到端口占用错误，却误以为配置本身损坏。

使用 systemd 管理普通代理服务

创建专用的 mihomo 系统用户，并让该用户拥有工作目录的读取与必要写入权限，再创建下面的服务文件。本例不启用 TUN，以普通用户运行本地代理；不要原样当作带虚拟接口权限的服务。发行版的创建用户命令各不相同，应使用系统自带的账户管理工具完成。配置和缓存目录若混用，应明确哪些文件需要更新写入，避免后续订阅或规则刷新时才暴露权限问题。

# /etc/systemd/system/mihomo.service
[Unit]
Description=mihomo local proxy
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
UMask=0077

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl status mihomo --no-pager
journalctl -u mihomo -b -n 80 --no-pager

修改配置后先用与服务相同的账户和路径测试，再重启服务并查看本次启动日志。network-online.target 的具体等待效果取决于发行版是否配置了相应的网络等待服务，不能保证任意远端资源此时一定可达。订阅更新也不由这份 unit 自动完成，应采用明确的下载、测试和替换流程；新配置验证失败时保留旧文件，避免定时任务把错误页面覆盖成正式配置。

TUN 权限、容器与终端环境

Linux TUN 需要可用的虚拟接口设备、网络管理权限与适当路由配置。不能只在 YAML 中设置 enable: true 就假定权限已经齐全。容器还受设备映射、网络命名空间与能力限制影响，应先在宿主环境理解链路，再设计容器接管。普通代理服务使用的权限约束与 TUN 服务需求不同，修改前应评估所需能力及范围，不要直接把整套部署改为高权限运行来掩盖问题。

终端会话可按需设置代理变量，但后台服务不会自动继承交互式 shell 的全部环境；反过来，mihomo 自身的订阅或资源请求也不应误指向尚未启动的代理入口。远程服务器调整默认路由前保留第二个管理会话与回滚路径，防止 SSH 被接管后失联。更完整的桌面与无界面对照见Linux 部署 mihomo 技术笔记。

配置常见问题与恢复

配置文件解析与规则名称

YAML 使用空格缩进，不能用制表符混排；同一层级保持一致，列表项写在正确父字段之下。出现行号错误时，既要看报错行，也要检查上一行的冒号、引号和缩进。把配置贴入富文本编辑器可能引入全角标点或不可见字符，建议使用纯文本编辑器。不要通过删除整段 rules 来掩盖错误，因为内核能启动与分流符合预期是两个目标，删掉规则可能改变所有连接的路径。

规则按顺序匹配，较具体的域名规则通常放在通用兜底之前。下面只是规则片段，PROXY 必须对应运行配置里已有的代理或策略组。若订阅使用其他组名，应修改引用，而不是另外创建一个空组。配置中的名称通常要求精确对应，大小写、空格与符号差异都可能导致找不到目标。规则命中与策略组最终选择还要分别查看，命中代理组不代表该组没有选中 DIRECT。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

系统代理正常，TUN 却失败

系统代理依赖应用主动遵守代理设置，TUN 则通过虚拟接口与路由接管更广的连接，两者的权限、DNS 路径和故障范围不同。系统代理可用而 TUN 失败，应先检查权限与路由，不要立刻更换订阅。下面是 mihomo 的 TUN 字段片段，不是独立配置；客户端可能由界面生成或覆写这些字段。启用前需要配合完整 DNS 方案，单独复制片段不能保证所有平台行为一致。

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

DNS 劫持片段针对相应的传统 DNS 请求，不表示所有加密 DNS 都会以同样方式进入内核。浏览器的安全 DNS、系统私人 DNS、IPv6 路由与应用自带解析器都可能改变观察结果。先确认域名解析失败还是连接失败，再决定调整 resolver、fake-ip 或路由排除。相关机制可对照TUN 模式与系统代理的区别，避免为了一个应用的问题同时更改多个网络层。

订阅更新、覆写与外部资源

订阅更新失败时保留上一份可运行配置，记录状态码、超时类型或解析行号。地址失效、权限过期、响应被替换成网页、请求网络不通，需要不同的处理路径。若当前订阅必须通过代理才能更新，而代理又依赖该订阅，应预先准备可靠的更新路径，避免形成启动循环。自动更新间隔应结合提供方限制与实际需求，不要通过高频重复请求处理暂时性错误。

规则集合与代理集合可能各自具有缓存和更新时间，主订阅更新成功不能证明所有资源都更新成功。修改覆写后应检查最终运行配置，重点核对端口、DNS、组名、规则顺序和监听地址。若客户端支持配置预览或导出，导出前注意其中可能包含订阅信息与认证内容；向他人求助时应先脱敏。对于持续复现的解析错误，提供最小化片段通常比发送整份私人配置更有帮助。

按现象确定下一步

排错记录至少包含平台、客户端名称、当前模式、接管方式、错误出现的阶段，以及一条脱敏后的相关日志。不要把节点测速、浏览器访问和后台更新混为同一个测试，它们可能使用不同目标和请求路径。只有某个网站失败时，还需考虑目标服务自身状态、出口地区政策和账号限制。先证明请求进入了预期策略，再判断远端是否可达，比盲目切换模式更有效。

完成修复后，只把经过验证的最小改动写回长期配置，并更新备份。升级客户端、切换内核或迁移设备时，重新执行一次基础验证，不直接沿用旧环境的结论。需要按问题快速定位，可转到帮助中心；需要理解字段含义，可查术语表。本页侧重跨平台边界，首次配置仍建议按快速上手主线逐步完成，避免在基础连接尚未建立时叠加高级功能。