Clash 故障排查手册

无法上网：先分清本地接入与代理链路

建立关闭代理后的网络基线

浏览器所有页面都打不开时，先关闭客户端的系统代理与 TUN 模式，再测试平时可直连的网站。客户端退出不一定会清除系统中残留的手动代理，因此还要打开操作系统网络设置核对。若关闭代理后仍不能上网，优先检查无线连接、网线、路由器以及是否需要完成网络登录，而不是继续修改节点。

酒店、校园和公共无线网络常要求先打开认证页面。代理或自定义 DNS 可能让认证跳转失败，表现为已经连接无线网络却打不开网页。暂停代理，完成网络认证，再恢复客户端；如果同一网络上的其他设备也无法直连，应先处理网络本身。只有直连基线正常，后续对代理路径的比较才有意义。

用显式代理请求划分故障位置

恢复客户端后，确认内核正在运行，并查看设置中实际的混合端口。下面使用常见的本机端口举例；若实际端口不同，先修改命令。第一条绕过代理环境变量，第二条明确经过本地 HTTP 代理。Windows 请使用 curl.exe，macOS 与 Linux 使用 curl，避免把其他命令别名当成同一工具。

curl --noproxy "*" -I --connect-timeout 10 https://example.com
curl -x http://127.0.0.1:7890 -I --connect-timeout 10 https://example.com

测试目标应替换为当前网络中已知可访问的站点，两个请求使用同一个地址。若第二条立即提示连接被拒绝，问题通常在本地监听端口或内核；若代理请求能返回 HTTP 响应而浏览器仍失败，则继续检查浏览器扩展、系统代理和应用自己的网络设置。网站返回拒绝访问的状态码，也不等同于代理连接失败。

检查模式、策略与规则的实际命中

本地端口可连接但目标站点打不开时，先看当前使用的是规则、全局还是直连模式。规则模式需要确认连接记录中命中的规则与策略组，不能只看主界面选中的节点。某个子策略组可能仍停留在失效节点，或者流量被提前命中的直连规则接走。对照连接记录中的目标域名、规则与最终出站逐项检查。

可以短暂使用全局模式作对照，并手动指定已知可用的节点。如果全局模式正常、规则模式失败，重点转向规则顺序、规则集加载及 DNS；如果两者都失败，优先查看节点链路。全局模式只是定位工具，不是所有故障的长期解决办法。完成比较后恢复原模式，再修正具体规则，避免把本应直连的服务也送入代理。

恢复顺序与停止条件

仅少数网站失败时，检查目标服务是否故障、是否限制出口地区，以及当前账户是否允许访问。浏览器证书报错还要检查设备日期和时区，不应通过关闭证书验证解决。若网络中有另一套 VPN、加速器或安全软件，先退出其中一套再测试，避免多个程序同时改变默认路由，导致请求进入互相覆盖的路径。

每完成一步，都用原来的测试地址复测，并记录直连、显式代理和浏览器访问三种结果。三者一致恢复后，再逐项恢复其他网络工具。若必须进一步求助，提供报错原文和发生阶段，而不是只描述“连接失败”。基础连接恢复后，可回到系统代理设置教程核对日常使用方式。

节点超时：区分探测失败与实际不可用

确认超时来自哪一种测试

客户端的节点测速通常向指定网址发出请求，再根据响应计算耗时。这不是完整的下载速度测试，也不保证所有应用都能通过同一节点访问。探测网址自身受限、返回内容不符合预期，或超时时间设置过短，都可能出现测速失败。先使用该节点访问实际业务，再判断是探测条件异常还是代理链路确实不可用。

如果网页可打开而只有测速显示超时，检查测试地址的协议与可达性，优先沿用客户端或订阅提供方建议的测试方式。不要连续批量测速来确认单个节点；大量并发探测可能触发连接限制，也会占用当前网络资源。先选一个节点单独测试，等待结果完成，再用另一个已知可用的节点作对照。

