Clash 全平台配置

通用准备与配置边界

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

Clash 生态中的图形客户端负责显示配置、管理启动和设置系统代理；内核负责监听端口、解析规则并建立连接；订阅则提供服务器参数、策略组及其他配置。三者不是同一个东西。安装客户端不会自动获得可用的订阅，导入链接也不代表内核已经成功加载。排错时应分别确认：程序能否启动、配置能否解析、连接是否真正进入内核、目标出口是否可用。

选择安装包时先打开系统的设备信息，记录操作系统、处理器架构及当前用户权限。本站在支持的平台优先提供 Clash Plus，具体选择见客户端安装包。不同客户端对内核字段、系统服务和导入方式的支持存在差异，不应仅凭扩展名相同就判断配置完全兼容。已经停止维护的归档客户端更适合复现旧环境，不宜作为新设备的默认起点。

保存配置来源，控制凭据传播

订阅地址通常含有用于识别账户的参数，应按凭据对待。复制时确认没有带入换行、聊天软件附加文字或末尾标点；不要把完整地址放进截图、工单和公开日志。浏览器能够打开链接，只能说明该请求在浏览器环境中成功，不代表客户端使用的网络路径、请求头或证书环境相同。遇到格式不支持时，应先向提供方确认 Clash 或目标内核适用的配置格式。

首次导入前保存原配置的副本，并记录当前选中的配置名称。远程订阅更新可能覆盖下载得到的内容，长期自定义规则应优先放在客户端明确支持的覆写、合并或扩展配置中。不同产品的合并顺序并不一致，保存后需要检查最终生效配置。跨设备复制时只携带必要字段，路径、网卡名称和本地监听地址应在新设备上重新确认。

先建立最小可用路径

建议先使用规则模式，选择一个可用策略组，再启用一种流量接管方式。桌面系统可先测试系统代理；移动系统通常由客户端建立系统 VPN 隧道。TUN 用来接管更多应用的网络连接，但会引入虚拟网卡、路由与 DNS 的额外变量。初次配置同时启用多个客户端、全局模式和 TUN，会使日志难以归因，也容易留下重复路由。

下面是一段用于理解本地监听设置的示例，不含服务器信息，不能单独建立代理连接。端口并非固定要求，只需未被占用，并与调用方保持一致；已有配置中存在这些字段时应修改原项，不要重复添加同名键。

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

其中混合端口可接收 HTTP 与 SOCKS 请求，允许局域网连接决定是否接受其他设备访问，本地绑定地址进一步限制监听范围。保持只允许本机连接，能避免尚未配置认证时将端口暴露到网络。系统时间也应先同步，时间偏差可能让加密握手和证书判断失败。完成准备后，每次只改一个设置，立即测试并查看新日志，这比一次修改多处更容易确定原因。

Windows 安装与流量接管

选择安装包并完成首次启动

在系统设置的“系统信息”中确认处理器架构，再到Windows 安装包选择对应客户端。优先考虑 Clash Plus，也可按功能需求选择 Clash Verge Rev、FlClash 或 Clash Nyanpasu；Clash for Windows 属于已停止维护的归档选择。不要把其他架构的文件仅通过重命名当作兼容版本，也不要在解压目录未完整保留的情况下单独移动主程序。

运行安装程序时，先查看系统显示的文件来源与发布者信息。安全提示不能仅凭文件名判断，遇到异常应停止并核对下载来源，不要直接关闭系统防护。安装完成后先用普通用户启动，确认托盘图标、设置页及日志可以打开。只有安装服务、启用虚拟网卡或修改受保护配置时才按客户端说明提升权限，避免整个使用过程长期依赖管理员运行。

导入订阅，确认当前配置

进入配置管理页，选择从链接导入，粘贴完整订阅地址并保存。下载完成后主动选择该配置，检查是否出现解析错误，再进入代理或策略组页面选择出口。部分客户端把“下载配置”和“启用配置”分成两步，列表中有文件不代表内核正在使用它。若提供方给的是本地文件，使用文件导入入口，不要将文件路径粘贴进订阅网址输入框。

导入失败时先观察错误属于连接失败、响应格式异常还是字段不支持。网页返回登录页时，客户端获得的可能是 HTML 而非配置；提示字段不识别时，应确认订阅是否面向当前内核。先保留原文件，不要删掉所有看不懂的字段来消除报错。成功加载后记录配置名称和策略组选择，随后再测试更新，确认更新不会切换到另一份配置。

