Clash 全平台安装配置手册：Windows、macOS、Android、iOS、Linux

准备工作：架构、订阅与接管方式

先区分客户端、内核与配置文件

客户端负责界面、订阅管理、系统集成和权限申请；mihomo 内核负责解析配置、建立连接、执行规则。相似的界面不代表相同的配置能力，同样叫 Clash 配置，也可能包含特定内核才支持的字段。导入前应确认订阅提供方说明的兼容目标。ClashX 是 macOS 生态中的客户端名称，不是 Windows、手机和 Linux 安装包的通用名称，不能把一个平台的程序复制到另一平台运行。

完整配置通常包含节点或节点提供器、策略组、规则与 DNS 设置。订阅地址则是返回这些内容的入口，不能只凭地址后缀判断格式。浏览器能打开链接，也不代表返回的是可解析的 YAML；登录页面、流量到期提示和网页错误内容都会导致导入失败。订阅含访问凭据，应视为私密数据，不要贴到公开评论、在线转换页面或故障截图中。

确认系统架构与已有网络设置

Windows 在“设置 → 系统 → 系统信息”查看系统类型；macOS 在“关于本机”查看芯片；Linux 执行 uname -m。Apple Silicon 与 Intel 需要分别选择对应包，Linux 的包格式还要与发行版匹配。Android 安装包也有 ARM64、ARM 等架构差异，优先按下载页说明选择。文件能下载成功不等于适合当前设备，安装错误应先核对架构，再考虑重新下载。

开始前记下原有代理、VPN、DNS 与网络过滤软件设置。公司设备可能由管理策略强制指定代理或证书，遇到权限限制应联系设备管理员，不要反复覆盖系统配置。初次排查时只运行一个负责接管流量的客户端，避免多个程序同时修改系统代理或默认路由。原有企业 VPN 有工作用途时，先确认是否允许并存，再决定测试顺序。

方式	作用范围	起步建议
系统代理	读取系统代理设置的应用	先用浏览器验证
TUN	经虚拟网卡与路由接管的流量	有需要再启用，检查权限
应用内代理	手动填写代理地址的应用	确认协议与监听端口
移动端 VPN 接口	按系统授权进入网络扩展的流量	留意其他 VPN 的占用

建立可重复的初次连接流程

先安装客户端并完成一次正常启动，再导入订阅，确认配置被选中且策略组有可用成员，然后选择规则模式、指定一个节点，最后开启系统代理或移动端连接。每完成一步就观察日志与界面，不要一次性改端口、DNS、路由和规则。若首次测试失败，保持配置不变，先判断问题发生在订阅获取、内核启动、入口监听还是出站连接阶段。

测试至少分为两个目标：一个预期直连的网站，一个需要代理的网站。浏览器页面可作为入口，但仍要在连接列表确认实际命中的策略。缓存页面、连接复用与浏览器安全 DNS 都可能让一次打开结果产生误导。完成基线测试后再开启自动更新、开机启动与 TUN，后续异常才有明确的回退点。迁移设备时同时保留原配置副本与自定义规则记录。

Windows：安装、系统代理与 TUN

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

Windows 优先选择 Clash Plus。需要比较桌面功能时，可依次查看 Clash Verge Rev、FlClash 与 Clash Nyanpasu；Clash for Windows 属于已停止维护的归档客户端，不建议作为新安装的起点。到Windows 安装包选择与系统类型相符的文件，保存配置后再替换旧客户端，避免迁移时丢失订阅与本地规则。

运行安装程序时阅读权限提示，完成后先以普通用户身份启动。客户端界面能打开，但内核可能因端口占用、配置错误或安全策略而未运行，应查看内核日志确认。需要服务组件或虚拟网卡时，再通过客户端提供的安装入口申请管理员权限，不必把所有日常操作都放在管理员会话中。受组织管理的设备可能禁止安装网络服务，这与订阅内容无关。

导入订阅后检查选中状态

在“配置”“订阅”或相近入口添加远程配置，粘贴完整链接并更新。出现配置卡片后，将其设为当前配置，再进入策略组选择一个明确的节点。仅新增订阅但未切换当前配置，实际运行的仍可能是旧文件。策略组列表为空时，先查看订阅响应与解析日志，不要通过反复开关系统代理尝试修复配置内容。