按日志阶段检查服务器连接

连接日志中的域名解析失败、连接被拒绝、握手失败与读写超时，指向不同位置。解析失败说明尚未拿到服务器地址；连接被拒绝通常说明目标端口没有接受连接；握手失败则可能与协议参数、认证信息、设备时间或链路干扰有关。记录完整错误链，特别是最底层原因，不要仅截取界面上的红色状态。

在 Windows 可用下列命令检查订阅中节点服务器的 TCP 端口是否可达。地址与端口需要换成实际节点信息。该测试只证明 TCP 建连情况，不能证明代理认证成功；对于以 UDP 为主要传输方式的节点，TCP 测试失败也不能直接作为节点失效的结论。不要把节点信息贴到公开讨论区。

Test-NetConnection -ComputerName example.com -Port 443

如果服务器使用域名，先核对域名是否被解析为预期类型的地址。某些网络只有 IPv4 可用，却优先尝试不可达的 IPv6 路径，会造成等待后失败。可在有记录的前提下临时调整客户端的 IPv6 相关设置作比较，但不要直接删除订阅中的服务器域名，因为部分协议还依赖该域名参与 TLS 握手。

核对协议参数与订阅状态

节点能够建立底层连接却在握手时失败，应重新更新订阅，确认账户状态、有效期和设备限制。手工复制节点时容易遗漏加密方式、传输类型、服务器名称、路径或公钥等字段。优先重新导入完整且受当前客户端支持的配置，不要凭其他节点的参数拼接。不同协议中名称相近的字段也不一定可以互换。

部分新协议需要较新的内核能力。界面能够显示节点名称，并不代表底层内核能够正确加载全部参数。检查启动日志中是否有不支持的代理类型或字段提示；如果使用已停止维护的 Clash for Windows 或 ClashX Meta，先保留原配置，再到客户端下载页选择维护中的客户端验证，常规选型优先考虑 Clash Plus。

通过网络与节点交叉测试缩小范围

同一设备切换到手机热点后恢复，说明原网络的出口、认证、路由或防火墙值得优先检查；但热点与原网络可能采用不同 IP 协议栈，不能仅凭这一结果断定某个运营商限制了节点。保持客户端和配置不变，再比较两个网络的解析结果与错误阶段，才能把网络差异和配置差异分开。

若只有一个节点失败，其他节点使用正常，停止修改全局 DNS 和系统代理，转向该节点的可用性与参数。若所有节点在多个网络都失败，则检查订阅账户和客户端兼容性。自动策略组还可能反复选回异常节点，排查期间先固定单个出站；恢复后再阅读策略组类型与选用场景调整探测逻辑。

订阅失败：分开检查下载、解析与应用

先识别失败发生的阶段

订阅导入并不是一个动作，而是获取链接内容、解析配置、下载关联资源和启用配置的连续过程。更新按钮报错，未必意味着原配置已经失效；有些客户端会保留上一次成功更新的内容。先查看配置卡片的更新时间和当前启用状态，再读错误详情，避免删除唯一可用的旧配置后，连更新订阅的网络路径也一并丢失。

复制订阅链接时，检查是否带入空格、换行、中文标点或聊天软件附加的说明。链接的查询参数可能承担身份认证作用，不能随意删减，也不能公开展示。若提供方要求登录后生成专用订阅，应使用对应入口，而不是账户网页地址。普通网页地址虽然能在浏览器中打开，却不一定返回客户端能够解析的配置。

处理下载失败与更新路径循环

出现请求超时、连接重置或解析失败时，先确认订阅域名是否能正常访问，再检查客户端更新订阅使用的是直连、当前代理还是自定义下载路径。有些网络无法直连订阅服务，但旧节点仍可用，可临时让更新请求通过旧配置完成；反过来，旧代理已经失效时，强制经代理更新就会形成循环，应改回可达的下载路径。