系统代理、UWP 回环与 TUN

在客户端开启系统代理后，检查 Windows 代理设置是否指向客户端实际监听的本机地址和端口。浏览器有自己的代理扩展时，可能覆盖系统设置，测试阶段应先统一路径。命令行程序不一定遵循系统代理，可以用显式代理请求区分“应用未接管”和“出口失败”；下面的端口应替换为设置页中的真实值，测试地址也可改为正在排查的网站。

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

如果浏览器可访问而某些商店应用不可访问，可能涉及 UWP 应用访问本机回环地址的限制。只对确有需要的应用检查回环权限，优先采用客户端提供的管理入口，不要批量放开所有应用。也可评估 TUN 是否适合当前场景，但 TUN 不能替代对订阅有效性和规则命中的确认。企业设备受组织策略管理时，应遵守设备管理要求。

TUN 首次启用可能要求安装服务或创建虚拟网卡。确认系统代理测试已经通过后，再启用 TUN 并检查日志是否报告接口建立、路由设置或权限错误。防火墙弹窗应按实际网络范围授权：仅供本机使用不需要开放公共网络入站。另一款 VPN、安全软件的网络过滤模块或旧虚拟网卡可能改变路由，排查时先停用重复接管者，而不是反复重装客户端。

开机自启与退出后的恢复

“开机自启”通常指用户登录后启动界面；“服务模式”可能让内核独立于界面运行，两者不能混为一谈。先配置好可用订阅，再启用自启，并重启验证配置是否被自动选中。若启动后短暂无法联网，检查网络就绪时间、服务权限和订阅是否必须在线下载。不要同时在任务计划程序与客户端设置中重复添加启动任务。

更完整的安装分支见Windows 防火墙、UWP 回环与 TUN 常见坑。记录发生问题时使用的网络类型、权限和接管方式，通常比只描述“连接不上”更有诊断价值。

macOS 安装与网络权限

确认芯片与应用来源

通过苹果菜单中的“关于本机”查看芯片类型，在macOS 安装包选择 Apple Silicon 或 Intel 对应文件。优先选择 Clash Plus，也可使用 Clash Verge Rev、FlClash；ClashX Meta 为已停止维护的归档客户端。即使系统可以通过兼容机制运行其他架构程序，也应优先使用与设备匹配的安装包，减少额外兼容层造成的启动和权限问题。

打开磁盘映像后，将应用放入应用程序目录，再从该位置启动，不要长期在挂载的安装映像内运行。首次启动的安全提示应结合下载来源和系统显示的信息判断；若系统提示文件损坏或来源异常，先重新获取匹配的包并检查系统兼容要求，不要直接执行网上来源不明的解除限制命令。需要安装辅助服务时，确认弹窗确实来自当前操作。

导入配置并区分网络服务

在配置页粘贴订阅链接，完成下载后选中配置，再检查日志中的解析结果。通过浏览器跳转导入时，应核对接收链接的应用，设备上安装多款客户端可能导致协议关联指向旧程序。无法唤起时可以回到客户端手动粘贴，但不要将含凭据的链接发送到第三方转换页面。导入成功后选择规则模式及实际可用的策略组，先用浏览器进行最小测试。

macOS 的系统代理与当前网络服务关联，无线网络、有线适配器及其他网络服务可能各有设置。切换网络后访问异常，先确认当前启用的服务是否仍使用客户端监听的本地端口。自动代理脚本和手动网页代理可能形成不同路径，应清楚实际启用的是哪一种。下面的命令只用于读取状态，不修改系统配置；服务名称并不一定叫 Wi-Fi，应先列出设备上的实际名称。

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"

输出中的启用状态、服务器地址和端口应与客户端一致。如果客户端退出后仍指向本地端口，系统请求会发往已经不存在的监听服务。恢复时在系统网络设置中关闭对应代理项，并检查自动代理配置是否也被开启。不要在不知道现状时连续运行多条修改网络服务的命令，否则容易修复无线网络却遗漏有线网络。

TUN、辅助服务与 DNS

TUN 的实现取决于客户端与内核，有的通过特权辅助服务调整路由，有的涉及系统网络扩展授权。按当前客户端的说明完成授权，看到菜单中的开关亮起后，仍要从日志确认接口和路由实际建立。系统升级或迁移应用目录后，旧服务可能需要修复或重新授权；应通过客户端自己的服务管理入口处理，不要手动删除不确定归属的系统文件。