从 Clash for Windows 迁移时，可保留订阅地址与自行添加的规则，但不要直接覆盖新客户端的全部应用数据目录。旧版界面偏好、服务路径和扩展脚本未必可移植。先在新客户端导入原始订阅，验证基础连接，再逐项恢复覆写内容。涉及旧脚本语法或内核专有字段时，以新客户端的配置检查结果为准。

系统代理正常后再处理应用差异

先保持规则模式，打开客户端的系统代理开关。在 Windows“设置 → 网络和 Internet → 代理”核对手动代理地址与端口，通常应指向本机监听地址。浏览器能够访问后，再测试开发工具或其他应用。部分应用使用独立代理设置，部分后台服务读取 WinHTTP 配置，不会因为桌面系统代理开启就自动改变路线。

命令行可显式指定入口进行验证。下面命令只测试本机 HTTP 代理链路，目标站点是否走节点仍由配置规则决定。PowerShell 中使用 curl.exe 可以避免旧环境下同名命令别名造成参数差异；若客户端实际端口不是 7890，命令里的端口也应同步修改。

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

若提示连接被拒绝，优先检查客户端是否启动、端口是否一致、监听是否成功。若已连接本机但远端超时，再检查策略组、节点与 DNS。UWP 应用在部分场景存在回环限制，可查看客户端是否提供对应管理入口；不要给全部应用批量放行作为常规处理。确实需要的应用再单独设置，并记录改动以便恢复。

TUN、自动启动与退出后的恢复

游戏、独立网络栈或不读取系统代理的应用，可考虑 TUN。先按客户端提示安装服务，再开启增强模式，观察虚拟网卡和路由是否创建成功。TUN 已能接管目标应用时，不必为了追求更多开关而重复叠加其他代理工具。若开启后本地打印、局域网服务或企业网络异常，应检查私有网段排除规则与现有 VPN 路由。

开机自启与内核启动是两件事。登录后界面出现，不表示服务已就绪；服务就绪，也不表示订阅已加载或代理开关已恢复。重启后按此顺序逐项检查。退出客户端前先关闭系统代理；若程序异常结束后网页失联，回到系统代理页清除残留设置，再测试直连。更多启动问题可查开机自启问答，客户端取舍见Windows 横向评测。

macOS：芯片架构、网络权限与菜单栏

按芯片选择客户端并迁移配置

macOS 首推 Clash Plus，也可选择 Clash Verge Rev 或 FlClash。ClashX Meta 已停止维护，归档包适用于有明确兼容需求的旧环境，不适合作为新功能支持的依据。在“关于本机”确认是 Apple 芯片还是 Intel，再进入macOS 下载区域选择对应架构。不要仅按机型年份判断，同一年出售的设备可能采用不同芯片。

打开磁盘映像后，把应用拖入“应用程序”，再从该目录启动，避免一直运行映像中的副本。替换旧程序前正常退出旧客户端；若提示文件正在使用，还应检查菜单栏进程是否结束。首次打开遇到系统安全提示，应先确认文件来源，再按系统提供的审核流程处理，不要通过关闭整机安全机制解决单个应用的启动问题。

导入订阅与理解菜单栏状态

在客户端配置入口添加订阅或导入本地 YAML。保存后选择该配置，并检查策略组中当前使用的成员。菜单栏中的规则、全局、直连通常表示路由模式，而节点名称属于策略组选择，两者不能互相替代。选择规则模式后，仍需确认规则引用的策略组有正确成员，否则界面看似正常，实际流量可能进入未准备好的出站路径。

从 ClashX 或 ClashX Meta 转移到其他客户端时，先导入订阅源，再迁移自己维护的规则片段。菜单栏偏好、快捷键、辅助服务与本地脚本属于应用层，不宜整目录覆盖。远程配置更新也可能覆盖直接编辑的内容，长期维护的自定义规则应放在客户端支持的覆写或合并入口，并核对最终生效配置，而不是只查看编辑窗口。

系统代理、辅助服务与网络位置