认证失败或拒绝访问通常要回到提供方检查链接状态、账户限制及是否需要重新生成地址。请求过于频繁也可能被暂时限制，连续点击更新不会加快恢复。若日志显示服务器证书相关错误，先核对系统时间与网络登录状态。不要通过全局跳过证书验证来长期维持订阅更新，这会掩盖错误来源并降低连接安全性。

区分配置格式错误与内核兼容问题

下载成功后出现 YAML 解析错误，应查看报错行附近的缩进、冒号和引号。YAML 通常使用空格缩进，复制代码时混入制表符，或将中文冒号写入字段名，都可能使文件无法加载。但错误位置也可能只是解析器停止的位置，真正问题在上一行。先恢复最后可用文件，再在副本中修正，不要直接重写整份订阅。

如果返回内容是登录页面、维护页面或结构化错误信息，它也可能被保存成配置文件，随后触发解析错误。此时应检查响应内容的开头是否符合配置格式，而不是反复调整缩进。对于协议不兼容的问题，要选择提供方标注的 Clash 或 mihomo 适用格式，并确认当前客户端实际使用的内核支持相关字段。

节点列表存在却无法启用配置时，还需检查规则集和代理提供器是否加载成功。配置主体、节点提供器和规则提供器可能来自不同地址，其中任何一项失败都可能影响最终使用。日志若明确提到某个资源名称，应单独追查该资源的路径、访问方式及格式，不能把全部错误归为主订阅链接失效。

保留自定义规则与安全边界

订阅更新通常会覆盖远程管理的字段。端口、局域网开关和自定义规则应优先使用客户端支持的覆写、合并或扩展机制保存，具体执行顺序以客户端说明为准。直接编辑下载后的文件，可能只在本次会话有效。确认一次更新后，再核对自定义规则是否仍然存在，并通过连接记录验证实际命中，而不只是检查文本。

配置中存在远程资源与脚本化扩展时，要确认来源和用途。订阅地址相当于访问凭据，转换服务也可能接触其中的节点信息，不应随意交给来历不明的网站。关于转换必要性与适用格式，可查看订阅转换常见问题；基础导入流程见订阅导入教程。

速度慢：按节点、线路与本机逐层比较

把等待、延迟与吞吐分开记录

网页首次打开等待很久、视频播放中断、文件下载慢，可能来自完全不同的环节。首次等待常与 DNS、握手和规则资源加载有关；持续下载速度则更依赖链路带宽、拥堵和目标服务器限制。节点测速显示的请求耗时不是可用带宽，数值较低的节点也可能在高峰期出现吞吐下降，不能据此直接判断速度异常。

比较时固定设备、目标地址、测试方式和时间窗口，只替换一个变量。先用同一文件或同一业务比较两个节点，再保持节点不变切换网络。测速工具可能消耗较多流量，也可能触发服务端限速，测试前确认账户额度。不要让云盘同步、系统更新与带宽测试同时运行，否则看到的下降可能只是本机资源被分摊。

先判断节点与出口线路

若只有某个节点慢，先看同地区或不同线路节点是否存在相同现象。相同地区不代表相同路由，不同名称也不代表使用独立出口。晚上慢、其他时段恢复，通常值得观察拥堵与服务端负载；全天稳定在某个上限，则还应检查套餐、目标服务、路由器限速及本地接入速率，不能直接归因于客户端。

只有某个站点或下载源慢时，可比较另一节点访问同一资源的情况。部分内容分发网络会根据 DNS 或出口地址分配服务器，换节点后命中不同边缘站点，速度可能明显变化。此时应围绕目标服务调整策略，而不是把所有流量改成全局代理。先确认规则命中，再决定是否为该服务设置单独策略组。

检查本机资源与接入方式

在任务管理器或活动监视器中检查客户端内核、浏览器和安全软件的 CPU 占用。高吞吐、复杂规则与大量并发连接可能增加处理负担；持续开启详细日志也会增加磁盘写入。定位完成后恢复常规日志级别。若 CPU 接近满载而网络利用率不高，应优先排查本机瓶颈，而不是一味寻找所谓更快节点。