如果启用 TUN 后只有公司内网域名失效，问题可能来自分流 DNS 或企业 VPN 路由，而不是节点整体不可用。记录失效域名、连接的网络服务和命中规则，检查客户端是否覆盖原有解析路径。对依赖内网解析的环境，需要保留相应域名的正确解析来源，不能简单把所有 DNS 请求送到同一个公共解析器。处理完后分别测试内网和公网，避免只修复一侧。

系统代理主要影响遵循系统设置的程序，终端工具可能需要显式指定代理或设置环境变量。环境变量只对继承它的进程有效，不等于全系统接管。若终端可访问而浏览器不可访问，应反过来检查浏览器扩展、缓存及系统网络服务；若两者均失败，再查看客户端日志和当前策略组。不要用是否显示代理图标代替真实请求验证。

登录启动、休眠与网络切换

需要登录后启动时，使用客户端内的启动选项，并在系统登录项中确认没有被禁用。辅助服务运行与菜单栏界面显示是两件事，关闭窗口未必会停止内核。休眠恢复、热点切换或有线适配器重新插入后，接口名称和默认路由可能变化；先停用再启用当前接管方式，观察是否重新建立路由，不要立即覆盖订阅。

迁移到另一台 Mac 时可导出配置，但要重新授权服务、检查本地文件路径并重新选择策略组。私有证书、组织网络配置和系统钥匙串内容不应通过普通订阅文件传播。稳定运行后再逐项恢复自动更新、自启与其他扩展设置，并保留一次正常连接时的日志特征，方便与故障状态对照。

Android 安装与后台连接

按架构安装并处理授权

在Android 安装包中优先选择 Clash Plus，其他选项包括 Clash Meta for Android、FlClash 和 Surfboard。不同应用支持的配置格式和协议集合可能不同，不能把同一订阅在某应用导入失败直接归因于手机。先确认订阅提供方支持的格式，再选择客户端。安装包架构需与设备匹配；较旧或特殊设备应依据系统信息判断，不要仅凭手机品牌选择。

从浏览器或文件管理器打开安装包时，系统可能要求允许该来源安装应用。只为当前需要的来源授权，完成安装后可按设备策略收回。若提示与现有应用签名冲突，通常不能直接覆盖安装；先导出必要配置，确认新旧应用来源及包名，再决定是否卸载。卸载可能清除配置、日志与授权，不能当作没有成本的第一步排错方法。

导入订阅与建立系统隧道

打开客户端的配置或订阅管理页，添加远程链接，保存后执行更新，并选择这份配置作为当前配置。名称可以使用便于区分的本地标签，不要把完整凭据写入名称。导入本地文件时，通过系统文件选择器授权访问即可；文件出现在下载目录，不代表客户端自动拥有读取权限。导入后检查策略组是否正常出现，以及有没有不支持字段的错误。

点击启动后，Android 通常弹出系统 VPN 连接请求。这里的 VPN 权限用于让客户端接收本机流量，并不表示系统自动提供远程出口。确认请求来自刚刚打开的应用后再允许。大多数普通使用环境同一时间只允许一条系统 VPN 连接，其他 VPN、防火墙或使用相同机制的过滤应用可能互相替换，切换时应先明确停止哪一方。

移动端的系统隧道与桌面“设置系统代理”不同，不必再到无线网络高级设置中填写同一个本地代理。无线网络里的手动 HTTP 代理通常只对部分应用和当前网络生效，叠加后反而可能把流量送入错误端口。先保留一种接管路径，确认浏览器和目标应用都能产生连接日志，再考虑按应用分流或局域网服务。

应用分流与后台限制

客户端若提供按应用选择功能，要先看清当前采用的是“仅代理所选应用”还是“绕过所选应用”。勾选同一应用在两种模式下意义相反。通过应用名单决定流量是否进入隧道，通过域名和地址规则决定进入后使用哪个出口，两层设置应分开验证。若日志完全没有目标应用的请求，优先检查应用名单，而不是增加更多域名规则。

锁屏后断连常与系统电池管理有关。先确认客户端是否显示前台服务通知，再在设备的电池设置中检查该应用是否被限制后台运行。不同厂商的自启动、后台活动与省电策略名称不同，应只调整与当前应用有关的项，不要整体关闭设备节能功能。测试时分别观察亮屏、锁屏和较长待机后的连接，避免只在启动瞬间判断结果。