开启系统代理后，可在“系统设置 → 网络 → 当前网络服务 → 详细信息 → 代理”核对 HTTP 与 HTTPS 代理。系统不同版本的名称可能略有调整，重点是当前正在使用的 Wi-Fi 或以太网服务，而非列表中的闲置网络。更换网卡、接入扩展坞或切换网络位置后，应重新验证代理是否仍作用于当前服务。

可在终端查看系统代理状态，输出中的启用标志、服务器与端口应和客户端一致。此命令只读取状态，不会修改系统设置。若显示代理已开但浏览器仍未出现连接记录，检查浏览器是否安装独立代理扩展，或者是否存在绕过本地与指定域名的例外列表。

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

首次启用 TUN 或网络辅助服务时，系统可能要求授权并输入本机管理员密码。应在客户端发起操作后核对系统提示，确认请求对应当前应用。若服务安装失败，先检查应用路径、系统权限和日志，不要把同一服务反复安装到多个副本下。菜单栏图标存在不等于辅助服务已运行，连接页面和启动日志才是进一步判断的依据。

睡眠恢复、终端工具与本地开发

Mac 从睡眠唤醒或从 Wi-Fi 切到热点后，旧连接可能失效。先尝试重新加载配置或重新建立连接，再判断是否需要更换节点。只有 TUN 开启时异常，可暂时退回系统代理验证，区分订阅问题与虚拟网卡路由问题。若关闭客户端后仍不能直连，应在当前网络服务中检查是否遗留手动代理，同时检查其他 VPN 是否仍处于连接状态。

终端工具通常不会完整继承图形界面的系统代理。需要时在当前终端设置环境变量，先临时测试，再决定是否写入 shell 配置。配置 NO_PROXY 时可加入本机开发地址，防止本地服务绕到代理入口；不要把不理解的大范围域名加入绕过列表。Git、包管理器与容器还可能各有独立设置，逐个检查比反复修改系统开关更有效。

Android：安装授权、VPN 接口与后台保活

选择架构并保留应用数据

Android 首推 Clash Plus，其他可选项依次为 Clash Meta for Android、FlClash、Surfboard。不同客户端对订阅格式、规则语法和扩展字段的支持不完全相同，尤其不能把针对 mihomo 的复杂配置默认视为所有客户端通用。先查看Android 安装包说明，确认架构与配置兼容性，再下载安装。

安装本地安装包时，系统可能要求给浏览器或文件管理器授予安装未知应用的权限，应仅对实际使用的来源临时授权。出现解析失败，先核对文件是否完整下载、架构是否匹配、系统是否满足要求。更新时若提示签名不一致，不要立即卸载；先导出能够导出的配置与本地规则，确认现有应用来源，再决定是否迁移，卸载通常会同时移除应用数据。

订阅导入与首次 VPN 授权

将订阅地址粘贴到配置入口，完成下载后选择该配置。有的客户端先新增资料，再单独点击更新，只有标题出现并不代表节点已经获取。若导入失败，可先用当前网络确认订阅服务是否可达；若订阅地址本身需要代理访问，应采用可信的备用网络或订阅提供方给出的导入方式，不要把私密链接发到公开转换服务。

选择策略组与节点后启动连接，Android 会显示 VPN 授权提示。确认请求来自刚安装的客户端后允许，随后观察系统 VPN 标识和客户端连接状态。该接口用于把流量交给本地客户端处理，并不意味着所有流量一定经过远端节点；规则仍可让部分连接直连。启动失败时应先看授权是否被拒绝，再检查其他 VPN、网络过滤器或防火墙应用是否占用接口。

按应用分流与系统网络设置

需要仅接管部分应用时，使用客户端的应用访问控制，先确认当前模式是“仅选中应用”还是“排除选中应用”。两种模式含义相反，列表相同也会得到完全不同的结果。修改后通常需要重建 VPN 连接，已建立的连接未必立即改道。测试时关闭目标应用再重新打开，并结合连接记录确认流量是否进入客户端。

Android 的私人 DNS、浏览器安全 DNS 与客户端 DNS 可能同时存在。域名解析异常时，先记录原设置，再逐一测试，不要同时改多个层级。若按 IP 建立的连接正常、域名访问失败，可重点检查解析链路；若所有请求都超时，还需要检查节点和路由，不能仅凭“网页打不开”就认定是 DNS 问题。企业工作资料中的应用也可能受独立策略约束。

