V2Ray 完整手册
从安装到路由分流

第一阶段：理解客户端、内核与连接链路

把一次代理连接拆成几个独立环节：应用产生请求，客户端提供本地入口，内核读取配置并执行路由，选中的服务器负责后续转发。图形界面负责组织这些设置，并不等于连接本身。窗口能够打开，只能证明界面启动成功；订阅能够更新，只能证明取得了配置；目标页面能够正常访问，才说明这次请求经过的链路可以工作。分清这些边界，排错时才能找到应当检查的位置。

区分 Project V、V2Fly 与 Xray

V2Ray 属于 Project V 代理工具生态。V2Fly 延续相关内核的社区维护，Xray 则是另一个持续发展的内核分支。内核负责协议处理、传输、加密连接、路由和 DNS 等实际工作；v2rayN、v2rayNG、v2flyNG 是管理配置与启动内核的图形客户端。客户端名称相近，不代表内核、功能和配置字段完全一致。阅读某项功能说明时，要同时核对所用客户端、实际内核和服务器要求。

区分协议、传输与连接参数

VMess、VLESS、Trojan 等名称描述协议层，WebSocket、gRPC 等名称描述传输方式，TLS 则涉及加密握手与证书验证。这些选项不是互相替代的按钮，而是需要配套工作的不同层次。服务器要求哪种组合，客户端就必须对应填写。地址和端口正确但路径错误，或者协议正确但服务器名称错误，仍会连接失败。优先使用完整分享链接或订阅，避免仅凭名称手工拼接配置。

节点是客户端保存的一组连接参数，通常包括服务器地址、端口、用户标识、传输方式及相关安全选项。节点名称主要便于识别，名称里写的地区或线路说明并不能直接证明实际出口和性能。订阅则是一种批量取得节点配置的方式。导入订阅不会替用户创建服务，也不保证其中每个节点当前可用。客户端、订阅来源和远端服务是三个需要分别理解的对象。

沿流量路径判断设置作用

应用是否把请求交给客户端，由系统代理、应用自身代理设置或 TUN 接管方式决定。请求进入内核以后，才由路由规则决定直连、代理或阻止。系统代理里的“自动配置”与路由里的“全局”因此不属于同一个维度：前者解决如何进入，后者解决进入以后如何出去。某个应用完全不读取系统代理时，仅更换路由规则通常不会改变该应用的网络路径。

学习时先用一台设备、一个客户端和一个已知可用节点建立最小链路，不要同时运行多套代理工具。测试内容也保持固定：先确认普通网络可用，再测试一个需要代理的目标，最后观察日志与出口。只有知道每一步的预期结果，后续修改 DNS、路由和虚拟网卡时，才能判断新设置是在解决问题，还是引入了另一层故障。

第二阶段：按平台与配置需求选择客户端

桌面平台首选 v2rayN。选择安装包时，先确认操作系统，再确认处理器架构，最后看界面分支与包格式。不要把“客户端支持某个平台”理解成“任意安装包都能在该平台运行”。同一产品的不同构建可能具有不同的依赖、权限要求和界面布局。进入客户端下载页后，按对应平台查看入口，不凭其他教程截图中的文件名猜测当前应该下载哪个包。

桌面版与经典 WPF 版的选择

Windows 下提供 v2rayN 桌面版与经典 WPF 版。桌面版采用新一代跨平台界面，WPF 版保留经典界面。初次配置可从桌面版开始；如果已有成熟的 WPF 操作流程，也可以继续按该界面的菜单组织设置。两种界面可能使用不同的设置入口或本地数据布局，不要一边运行旧实例，一边用新实例修改同一份数据。切换前先退出客户端，再保存原有配置。

macOS 按芯片选择 Apple Silicon 或 Intel 构建，可从系统的“关于本机”确认处理器信息。Linux 先看发行版的软件包体系，再确认是 x64 还是 arm64。deb 与 rpm 是包管理格式，不是性能档位；架构也不能按设备外观判断。能够借助兼容层启动，不等于已经选中了最适合本机的构建。遇到安装失败时，先排除包格式和架构不匹配，再考虑依赖问题。

Android 按内核与架构选择