“始终开启 VPN”和“阻止未通过 VPN 的连接”属于系统级策略，后者可能在客户端尚未启动或配置失效时阻断其他网络。仅在理解行为并完成重启测试后启用。不要把客户端的自动重连选项当成系统级阻断策略，两者处理的阶段不同。取消强制策略时，也应确认系统设置已经恢复，而不只是关闭应用内开关。

DNS、私有 DNS 与热点边界

Android 私有 DNS、客户端 DNS 和应用自带的加密解析可能同时存在。域名访问异常时，记录这些设置的原始状态，再逐一对照测试，不要同时修改。某些应用复用缓存或长连接，变更 DNS 后需要重新发起请求才会体现差异。只看到 IP 地址可达，也不能据此认定应永久禁用所有 DNS 功能。

手机自身的 VPN 通常不会自动接管通过热点连接的其他设备。想让电脑借用手机上的代理，需要客户端明确支持局域网监听，并配置可达地址、认证和防火墙；这与开启热点是两件独立的事。普通移动使用建议保持局域网访问关闭。若订阅更新在移动网络失败、无线网络成功，进一步检查流量权限、网络限制和提供方可达性，避免将网络差异误判为配置损坏。

iOS 安装与隧道配置

从商店安装 Clash Plus

iPhone 与 iPad 可使用 Clash Plus，安装入口见iOS 客户端，或直接打开App Store 中的 Clash Plus。产品官网为 clashplus.io。安装前阅读商店页面中的系统兼容信息，以设备实际显示为准；不要把其他平台的安装文件当作移动系统应用导入，也不需要为使用订阅安装来源不明的设备管理描述文件。

首次打开时先熟悉配置页、代理模式和连接开关。通知权限与网络隧道权限用途不同：通知用于呈现状态或提醒，建立隧道则需要系统确认 VPN 配置。若设备由学校或组织管理，网络能力可能受策略限制，应先确认允许范围。安装应用成功不意味着已经具有可用配置，后续仍要导入订阅并选择正确的出口策略。

导入链接并检查配置来源

复制提供方给出的完整订阅地址，在客户端中选择通过链接添加配置，填写本地名称并保存。剪贴板授权出现时，确认正在执行粘贴操作即可。浏览器中的快捷导入会调用应用关联机制，若没有跳转，可回到客户端手动添加；不必反复打开相同链接，以免产生多份难以区分的配置。含有账户参数的订阅地址不应保存到公开备忘录或共享截图中。

更新完成后选中配置，再查看策略组。若导入后仅显示空白列表，检查下载是否真的成功、返回内容是否为配置，以及该格式是否被客户端支持。订阅提供的节点信息和规则可能在同一文件内，也可能通过客户端支持的其他结构组织，不能根据文件大小推断是否完整。手动编辑前保存副本，避免修复一项格式问题时破坏原有缩进和组名。

允许 VPN 配置并验证规则

首次启动连接时，系统会要求允许添加 VPN 配置，可能需要设备密码或其他本机确认。授权完成后回到应用检查连接状态，再打开浏览器发起新的请求。状态栏中的 VPN 标识说明系统隧道已建立，不代表远端服务必然正常，也不代表所有请求都走同一个出口。规则模式仍可能让部分域名直连，因此验证时应同时查看命中规则与策略组。

iOS 的客户端通常利用系统网络扩展接收流量，不等同于桌面系统的 HTTP 代理设置。无线网络详情里的手动代理设置是另一条路径，一般不需要为了启动客户端再额外填写。设备上存在其他 VPN 配置时，应确认当前激活的是哪一个；反复切换不同应用可能使系统选择发生变化，排错期间保持一款客户端运行，减少配置关联的干扰。

规则命中的判断应以本次连接日志为准。应用可能复用已有连接，修改规则后仅返回原页面不一定触发新匹配。可关闭目标页面后重新访问，必要时重启目标应用；不要为了验证一个域名就反复清空整台设备的网络设置。若规则引用的策略组不存在，应修复名称或订阅兼容性，而不是把所有请求永久改成全局模式来掩盖错误。

后台运行与按需连接

系统隧道与前台界面生命周期不同，切换到其他应用不一定会停止连接；相反，强制结束界面也不能作为判断隧道是否关闭的唯一依据。停用时使用客户端连接开关，并在系统 VPN 状态中确认。若支持按需连接，应先阅读触发条件，在无线网络与蜂窝网络之间分别测试，确认是否存在自动启动、网络切换重连或特定网络例外。