锁屏断连、网络切换与电池策略

前台正常而锁屏后断连，优先检查电池优化、后台活动和自动启动权限。不同厂商将入口放在电池、应用管理或安全中心，按功能寻找即可。先允许客户端必要的后台运行，再进行一次锁屏测试；不必关闭所有应用的省电限制。常驻通知在部分系统上承担前台服务提示作用，隐藏通知后若连接不稳定，应恢复默认行为再比较。

从 Wi-Fi 切换到移动数据后，原有连接可能需要重建。客户端显示已连接时，也要观察新请求能否建立，而不是只看图标。可先停止再启动连接，随后测试同一目标；只有某个网络失败时，重点比较该网络的 DNS、IPv6 与接入限制。不要把节点列表中的一次测试结果当作所有应用可用性的保证。

同一台手机一般不能让多个普通 VPN 应用同时接管同一用户的网络。与广告过滤、防火墙或企业 VPN 冲突时，应按用途选择接管方，而不是轮流快速点击开关。需要让电视使用手机或电脑代理，则要额外检查热点隔离、监听地址与防火墙；开启手机 VPN 本身不保证热点客户端的流量也被代理。局域网共享步骤可继续阅读混合端口与局域网连接说明。

iOS：Clash Plus、配置导入与网络扩展

从商店安装并核对配置来源

iPhone 与 iPad 首推 Clash Plus。可从App Store 的 Clash Plus 页面安装，产品信息见官网 clashplus.io；本站的iOS 下载入口也汇总了相同去向。安装后先打开客户端，阅读系统权限提示，再准备导入订阅。不要将 Apple 账户信息或设备密码填写到订阅服务的网页表单中。

iOS 客户端与桌面端的界面组织、网络扩展能力和配置兼容范围可能不同。已有桌面订阅时，先确认提供方是否说明支持当前客户端，尤其留意脚本、外部资源和内核专有字段。配置名称相同不意味着解析实现完全相同。若服务提供多个订阅格式，应选择明确匹配的格式，而不是逐个尝试未知转换链接。

完成导入、选择策略与连接授权

在客户端的配置或订阅入口新增地址，更新后选中对应配置，再进入策略组查看成员。先手动选择一个节点进行基线测试，成功后再使用自动选择等策略。自动策略依赖测试地址、间隔与候选成员，单次测试结果只说明测试目标的响应，不能保证视频、工作系统与其他服务都具备相同可用性。

首次启动连接时，iOS 会请求添加 VPN 配置，按系统提示完成设备验证。授权成功后，还要回到客户端确认连接实际启动。这个 VPN 配置用于本地网络扩展接管，不等同于订阅账户，也不会代替节点信息。若误删了系统中的 VPN 配置，通常需要从客户端再次发起授权，而不是重新购买订阅或重置全部网络设置。

测试时先使用 Safari 打开一个预期直连目标，再打开需要代理的目标。随后查看客户端能够提供的连接或日志信息，确认规则命中是否符合预期。浏览器已有页面可能来自缓存，应用也可能复用旧连接；切换策略后应重新发起请求。只看系统状态栏标识，无法判断当前目标是否真的经过所选节点。

理解系统限制与连接冲突

iOS 的连接通常通过网络扩展实现，不需要照搬桌面端“系统代理加 TUN”的双开关流程。不同客户端可能使用不同术语，应以当前界面说明为准。手动给 Wi-Fi 填写 HTTP 代理是另一条路径，只影响适用该设置的流量，也不适合作为移动数据连接的替代。基础测试阶段应保留一条清晰的接管路径，避免手动 Wi-Fi 代理与网络扩展叠加。

如果设备已有其他 VPN、内容过滤或组织管理配置，连接可能被替换、阻止或在网络变化后恢复为另一套设置。在系统“设置”中搜索 VPN，核对当前连接所属应用。组织管理设备应先询问管理员，不要直接删除工作配置。专用代理类系统功能、浏览器隐私功能与应用内网络设置也可能改变访问路径，排错时需要分别记录其状态。

网络切换、更新与耗电判断