无线信号弱、同频干扰、蓝牙共存和路由器性能不足，也会造成波动。条件允许时用有线连接作对照，并暂停其他设备的大流量任务。切换系统代理与 TUN 模式时，要确认应用实际走了同一个节点；若两种模式对应不同规则或 DNS 路径，得到的速度差异不能简单理解为某种接入方式天生更快。

谨慎调整并发、MTU 与自动策略

提高并发连接数不能突破线路本身的带宽，还可能加重服务器连接限制。并发参数应依据当前内核文档和实际应用行为调整，不要照搬其他协议的经验值。若出现小网页正常、大文件卡住，或只有某条隧道异常，可进一步检查路径 MTU；先比较退出其他 VPN 后的结果，再记录原值进行小范围验证。

不建议直接使用网上流传的固定 MTU 数字。不同接入网络与隧道封装的有效载荷不同，盲目降低可能只是暂时绕开问题，也可能带来额外开销。若确定与 TUN 有关，应参考客户端支持的诊断方法检查分片与路由，并保留可以恢复的设置；普通网页偶发慢，并不足以支持修改系统网络栈。

自动测速策略组可能在探测条件变化时切换节点，但已有连接不一定跟随新出站。测试时先固定节点，结束后再恢复自动策略。更完整的分层判断与结果记录见Clash 速度慢的分层排查；测速入口和基础比较方式见节点测速教程。

DNS 问题：检查解析路径与连接地址

从错误信息判断是否需要检查 DNS

日志明确出现域名解析失败、找不到主机或 DNS 查询超时，应检查解析环节；已经连接目标 IP 后才发生认证失败，则不宜优先修改 DNS。部分网站能打开、部分网站一直等待，也可能与解析有关，但目标服务故障、规则误匹配和 IPv6 路径不可达会产生相似现象，需要结合连接记录确认。

系统 DNS、浏览器安全 DNS、客户端内置 DNS 和代理服务器侧解析，可能同时存在。命令行工具得到的地址未必就是浏览器实际使用的地址。先画清请求路径：应用向谁查询，查询是否进入 TUN，客户端是否返回映射地址，最终由哪个出站建立连接。只替换系统 DNS，未必能够改变被浏览器或客户端接管的查询。

理解 fake-ip 与真实地址解析

启用 fake-ip 时，客户端会向应用返回保留地址段中的映射地址，再在后续连接中恢复对应域名。这种结果不等于域名被错误解析，也不应拿该地址直接进行公网连通性测试。关键是返回映射地址后，应用连接是否仍进入同一客户端。如果 DNS 经过代理而连接绕过客户端，就可能出现拿到映射地址却无法访问的现象。

需要局域网发现、使用特殊域名或自行验证解析结果的应用，可能不适合全部采用 fake-ip。应根据具体域名配置过滤例外，避免直接关闭整套 DNS 方案。以下片段展示字段关系，不能替代完整配置；监听地址使用本机回环，端口也必须避开其他服务。采用前先确认客户端覆写机制是否会覆盖这些字段。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

示例中的解析服务仅用于说明语法，不保证在所有网络可达；实际应选择当前网络能够稳定访问且符合自身隐私要求的服务。仅配置监听在本地端口，并不会自动让系统查询进入该端口，还需要客户端的 TUN DNS 接管或其他明确的转发机制。不要为了接管 DNS，随意把服务监听开放到全部网卡。

避免加密 DNS 的启动依赖循环

使用 DoH 等带域名的上游时，客户端可能需要先解析该上游自身的域名。如果这一步又依赖尚未建立的代理或同一上游，就会形成启动循环。应按照内核文档配置可达的引导解析路径，同时检查代理节点服务器域名使用的解析器。字段是否受支持、是否遵循路由规则，都需要以当前内核行为为准。