锁屏恢复后某个应用暂时无法加载，先发起新的请求并检查日志，区分旧连接失效与隧道持续不可用。低电量状态、网络切换和目标服务自身的会话限制都可能影响表现，不能仅凭一次重连就确定原因。网络环境变化后，订阅所列服务器的可达性也可能不同；应在当前网络下测试，不要沿用另一网络中的结论。

迁移设备与配置更新

更换设备后，需要重新检查系统 VPN 授权、当前配置及策略组选择，不能假定设备备份会完整恢复所有连接权限。导出文件前检查其中是否含有订阅凭据和服务器密码，只通过可信渠道传送。来自桌面内核的文件可能带有监听端口、网卡与本地路径字段，移动客户端对这些字段的处理取决于自身实现，应使用兼容配置而非逐项照搬。

定期更新订阅可以获取提供方的变更，但不应在网络故障时无限重复更新。先判断原配置是否仍可用，再检查更新请求是否成功、远程内容是否改变、当前选中配置是否一致。有关更新异常的通用说明见订阅更新问题。保留一份能够正常加载的本地备份，有助于将“获取失败”和“新配置不可用”分开处理。

Linux 桌面与内核部署

选择图形客户端或独立内核

Linux 桌面可到Linux 安装包选择 Clash Verge Rev 或 FlClash。先确认发行版、处理器架构和包管理格式，再使用发行版支持的安装方式。下载页提供的包并不代表覆盖所有发行版和架构，不能把其他系统的安装包改扩展名使用。安装时阅读包管理器给出的依赖信息，发生依赖冲突应先定位来源，不要直接强制忽略检查。

图形客户端适合交互式导入订阅和切换策略；独立 Mihomo 内核更适合服务器、路由器或自行维护服务的用户，入口见内核下载。内核没有图形界面，文件解压后还需要执行权限、配置目录和启动方式。普通桌面用户不必为了启用代理先搭建后台服务，先通过图形客户端验证网络路径，能减少部署变量。

图形界面中的订阅与代理

安装后在配置页导入远程订阅，下载完成后选中配置并检查日志。图形界面可正常显示，不代表其内核进程已经启动；应检查实际监听地址及端口。桌面环境的系统代理支持程度不同，有的程序读取桌面设置，有的只读取环境变量，也有程序完全使用自己的网络设置。因此“浏览器成功但终端失败”不一定是节点问题。

终端测试可以临时指定代理，不立即修改登录脚本。下面的环境变量仅影响当前 shell 及其后续启动的子进程；已经运行的桌面程序不会自动获得它们。退出测试时清除变量，避免客户端关闭后终端仍向本地端口发送请求。地址与端口都应以客户端实际监听值为准，涉及凭据时不要把密码写进可公开读取的脚本。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl --head https://example.com
unset http_proxy https_proxy

这里 HTTPS 目标通过 HTTP 代理建立隧道，因此代理地址使用 HTTP 协议并不矛盾。还要检查是否存在大写变量、全局环境文件或工具自身配置，它们可能影响测试结果。容器、远程会话和沙箱应用有独立的网络或环境边界，容器中的本机地址通常不是宿主机，不能直接照搬桌面端口后认定服务不可用。

独立内核的目录与运行身份

手动部署时，将解压得到的可执行文件放入受控位置，赋予执行权限，并为配置和运行数据准备单独目录。先以前台方式启动，观察解析及监听是否成功，再考虑服务化。以下示例假设可执行文件已命名为 mihomo，配置已保存到用户目录下的配置文件中；命令本身不会生成有效订阅或补齐远端服务器参数。

mkdir -p "$HOME/.config/mihomo"
chmod u+x ./mihomo
./mihomo -t -d "$HOME/.config/mihomo"
./mihomo -d "$HOME/.config/mihomo"

测试通过只说明配置能够被解析，不保证远端服务可达。服务化时明确运行用户、工作目录、启动命令及配置路径，避免服务账户读取的是另一份默认配置。日志目录和更新产生的数据也需要适当写入权限。不要为了简化权限问题直接让所有文件对所有用户可写，配置中可能包含账户信息和控制接口凭据。

TUN、路由与 DNS 的权限

TUN 通常涉及访问虚拟网络设备和修改路由，需要相应系统能力。图形客户端可能通过辅助服务完成，独立内核则需要自行配置运行权限。不要盲目复制给任意文件授予网络管理能力的命令；先确认二进制位置、更新方式及威胁边界。二进制被替换后，文件级权限能力也可能变化，更新后需要重新验证。