从家庭 Wi-Fi 切换到蜂窝网络后，先观察新请求是否成功，再决定是否重建连接。若只有酒店或公共 Wi-Fi 失败，可能需要先完成该网络的登录认证；此时暂时断开客户端，完成网络准入，再重新连接测试。若公共网络认证页面仍打不开，应先恢复系统默认网络设置中的相关手动代理项，而不是不断切换订阅节点。

订阅更新应在稳定网络下执行，完成后确认当前策略组仍引用有效成员。节点被删除或改名时，原先手动选择的成员可能失效，需要重新选择。更新失败不必立刻删除可用旧配置；保留当前连接，再检查返回格式与服务状态。详细流程见订阅更新失败逐项自查，其中链接有效性与 YAML 检查同样适用于移动端。

耗电不能仅凭 VPN 标识持续显示来判断。应比较相近使用场景下的系统电池记录，并检查是否存在高频连接失败、过短测试间隔或大量重复日志。先恢复客户端默认测试频率，关闭不需要的详细日志，再观察。局域网设备发现异常时，也要检查本地网段分流与应用所需权限，不要为了访问一台打印机把全部连接长期切成全局代理。

Linux：桌面客户端与 systemd 运行

桌面安装先核对包格式与架构

Linux 桌面推荐 Clash Verge Rev，也可选择 FlClash。在Linux 下载区域按发行版选择包，Debian、Ubuntu 系通常使用 DEB，采用 RPM 的发行版选择对应格式。先执行 uname -m 判断架构，再核对下载页实际提供的文件。不要把软件包格式与处理器架构混为一谈，也不要把不匹配的桌面包强制安装到服务器。

优先使用发行版包管理器安装，以便处理依赖与后续卸载。启动后导入订阅、选择当前配置和策略组，再开启系统代理。GNOME、KDE 与终端应用读取代理的方式不同，桌面浏览器能连接不代表命令行已经配置。需要 TUN 时按客户端提示设置服务与权限，不应长期用 root 身份运行整个图形界面。缺少图形组件的服务器应直接采用内核运行方式。

无界面运行先手动验证配置

服务器或路由器用户可在内核下载区域选择匹配架构的 mihomo。解压后将实际可执行文件安装为 /usr/local/bin/mihomo，并准备独立配置目录。以下步骤假定该文件已经就位；不要把压缩包直接复制到可执行路径。配置中使用相对路径的规则集或节点提供器时，还要确保其资源位于正确工作目录。

先把已有的完整配置保存为 /etc/mihomo/config.yaml，限制读取权限，再执行配置测试。测试通过后以前台方式启动一次，观察监听、DNS 和出站日志。默认保留本机监听，确认功能正常再考虑其他设备访问。仅运行内核不会自动替终端、浏览器和系统服务设置代理，这也是服务器“进程正常但请求仍直连”的常见原因。

sudo install -d -m 700 /etc/mihomo
sudo chmod 600 /etc/mihomo/config.yaml
sudo /usr/local/bin/mihomo -t -d /etc/mihomo
sudo /usr/local/bin/mihomo -d /etc/mihomo

使用独立用户交给 systemd 管理

前台验证后先停止进程，再配置服务，避免同一端口被两个实例占用。下面示例适用于支持 systemd、且采用相应用户管理命令的发行版，只提供本机代理服务，不包含 TUN。建立专用用户并把目录所有权交给该用户；配置目录需要可写时，也应限于该服务用户。其他发行版应使用等效的系统账户创建方式。

sudo useradd --system --home-dir /etc/mihomo --shell /usr/sbin/nologin mihomo
sudo chown -R mihomo:mihomo /etc/mihomo

将以下内容保存到 /etc/systemd/system/mihomo.service。服务使用固定配置目录，进程失败后重启，并等待网络目标。网络目标就绪不保证订阅服务器一定可达，远程资源仍需独立检查。示例刻意不授予网络管理能力；配置若启用了 TUN，应先关闭，或按部署环境另行设计最小权限。