浏览器开启自定义安全 DNS 后，可能绕过系统解析策略，导致客户端规则与实际连接地址出现差异。排查时先记录原设置，再临时改为跟随系统作对照；若恢复正常，再决定为浏览器单独配置解析方案。企业网络中的内部域名还可能只能由指定 DNS 解析，不能把公共解析器当作所有域名的通用替代。

清理缓存前先确认配置已经修正

修改解析方案后，旧连接、浏览器缓存和系统缓存可能保留原结果。先关闭相关页面或应用连接，再按系统支持的方法刷新缓存。Windows 可执行下面的命令；其他平台的缓存服务与命令随系统环境不同，不应照搬。清缓存只会触发重新查询，不会修复一个仍然不可达的上游，也不会纠正错误的规则。

ipconfig /flushdns

恢复标准是同一域名在预期解析路径下得到合理结果，且实际业务可以稳定连接。规则模式还应核对域名规则是否先于宽泛的 IP 规则命中。关于 GEOIP、GEOSITE 与规则集的关系，可继续阅读规则分流实战，避免用反复更换 DNS 来掩盖规则设计问题。

系统代理不生效：核对端口、应用与 TUN

先区分两种流量接入方式

系统代理只是向遵循系统设置的应用声明代理地址，不会自动接管所有网络请求。某些命令行工具、游戏或自行管理网络的应用不会读取这项设置。TUN 则通过虚拟网卡和路由接收符合条件的流量，覆盖范围通常更广，但也受权限、路由、排除项与系统扩展状态影响。两者都开启，不代表覆盖范围简单相加。

如果浏览器正常而终端失败，先检查终端程序是否支持系统代理或环境变量，不要直接判断客户端失效。反过来，显式指定本地代理的命令可以访问，而所有浏览器失败，通常应检查系统代理是否写入正确网卡、浏览器扩展是否另设代理，以及应用是否缓存了旧设置。先用最简单的路径验证，再逐项恢复其他工具。

端口设置与监听地址

混合端口同时接收 HTTP 与 SOCKS 代理请求，外部控制端口用于管理接口，两者用途不同。把管理端口填入浏览器代理栏，通常不能转发网页流量。设置中看到的端口只是配置意图，是否真正监听还要看启动日志；若端口被占用，内核可能启动失败，或客户端提示需要更换端口。

本机使用时，代理地址通常填写 127.0.0.1，无需开放局域网访问。以下片段只展示本机代理入口，不包含可用节点。修改配置后还要重新加载并核对系统代理中的端口；如果客户端提供独立端口设置，优先在界面修改，避免远程订阅更新后又恢复旧值。

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

定位端口占用与 TUN 路由冲突

Windows 可使用下面的命令查看端口监听及对应进程编号，再到任务管理器确认进程身份。不要看到占用就直接结束未知进程；先退出旧客户端、残留内核或另一个代理工具，再重新启动目标客户端。修改端口后，浏览器、终端环境变量和局域网设备中的地址也要一起更新，否则它们仍会连接旧入口。

netstat -ano | findstr :7890

TUN 开启后全网断开，先关闭 TUN 验证系统代理是否可用，再检查客户端是否具备创建虚拟网卡所需权限。其他 VPN、容器网络和企业安全软件可能占用相近路由或更改接口优先级。每次只保留一套接管默认路由的工具作对照，不要直接删除系统网卡或批量清空路由，避免扩大故障范围。

退出后的恢复与局域网使用

客户端异常退出后，系统可能仍指向一个已经停止的本地代理。先关闭系统手动代理，再确认浏览器恢复直连；若通过自动配置脚本设置了代理，也要检查该入口。正常退出与强制结束进程的清理行为可能不同，恢复后应测试一次完整的开启、关闭流程，确认设置能够随客户端状态正确恢复。