Android 首选采用 Xray 内核的 v2rayNG；需要 V2Fly 内核配置路线时，再考虑 v2flyNG。两款客户端不是按节点数量或界面颜色区分，而是按内核兼容性与使用习惯选择。较新的主流手机通常选择 arm64，无法确认架构或遇到对应包安装兼容问题时，再查看通用版说明。通用版覆盖范围更广，但不意味着可以绕过操作系统本身的最低要求。

选择内核时，优先满足服务器配置所依赖的功能。不要认为切换到另一内核后，所有协议参数都能原样保留。某些安全选项、传输字段及新功能只在特定内核或构建中可用。如果导入时出现不支持字段、节点被跳过或配置检查失败，应回到订阅提供方说明确认适配范围，而不是连续更换随机选项。客户端更新也不能补齐服务端未配置的能力。

跨设备使用时，尽量统一节点来源与命名方式，但不要直接复制整个应用数据目录。桌面系统代理与 Android 的 VPN 接口接管方式不同，路由和 DNS 的可用选项也可能不同。更稳妥的迁移方法是重新导入订阅，重新选择活动节点，再按设备重新配置代理入口。保存一份选择依据，写清平台、架构和内核需求，后续更新时就不必重复猜测。

第三阶段：完成安装与启动前检查

安装前先确认设备具有可用的普通网络，系统日期、时间和时区正确，并留出配置与日志所需空间。证书验证依赖系统时间，时间明显偏差时，即使节点参数完全正确，也可能在 TLS 握手阶段失败。下载和启动属于本地准备阶段，此时不急于启用 TUN，也不先修改 DNS。把安装、内核启动和网络接管分开处理，能让第一次配置的故障范围保持清晰。

Windows：确认程序目录与运行依赖

按下载页说明运行安装程序，或将压缩包完整解压到具有写入权限的固定目录。不要直接在压缩包预览窗口里启动主程序，也不要只拖出一个可执行文件；相关文件缺失可能导致界面或内核启动失败。首次启动若提示需要运行组件，应按该构建的提示补齐对应架构的依赖。不要把依赖缺失误判为节点不可用，两者发生在完全不同的阶段。

启动后先检查主界面与托盘区，确认没有重复运行的实例。若日志提示本地端口已占用，先退出其他代理客户端，再重新启动。确实需要并行运行时，必须为不同实例设置不同监听端口，并明确哪个实例负责系统代理。初学阶段不建议这样叠加。防火墙提示也应结合程序路径和用途判断，不要为了排错一次性关闭整个系统的防护功能。

macOS 与 Linux：区分安装权限和接管权限

macOS 安装后，将应用放到稳定的位置再启动。遇到系统限制时，先核对下载入口、包类型和系统给出的具体提示，再通过系统允许的方式处理。不要照搬与当前系统无关的绕过命令。普通代理与 TUN 所需权限不同，能够打开界面不代表可以创建虚拟网络接口。先完成普通代理验证，只有确实需要接管更多应用时，再根据客户端提示授权相应能力。

Linux 使用与发行版匹配的包安装方式，留意包管理器输出的依赖错误。桌面客户端应在正常用户会话里运行；不能因为 TUN 需要权限，就默认长期以高权限运行整个桌面程序。启动失败时检查程序日志、目录写入权限及桌面环境条件。系统代理设置通常依赖桌面环境，命令行程序是否使用代理则另有自己的规则，不能用其中一个结果判断另一个。

Android：授权后再验证后台行为

Android 按系统流程完成安装，再打开客户端导入配置。首次建立连接时，系统会请求创建 VPN 连接的授权；这是客户端接管流量的系统接口，并不表示远端节点已经连通。若设备上另有占用同类接口的应用，应先停止它，再启动当前客户端。遇到启动后立刻断开，先看系统授权与应用日志，不要直接删除订阅或更改所有节点参数。

完成一次前台连接后，再观察锁屏或切换应用时是否断开。部分系统会限制后台运行，可按设备设置调整客户端的电池使用与后台权限，但不必对所有应用取消限制。安装阶段的验收目标是：界面正常、配置可以保存、内核能够启动、日志没有持续的本地启动错误。达到这些条件后，继续导入订阅并选择服务器；关于授权的具体点击路径，可结合快速上手教程操作。

第四阶段：导入订阅并管理活动服务器