启用后用路由与解析状态检查工具观察变化，例如查看当前路由、监听端口及系统解析服务状态。不同发行版可能采用不同 DNS 管理器，不应同时让多个组件反复覆写同一解析文件。若远程维护服务器，先保留第二条管理会话，并准备明确的恢复方法；错误的默认路由可能中断当前连接，不能只依赖图形开关恢复。

自启与关闭后的残留检查

桌面自启项只在用户会话开始后运行，系统服务则可能在登录前启动。选用哪一种取决于是否需要后台持续工作，不要两者同时启动同一端口的内核。重启后检查实际进程、配置目录及监听端口，而不是只看服务名称显示正常。停用时先恢复代理与路由，再停止进程；若端口冲突，确认占用者所属服务后再处理，避免误停其他网络程序。

配置常见问题与排查顺序

从现象定位故障层级

开始排错前记录操作系统、客户端名称、使用的配置、代理模式和接管方式，并记下问题开始前最后一次变更。先暂停其他代理与 VPN，再发起一次新的测试请求。若客户端完全没有收到连接，应检查系统代理、应用名单或 TUN 路由；若收到请求但出口连接失败，再看策略组与服务器；若连接已建立而页面异常，继续检查 DNS、规则及应用自身行为。

“显示已连接”可能只代表本地内核运行，或系统隧道已经建立，并不覆盖完整访问链路。将本地接管与远端可达性分开测试，能避免在错误层面反复修改。完整检查思路见已连接却打不开网页的排查清单；若日志明确指向远端超时，可继续查阅节点超时与连接失败排查顺序。

规则顺序、组名与配置更新

规则通常按顺序匹配，第一条符合条件的规则决定后续动作。宽泛规则放在前面可能遮挡更具体的规则，兜底规则一般放在末尾。下面的片段仅用于说明语法，要求配置中确实存在名为 PROXY 的策略组；如果实际组名不同，就要替换为现有组名。不要为了套用示例新建一个空组，也不要把片段直接追加为第二个顶层规则键。

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

地理地址规则依赖可用的相关数据，且域名解析结果会影响地址类匹配。全局模式可用于短时对照，但不能证明规则配置正确。确认某站异常时，查看该连接命中的规则与最终出口，不仅看策略组当前选项。远程更新可能改变组名，覆写规则引用旧名称时便可能加载失败；更新前后应对比错误信息，必要时恢复已知可用的备份再逐项迁移。

DNS 与 TUN 的交叉影响

DNS 负责把域名转换为可连接的地址；代理连接成功并不保证域名解析路径正确。启用虚拟地址模式后，部分域名可能获得用于映射的地址，这不是远端服务的真实地址。复制该地址给其他设备或绕过客户端使用，可能无法访问。需要兼容特殊应用时，应按内核文档配置相应域名例外，并确认规则仍能正确获得域名信息。

遇到内网域名、打印机或本地设备访问失败，先判断请求是否被错误送入隧道，以及解析是否仍来自原网络。不能用统一替换公共 DNS 的办法解决所有问题。关闭 TUN 对照测试时，也要确认系统代理和其他 DNS 设置是否仍在作用，否则测试并没有真正恢复原路径。IPv6 同样涉及独立的地址、解析与路由，只有一部分站点失败时应检查双栈差异，而不是立即永久禁用它。

订阅更新与测速结果

更新失败时先看响应类型：连接超时说明请求未完成，认证失败需要检查凭据与账户状态，格式错误则说明获取的内容无法按目标格式解析。更新请求是否经过代理取决于客户端实现及设置，不能假定始终直连或始终代理。旧配置仍可连接时，先保留它，不要连续删除重建；详细分支见帮助中心的订阅更新说明。

延迟测试只反映指定测试请求在当时的表现，不等于持续下载速度，也不保证所有目标网站可用。不同测试地址、握手阶段和并发状态会改变结果，应保持测试条件一致。选择出口后还要通过目标应用验证实际需求，相关原理见延迟测试与实际网速的区别。不要用一次测试数字替代连接日志和真实使用判断。

保留证据，再恢复稳定状态

分享日志前删除订阅地址、账户参数、服务器密码及不必要的个人网络信息，只保留错误类型、发生时间和必要上下文。调试级日志适合短时复现，完成后恢复正常级别，避免长期生成过量数据。每次修改后记录结果，无改善就恢复原值，直到找到能够解释现象的具体差异。稳定后再恢复自动更新与自启；需要重新走完整操作主线时，返回使用指南，不要把临时排错配置当作长期默认配置。