其他设备访问电脑代理时，应填写电脑的局域网地址，而不是手机自己的回环地址。只有确实需要共享时才开启允许局域网连接，并限制在可信网络和必要设备内；管理接口不应顺便对外开放。操作细节与防火墙边界见混合端口与局域网连接设置，本机使用则回到系统代理教程即可。

客户端崩溃：区分界面、内核与配置错误

确认退出的是哪一层

窗口关闭、托盘消失与内核停止不是同一件事。有些客户端关闭窗口后仍在后台运行，有些情况下界面还在但内核已经退出。先检查托盘、系统进程和本地监听端口，再判断是否发生崩溃。界面提示无法连接服务，也可能只是管理接口地址改变或后台服务尚未启动，而不是整个程序损坏。

记录崩溃前最后一次操作：导入配置、更新订阅、开启 TUN、切换网络还是从睡眠恢复。能够稳定复现的触发条件，比单独一张错误截图更有价值。保存客户端日志和系统应用错误记录，注意错误发生的时间是否一致；如果内核先报配置错误，随后界面提示断开，应先修复配置而不是重装界面程序。

保留数据后缩小配置范围

程序启动即退出时，先备份配置目录和自定义覆写，再尝试使用客户端提供的配置停用或重置入口。具体数据目录因应用和系统而异，应从客户端说明或日志位置查找，不要删除名称相近的整个用户目录。若必须手动移动文件，应在客户端与后台服务完全停止后操作，并保留原目录以便恢复。

能进入界面时，先停用最近新增的规则提供器、脚本扩展或复杂覆写，再逐项恢复。最小化配置的目的是确定哪一段引发故障，不是把订阅凭据重新手工拼装。若删除某个字段后恢复，还要检查该字段是否受当前内核支持、是否被重复合并，以及关联文件路径是否有效，不能直接认定它是客户端缺陷。

检查系统兼容、权限与资源

安装包架构必须匹配设备。Windows、macOS 与 Linux 的不同架构不能仅根据文件名相似就混用；Linux 还要核对发行版的软件包类型及桌面运行依赖。程序无法启动时，先看系统提示的具体原因。优先使用下载页中对应平台的客户端入口，常规使用首推 Clash Plus，不要从不明来源替换可执行文件。

macOS 可能需要在系统设置中明确授权网络相关组件；Windows 的 TUN 服务可能需要管理员许可。授权失败通常应沿系统提示处理，而不是长期关闭系统保护。安全软件隔离文件时，查看告警对象与原因，确认下载来源和应用身份后再处理；不要把整个磁盘或用户目录加入排除列表来绕过单个程序的启动问题。

长时间运行后崩溃，还应观察内存、连接数量与磁盘空间。大量连接、异常重试、过细日志或失控的资源更新，都可能增加资源消耗。先降低不必要的日志级别，关闭重复任务，再观察是否恢复稳定。缓存清理应使用客户端支持的入口；直接删除数据库或配置缓存前必须退出内核，避免写入中断造成新的损坏。

更新、回退与提交有效记录

更新后才出现问题时，先确认是否同时迁移了配置格式、启用了新功能或改变了默认 DNS。保留当前数据备份，再用独立配置测试维护中的客户端，不要让两个程序同时启用系统代理和 TUN。若确需回退，应使用可信渠道提供且兼容现有配置的安装包，同时防止新格式数据被旧程序直接覆盖。

提交问题时，附上系统类型、设备架构、客户端名称、可复现步骤与脱敏日志。若界面能够查看真实版本，可一并提供，但不要凭下载文件名猜测。日志中应保留错误类型和调用阶段，删除节点认证信息；截断到只剩“失败”二字会失去定位价值。配置同步与备份方式可参考多设备配置同步对比。

恢复后的验证不止是窗口重新打开。还要确认内核启动、端口监听、订阅更新与一次实际访问均正常，再重新开启之前停用的功能。若每次恢复某个扩展就复现故障，先保持该扩展关闭，单独查阅其兼容要求；无需为了一个可隔离的问题，反复清空整套客户端数据。