订阅地址是用于获取配置的入口，通常包含与账户关联的访问参数。仅在客户端的订阅设置中使用，不粘贴到公开讨论、截图或在线转换工具。先确认拿到的是订阅地址还是单条节点分享链接：前者用于订阅分组，后者通常从剪贴板导入。把网页账户地址放进订阅输入框，或者把原生配置文本当作订阅链接，都会造成解析失败。

按四步建立订阅分组

1. 打开 v2rayN 的订阅分组设置，添加分组，填写便于识别的备注和完整订阅地址。
2. 保存分组，再执行更新订阅；首次尝试使用当前能够工作的网络路径获取。
3. 回到服务器列表，确认节点确实归入该分组，并查看更新日志是否存在解析错误。
4. 选择一个节点并设为活动服务器，然后再配置系统代理或启动移动端连接。

示例地址可写成 https://example.com/sub?token=xxxx，其中域名和参数仅用于说明格式，不能提供实际节点。粘贴真实地址时，检查前后空格、换行和字符是否完整，尤其不要漏掉问号后的参数。分组备注只影响本地识别，不影响连接参数。“启用”通常决定该分组是否参与相应操作，具体行为以当前界面说明为准。

理解更新间隔与请求方式

自动更新间隔用于定期获取最新配置，不需要为了追求连接速度设置得很短。更新过于频繁可能触发订阅服务的请求限制，也会增加排错噪声。User-Agent 可能影响服务端返回的配置格式，通常保留客户端默认值；只有订阅提供方明确要求时再修改。如果更新结果是网页、登录页或格式不支持，先检查地址与返回内容类型，不要反复覆盖原来可用的分组。

订阅更新使用直连还是代理，要根据当时可用的网络决定。没有任何可用节点时，强制通过一个不可用的代理下载订阅，会形成无法自救的循环；已有正常代理而订阅地址直连失败时，才考虑切换获取路径。先记录失败发生在连接、认证还是解析阶段。更新失败不一定会删除现有节点，也不代表现有节点必须立即停用。

区分更新配置、测速与实际连接

更新订阅负责获取参数，设为活动服务器负责选择当前使用的出站，两者必须分别完成。节点测速也只说明某种测试在当时的结果。TCP 延迟主要反映建立 TCP 连接的情况，不能覆盖协议认证、TLS、传输和目标访问。真连接测试更接近一次实际请求，但仍受测试目标、超时设置和网络时段影响。不要只按列表里最小的数字决定长期使用的节点。

Android 在分组或订阅管理中添加地址并更新后，同样需要回到列表选择节点，再启动连接。不同客户端的菜单名称可能略有差异，操作顺序仍然是取得配置、选定配置、启动、验证。首次连接可继续阅读v2rayNG 选节点与代理生效验证。需要处理分享链接和原生配置时，参考订阅格式与配置转换说明，避免把不同输入格式混用。

第五阶段：配置代理入口并验证流量

桌面端先使用普通系统代理完成基础连接。选择活动服务器以后，打开客户端的系统代理菜单，按需要选择“自动配置系统代理”。这一步把本地代理入口写入系统设置，遵循该设置的应用才会把请求交给客户端。客户端保持运行是必要条件；如果程序关闭而系统代理仍指向本地端口，浏览器可能出现无法访问，但普通网络本身并没有因此消失。

区分三种系统代理动作

“自动配置系统代理”用于设置代理入口；“清除系统代理”用于移除相应系统设置；“不改变系统代理”表示客户端不主动修改当前系统配置。最后一项不是强制直连，也不表示系统里没有其他程序留下的代理。切换客户端或排查退出后断网时，应打开系统网络设置确认实际状态。不要只看托盘菜单文字，而忽略操作系统里仍然生效的地址与端口。

为不读取系统代理的应用单独配置

某些应用提供独立的 HTTP 或 SOCKS 代理选项，应按客户端显示的监听类型和端口填写。本机地址通常使用 127.0.0.1，端口以当前设置为准，不照抄其他设备的数值。需要用户名、密码的入口也必须对应配置。应用要求填写代理 URL 时，应同时确认协议前缀；只填一个端口，不能让两种代理协议自动互通。

本地监听地址与远端节点地址不要混淆。应用代理指向本机入口，远端服务器参数由客户端内核使用。默认仅本机使用时，保持回环监听；开启允许局域网连接会扩大可访问范围，需要同时考虑认证与防火墙。局域网其他设备填写的应是客户端所在设备的局域网地址，而不是它们各自的回环地址。普通个人使用不必为了测试而扩大监听范围。