[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
Restart=on-failure
RestartSec=5
UMask=0077
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

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

验证监听、环境变量与访问边界

用 ss -lntp 核对 7890 是否监听，再显式指定代理测试请求。如果服务启动后立即退出，先运行配置测试，再看日志中的路径权限与端口错误。若服务用户不能读取配置，不应通过放宽到所有用户可读来处理，应修正所有权与目录权限。配置更新后先测试，再执行 sudo systemctl restart mihomo，避免让语法错误中断现有服务。

curl -I --proxy http://127.0.0.1:7890 https://example.com
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

环境变量仅对当前 shell 及其子进程生效，不会自动传给已经运行的 systemd 服务。容器中的 127.0.0.1 指向容器自身，也不能直接当作宿主机地址。需要跨容器或局域网访问时，应明确监听接口、访问网段与防火墙规则。外部控制接口不要直接暴露到公网，远程管理可采用受保护的管理通道。完整部署思路见Linux 桌面与无界面运行说明。

配置常见问题：端口、规则、DNS 与恢复

混合端口与局域网监听

mixed-port 在同一端口接收 HTTP 与 SOCKS 代理请求，7890 是常用默认值，不是无法修改的固定要求。更改端口后，系统代理、终端环境变量、应用内设置与局域网设备都要同步。以下是现有配置的基础参数片段，不包含节点与策略组，不能单独替代完整订阅。客户端若使用配置覆写，应在对应入口修改，并核对运行时最终值。

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

只供本机使用时保持局域网连接关闭。需要给手机或电视共享时，再启用局域网访问并确认监听地址、防火墙和设备隔离设置。另一台设备应填写电脑的局域网地址，不是 127.0.0.1。只向可信网段放行，避免监听入口可被外部网络访问。allow-lan 与控制面板接口是不同配置，开放代理端口不等于应同时开放控制接口。

规则顺序、覆写与策略引用

规则通常按从上到下的顺序匹配，先命中的规则决定去向。具体域名规则应放在兜底规则之前，MATCH 一般置于末尾。下面片段假定完整配置中已经存在名为 Proxy 的策略组；大小写和名称必须一致。加入规则后要重新加载配置，并查看新连接的命中记录，已有连接可能继续沿用旧策略。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,adservice,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

订阅更新后规则消失，通常是直接编辑了远程配置文件。应改用客户端支持的覆写或合并机制，同时确认规则插入位置。YAML 缩进使用空格，不要混入制表符；包含冒号等特殊内容的字符串要正确引用。报错行未必是起因所在，上一行遗漏列表符号或层级也会影响解析。规则语法与策略引用都通过检查后，才进入网络排错阶段。

表现	先检查	再检查
订阅无法导入	链接响应与配置格式	缩进、字段与内核兼容
本机入口拒绝连接	进程与端口监听	端口冲突、服务权限
部分域名失败	命中规则与 DNS	节点、应用独立设置
TUN 开启后断网	权限、网卡与路由	DNS 接管、其他 VPN

DNS 与证书错误分开处理

DNS 决定域名如何解析，路由规则决定连接如何出站，两者有关但不能互相替代。出现部分域名异常时，应结合日志查看解析失败、规则命中与连接建立过程。fake-ip 模式会使用合成地址参与流量识别，不能仅因解析结果不同于公共 DNS 就判断异常。切换 DNS 模式后还可能存在系统或应用缓存，应重建连接再复测。

HTTPS 证书警告则应优先检查系统时间、目标域名、证书签发方和网络拦截设置，不要把“忽略证书错误”作为恢复步骤。若只在某个节点出现，停止使用该节点并换可信路径测试；若直连也出现，检查设备与当前网络。具体分支见HTTPS 证书错误处理，证书问题不应通过反复更换本机端口掩盖。

日志收集与回退顺序

排错时记录系统、客户端名称、当前模式、接管方式和错误发生时间，再保留对应时间段日志。日志可能包含域名、订阅地址和账户信息，分享前应删除敏感内容。先复现一次，再逐项改变变量；暂时关闭 TUN、保留系统代理测试，可以区分路由接管与节点连接问题，显式代理请求则能进一步确认本机入口。

恢复直连时，先关闭系统代理与 TUN，再正常退出客户端，最后核对系统中是否残留代理、VPN 或手动 DNS。不要一开始就重置全部网络，否则会丢失故障线索与工作网络配置。仍有疑问可查订阅相关问答；若只是希望重新完成一次连接，回到快速上手教程按主线执行即可。