移动端专项：VPN 权限、后台与网络切换

确认系统接管状态与其他 VPN

手机上看到已连接图标，只能说明系统中的 VPN 通道处于某种活动状态，不代表订阅节点、DNS 和目标服务都可用。先打开客户端确认当前配置、选中策略与日志，再用同一个网页验证。若状态图标来自另一款 VPN、广告过滤器或企业网络工具，应先确认实际占用通道的是哪个应用，避免把别的连接当作 Clash 已经生效。

Android 客户端通常通过系统 VPN 接口接管流量，首次连接需要用户授权。其他使用同类接口的应用可能与其争用通道；某些设备还设置了始终开启 VPN 或阻止未经过 VPN 的连接。原客户端被停止后，这些限制可能使全机断网。排查时先检查系统 VPN 设置，记录原状态，再决定临时关闭哪一项限制。

处理 Android 后台中断与应用分流

锁屏后断开、切到其他应用后恢复慢，先查看客户端是否被电池优化或后台限制终止。按系统提供的方式允许必要的后台运行和通知，再观察是否改善，不应为了一个网络应用批量放开所有后台权限。厂商系统的选项名称不同，判断依据是进程是否仍在、VPN 是否重建，以及日志中是否存在重新启动记录。

开启按应用代理或绕过应用后，要区分包含名单与排除名单。一个应用没有进入代理，可能只是被分流设置排除，并非规则失效。修改名单后通常需要重新建立连接，有些应用还会保留原网络会话。先彻底退出目标应用，再重连验证。工作资料、应用分身与主空间可能属于不同用户环境，不能假定一份名单覆盖所有副本。

Wi-Fi 正常、蜂窝网络失败时，检查客户端是否获得移动数据权限、是否启用了流量节省，以及当前网络是否有可用的 IPv4 或 IPv6 路径。不要照搬电脑上的监听地址与系统代理方式；手机本机的 VPN 接入和连接电脑共享代理是两条不同路径。跨路径测试时，应先关闭另一条，避免流量绕行导致判断混乱。

检查 iOS 网络扩展与连接恢复

iOS 使用 Clash Plus 时，先确认系统已经允许添加 VPN 配置，并检查当前启用的配置是否属于该客户端。若同时存在单位管理的网络配置或另一套按需连接设置，网络切换时可能触发不同连接。不要随意删除受管理设备中的描述文件，应先向相应管理方确认可调整范围，再做单独连接测试。

从无线网络切换到蜂窝网络后，旧连接可能已经失效，但应用仍保留原会话。先停止并重新建立客户端连接，再退出并重开目标应用，比较能否恢复。若只有休眠后出现异常，记录切换前后的网络类型、客户端状态与报错时间，不要仅以一次重连成功就判定节点正常。客户端入口见iOS 下载说明。

区分局域网共享与移动端本机代理

手机通过电脑共享代理时，必须连接到可互通的网络，并填写电脑当前的局域网地址与代理端口。电脑休眠、地址变化、访客网络隔离或防火墙阻挡，都会让手机突然无法访问。手机上的 127.0.0.1 指向手机自身，不能代表电脑；同名无线网络也不一定允许设备相互通信，应先确认网络隔离策略。

扫码或复制订阅到手机时，还应确认得到的是完整链接，而不是网页分享地址。手机和电脑若使用不同内核能力，同一订阅也可能需要选择对应格式；不要通过反复手工删字段维持两份配置。更新后分别核对自定义规则、应用分流与 DNS 行为，避免把同步成功误认为所有平台设置已经一致。

移动端恢复标准应包含前台访问、短暂锁屏后访问以及一次网络切换后的重连。测试期间只保留必要的代理功能，稳定后再恢复自动策略和应用分流。仍有问题时，按本页前面的订阅、DNS 与节点章节继续排查；一般使用疑问可查看常见问题，首次完整配置则按教程主线重新核对。