用三类证据确认连接

先访问一个普通可达目标，确认基础网络没有中断；再访问需要代理的测试目标，确认页面实际加载；最后结合出口信息和客户端日志判断流量路径。出口地址只能反映发起该请求的应用及当时路由，不能替其他应用作结论。若开启分流，直连目标显示本地网络出口是可能的预期结果，而不是代理一定失效。测试时应先写清目标预期走哪条路径。

若浏览器可用而某个应用失败，优先检查该应用的代理能力、独立设置与连接复用，不要立即更换节点。切换代理后，已建立的长连接可能继续沿用原路径，可关闭相关连接或重启测试应用再试。若全部应用都失败，再回到活动节点、内核日志和本地监听检查。完整的首次验收步骤见连接与代理生效验证。退出客户端后也检查一次系统代理是否恢复，形成完整的使用闭环。

第六阶段：建立路由分流与 DNS 规则

完成普通代理连接后再调整路由。路由规则决定进入内核的请求走代理、直连还是阻止，通常按照规则顺序匹配，具体行为取决于当前内核与规则类型。先使用客户端提供的常规分流方案，再补充少量明确需求，比一开始导入庞大规则集更容易维护。修改前记录当前路由方案、默认出站和规则顺序，保证出现问题时可以恢复。

从具体规则到默认出站

优先处理明确的本地与内部资源，例如局域网地址和内部域名，再处理特定业务域名，最后交给默认出站。需要更精确控制的规则通常放在更宽泛的规则之前。域名规则与 IP 规则匹配的信息不同：请求保留目标域名时可以进行域名匹配；只有目标 IP 时，可能需要解析结果或其他识别机制。不要假设每个请求都同时具备完整域名和地址信息。

下面是 Xray 路由字段的结构示例，仅展示局域网私有地址直连的写法。它不是完整客户端配置，且要求已有标签为 direct 的出站。通过图形界面配置时，应使用客户端提供的对应规则入口；不要把片段直接粘贴到订阅地址或覆盖整个运行配置。客户端可能重新生成配置，持久修改应保存在它支持的位置。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

让 DNS 路径与目标出站相互配合

DNS 把域名转换为地址，但由谁发起解析、解析请求走哪条路径、结果如何参与路由，是三个不同问题。应用自己解析后把 IP 交给代理，和应用把域名交给代理再解析，行为并不相同。只修改操作系统 DNS，不一定能改变内核内部的解析；只修改内核 DNS，也不一定能约束应用自带的解析功能。先确认实际使用哪一层，再决定修改位置。

内部域名通常需要由能够认识它的本地或单位 DNS 解析；代理目标则需要可用且与访问路径相容的解析方式。加密 DNS 还需要考虑解析服务自身的连接路径，以及其域名如何首次解析，避免依赖循环。不要把“更换一个 DNS 地址”当作所有访问问题的通用解法。修改后应清理相关应用缓存或重新建立连接，否则旧结果可能让测试看起来没有变化。

逐条验证规则而不是只看模式名称

每新增一条规则，选择一个应命中的目标和一个不应命中的目标分别测试，并观察日志中的目标与出站。若一个站点的主体可访问但图片或登录失败，检查它依赖的其他域名是否被分到不同路径。需要 IP 区域数据库或域名分类数据的规则，还依赖对应资源可用；资源缺失、名称不匹配或更新时间不同，都可能使预期与实际不一致。

日常使用以可解释、可恢复为目标。为每条自定义规则记录用途与测试目标，失效时先临时停用新增规则。若只是少数应用需要特殊路径，优先选择范围明确的方案，避免把整个网络都改成复杂策略。

第七阶段：按需启用 TUN 与虚拟网络接管

TUN 通过虚拟网络接口接入流量，适合无法直接配置代理、也不遵循系统代理的应用。它改变的是流量进入客户端的方式，不会自动改善远端节点质量，也不会消除线路拥塞。启用之前，必须先确认同一个节点在普通代理模式下能够完成访问。否则一旦出现断网，既无法确认节点状态，也难以区分虚拟接口、系统路由和 DNS 的问题。

先检查权限、冲突与默认设置

桌面端创建虚拟接口或调整系统路由通常需要额外权限，按客户端提示处理，不要仅凭开关已经点亮就认定接管成功。观察日志中是否存在权限不足、接口创建失败或路由写入失败。设备上若同时运行单位网络工具、其他虚拟网卡或另一套流量接管程序，应先确认它们的使用要求；不确定时先停止本次 TUN 测试，避免影响正在使用的工作连接。

首次启用保留客户端推荐的栈、接口和路由参数，不同时更改 MTU、DNS 劫持与嗅探选项。不同构建的 TUN 实现和设置入口可能不同，不能照搬另一内核的字段。系统代理与 TUN 是否同时开启，也应按客户端当前实现判断。测试时应明确哪条入口负责流量，不要靠重复开启多个入口来掩盖某个入口没有工作的事实。

分层验证接管范围

1. 保持已知可用节点，启用 TUN，确认内核持续运行且没有重复报错。
2. 测试浏览器与一个原本不读取系统代理的应用，分别观察实际请求。
3. 访问本地路由器、打印机或内部服务，确认局域网资源仍按预期到达。
4. 检查休眠唤醒、切换网络以及关闭 TUN 后，网络是否能够恢复。

如果外部目标可用而局域网资源失效，优先检查私有地址排除、内部域名解析与路由优先级，不要立即换节点。若域名访问失败而对已知目标的连接表现不同，应检查 DNS 路径，但不能仅凭某个 IP 能访问就断言全部解析正常。若只有特定应用失败，还需确认它使用的传输协议、连接方式与自身网络限制，TUN 不代表远端具备所有转发能力。

谨慎处理 UDP、IPv6 与 MTU

涉及 UDP 的应用，需要入口、内核、所选节点和远端服务共同支持相关流量。IPv6 也需要结合系统地址、默认路由、DNS 结果及客户端接管范围检查。不能因为 IPv4 测试成功就推断另一条地址路径同样正常。应分别观察实际连接目标和日志，确认未被接管的路径是否符合预期，而不是一遇到问题就永久关闭系统的一整类网络能力。

MTU 描述接口允许的报文大小。某些链路中，较大的报文或额外封装可能引发加载停顿，但相似现象也可能来自丢包、DNS 或服务器。只有具备对照证据时再调整，并保存原值。每次只改变一个参数，重复同一目标测试；没有改善就恢复。随意套用一个所谓通用数值，会让后续维护失去可靠基线。

Android 使用系统 VPN 接口接管流量，与桌面界面的 TUN 开关不必逐项对应。重点仍是系统授权、路由范围、DNS 和后台持续运行。没有明确需求时，维持已经验证的简单配置即可。

第八阶段：建立更新、备份与日常维护流程

能够连接以后，把维护重点从“不断改参数”转向“保持可用基线”。记录当前客户端分支、活动节点、路由方案、DNS 方案和是否启用 TUN。记录不需要包含完整凭据，也不需要保存每一次测速结果；它的用途是让下一次故障发生时，能够回答最近改过什么、上一次正常时用了什么。日常更新也应按这个基线进行，而不是同时替换所有组件。

分开管理四类更新

客户端更新影响界面与配置管理；内核更新影响协议与连接行为；订阅更新替换远端节点参数；规则资源更新则可能改变分流结果。它们不是同一个动作。某些构建提供组合更新入口，也应阅读提示，确认实际更新范围。若没有遇到兼容需求，不必在同一时刻升级客户端、切换内核、刷新全部规则，再用一个访问结果判断所有改动是否成功。

执行更新前退出多余实例并保存设置，更新后先用原节点、原路由完成一轮测试，再启用新功能。若出现配置迁移提示，确认旧数据是否仍可恢复。不要让新旧程序同时写入同一个配置目录。需要返回旧环境时，使用与其兼容的备份；不同构建的数据结构可能变化，直接把新配置复制回旧程序，未必可以还原原有行为。

备份以设置为单位，不公开敏感内容

优先使用客户端支持的导出或备份功能，保存分组、路由和必要偏好设置。备份文件可能包含订阅地址、用户标识或服务参数，应放在受控位置，不上传到公开附件区。跨设备迁移时，先恢复订阅与规则，再按目标设备重新配置监听端口、系统代理和 TUN 权限。不要把本机网络接口名称或局域网地址当作所有设备都通用的配置。

用于求助的材料与完整备份应分开。求助时提供现象、平台、使用模式、复现步骤及脱敏日志即可。隐藏地址中的访问参数、节点认证字段和账户信息，也检查截图的备注、二维码与剪贴板区域。删除日志时不用顺带清空全部配置；保留最近一次失败前后的关键段落，比提交大量重复重试信息更有价值。

把日常异常分成可重复的检查项

订阅突然更新失败，先看地址有效性和获取路径；只有一个节点失败，先换同组已知可用节点作对照；所有节点都变慢，先检查本地网络与设备负载；只有某个目标异常，先确认目标自身和分流结果。速度问题按节点、线路与本地设置分层处理，具体可读v2rayN 速度慢的分层排查。避免用反复重装代替定位。

长时间使用后，可清理失效分组、重复的手工节点和已经没有用途的规则，但应先确认活动配置不依赖它们。开机自启与自动配置系统代理也需要配套检查：客户端未能启动时，系统是否仍保留代理入口；网络尚未就绪时，自动更新失败是否会自行重试。休眠唤醒、无线与有线切换、移动热点切换，都值得做一次简单验收。

维护不以日志里完全没有提示为目标，而以连接行为可解释为目标。对持续出现的错误要定位，对正常关闭或临时网络切换产生的记录则结合上下文判断。保留简单、可复现的流程，比收集大量未经验证的优化参数更有用。

第九阶段：按层排错并规划进阶路线

进阶从读懂失败发生在哪里开始，而不是先收集更多开关。建立统一顺序：本地网络、客户端启动、配置解析、本地入口、远端连接、目标访问、路由与 DNS。每次只跨过已经得到证据的一层。浏览器提示超时本身无法说明是证书、解析还是路由；应结合客户端同一时刻的日志，确认请求是否进入、连接到了哪里，以及在哪个阶段停止。

从错误阶段缩小范围

启动时立即出现解析错误，优先检查字段、格式与内核兼容性；本地端口绑定失败，检查重复实例和端口占用；连接远端超时，检查地址、端口、网络路径与服务状态；握手或认证失败，核对协议、用户标识、传输与安全参数。目标返回明确的应用层错误时，也要考虑目标服务自身限制，不要把任何非成功响应都归因于代理客户端。

TLS 问题先核对设备时间，再核对服务器名称、证书覆盖范围及证书链。服务器地址与 TLS 使用的名称可以承担不同角色，但配置必须符合服务端要求。不要为了让错误提示消失而长期关闭证书验证；那会改变连接的验证条件，并没有修复名称或证书配置。具体顺序见TLS 握手与证书报错排查，修改前后都保留同一目标作对照。

为每次实验固定输入与判断标准

测试性能时固定设备、网络、节点和目标，区分连接建立耗时与持续传输速度。小文件加载慢可能与 DNS 或握手有关，持续下载慢则还要考虑线路带宽、拥塞和远端负载。Mux 多路复用也不是始终更快，它改变连接组织方式，效果依赖协议和网络环境。启用前记录原值，测试没有稳定改善就恢复，不凭一次偶然结果保留复杂设置。

从图形设置走向配置阅读

下一步可学习入站、出站、路由和 DNS 的配置结构，先把图形界面里的选项对应到实际含义，再阅读内核支持的字段。客户端生成的运行配置不一定是持久编辑入口，手工修改可能在重启时被覆盖。使用自定义配置功能时，先准备独立测试配置，不要覆盖日常可用方案；所有示例中的出站标签、资源名称和依赖都要逐项确认。

需要在路由器或旁路由部署时，再学习系统转发、策略路由、透明代理和 DNS 回环。那是网络设备层面的新主题，不是把桌面客户端的 TUN 参数原样搬过去。先阅读Xray 路由器与旁路由部署概览理解主路由与旁路由的职责，准备本地恢复入口后再实验，避免改动默认网关后无法访问管理界面。

最终应能完成三件事：用最小配置建立连接，用证据解释每条流量的去向，在异常时恢复到已知可用状态。遇到新的问题，先回到本页对应阶段，而不是从头重装。首次配置可以重新沿快速教程的订阅导入步骤核对；更换设备或客户端时回到下载页重新确认平台与架构。保留清晰边界，进阶配置才有可靠基础。